Publishing module
Collaboration Bundled: Community Edition
Edition |
CE |
License |
|
Issues |
|
Maven site |
|
Latest |
1.3.13 |
The module handles publishing of content from an author instance to a public instance. In DX Core, the functionality of this module is extended by the Publishing Transactional module, which ensures synchronization of content between multiple public instances.
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. |
Module structure
The module (parent) consists of four submodules. All of the submodules are required for the correct functioning of the publishing feature.
artifactID | |
---|---|
|
Parent reactor. |
|
Provides the main functionality. |
|
Handles send operations to the public instance. |
|
Handles receive requests on the public instance. |
|
Generates new publishing keys and provides a publishing monitor. |
Installing with Maven
Bundled modules are automatically installed for you.
If the module is unbundled, add the following to your bundle including your project’s <dependencyManagement>
section and your webapp’s <dependencies>
section.
If the module is unbundled but the version is managed by the parent POM, add the following to your webapp’s <dependencies>
section.
<dependency>
<groupId>info.magnolia.publishing</groupId>
<artifactId>magnolia-publishing-core</artifactId>
<version>1.3.13</version> (1)
</dependency>
1 | Should you need to specify the module version, do it using <version> . |
<dependency>
<groupId>info.magnolia.publishing</groupId>
<artifactId>magnolia-publishing-sender</artifactId>
<version>1.3.13</version> (1)
</dependency>
1 | Should you need to specify the module version, do it using <version> . |
<dependency>
<groupId>info.magnolia.publishing</groupId>
<artifactId>magnolia-publishing-receiver</artifactId>
<version>1.3.13</version> (1)
</dependency>
1 | Should you need to specify the module version, do it using <version> . |
<dependency>
<groupId>info.magnolia.publishing</groupId>
<artifactId>magnolia-publishing-app</artifactId>
<version>1.3.13</version> (1)
</dependency>
1 | Should you need to specify the module version, do it using <version> . |
Configuration
Publishing is configured in Configuration >
/modules/publishing-core
.
Be very careful when modifying the configuration of publishing and always test the changes thoroughly before applying them to a live environment. Sometimes there may exist a better way of solving a publishing-related problem than by tweaking a publishing configuration. |
Main part
The main part of the configuration is under /modules/publishing-core/config
.
publishingLogStorage
Defines where the information about publishing is logged. The default implementation (info.magnolia.publishing.monitor.MemoryPublishingStorage) keeps the information in memory.
operations
Contains the list of operations provided by Magnolia and the respective operation classes:
-
publish
-
unpublish
-
commit
(DX Core only) -
rollback
(DX Core only)You can define your own operations and add them to the list, but in this case, you will also have to implement your own send and receive operations. info.magnolia.publishing.operation.SendOperation is a base interface that all send operations must implement.
With a custom-defined operation, you can publish content to something that’s not a Magnolia public instance, for example to a custom API or a Content Delivery Network.
lockManagerMode
property
The property has been introduced with module version 1.2.6.
By default, path-based locking is configured using lockManagerMode=path
.
Node-based locking can be set with lockManagerMode=compatibility
.
The setting is applicable only on public instances. Changing the property on the author instance has no effect. |
Publish and unpublish commands
Users typically publish content by clicking Publish in the Action bar. The click executes a publish
command which pushes the content from the author instance to the public instance(s).
Conversely, when users click Unpublish the system executes an unpublish
command which deletes the content from the public instance(s).
The publish
and unpublish
commands are configured in /modules/publishing-core/commands
.
The default
catalog contains the commands which just publish the content without versioning.
Magnolia also provides a versioned
command catalog.
It contains identically named publish
and unpublish
commands which first version the content and then delegate to the default commands.
Both in the To use one of these commands, define the catalog and the command name in the action definition. See an example in Executing commands with actions. |
Property | Description | ||
---|---|---|---|
|
optional, default is Security setting that prevents cookies from being read by a potentially malicious code. |
||
|
optional, default is When you publish a node and its children, you often end up publishing content whose status is already Published. Such nodes don’t need to be published, but it’s often more convenient to just publish the whole tree than node-by-node. To improve the performance of the author instance:
This may also help improve scalability, especially in cases where the author instance has a high concurrent load, typically with many editors activating large amounts of content at the same time. |
||
|
optional Version of the node to be published. If not specified, the current state of the node will be published.
The property can only be used with |
||
|
optional Versions of the node to be published. If not specified, the current state of the nodes will be published.
The property can only be used with |
||
|
optional If defined, instead of transferring nodes one-by-one, the publication process transfers the subtrees that have fewer descendants in one transaction than defined using the If the number of descendants is higher, each child will be published one-by-one, which is the same as when It’s therefore better to split flat structures into sub-folders for For more suggestions regarding the
|
Configuring itemsPerRequest
Determining the value of itemsPerRequest
depends on how much data you want to send in one HTTP transaction.
It could be, for example, 100
nodes for workspaces without binary data. For the assets
workspace, 100
assets might be too much though, depending on the average size of your assets.
You can get an approximate size of data in one transaction by exporting the trees and checking the size of the exported files. |
This doesn’t support publishing versions. Therefore, it’s not supported for apps with a publication workflow. |
How does itemsPerRequest
work?
Consider the following tree structure.
'tour-types':
'active': {}
'destinations':
'europe': {}
'asia': {}
If you publish /tour-types
without itemsPerRequest
defined, each node is sent to public instances separately:
INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/destinations].
INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/destinations/asia].
INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/destinations/europe].
INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/active].
Now, for the publish
action in the tourCategories.yaml
app, let’s set itemsPerRequest
to a very small number (just for demonstration purposes):
subApps:
browser:
actions:
publish:
params:
itemsPerRequest: 2
Publish /tour-types
again.
-
It first tries to publish the whole
/tour-types
subtree, but it has too many descendants compared to theitemsPerRequest
. So, the/tour-types
folder has to be published separately. -
/tour-types/destination
has two descendants, and so fits theitemsPerRequest
. Therefore, it will be published including its children in one transaction. -
/tour-types/active
doesn’t have children, so it’s published separately. TheitemsPerRequest
param doesn’t have any effect.
INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types]. INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/destinations]. INFO ing.receiver.operation.jcr.JcrPublicationOperation: About to update content under path [/tour-types/active].
In this example, we decreased the number of transactions to just a few. In practice, you can reduce the number of transactions from thousands to dozens, provided the workspace structure has been created as a more or less balanced tree.
Disabling publishing
If necessary, you can disable publishing on the public instance(s) by adding the enabled
node in Configuration > /server/filters/publishing
and setting its value to false
.
How publishing works
For an overview of how publishing works see the Publishing overview page.