Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

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

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 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

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.

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 magnoliaCorporateWebsite or magnoliaIntranet.

The configurable properties are:

Property

Description

Default value

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. Possible values are true and false.

true

class

Name of the Java class that contains the business logic. The default activation mechanism uses the HTTP protocol.

DefaultSubscriber

connectionTimeoutOptional. 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.10000
readTimeoutOptional. 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.600000

Subscriptions

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 website or dms.

The configurable properties are:

Property

Description

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 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.

Trailing slash

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

fromURI path

Activated content

/

Everything

/demo-project

The /demo-project site home page and all content under it.

/demo-project/

Only content under /demo-project but not the page itself.

/demo-project/about

The about section and all content under it.

/demo-project/about/

Only content under the about section but not the about section page itself.

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.

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.

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, 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 /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.

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.

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.