Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.
This page contains some background (conceptual) information about publishing, a refactored implementation of activation. As the name suggests, 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 Magnolia EE).
How publishing works
On the author instance
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.
Package consists of properties and files that will be sent to the public instance.
Packages are only used with a publication and are created by the
Packager which adds the properties and
XML exports of the content to a
Sender creates an instance of
SenderOperation and passes:
Packageupon publication, or
to the instance, together with
SendOperation executes the transfer to the public instance.
On the public instance
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.
All siblings of a published node appear in the same order as on the author instance at the time of approving publication. To disable such ordering of sibling nodes, set
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).
Authentication and security
Publishing is authenticated using public-key cryptography. The authentication configuration for publishing is stored in
/server/activation, see Activation security for more on this.
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.1.9 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.
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 provides a way to publish content-managed transactions. Content will be:
commitedif all receivers respond with success status.
rollbackedif 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.
By default Magnolia uses the HTTP transport layer.
Workspaces are publishable by default
In contrast to Activation, the Publishing module makes all workspaces publishable by default.