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.

Packaging

A 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 Package.

Sending

The Sender creates an instance of SenderOperation and passes:

  • the Package upon publication, or

  • the Node upon unpublication

to the instance, together with ReceiverDefinition. The SendOperation executes the transfer to the public instance.

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.

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 locks the node (if it exists) where content is to be published and its parent node. 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

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.

Transport layer

By default Magnolia uses the HTTP transport layer.

Workspaces are publishable by default

The Publishing module makes all workspaces publishable by default.

Disabling publishing workflow in the Pages app

Magnolia ships with publishing approval and rejection workflows. By default, it is only enabled in the Pages app. To disable it for this app, remove the following decoration:

/workflow-pages/decorations/pages-app/apps/pages-app/pages-app.subApps.yaml

Disabling the workflow in the Pages app may be appropriate for a simple site workforce where there are no separate editor and publisher roles.

Feedback