Magnolia 6.1 reached end of life on March 31, 2021. This branch is no longer supported, see End-of-life policy.
Magnolia is distributed as two web-applications: author and public. Editors work on the author instance, typically in a secure location inaccessible from the Internet. Editors publish content from the author instance to public instances. Public instances serve the content to visitors. In a typical production setup you have at least two public instances, often more.
Magnolia's author-public instance model follows the publish-subscribe pattern. In this software design pattern, an author instance acts as a publisher. Public instances take on the role of a subscriber. The publisher classifies content so that subscribers can register interest in a particular type of content.
In Magnolia, editors create content in a particular workspace. It is common to organize content into a hierarchical tree structure on the author instance. This process is the equivalent of message filtering in the pub-sub pattern. Public instances subscribe to a particular workspace and path in the content hierarchy, receiving only content they are interested in.
Separating author instances from public instances has its benefits:
Magnolia's author/public instance model is very similar to the publish-subscribe messaging pattern.
Author and public instances run identical software. They both have an AdminCentral that you can log into. The differences are configuration and security only.
Configuration | Author | Public |
---|---|---|
/server/admin | true | false |
/modules/ui-admincentral/virtualURIMapping/default/toURI | Not set. | Set. |
anonymous role | Has author instance permissions | Has public instance permissions |
anonymous system user | Has author instance roles | Has public instance roles |
Subscribers | Has active subscribers | Has no subscribers |
There are many ways to find out what kind of instance you have:
/server/admin
property in the configuration. It is true
for author and false
for public instance.isAdmin()
method provided by the ServerConfiguration class.cmsfn.isAuthorInstance()
or cmsfn.isPublicInstance()
templating functions.Each public instance can serve content targeted to a particular audience or geographic area. For example, one instance can serve visitors from Europe and another visitors from the U.S.
Magnolia's multisite feature provides granularity for content control on multilanguage and multidomain installations. Administrators have the option to direct editors to the author instance through a specific domain. Editors edit only the part of the content structure that resides at the specified domain. To ensure a consistent browsing experience, URLs are adapted to always reflect the domain. You can also configure multiple domains to access the same instance.
Place secure and sensitive content on separate instances. This diagram shows a possible placement strategy where a public extranet instance resides on its own instance and has its own URL.
A distributed instance setup allows you to respond to high availability requirements and sudden increases in traffic. Here are common problem scenarios:
You can address the issues by adding a new public instance to serve the same content, helping the existing instances deal with the load.
Magnolia instance configurations start from a standard 3-instance setup and scale up. You can add any number of instances for load balancing and high availability. Public instances can subscribe to specific content such as intranet or extranet.