DX Core publishing vs. Swift publication
DX Core publishing
On DX Core, the default Magnolia publication process follows the four-eye workflow in the Pages app. You can disable the workflow in the Pages app to speed up the publishing process if there are no separate editor and publisher roles.
Disable the publishing workflow in the Pages app
Magnolia ships with publishing approval and rejection workflows. By default, it is only enabled in the Pages app.
Disabling the workflow in the Pages app may be appropriate for a simple site workforce where there are no separate editor and publisher roles.
To disable the publishing workflow for the Pages app:
-
Remove the following decoration:
/workflow-pages/decorations/pages-app/apps/pages-app/pages-app.subApps.yaml -
Add the
itemTypesproperty on the/modules/publishing-core/commands/default/publishnode with the following values:mgnl:contentNode,mgnl:componentVariants
|
Removing a decoration? The only way to remove an existing decoration is to either override it with another decoration or remove the whole module with the original decoration. |
Swift publication
|
This module has yet to be released. If you want to learn more, contact us at swift.publishing@magnolia-cms.com for information on availability and technology previews. |
Swift Publication offers a more scalable and efficient method for versioning and publishing content than the default DX Core publishing workflow. It is initially available as a technical preview program for selected customers with the release of Magnolia 6.3. It is delivered as a standalone enterprise module that can be used as a drop-in replacement for DX Core publishing. It requires the provisioning of additional infrastructure (an external version store and a message broker). PaaS users can use it out of the box, while on-premises users must provision the external infrastructure themselves.
Swift Publication stores versions in an external version store, such as S3 or Azure Blob Storage. In production environments, we recommend using a message broker to communicate between author and public instances. When an author publishes changes, the changes are sent to and stored in the external version store. The public instances receive notifications via the message broker and fetch the corresponding version from the version store. For development and testing environments, you can coordinate directly via REST instead of using a message broker.
This architecture provides a couple of advantages over the default DX Core publication process:
-
There is less load on the author instance as versions are maintained externally
-
Better and more flexible scalability regarding the size and frequency of publications, as well as the number of public instances
-
Improved resilience and easier failure recovery
-
Simple transactionality model (eventual consistency amongst public instances)
|
Remember, these benefits come with the added complexity of provisioning, configuring, and maintaining the external version store and message broker. For smaller sites, you might not consider the extra effort justified. |