Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

Content approval workflow and miscellaneous diagrams.


Content workflow
Magnolia ships with a basic "four-eye" editorial content workflow used for page activations. Activations are submitted to a workflow queue for approval. A publisher can examine the workflow item, see what the changes are, who made them and when, and decide whether to publish the modified content to a public instance.

Multi-stage activation
A multi-stage activation setup consists of one author, one public staging and multiple public instances. The extra part in comparison to the standard deployment is the staging instance in between.

This setup is used by companies activating bigger chunks of content and requiring complex review before pushing everything to public.

A disadvantage of the setup is that even minor changes have to go through the complete process and multiple instances. Deactivations have to be handled carefully to make sure content is deactivated from public instances before it is deactivated anywhere else.

The staging instance is configured as a subscriber to the author instance. The public instances are configured as subscribers to the staging instance. The staging instance is a special case of a public instance that displays the Status column in AdminCentral. It has subscribers so it displays the column. However, the activation status of content is only synched forward in the chain, with the public subscribers, not with the author behind it.

The staging instance is not typically accessible to the Internet. Only selected users see the whole site chain and either approve and activate content to the publics or send their workflow comments back to editors for further changes, in which case content is not activated.

Magnolia upgrade process
Overview of steps involved when upgrading Magnolia. The existing installation on a client site may contain custom modules that need to be tested on the new Magnolia version. Content is replicated from production for realistic testing. Test cycle discovers issues that are fixed before production release.

Disaster recovery
Suggested disaster recovery setup:

  1. Run Magnolia software stack on a virtual machine.
  2. Take a snapshot of the whole stack and store the image in disaster recovery store.
  3. Recover the image from DR.


  • Fast: 15 min for 35 GB snapshot, 5 min for 35 GB recovery
  • Preserves current state. Content, templates and resources are in sync when recovered.
  • No labels