Updating
Every published @manablox/* package shares one version and is released together: the
CMS packages from the CMS repository and the premium plugins from theirs, at the same
version. What changed in each release is in the
CHANGELOG of the CMS
repository, and the premium plugins’ in their own; read it before an update, since a 0.x release may ask
for a step of its own.
Steps
- Back up the database and the uploads (see Operations). Migrations only go forward; the backup is the way back.
- Update the packages together. Raise every
@manablox/*dependency, plugins included, to the new version and install, for examplepnpm update "@manablox/*" --latest. Never update one package alone. - Let queued jobs finish when the release notes say a job changed, then stop the CMS processes.
- Migrate.
manablox migrate(pnpm migratein a created project) applies the core’s migrations and those of every plugin the config loads. In the Docker setup themigrateservice runs them beforeapi,public-apiandsitestart, so a failed migration stops the update before a request sees it (see Deployment). - Start the processes again and check the admin and one delivery request.
Plugins
manablox plugin list shows the plugins of the instance and whether each is enabled.
manablox plugin install <id> adds one at the instance’s version, uninstall removes its
code and config but keeps its data, and enable / disable switch it without touching
the dependency (see Adding and removing features later). A plugin’s migrations run with the
core’s in step 4.
Frontends
A frontend on @manablox/public-sdk, @manablox/live-preview or @manablox/nuxt updates
those packages to the same version and is deployed again; the live preview only connects
when the admin and the frontend speak the same protocol version.