Deservedly called an enterprise-level CMS, Drupal offers flexible ways to fulfill the needs of any enterprise. One of the common needs of universities, government institutions, corporations, and other even large and complex organizations is to have a series of related websites that would be easy to manage.

Absolutely achievable with Drupal! For this purpose, there is the multisite approach. Read on to learn more about Drupal multisite and the flexible ways to manage multiple sites within the setup. The sites may share the general settings and differ where it is necessary — exactly what is required by the departments within an organization. That being said, our attention will be especially focused on Drupal multisite configuration management.

The main things to know about Drupal multisite

Drupal multisite is a setup that allows you to create and manage multiple Drupal installations from the same codebase. In addition to the codebase and the Drupal core, sites united into a multisite setup have the same set of available modules and themes.

However, this fact does not make them all identical. Multisite-based websites have different databases, URLs, content, and users. The sites may look different in design or similar, just visually distinguished by logo and color — all this is up to the customers to decide. And, of course, they may differ in layout components, menus, editorial workflows, modules or themes that are enabled per site from the list of available ones, and many other things that belong to Drupal configuration that we are going to discuss further in this post.

The main mission of Drupal multisite is to save time and costs for website creation, maintenance, updates, and deployment. Doing all these actions using the same codebase is significantly faster and easier. This makes multisite a very reasonable solution for organizations that need a set of websites.

All this sounds very nice, but multisite also has downsides (or things to consider). The sites remain closely connected so performance or security issues or other errors on one of them may affect the whole ecosystem. Next, multisite is not for everyone — it’s only suitable for websites that are similar in information architecture and features, otherwise it may bring more complexity than benefits. Finally, for multisite management to be fast and easy, you need to know some subtle nuances and tricks about it. Many of these are related to Drupal multisite configuration management that we are now moving on to.

Drupal multisite management with shared configuration

Drupal configuration includes plenty of important settings for websites:

• site name
• contact information
• color settings of the theme
• content types and their fields
• Views
• taxonomy vocabularies,
• image styles
• user account settings
• content management workflows
• enabled modules
• module settings
• and much more

How to avoid the overhead of configuring this on each site separately — for example, installing a new module on each of them one by one? Luckily, when using multisite, it’s possible to use a shared configuration.

As of Drupal 8.x, we got a new configuration management system that was deservedly named one of D8’s best benefits. The new system makes it easy to save the configuration into a YAML file and restore it on any website. It is fully applicable to the multisite setup, very straightforward, and requires no hooks. All sites within the multisite ecosystem can receive the new features simultaneously every time they are added.

Partial configuration sharing in Drupal multisite management

Despite the benefits of the Drupal configuration management system, it also has some limitations — it only allows for full imports and exports. But, of course, as we mentioned in the multisite approach overview, websites need to differ in their configuration. At least, they differ in the site name, logo, contact information, but also there are so many other specific config items that vary across the sites based on their requirements.

The great news is there are contributed modules that enable developers to have their configuration shared partially and avoid using the whole set of configurations across the multisite ecosystem. There will be site-specific config options in addition to the shared ones. These modules are very helpful when it comes to multisite configuration management.

• Config Split
  The Config Split module for Drupal (Configuration Split as the full name) enables developers to use specific configuration subsets meant only for specific websites or groups of websites. This is very useful, for example, if there are modules that only need to be enabled on certain sites and disabled across the other sites in the multisite setup.
  In addition to multisite, the Config Split is widely used for splitting configurations between different environments of the same website — the classic example is disabling the Devel module in production. The key maintainer of the Config Split module — Fabian Bircher (Bircher) — gave a great speech “Advanced Configuration Management with Config Split et al” at DrupalCon Vienna and summed it up in slides. Here is a quote from his speech:
  

  “For example, you have the Devel module and you don’t want the Devel module on your production site, but the configuration management is just all or nothing. So you would have to disable the Devel module, then export. You don’t want that — it’s a hassle and error-prone if you do it manually. You can do it with Configuration Split — you list the modules you want to split off and add environment-specific configuration.”

  
  Using the Config Split module, developers can define the configuration subsets for separate directories. The module allows them to select configurations from site-specific folders every time the import takes place.
  The Config Split module depends on the Config Filter module for the integration with the config import/export workflows in the Drupal admin dashboard and Drush command-line interface. The module’s work is fully in line with Drupal’s configuration management system — it just filters the configurations and allows for the use of the main folder and separate folders.
• Config Ignore
  Another module for shared configuration management in Drupal, the Config Ignore, is also brought to you by Fabian Bircher. The module is meant for protecting specific configurations from being overridden during the config import. The configuration you want will always stay in place.
  For example, the system.site configuration containing the website’s name, slogan, email, and similar details always differs for every website in the multisite setup. It can remain untouched no matter what the main configuration folder includes. All you need is to configure the module to ignore the system.site settings and all other settings that vary across the sites.
  The ignored configuration will be applied upon the installation of a new site in your multisite setup, but will never be imported again later. To avoid using the base configuration at all, you can either try the Config Export Ignore module or use a .gitignore in the config directory.

Final thoughts

Indeed, Drupal multisite is meant to simplify the workflows of multiple site management, but it requires the right approaches and tools. Hopefully, our tour of managing Drupal multisite configuration has been helpful. Drop us a line to get a quote on whether your business will benefit from Drupal multisite and how our Drupal team can make your multisite management as convenient, smooth, and flexible as possible.