- Drupal's built-in "multi-site" feature was invented a decade ago.
- It is hardly documented.
- IF and after you managed to set it up, there's a 99.9% guarantee that your sites will blow up with unrecoverable errors and data loss — especially when running module updates (due to potentially shared database tables).
- It requires custom settings as well as highly advanced customizations and custom code changes for Drupal core to work out in practice — built-in features should not require you to hack core.
- D7 introduced a new
/sites/sites.phpfile to specify site aliases.
- D8 only enables the multi-site functionality, if
/sites/sites.phpexists, so as to skip it for the 99% use-case
- …because the fundamental idea is obsolete to begin with.
Deprecate in 8.X.Y
Remove in 9.X.Y
The modern approach to multi-site is:
git— Same code, different sites. Under your control. And well-maintainable.
If there's any point in shared database tables → The
'prefix'array of Database connection info in
settings.phpstill exists. Sharing a db table between different sites is still possible.
In Drupal 8 and beyond, it is much more likely that you want to replace the storage/backend of selected services with a shared storage/backend — if that makes sense for your setup (because application state still has to be synchronized separately/manually).
Anything else falls under the umbrella of installation profiles.
Simpler use-cases can be resolved via symlinks.
User interface changes
- ~100 lines of incomplete docs in
- Plenty of incomplete drupal.org handbook pages: Gone.
An alternative site directory will only be kept for testing framework purposes, hard-coded into
DrupalKernel, in order to still be able to install a cleanly isolated test site for web tests.