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, they are only enabled in the Pages app.
Disabling the workflow in the Pages app may be appropriate for a simple site workflow where there are no separate editor and publisher roles.
There are several options to disable the publishing workflow for the Pages app.
-
Create a DX Core webapp that excludes the Workflow and Personalization modules.
-
Decorate the
pages-appand add a dependency toworkflow-pages. The dependency is necessary so that the light module decoration isn’t overridden again.Click to see the decorations
/light-modules/my-module/decorations/pages-app/apps/pages-app.subApps.yamlbrowser: actions: publish: !override icon: icon-publish $type: jcrCommandAction command: personalizationActivation availability: writePermissionRequired: true rules: isPublishable: $type: jcrPublishableRule publishRecursive: !override icon: icon-publish-incl-sub $type: jcrCommandAction command: personalizationActivation params: recursive: true availability: writePermissionRequired: true rules: isPublishable: $type: jcrPublishableRulelight-modules/my-module/module.yamlversion: 1.0.2 displayName: Shareable dependencies: workflow-pages: version: 6.0/*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.
-
Delete the content of the
workflow-pagesdecoration. This approach doesn’t persist the changes when an instance is upgraded and involves extra configuration steps.Click to see more details
Editing a resource in the Resources files app creates a copy of the recourse in JCR. This isn’t recommended for deployment and maintenance. For productive environments, you should use a decorator, as described above. Resource Files app
-
Go to the Resource Files app.
-
Search for
pages-app. -
Select the file
/workflow-pages/decorations/pages-app/apps/pages-app/pages-app.subApps.yaml. -
Click Edit file.
Make a copy of the contents if you need to restore the four-eye workflow actions later. -
Delete its contents and Save changes.
Configuration app
-
Add the
itemTypesproperty on the/modules/publishing-core/commands/default/publish/publishnode as shown below./modules/publishing-core/commands/default/publish/publish Node name Value ⸬ publish
⸬ publish
⬩ class
info.magnolia.publishing.command.PublicationCommand
⬩ itemTypes
mgnl:contentNode,mgnl:componentVariants
-
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. |