How to use Multisite

This page and its subpages explain how to use the Multisite module to set up and run multiple websites from one Magnolia installation.

The page presents a few typical use cases for a multisite setup and the corresponding configuration required. Full working examples of certain use cases are in the subpages. We assume that you already know some basics about a Magnolia site definition. 

Overview

Typical use cases

Using multisite makes sense in the following scenarios:

• You have multiple websites with completely different purposes.
• You have minisites and run campaigns.
• You have different websites for subsidiaries and country branches.
• You have localized versions of the same website
• You use handles and URI prefixes to get shorter URLs.

How multisite works

In the Multisite module, you configure two important elements:

• Site definitions
  The Multisite module is delivered with one default site definition called fallback. When developing your multisite project, you configure your own site definitions. Every site definition can have its own theme and template prototype. A site definition contains a domain mapping and mapping to a node in a repository (URI2RepositoryMapping).

• Site resolution rules
  The site resolution rules ensure that Magnolia can properly assign a site for a given request. The Multisite module comes with a standard set of site resolution rules. The standard rules usually are sufficient. We strongly recommend you be careful if you choose to change these rules. 
  When a request is sent to Magnolia, MultiSiteFilter analyses the request to determine which site definition it fits. Once the site has been determined, it is set to the AggregationState from where it can be read during further request processing.

Setting up multisite - main steps

The following bullet points summarize what you need to do to set up a multisite environment with one Magnolia installation:

• Create trees or subtrees of JCR nodes (usually pages) with different purposes.
• Configure site definitions. For each one, define:
  • A mapping pointing to the tree or subtree of JCR nodes (usually pages).
  • A domain mapping to map a domain to the site.
• Access the distinct content (sub)trees via distinct domains.

Magnolia setup and domains in a production environment

Magnolia is distributed as two web-applications: author and public. Among other things, editors create pages on the author instance and publish content from the author instance to public instances. Public instances serve the content to visitors. In a typical production setup you have one author and several public Instances. 

In a production setup, the author instance and public instance are typically accessed via distinct domains.

Example of domains in a production environment

This table shows the difference between domains when pointing to author or public instances in a production environment. 

Serving the webapps from root context

In a production environment, you access the public instance by requesting the root path of the domain. For example, when you request www.yourdomain.net you expect it to serve the webapp typically called magnoliaPublic. The same is true for the author instance: you expect author.yourdomain.net to serve the webapp called magnoliaAuthor.

If you run a bundle on localhost, you request the public instance using http://localhost:8080/magnoliaPublic. In this case, the webapp magnoliaPublic is served from /magnoliaPublic.

Application servers such as Tomcat generally only serve one webapp from root context within the same connector. However, in a production environment, you typically run the author instance and the public instance in different networks. Alternatively, you may run two Tomcat instances on the same host, or run one Tomcat instance with two connectors.

Mapping multiple domains to the application server

In a production environment, you typically use a web server such as Apache in front of Tomcat. Read Apache httpd in front of Tomcat to get some ideas about such a setup. When using the Apache HTTP Server (Apache httpd) and Apache Tomcat together, mod_jk or mod_proxy_ajp can be used to redirect from Apache httpd to Tomcat.

In a multisite setup, where your public context serves content for multiple domains, you must map multiple domains to your application server (such as Tomcat). If you use a web server in front of the application, you must define multiple virtual hosts on the web server to redirect the request from Apache http to Apache Tomcat.

<VirtualHost *:80>
 ServerName www.best-comics.net
 ProxyPass / ajp://localhost:8010/
 ProxyPassReverse / ajp://localhost:8010/
</VirtualHost>
 
<VirtualHost *:80>
 ServerName www.best-vinyl.net
 ProxyPass / ajp://localhost:8010/
 ProxyPassReverse / ajp://localhost:8010/
</VirtualHost>

Fallback site

The multisite module provides a fallback site. The fallback site is a special site definition that is used when no site matches the request. 

When using multisite, it is common to have one main site and some additional sites. It generally makes sense to adapt the fallback site so that it extends your main site.

For example, the Magnolia Travel demo has two sites: travel-demo and sportstation. When the demo modules are installed, the fallback site is changed to extend travel-demo site.

Without the demo modules, the configuration of the fallback site looks like this:

Configuration

This section is about site definition configuration in the context of multisite. It explains how to configure multiple, distinct site definitions which require the definition of  domains and mappings nodes.

We assume that you already know some basics about Magnolia site definition configuration (such as prototypes, themes, imaging variations and sitefn templating functions). 

Site app

Go to the Site app to configure a site definition. 

If your bundle contains the Multisite module, the Site app shows the node /modules/multisite/config/sites from the configuration workspace.

When you open the Site app you see all configured sites as top-level nodes:

In this example there are two sites: fallback and comics-site.  

Site definition name

The node name of the site definition is called site-definition-name .

If a site is properly configured, it can be accessed using the following URL:

<protocol>://<domain>:<port>/<context>/<site-definition-name>

Note that this only works if the domain part of the URL is different from the domain that is mapped to the site of the given site-definition-name .

Mappings and domains

The mappings and domains nodes are required in a multisite context. You must create a least one entry on both mappings and domains to ensure a proper site definition for a distinct site.

Example:

The site defined above allows you to access:

• The content node /comics via the URL www.best-comics.net.
• The content node /comics/belgian-comics/morris/lucky-luke/jolly-jumper via the URL www.best-comics.net/jollyjumper.

mappings configuration

The mapping nodes define the JCR content nodes (usually page nodes) assigned to the site definition.

A mapping has the following properties:

domains configuration

A domain node assigns a domain to the given site definition. It defines how the above mapped content node(s) can be accessed by URL. You can map multiples domain to the same site.

A domain mapping has the following properties:

The site resolution rules ensure that Magnolia can properly assign a site for a given request. The Multisite module comes with a standard set of site resolution rules. The standard rules usually are sufficient. 

Rule configuration

The multisite site resolution rules are configured below the node /modules/multisite/config/rules. 

Note that every rule contains one or more configured Matcher classes.

Disabling the uri-starts-with-sitename rule on the public instance

The uri-starts-with-sitename rule is a cross-site-evaluation rule that enables you to access a site using its site-definition-name from another domain. This is desired and required on the author instance, which typically runs on a domain different from the domain(s) mapped to a site definition(s).

If you have two site definitions, this rule allows you to access site A from the domain which is mapped to site B. This is typically not desired on a public instance.

Custom site resolution rules and matcher classes

You can write your own custom matcher classes to create new rules. The custom class should extend AbstractMatcher , which implements the RequestMatcher interface. 

To understand multisite setup in different use cases, look at the following examples:

• Two sites with different domains
• Minisite using URL prefix and domain