Subscribers

Public instances that receive published content are known as subscribers.

License limitations

• Community Edition supports one subscriber. You can configure many subscribers but only the first subscriber will receive published content.
• Enterprise Edition supports many subscribers.

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 Activation module. The Enterprise Edition uses the Transactional Activation module.

Verifying activation success

There are three ways to verify successful activation:

• Status indicator changes to green on the author instance.
• Page content on the public instance is new. Request the page to test.
• Activation log /webapps/magnoliaAuthor/logs/magnolia-activation.log contains a success entry. See Monitoring about logging and debugging.

Connection to subscriber during activation

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 [2001:0db8:85a3:0000:0000:8a2e:0370:7334].

URL syntax

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.

Configuration

Subscriber configuration is in Configuration > /server/activation/subscribers. Here you define 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.

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 corporateWebsite or intranet.

The configurable properties are:

• URL: Host name (or IP address) and port number of the receiving instance.
• active: Enables or disables the subscriber without deleting the setup. Useful when there are multiple subscribers. Default is true.
• class: Java class that holds the subscriber configuration. Default is  info.magnolia.module.activation.DefaultSubscriber. The default activation mechanism uses the HTTP protocol.
• connectionTimeout: 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. Default is 10000 ms. A timeout of zero is interpreted as an infinite timeout.
• readTimeout: 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. Default is 10000. A timeout of zero is interpreted as an infinite timeout.

Subscriptions

The content to be activated is configured in a subscription. By default, there is a subscription for each Magnolia workspace. The subscription node name is up to you. The default naming convention uses the name of the workspace, for example websiteSubscription.

The configurable properties are:

• fromURI: Path on the author instance from which the content is activated. Root / (forward slash) is used to activate everything in the repository. To activate a particular site provide the site root node such as /demo-project. To activate a particular branch or node, provide a more precise path such as /demo-project/about.
• repository: Name of the workspace.
• toURI: Path on the public instance to which the content is activated.

Subscribers can subscribe to any content item: websites, website sections, configuration settings, custom content types, forums, comments, documents, images and so on. For example, a campaign microsite could be published to a dedicated public instance.

Trailing slash

A trailing slash in the fromURI path limits the activated content to the subnodes.

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. productionOne and 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 http://localhost:8080/magnoliaProductionOne .

Use cases

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 public, intranet and 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 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.

Subscription 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 /news-overview.

Activating multiple sites to the same public instance

The example sites /demo-project and /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.

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 magnoliaPublic8080 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 DAM folder /branding.

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.

Delayed publishing

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.

Heavy binary content to one public

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.