Multisite example - Two sites with different domains

This page contains an example of how to configure multiple sites to manage different websites mapped to different domains.

Example scenario:  Eric has a store where he sells comic books and vinyl records. He wants different sites for his products. Comic books are his main business. 

Setting up domains

Eric has registered two domains: one for comics and one for vinyl. Since comics is his primary business, he registered the domain  www.best-comics.net  for the comics first, so this will be his main domain.

Use only one domain -  a subdomain of the main domain - to access the author instance (see Magnolia setup and domains).

Setting up content

Eric has created a lot of pages. When simplified, his website workspace has a structure with two pages in root directory as shown below. The two pages act as the home pages for the two different websites (both have many subpages not shown here).

Setting up site definitions

This table shows the configuration of the site definitions required by Eric.

Note the following points which reflect common practice and the scenario:

• We have a main site definition - here it is comics-site - that defines a prototype.
• The fallback site:
  • Extends the main site by using @extends=../comics-site.
  • mappings does not inherit from the main site because we use @extends=override.

Removing unwanted virtualURIMapping on public context

Request the URL http://www.best-comics.net. If you are redirected to the admin login page (http://www.best-comics.net/.magnolia/admincentral),  the public context contains a virtualURIMapping. This URI mapping is fine for an author context but not for the public context.

To remove the mapping:

Use the Configuration app to search for virtualURIMapping.

On a standard Magnolia bundle you typically find the following node: /modules/ui-admincentral/virtualURIMapping.

Delete the node /modules/ui-admincentral/virtualURIMapping/default.

Checking the access URLs 

Test the setup. Make sure you have pages shown in content setup in both the author and public instances.

Managing cross-site links

Imagine that Eric wants to advertise his vinyl records store from the comic book store and vice versa. So he creates links from pages on the comics-site to the vinyl-site and vice versa. 

Use the link component from mtk (mtk:components/link) in your page template to add links:

In this example, on the root page of the comics-site we add a link to the root page of the vinyl-site.

When Magnolia resolves links in a multisite context, it creates links that start with the domain:

Managing cross-site access

You can access a site using the site-definition-name. The full pattern of this kind of URL looks like this:

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

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

In the author instance

This way of accessing a site and its pages is necessary in the author instance. It is the usual way to access a site in the author instance, since the domain of the author instance usually is different from the domains mapped to the public instance and mapped to the sites. In this scenario, the access URLs of the sites on author are:

• author.best-comics.net/comics-site
• author.best-comics.net/vinyl-site

In the public instance - preventing it

Following the above URL pattern, you can access the sites in the public instance using:

• www.best-comics.net/vinyl-site
• www.best-vinyl.net/comics-site

Note that the first URL accesses the vinyl site via the comic site domain and the second URL accesses the comic site via the vinyl site domain.

This type of access should be avoided in a public instance because:

• The same content is served from different URLs. This has a negative impact in the context of SEO (Search engine optimization) and may decrease the Google ranking.
• Content rendered by the "wrong" site may appear with "wrong" styling or may have missing web resources due to different themes.

To prevent this:

Disable the uri-starts-with-sitename rule in the public context.

Add an additional voter AdminOnlyMatcher to the rule. This way you can use the same configuration on both the author and public instances.

Matcher 0 is set by default in the uri-starts-with-sitename rule. Add AdminOnlyMatcher as a second matcher to ensure the rule is applied in the author instance only.