Multi-site installations
This page is for engineers who design an installation that serves more than one site, and for those who decide between one installation and several. Exponential has served several sites from one code base for a long time; 6.0.15 added per-site settings inside extensions and per-site logs and caches.
Contents
- The building blocks
- Per-site settings inside extensions
- Per-site logs and caches
- Links between sites
- One installation or several
- Checklist
The building blocks
| Block | What it gives |
|---|---|
| Siteaccess per site (and per language) | its own settings, design, host or path match (Siteaccesses and configuration) |
| Content tree | sites can share one tree or each use a subtree (content.ini [NodeSettings] RootNode, site.ini [SiteSettings] IndexPage per siteaccess) |
VarDir per site | storage, cache and logs of each site in var/<site>/ |
| A site in its own extension | its settings, design and code versioned together |
| Roles with subtree or section limitations | editors of one site cannot change another |
Per-site settings inside extensions
Since January 2026 an extension that holds a site can carry override settings that are active only while one of its
siteaccesses runs: extension/<site>/settings/override/ applies to all of its siteaccesses, and its
settings/siteaccess/<name>/ to one. Clearing the INI cache clears it for every project on the installation
(Per-site settings inside extensions).
Per-site logs and caches
All in site.ini [FileSettings]; every default keeps the old behavior:
| Setting | Effect |
|---|---|
UseGlobalLogDir=disabled | debug logs go to the site's log directory instead of var/log |
LogDir, LogVarDir | logs on another file system, or every site's logs under one directory |
CacheVarDir | every site's caches on one memory file system |
ExpiryDir | expiry timestamps kept where the cache storage is |
INICacheDir=site | the INI cache per site, cleared on its own |
Under Velocity and on the command line every value is derived again from site.ini when the siteaccess changes;
nothing is kept from one request or site to the next (Logs, INI cache and expiry timestamps per site).
Links between sites
When several sites share one content tree and a page of one site lists content of another (a tag page, a search
result, a related item), the links point into the wrong site and answer 404 unless the ezurlmultisite extension
resolves them to the other site's address (Links to content of another site).
One installation or several
| One installation | Several installations |
|---|---|
| one deploy, one upgrade, one set of extensions | each site upgrades on its own schedule |
| shared content and users are possible | strict isolation of data and code |
| one database and one failure domain | failures stay in one site |
| per-site settings, logs and caches as above | per-site everything by construction |
Choose one installation when the sites share people, content or release schedule; choose several when they must be isolated from each other.
Checklist
- To do: Each site has its siteaccesses, in
AvailableSiteAccessList[], with host or path matching. - To do: Each site's settings live in its extension, not in a shared
settings/override/. - To do: Logs and caches are per site where operators need them apart.
- To do: Roles keep each site's editors in their subtree or section.
- To do: The trusted proxy list and the certificates cover every host name.
- To do: Cronjobs run once per installation, not once per site, unless a part is site-specific.
Related pages
- Multisite and multilingual planning
- Siteaccess settings
- Internationalization and right to left
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.