Multisite

Multisite is a way to host more than one Drupal website from a single Drupal installation. You install core, modules and themes once, then add a folder under sites for each extra site. Which folder answers a request depends on the address that was asked for.

How multisite works in Drupal 11

The Drupal.org multisite documentation, written for Drupal 8 and later, describes the sites as separate and independent, each with its own database, configuration, files and base domain or URL.

Three pieces of core 11.4.10 make it work:

• sites/sites.php. The file switches the feature on. Core's INSTALL.txt tells you to copy example.sites.php to that name. Without it, DrupalKernel::findSitePath() always returns sites/default.
• One folder per site. Each extra site gets a subfolder of sites with its own settings.php. The easiest start, according to INSTALL.txt, is to copy default.settings.php from sites/default.
• Site-specific code. A site folder can hold its own modules and themes directories next to the shared modules and themes in the web root. Code in a site folder is not available to the other sites.

Install profiles work the other way round. The README in the web root's profiles directory says profiles placed there are available to every site during its first installation, so each site can start from a different install profile.

Folder names come from the site's address. INSTALL.txt says to leave out www. if visitors can reach the site without it. A port counts as the deepest subdomain, so http://www.example.com:8080/ can load from sites/8080.www.example.com/. A path becomes a dot-separated suffix, as in sites/sub.example.com.site3.

Example

Three sites share one codebase:

sites/sites.php
        sites/default/settings.php
        sites/example.com/settings.php
        sites/sub.example.com.site3/settings.php

For the request www.sub.example.com/site3, INSTALL.txt says Drupal checks the folders in this order and uses the first one that has a settings.php:

sites/www.sub.example.com.site3
        sites/sub.example.com.site3
        sites/example.com.site3
        sites/www.sub.example.com
        sites/sub.example.com
        sites/example.com
        sites/default

Here the second entry matches, so the request is served by the site3 site.

Common mistakes

• Leaving trusted_host_patterns too narrow. The comments in default.settings.php say that on a multisite you should list every host pattern the sites use.
• Running Drush without --uri. The command then runs against the default site, not the one you meant.
• Expecting one configuration export for all sites. Databases are separate, so each site needs its own configuration export and import.

For marketing and content teams

With multisite, brands or country sites can look and behave differently while one development team maintains the code. The trade-off is the shared codebase: when your developer updates a module through Composer, the new code reaches every site in that installation. Ask which sites share a codebase before you request a feature that only one of them needs.

Sources

• Drupal.org: Multisite Drupal
• Drupal.org: Multisite folder structure in Drupal
• Drupal core 11.4.10 source: INSTALL.txt, Multisite configuration section (git.drupalcode.org)
• Drupal core 11.4.10 source: DrupalKernel::findSitePath() (git.drupalcode.org)
• Drupal core 11.4.10 source: example.sites.php and default.settings.php (git.drupalcode.org)
• Drupal core 11.4.10 source: profiles/README.txt (git.drupalcode.org)
• Drush: config:export command