Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
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.
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.
There are three ways to verify successful activation:
/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 to subscriber (public instance) during activation is done by the
java.net.URL class. In addition to IPv4, this class support IPv6 addresses. When using an IPv6 address, the address has to be enclosed in square brackets. For example
You can use either HTTP or HTTPS protocol in the subscriber URL. The syntax of URL is defined by RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax and amended by RFC 2732: Format for Literal IPv6 Addresses in URLs. The Literal IPv6 address format also supports scoped addresses. The syntax and usage of scope_ids is described in Textual representation of IPv6 scoped addresses.
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 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.
|Optional. Sets a connection timeout in milliseconds. If the timeout expires before a connection to the subscriber can be established, a java.net.SocketTimeoutException is raised. A timeout of zero is interpreted as an infinite timeout.|
|Optional. Sets the read timeout in milliseconds. If the timeout expires before the activated content is read from the author instance, a java.net.SocketTimeoutException is raised. A timeout of zero is interpreted as an infinite timeout.|
The content to be activated is configured in a subscription. By default, there is a subscription for each Magnolia 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.
Only content under
Only content under the
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.
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, two of the 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.
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.
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 intended 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
The example sites
/demo-features that ship with the Magnolia 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.
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 author instances to the same public instance can be useful when:
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 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.
You can reduce the bandwidth requirements of the activation process by transferring large binary content such as documents, images and video to a public instance that acts as a media server. Compared to other public instances, the media instance may have more disk space or is configured specifically for fast video streaming. The binary content is activated once to that instance only. Other public instances may be identical in other respects but they all reference binary resources from the media instance.