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
for the comics first, so this will be his main domain.
|author instance||public instance|
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.
- Extends the main site by using
- mappings does not inherit from the main site because we use
- Extends the main site by using
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
On a standard Magnolia bundle you typically find the following node:
Delete this node on the public instance
Delete the node
Checking the access URLs
Test the setup. Make sure you have pages shown in content setup in both the author and public instances.
|URL||website on browser||rendered page node|
To access the root page of a site in the author instance, which is accessed on a domain that is not mapped to a site, use the following URL:
Note that Magnolia creates these links automatically, for example, when you open the Preview tab in the author instance.
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
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:
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:
In the public instance - preventing it
Following the above URL pattern, you can access the sites in the public instance using:
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:
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.
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.