Site definitions enable you to individually control multiple websites, each with distinct domains and languages, within a single Magnolia installation.
Each website corresponds to a website’s root page and its subpages in the Pages app.
The definition needs to be mapped to the website content.
Specifically, you have to map your site definition to your website’s root page.
The site definition and website must have the same name.
Additionally, every site definition can have its own site-wide theme and template prototype configurations.
Template prototypes are used to define master page templates.
Anything configured in them (for example, navigation, common page areas, or JavaScript) is applied to all page templates.
Themes allow you to define different image renditions.
Go to the How to use Multisite page to configure multiple sites from one Magnolia installation.
Do I need a site definition?
No, it’s not necessary to use a site definition.
A site based on concrete template definitions works perfectly well.
A site definition is an advanced option.
It’s useful when you have a large site and want to avoid repeating a similar configuration.
Without a site definition you can still:
Choose which templates are available to editors.
Add CSS and JavaScript at the page level instead of site level.
You need the Site module to create a site definition.
The module may not always be included, for example when you create your own webapp based on the empty webapp.
Add a dependency to the Site module in your webapp POM file.
DX Core provides the multisite feature.
It allows you to configure a different site definition for each website in a single Magnolia instance.
Each site can be mapped to a different domain and you can serve content from different workspaces.
These features are in the Multisite module.
Site limitation
In DX Core, the number of sites that can be used is defined by the
number of sites purchased.
In the Community Edition, you can only create and use one site.
Configuring a site definition
You can configure a site using a YAML definition file in the sites folder of your module.
Configuration properties
Property
Description
templates
optional
prototype
optional
The template prototype is a master template definition which applies to the whole site.
Anything you configure in the prototype is applied to all page templates.
Incorrect filter configuration may block all user traffic.
If access to Magnolia is blocked by an incorrect filter configuration, you can fix this by decorating the site config and overriding the incorrect values.
Filter configuration parameters determine which headers are allowed or checked by this filter.
If forwardingEnabled is set to false (default), the filter blocks requests containing specific headers.
This is to ensure security when proxy headers aren’t expected.
The default setting prevents undesired traffic blocking.
If forwardingEnabled is set to true, the filter checks the values of specific headers in incoming requests.
Requests with unexpected header values are blocked for security reasons.
Available header names:
x_forwarded_for for X-Forwarded-For
x_forwarded_host for X-Forwarded-Host
x_forwarded_proto for X-Forwarded-Proto
x_forwarded_port for X-Forwarded-Port
When using a proxy in front of Magnolia, it’s highly recommended to apply IP filtering in Tomcat so that only requests from the trusted proxy would be processed.
The mappings property defines exactly to which node a site definition applies.
For example, in the mapping definition below, the root page /home-page is the website for which the site definition applies.
The URIPrefix maps a requested URL to one of the workspaces. For the website repository, it’s always empty.
See URI to repository mapping for more information.
2
The handlePrefix specifies the website to which the site definition is applied.
The site definition and website must have the same name.
The URIPrefix defined in the site definition takes higher precedence over the system-wide configuration in the server config.
Open the Configuration app, select the config workspace in JCR, and go to the /server/URI2RepositoryMapping/mappings node to see the general settings.
Some example mappings from the travel-demo are shown below.
In addition to the website mapping, a mapping is set up for the dam repository.
It maps the site definition to the /travel-assets folder in the dam repository, overriding the general /dam/ setting in URI2RepositoryMapping.
The URIPrefix and repository names must match those defined in the Magnolia URI2RepositoryMapping.
domains:travel-demo:name:travel-demo.magnolia-cms.commappings:website:URIPrefix:''handlePrefix:/travelrepository:website# Optional: The /dam/ mapping is rarely used. It's an example of a possible DAM mapping if needed.dam:URIPrefix:'/dam/'handlePrefix:/travel-assetsrepository:damCopy
Example configuration
For an example site definition, see the Magnolia travel.yaml definition file.
Site definitions in CE and DX Core
The steps to create a site definition can vary depending on which modules you have installed.
In the Magnolia Community Edition, you are only allowed a single site definition.
For Magnolia DX Core, multiple site definitions are allowed.
Community Edition
When using the Community Edition, only the Site module is installed.
Because of this, you only have the option for a single site definition in your project.
If you need to work with multiple sites, you must upgrade to Magnolia DX Core.
DX Core
When using Magnolie DX Core, only the Multisite module is installed.
With this module, you can have as many sites as required.
However, there are physical limits as each new site that’s added creates additional complexity.
It can sometimes be helpful to break the installations into multiple author instances.
Especially in cases where you have multiple different teams spanning different regions.
You can have as many author instances as you need as long as the content stays independent.