Publishing overview
Publishing handles how content gets published from an author instance to a public instance. Publishing is installed by the Publishing module and extended by the Publishing Transactional module (in DX Core).
Publishing is a refactored version of the former activation. The original Activation module has been broken into multiple submodules, see the module structure. The driving decision was to have a set of maintainable and extensible components. Another reason was to remove deprecated code. The core concepts remain the same. The transport layer is still using the HTTP protocol, but you can now easily plug in any type of transport layer.
The publishing implementation also allows you to define and use custom publishing operations with which you can publish content to something that is not a Magnolia public instance, for example to a custom API or a Content Delivery Network.
How publishing works
On the author instance
Collecting
The PublishingCommand
collects the content that needs to be
(un)published. This content is then sent to an implementation of
Sender
, a component responsible for content packaging.
Large flat content repositories can negatively impact overall performance, particularly search. For this reason, you must organize pages into a folder hierarchy to ensure optimal performance. Also, features that constantly create content (such as messages, tasks, and versions) should be checked regularly to clean up old content. |
On the public instance
Receiving
The PublicationFilter
receives a sender’s request. The request is then sent to the Dispatcher
which decides what to do with the request depending on the request headers. The Dispatcher
extracts the data from the request and creates a ReceiveOperation
responsible for creating/updating/deleting the content.
Ordering of siblings
All siblings of a published node appear in the same order as on the author instance at the time of approving publication. If you are publishing nodes with hundreds of child nodes, you may need to optimize ordering to significantly speed up the process.
This default behavior does not take into account the order at any other point in time (such as the time of creating the published version). |
Other aspects
Authentication and security
Publishing is authenticated using public-key cryptography. The authentication configuration for publishing is stored
in /server/activation
, see Publishing security for more on this.
Locking
Each publishing request executes a lock for either a path or node where content is to be published.
Path-based locking has been introduced as the default way of locking with version 1.2.6 of the Publishing module. Node-based locking is available for compatibility reasons. See the lockManagerMode property on the module page for configuration details.
|
In case two users publish to the same (sub)tree, the locking mechanism will wait with a predefined amount of time and will try to obtain a lock for the operation. If the operation receives the lock, it can proceed with content (un)publishing. If not, publishing is considered unsuccessful and the respective status code is returned to the sender.
Content publishing and content synchronization Always wait with content publishing actions until all content synchronization tasks have been finished. If you attempt to publish a page while the Synchronization module is mid-sync and hasn’t yet synchronized the page’s parent, the publishing process will fail. |
Recursive and non-recursive publishing
Magnolia supports two methods of publishing content:
-
Non-recursive, which publishes only the selected node and its properties.
-
Recursive, which publishes the selected node, its properties and its children.
Transactional publishing
Transactional publishing provides a way to publish content-managed transactions. Content will be:
-
commited
if all receivers respond with success status. -
rollbacked
if at least one of the receivers respond with error status.
The transactional publishing receiver uses mgnlSystem
workspace to
store the backups of the published content. If content is to be
commited, the backup is removed. If content is to be rollbacked, the
backup is restored to the workspace it belongs to.
Workspaces are publishable by default
The Publishing module makes all workspaces publishable by default.
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
itemTypes
property on the/modules/publishing-core/commands/default/publish
node 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. |