Update of the various possible solutions for managing multiple Drupal sites by sharing the Drupal architecture, even taking advantage of an inheritance principle for configurations and developments...
We are taking advantage of the evolution of our various multi-site projects to list robust and available solutions for running a Drupal multi-site instance.
Multi-sites
Drupal has a feature that allows you to serve distinct and independent sites from a single codebase. Each site has its own database, its own configuration, files, and a base domain or URL.
The main reason to use a Drupal multi-site installation is to save time when you manage more than one Drupal site using the same core version. Whenever a new Drupal core update is released, you'll only need to apply it once to a single codebase, instead of doing it for each site separately.
But there are downsides:
- Technical skills are required to deploy a new site (create a VHOST, configure it, etc.)
- The different sites must be physically hosted on the same infrastructure.
Multi-domains
Domain Access is a suite of modules that uses content syndication with centralized user management, all running across multiple domains.
Each domain corresponds to a sub-site, but all point to a single Drupal installation with a unique database. Each entity is simply mapped to one or more domains where it should be published.
The module lets you share users, content, and configurations across a group of sites such as:
- example.com
- one.example.com
- two.example.com
- mon.exemple.com
- thisexample.com - can use any domain string
- example.com:3000 - treats non-standard ports as unique
By default, these sites share all the tables (database) of your Drupal installation.
The downside is that, since there is only one site, there is only one structure for content types, views, panels, etc. Content type definitions can't vary, because there's only one Drupal installation. Views are, technically, cross-domain, although filters are available for the "current domain" (similar to "current user").
However, Domain Access allows for quite specific domain-based configuration. Almost all configuration variables (those that use the basic settings form) can be set by domain, including the active theme. Since themes can be different, and themes can always have a common base theme, this allows a lot of flexibility regarding “graphic differences” between each site.
The Domain Path module can also sort duplicate path aliases, such as "about" (which many domains might have).
Site Factory with AEGIR
Aegir is a distribution that automates most common tasks related to deploying, maintaining, or backing up your Drupal sites. It is a "super distribution" in the sense that it can administer all distributions installed on your server.
Aegir is very similar to a multi-site installation in that, as soon as you define a distribution — a set of modules and features with a theme is available.
And once Aegir is installed → You can easily deploy an unlimited number of sites based on this distribution.
What AEGIR brings compared to multi-site:
- The ability to host on different servers;
- A graphical interface for deployment, migrating from one server to another, creating test environments, and updating the sites involved.
- Other “Drupal” distributions can be managed with Aegir, for example a specific distribution for minisites, intranets, etc.
Comparison Multi-Sites (and AEGIR) vs Multidomain
| Multi-sites (and Aegir) | Multi-domains |
|---|---|
| A multi-site installation is by far the one that offers better performance along with a much higher capacity for scaling up. | Domain Access uses only one database. Behind several "virtual" sites there is actually just one and the same physical site. |
| Since each sub-site has its own database, the traffic on one sub-site doesn't really impact the others. | This type of setup directly affects performance and scalability. And, a shared database also means a single point of failure. |
| In a multi-site installation, the content and users of each sub-site are stored in separate databases. The admin interface thus remains clear and perfectly organized. |
Domain Access relies entirely on content syndication distributed across several domains. This can quickly result in a large amount of content (views, menus, blocks) in the Drupal admin interface. |
| Depending on the context and nature of the project, having to manage separate databases can be an advantage or a disadvantage. But in all cases, one sticking point remains. Content and users can't be directly and immediately shared. This can become very problematic for small teams or, worse, when a single administrator is forced to constantly juggle the admin panels of each sub-site. |
Due to the shared database, the most annoying issue with Domain Access is that the menu becomes complex to manage for the administrator. |
| With Multi-sites, all sub-sites fully share the same codebase, but it's absolutely possible to install modules or a theme specific to each sub-site, all while retaining Drupal's full flexibility and without affecting other sub-sites in any way. |
With Domain Access, even if a module is installed for just one sub-site, it must still be loaded through Drupal’s bootstrapping process. In other words, you can't “physically” limit a module to just one sub-site. |
How to choose?
To ensure you make the best choice between Multi-sites and Domain Access, it is highly recommended to ask yourself the following questions:
- How many sub-sites will you have to manage?
- Is it necessary/mandatory to have just one admin panel?
- Will you need to share content and users between the different sub-sites?
Sample requests:
- Case #1: You want 30 similar but independent sites.
- Case #2: You want 30 similar sites, with a single admin backend and the ability to share content between sites.
- Case #3: You wish to develop a product (a distribution) in which all users can participate via the website.
Now, in light of the explanations above, here are the recommendations for each situation:
- Case #1: Multi-site
- Case #2: Domain access
- Case #3: Multi-site using Aegir
We like Aegir but we must mobilize the community to help evolve the solution which, as it stands, can't support Drupal 10 sites. The rewrite work for Aegir5 is underway and we hope to support these efforts to release a stable version as soon as possible.
Conclusion and key things to watch out for with the “Domains” option
This is a very foundational choice from the start. Once we select an architecture and deploy it, it's hard to go back.
This limitation mainly concerns modules that deeply alter Drupal:
- User and role management (access rights);
- URL rewriting.
With Domains, take the example of a menu: either we have a single menu for everyone and, depending on the current domain, redirect to the correct pages. But if one site wants its own module, then you have to make a copy and tell Drupal that on this domain, this menu will be shown instead of the default one.
Same goes for “Views”: by default they take a context parameter corresponding to the current Domain. Similarly, you might have a “News List” View that, for each partner site, only displays its news and the central portal’s news. But if a partner wants a different view, it will need to be duplicated, etc.
Structure modifications (such as specific fields for one partner and not another), while technically possible, should be limited to avoid complicating maintenance.
If every partner accepts a unified structure and the only major differences between each portal are:
- The Drupal theme (appearance, colors, a logo)
- The default “document base” to query
- and, of course, the content on each site can be different.
... Domains will be a good solution.
We believe it’s important during the design phase to collect each partner’s requirements carefully in order to create the best structure, one that offers good compromise for everyone and which should be adhered to as much as possible.
If each site administrator imposes their differences and wants additional features, it will quickly become technically and organizationally overwhelming. This is something that can occur during a project and is not fully under our control.
One last thing to watch out for: if, for whatever reason (overload, attack, etc.) one site goes down, then they all go down.
Regarding content export if a partner decides to leave the group:
- It’s complicated to isolate the site and host it elsewhere (unlike with multi-sites);
- But exporting the partner site's content (in XML/JSON format) is, of course, possible. Drupal 9/10 can (with some back-office configuration work) expose any entity as a REST API.