Receivers

In the context of the Publishing module, receiver is usually a public Magnolia instance that receives content from an author instance.

This page explains how to configure receivers.

About the publishing process

Publishing may refer either to a system process that copies content from an author to public instances or to a user action which triggers the process.

Before Magnolia 5.6, the system process was called activation.

For more information about how publishing works, please refer to the Publishing overview page.

License limitations

  • The Community Edition supports one receiver. You can configure many receivers but only the first receiver will receive published content. The publishing process is handled by the Publishing module itself.

  • DX Core supports many receivers and the process is handled by the Publishing and Publishing Transactional modules.

Verifying publication success

There are three ways to verify successful publication:

  • Status indicator changes to green on the author instance.

  • Page content on the public instance is new. Request the page to test.

  • Publication log /webapps/magnoliaAuthor/logs/magnolia-activation.log contains a success entry. See Monitoring about logging and debugging.

Configuration

Receiver configuration is in Configuration > /modules/publishing-core/config/receivers where you define the address(es) of the receiver(s). In the default setup, the public instance is configured as a receiver of the author instance.

Here is an example receiver from the default installation. The name of the receiver node is magnoliaPublic8080. You can choose any name, just pick a descriptive name like corporate-website or intranet.

Receiver configuration

Property Description

url

required

Host name (or IP address) and port number of the receiving public instance.

The connection to a receiver (public instance) during the publishing process is implemented using Apache HttpClient v4.5.3 (https://hc.apache.org/httpcomponents-client-4.5.x/index.html^).

enabled

optional, default is true

Enables or disables the receiver without deleting the setup.

Useful when there are multiple receivers.

connectionTimeout

optional, default is 10000 (10 seconds)

Sets a connection timeout in milliseconds.

If time runs out before a connection to the receiver can be established, a java.net.SocketTimeoutException is thrown (0 is interpreted as an infinite timeout).

readTimeout

optional, default is 600000 (10 minutes)

Sets the read timeout in milliseconds.

If time runs before the published content is read from the author instance, a java.net.SocketTimeoutException is thrown (0 is interpreted as an infinite timeout).

Workspaces

For each receiver the content to be published is configured under the workspaces node. The name of the workspace node (see the placeholder <workspace-node-name> below) is arbitrary, but by convention the name of the Magnolia workspace is used.

All Magnolia workspaces are enabled by default but can be selectively excluded from publishing.

Receivers workspace

Property Description

workspace

required

Name of the workspace.

fromPath

required

Workspace path on the author instance from which content is published.

For a single site, enter the site node such as /my-site. To receive content from a particular branch, enter a more precise path such as /my-site/about.

A trailing slash in the path limits the published content to the subnodes:

/

Everything

/my-site /my-site

node and everything under it.

/my-site/about about

node and everything under it.

/my-site/about/

Content under /my-site/about page but not the node itself.

toPath

required

Workspace path on the public instance to which the content is published.

enabled

optional, default is true

A Node2Bean property that turns the mapping on (true) or off (false).

excluded

optional, default is false

The true setting excludes the configured fromPath from publication.

This property allows you to define exceptions such as "Publish everything in the website workspace except the about node and everything under it."

Receivers can receive any content item: websites, website sections, configuration settings, custom content types, forums, comments, documents, images and so on. For example, you could publish a campaign site to a dedicated public instance.

Multiple receivers

In DX Core, the author instance can publish content to multiple receivers. Receivers are key to building high-availability, load-balanced environments since they can be configured to receive targeted content. See Creating a new public instance.

Typically, each receiver resides on a separate server. In the example below, productionOne and productionTwo are receivers. Each has a unique domain name (siteone, sitetwo) so they likely to receive different content.

Multiple receivers folder

Once you have your production environment established, it is recommended that you delete the default magnoliaPublic8080 receiver. This avoids unnecessary errors in log files that may obfuscate errors from the actual receivers.

Use cases

Site-specific receivers

Magnolia’s multisite feature allows you to manage many sites on one author instance. You can configure a separate receiver for each site. When content from one site is published, it goes only to the receiver configured for that site.

In the example below, a public corporate website, an extranet site and an intranet site are all managed on the same author instance. Receivers public, extranet and intranet are bound with the corresponding sites. For example, the intranet receiver is bound with content in the /intranet site. Content on that site is published to the magnoliaIntranet public instance.

This kind of configuration simplifies the security setup. You don’t need to segregate anonymous visitors from authenticated intranet visitors since no intranet content is ever published to the magnoliaPublic instance. Intranet content is published only to magnoliaIntranet which is a completely different instance.

Site-specific receivers

Flat authoring

Receiver configuration can turn a hierarchical site structure to a flat one or vice versa. Editors may prefer a flat hierarchy on the author instance. For example, a busy site section such as news is edited several times a day. If that section resides deep in the site hierarchy, it takes editors too much time to navigate the tree. Make an editor’s life easier by moving the news section to the root level on the author instance. Adding news is now quicker. The receiver configuration publishes the news pages to their intended deeper location on the public instance.

Flat author receivers

Flat public site

An opposite example is a flat public site. Search engines prefer a shallow site structure. As a rule of thumb, the flatter the public structure the better. The higher a page appears in the site structure, the more likely it will be ranked high by a crawler.

In this example, news pages are published from a deep authoring location /usa/politics/2015 to a more SEO-favorable /news.

Flat public receivers

Publishing multiple sites to the same public instance

The demo websites /travel and /sportstation that ship with the Magnolia Travel Demo bundle are an example of publishing two different sites to the same public instance. No configuration is necessary for the website workspace, though. By default all workspaces are attached automatically to the magnoliaPublic8080 receiver.

Publishing the same content to multiple public instances

You can publish the same content to many sites. A corporation with regional affiliates may want to keep branding under tight control. Company logos, slogans and boilerplate text must be displayed on affiliate sites in exactly the same way.

Suppose that the corporation stores branding material such as logos in the dam workspace in the /branding folder. In this example, the brand material is published to the corporation’s affiliate sites for Asia and Europe. While the content is the same, you can publish it to a different location on the target sites depending on how those sites are organized:

Publishing the same content to multiple public instances

Publishing content from multiple author instances

Publishing content from multiple author instances to the same public instance can be useful when:

  • You serve multiple websites from the same server. The server may be specifically designed to serve a particular type of content (files, video).

  • Different editorial teams contribute content to the same site. For example, a finance news team in Asia writes about Asian markets on their own author instance. However, they publish the content to a U.S.-based public site.

Multiple author instances do not know about each other, which can lead to conflicts. When one user working on author1 publishes a page, another user on author2 does not know about this. He does not see the page on author2, only on the public instance. Even pages that exist on both author instances may be edited unnoticed. The Soft Locking module helps you handle concurrent editing but it only works within one author instance.

Publishing heavy binary content to a dedicated instance

You can publish large binary content such as video to a dedicated public instance that acts as a media server. Compared to other public instances, the media server may have more disk space or it may be configured specifically for video streaming. Other public instances serve HTML on their own but link to videos on the media instance.

Feedback

DX Core

×

Location

This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules