Updated on June 20, 2022

Often, you develop a website to be installed and used once, by one organization. But sometimes, for larger organizations, you need to develop a series of websites that are very similar. This case is very common in big institutions with independent departments or branches, such as:

  • Universities
  • Government Institutions
  • Corporate Divisions
  • Intranets

Multi-site: Same Code, Different Databases

As easy as it is to just duplicate an existing codebase, it's not necessarily a good idea to have dozens of identical website folders if most of this codebase could be shared.

Did you know that most Drupal sites using the same version, share around 99.8% of the source code? Drupal core, libraries, modules, themes... everything comes from the same place: Drupal.org. And for organizations that share the same functionality and look and feel across multiple sites, this number is even higher.

Drupal introduced multi-site support in 2005 (yes, 12 years ago) so that multiple websites could share the same codebase, but with different databases.

How to Create a Drupal Multi-site

Just like with previous versions, you can create a new installation either from scratch or as a sub-site of an existing Drupal installation. The only thing you need is a new empty database.

For a detailed list of steps, you can take a look at Drupal.org Docs about Multi-site - Sharing the same code base.

Using drush, you can run this simple command:

$ drush site-install --db-url=mysql://db_user:[email protected]/sample_site_db --sites-subdir=sample.subsite.com --yes

Multi-sites with Shared Configuration

Drupal introduced Configuration Management(CM) on the 8.x version. CM takes care of storing your current site configuration on files and then these can be restored over the same or on top of another Drupal site.

The biggest difference with Drupal multi-site is that we can use CM to increase the amount of shared resources between sites. With CM, sites can share the same base configuration as well as the same code base. You can have a two sites in a shared environment in which the only differences are the content and the "non-config" components of your site.

1 - Add the Config Installer Profile

$ drush dl config_installer

2 - Create config directory for exporting your current config

$ mkdir config

3 - Export your base config (this will be cloned on the new site)

$ drush cex --destination=config/base

4 - Install a subsite from the existing configuration

$ drush site-install config_installer config_installer_sync_configure_form.sync_directory=config/base --db-url=mysql://db_user:[email protected]/sample_site_db --sites-subdir=sample.subsite.com --yes

Partially Sharing Configuration

There are specific details like the site name, contact information and enabled modules, that you may want to exclude while sharing the configuration between multi-sites. Configuration management is intended to be used for full exports and imports, however, there are some contributed modules that can help you alter this functionality.

The config_split module allows you to create a separate configuration repository for a sub-set of your configuration files. This specific project is inspired by --skip-modules filter from drush that is very popular for excluding development modules like Devel to be enabled on Production environments.

What About Features?

If you've been using Drupal 7, for sure you'll be saying "I used to do something like this on D7 using Features".

Features is a module that is the precursor of configuration management. Initially, it was intended to export a reusable set of configuration bundled in a way that could be easily used on another Drupal site. Sounds familiar, right?

In Drupal, Features relies on configuration management, but at the same time to achieve its original purpose (bundling functionality for re-use across many sites). While configuration management allows you to export all config entities at once, Features links configuration all based on dependencies and exports a complete working package which you can install and update independently.

For example: if you export the blog post content type, all the related fields, settings, view modes and module dependencies for blog posts will be exported as well. And you can package this with the blog View and other related configuration.

The benefit of using Features in a multi-site environment is that you can select configuration that will be managed via Features and deployed across all sites, and use the tools for updating and reverting features to keep these site components consistent while others change. That being said, there are draw-backs to using Features. It will add to the overall complexity of your configuration management workflow and has relatively few users to date for Drupal.

What to do next?

If you are new to Drupal, I suggest you take a look at my Configuration Management blog posts:

If you want to learn more about multi-site setup, here are a few interesting links from Drupal.org:

Tags
Higher Education
Drupal
Drupal Planet