Public instances that receive activated content are known as subscribers. The Community Edition supports a single public subscriber. In the Enterprise Edition any number of subscribers can subscribe to a single author instance.
- About the activation process
- Verifying activation success
- Use cases
About the activation process
Activation is the process of publishing content from an author instance to one or more public instances. Activation can trigger an optional editorial workflow in which a publisher reviews the changes and approves them for publication. For instructions on how to activate content see Activating and De-activating.
In the Community Edition, activation is handled by the Exchange Simple module. The Enterprise Edition uses the Transactional Activation module.
Verifying activation success
There are three ways to verify successful activation:
- On the author instance, when a resource is activated the status indicator changes to green. Click Refresh to check. Green indicates activated, yellow indicates modification since activation and red indicates either never activated or deactivated.
- Request the page on the public instance and look at its content. If the content is the same as on the author instance, the page was activated successfully.
- Check the activation log file. Each activation request is logged in
/webapps/magnoliaAuthor/logs/magnolia-activation.log. You can also view the content of this file in Tools > Log Viewer. See Monitoring for more about logging and debugging.
Connection during activation to subscriber
Connection during activation to subscriber (public instance) is done by java.net.URL class. In addition to IPv4, this class support IPv6s. When using an IPv6 address, the address has to be enclosed in square brackets. For example, [address].
The syntax of URL is defined by RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, amended by RFC 2732: Format for Literal IPv6 Addresses in URLs. The Literal IPv6 address format also supports scope_ids. The syntax and usage of scope_ids is described here.
A subscriber configuration defines the address of the subscriber and the type of content it should receive. In the default setup the public instance is configured as a subscriber of the author instance. To access subscriber configuration, go to Configuration > Subscribers.
A subscriber is a public Magnolia CMS instance. Each subscriber is configured with a content node that has three properties and a subscription configuration which tells the activation process what content should be sent to that public instance.
Here is an example subscriber from the default installation. The name of the subscriber node is
magnoliaPublic8080. You can choose any name, just pick a descriptive name like
The configurable properties are:
| ||Host name (or IP address) and port number of the receiving instance.|
| || Enables or disables the subscriber without deleting the setup. Useful when there are multiple subscribers. Possible values are ||
| ||Name of the Java class that contains the business logic. The default activation mechanism uses the HTTP protocol.||
The content to be activated is configured in a subscription. By default, there is a subscription for each Magnolia CMS workspace. Again, you can name the subscription nodes as you prefer. The default naming convention uses the name of the workspace, for example
The configurable properties are:
| || Path on the author instance from which the content is activated. Root
| ||Name of the workspace.|
| ||Path on the public instance to which the content is activated.|
Subscribers can subscribe to any content item: websites, website sections, configuration settings, custom data types and data nodes, forums, comments, documents, images and so on. For example, a campaign microsite could be published to a dedicated public instance.
A trailing slash in the
fromURI path limits the activated content to the subnodes.
|fromURI path||Activated content|
| || The
| || Only content under
| || The
| || Only content under the
Configuring multiple subscribers
A single author instance can activate to multiple subscribers or public instances. Subscribers are key to building high-availability, load-balanced environments since they can be configured to receive targeted content. How to set up additional public instances is discussed in Creating a new public instance.
Each public subscriber is configured in a separate node in
/server/activation/subscribers. To configure additional subscribers, copy the default configuration, rename the node and edit the
URL property and any relevant nodes in the
/subscriptions sub node.
Typically, each subscriber would reside on a separate server. In the example below is a production environment.
productionTwo are subscribers. Each has a unique domain name so they likely receive different content. You can mimic the domains on your local system by adding them to the system hosts file and mapping to local instances such as
In the example above, all three subscribers are active. Once you have your production environment established, it is recommended that you delete the default
/magnoliaPublic8080 subscriber. This avoids unnecessary errors in log files that may obfuscate errors from actual subscribers.
Site specific subscribers
The multi-site feature in Enterprise Edition allows you to manage many sites in one author instance. You can configure a separate subscriber for each site. When content from one site is activated, it goes only to the subscriber 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. Subscribers
extranet subscribe to the root nodes of the sites and are mapped to different public instances. For example, the
intranet subscriber subscribes to changes in the
/intranet site root. Any changes to website content on that site are activated to the
magnoliaIntranet public instance.
Such a configuration may simplify the security setup. You don't need to segregate anonymous visitors from intranet visitors on the corporate website
magnoliaPublic when no intranet content is activated to that instance. Intranet content is activated only to
magnoliaIntranet which is a completely different instance.
Flattening or deepening the site structure
Subscriber configuration can turn a hierarchical site structure to a flat one or vice versa. Editors may prefer to organize the site hierarchy differently on author and public instances. For example, a busy site section such as News may need to be edited several times a day. If that section resides deep in the site hierarchy it takes editors too much time to open the containing tree nodes. You can make their life easier by promoting the section to the root level. Adding news pages is now quicker. A custom subscription activates the news pages to their original deeper location on the public instance.
In the example below, the News Overview page and its subpages were moved from their original location
/demo-project/news-and-events/news-overview to site root level
/news-overview on the author instance. This makes it quicker for editors to add news pages under the overview.
news activates the news pages to their original deep location on the public instance.
The activated hierarchy on the public instance looks like this.
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. See our SEO Tech Brief for more on this topic.
In this case the
news subscription activates news pages from the original deep location
/demo-project/news-and-events/news-overview to an SEO-favorable
Activating multiple sites to the same public instance
The example sites
/demo-features that ship with the Magnolia CMS bundle are an example of activating two different sites to the same public instance. Both sites have site root nodes in the
website workspace, as you can see in AdminCentral.
Both sites also have site definitions that apply templates, themes, domains and locales to the site. This makes them sites by definition.
However, both sites are activated to the same subscriber. Subscriber
demoPublic subscribes to the root node
/ in the
website workspace so changes to either site will be activated to it.
Activating the same content to multiple public instances
Same content can be activated to many sites. An example of such content is branding and corporate imagery. A large corporation with regional affiliates wants to keep branding under tight control. Company logo, slogan and boilerplate text must be repeated on all affiliate websites in exactly the same way.
Suppose that the parent corporation stores branding material such as logos, document templates and boilerplate text in a DMS folder
The folder's content is activated to European and Asian affiliate sites. While the folder's content is the same, it can reside in a different location on the target sites depending on how they are organized.
Activating content from multiple authors to the same site
Activating 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 particular type of content (file downloads, video).
- Different editorial teams contribute content to the same site. For example, a financial news team in Japan writes on their own author instance about Asian markets, activating the content to a U.S. based public site.
Author instances do not know about each other. This can lead to conflicts. When an editor working on
author1 activates a page, editors on
author2 do not know that this happened. They will never see the page on
author2, only on the public instance. Similarly, edits to a page that exists on both author instances go unnoticed by the other team. The Soft Locking module supports concurrent editing but it only works within one author instance.
A variation of activating the same content to two different sites is time-delayed activation. A custom workflow can active content first to one site and later to another site.
For example, announcements about job openings can be first posted to an intranet site. A week later the same job is posted to a public website. This gives internal applicants some headway.
Another example of delayed publishing is exclusive content. An article can be activated to a premium partner's site for a period of exclusive publication. The partner holds publishing rights to the content for a day, after which the same content is published to standard partners.