Multi-domain

The multi-domain system allows you to share data between multiple domains each running a separate instance of Aurora.

This article aims to describe how to manage your domains in Aurora and how these domains interact with one another when configured to be synchronised.

Introduction

Aurora can be setup to manage more than one domain and allow some different data values to be shared between different domains.

Managing Domains

You can manage your domains from the Aurora Back-end under Store > Configure > Domains.

This interface allows you to manage the domain features of your Aurora instance, including:

Field Name	Default	Description	Required
Domain Name	N/A	This is the domain name that is being managed. Aurora uses this when generating various absolute URLs/links throughout its processes, including but not limited to the URLs/links provided in automatically generated emails. Changing this field can breaking linking across a wide array of services in Aurora, so please treat this field with grate care. If you are unsure if you should be editing this field, then do not do so and instead, seek advice first.	Yes
Domain Regular Expression	N/A	This field allows you to configure when the domain record should be applied to the incoming request, based on a regular expression. Changing this field can bring your Store down if not managed correctly, so please treat this field with grate care. If you are unsure if you should be editing this field, then do not do so and instead, seek advice first.	Yes
Enforce Domain?	No/Off	Setting this field will force Aurora to redirect the incoming request to the domain configured under "Domain Name" if it is not already in use by the client.	No
Templates Directory	N/A	This field controls the parent template directory used when generating your Front-end. In the following examples, the template directory is the section reading "domain-x" from your templates directory, where "domain-a" or "domain-b" would be set in your "Templates Directory" field: templates/domain-a/theam-1/en-gb/etc... templates/domain-b/theam-1/en-gb/etc...	Yes
Templates Sub-directory	The current domain name, e.g. your-domain.co.uk	This field allows you to specify a further sub-directory to search inside for 'shared' templates within your main "Template Directory". In the following examples, the template subdirectory is the section reading "theme-x" from your templates directory, where "theme-1" or "theme-2" would be set in your "Templates Subdirectory" field: templates/your-domain.co.uk/theam-1/en-gb/etc... templates/your-domain.co.uk/theam-2/en-gb/etc... For more detail on how this manifests in your Front-end Templates, please see the Multi-Domain Templates (Themes/Theming) support article.	No
Default Currency	N/A	This tells Aurora what currency you would like it to have the customer to use by default when visiting the domain for the first time.	Yes
Default Language	The system wide Default Language.	This tells Aurora what language you would like it to have the customer to use by default when visiting the domain for the first time.	No
Product Channel	None	This tells Aurora which product channel to use when a customer visits this domain. Any Product Channel set on the Locale will override this value, including if the default locale has a Product Channel set up.	No

What else can I manage by Domain?

📘
There are a range of feature that allow you to adjust their setting by domain. See the list below of features you can manage by domain.

Front-end Templates
Product Channels
The 'No Payment' payment method

There are a range of other thing you can configure, such a default values for language and currency by domain, however the above is the list of entities that you can actually customise by domain.

👍
So what can this do for me?
Why not launch into the deployment of Kiosks in your stores (using domain-specific Front-end Templates and the Adyen POS integration)?! Or create a responsive Front-end for your in-store app?

Updated 14 days ago