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.
Type | Author | Public |
---|---|---|
comics |
|
|
vinyl |
|
|
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).
Page | Title |
---|---|
comics |
Best comics |
vinyl |
Best vinyl |
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 www.best-comics.net
. If you are redirected to the
admin login page (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 Find Bar to search for
virtualURIMapping
in the
Configuration app.
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 Setting up content in both the author and public instances.
Author instance
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
(mtk2: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>
This only works if the domain is different from the domain which is mapped to the site of the given site-definition-name. |
On 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
On 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 withwrong
styling or may have missing web resources due to different themes.
To prevent this, see the Disabling the uri-starts-with-sitename rule on the public instance.
|