Multi-Domain Templates (Themes/Theming)
Aurora supports multiple domain hosting and also allows you to configure what templates should be used for each.
This articles explains how to manage your Domain Templates and how this manifests in practical terms for your Front-end Template files.
For more general help understanding how to manage your domain settings in Aurora, please see the Multi-domain support article.
Introduction
Multi-domain Templates allow you to service/manage the Front-end Templates for any number of Aurora Stores using a single (centralised) set of templates. This system is referred to as the Multi-domain Templates system or something as Theming and can be configured to either load templates from your Front-end Template repository by:
- Domain name.
- The Template Sub-directory setting configured under Store > Configure > Domains (see the Multi-domain support article for more detail regarding how to manage this value).
To better understand how to edit the settings, see the Multi-domain support article, but to better understand how this affects your templates, read on...
How does Aurora use the Front-end Templates?
Aurora will allow you to override any or all of your 'base' templates (including HTML files, CSS, JS and Images) with domain/theme specific alternatives. You can do this very simply by creating a replacement copy of any file in your templates directory with the desired replacement.
For example, if you include a file called "advert.tpl.html" on your homepage and you wish to have this template differ from one domain/theme to the next, you simply create a replacement file in a domain/theme specific directory, as follows...
templates/your_templates/advert.tpl.html
templates/your_templates/www.other-domain.com/advert.tpl.html
templates/your_templates/template-sub-directory/advert.tpl.html
How to Manage the Front-end Templates
To replace just the header template for a particular domain/theme, you might create a template structure as follows:
templates/design_one/index.tpl.html
templates/design_one/_includes/header.tpl.html
templates/design_one/www.other-domain.com/_includes/header.tpl.html
templates/design_one/template-sub-directory/_includes/header.tpl.html
It is strongly recommended that entire root templates not simply be copied and changed. For example, don't just copy the Domain 1 "template.css" file over and change it for Domain 2. You should instead, create a "custom.css" (the name is unimportant and can be anything) which is perhaps empty in the Domain 1 version and contains just the differences that need applying over the Domain 1 CSS to achieve the Domain 2 layout.
Doing this makes the most out of this templating system and avoids the need to manage two entire sets of template CSS (which is the entire point of this approach).
Replacing Images, CSS and JS Files
Similarly, Images and CSS can be overridden in the same way, as long as the commands described in this section are used when making reference to them in the templates. Here are some examples of the kind of directory structures you might create for this purpose:
templates/design_one/index.tpl.html
templates/design_one/_includes/header.tpl.html
templates/design_one/_css/custom.css
templates/design_one/_css/templates.css
templates/design_one/_images/icons/logo.png
templates/design_one/www.other-domain.com/_css/custom.css
templates/design_one/www.other-domain.com/_images/icons/logo.png
Example Domain/Theme Templates
To help demonstrate how this works, the Aurora Demo Example Front-end Templates include a few examples of how you might achieve a few common domain/theme specific template overrides. Please find these examples in the templates/example.com directory, named "theme1", "theme2" and "theme3".
Each theme directory is intended to demonstrate something slightly different, as described below:
- Theme 1:
- A different homepage (index).
- Some custom CSS.
- Some custom JS.
- Theme 2:
- A different homepage (index).
- Some custom CSS.
- Theme 3:
- A different header and footer.
- A few different images.
These examples are intentionally very simple, as they are intended only to demonstrate the system in action.
Updated over 2 years ago