Multisite Management

Drupal allows you to manage many sites with the same code through its multisite feature. This can be useful in many settings where it’s desirable to have parity across a large number of Drupal applications. Leveraging one codebase allows for a level of scale where you can manage a lot of sites uniformly way. However, this comes with some benefits and drawbacks that adopters should be mindful of before they implement.

In this chapter we’re going to cover the following main topics:

• The multisite feature
• Benefits
• Drawbacks
• Automating deployments across many sites

The multisite feature

Every Drupal codebase has a site’s directory. Single site instances leverage a sites/default directory to store the Drupal application settings, which includes its corresponding database. Another standard convention is to place custom and contributed modules within the sites/all directory. The intention for this convention is to potentially share code. The “default” site still has access to the code found in sites/all.

Default does not have to be the only site if used at all. Suppose a university wants to offer each department its website but wants to maintain all websites through centralized IT. One Drupal codebase could be leveraged that has a specific site directory for every department in the university. The same modules and features can then be installed on each site given they're all running the same code.

Each Drupal application has a sites.php file that helps map a domain to its corresponding site directory. This is not...

Benefits

Drupal developers get major benefits and significant drawbacks with the multisite feature.

The main benefit is consistent governance to help manage sites at scale. Imagine having to manage hundreds or even thousands of similar Drupal applications. Performing code updates site by site would be extremely laborious.

Another benefit is growth. New sites can be added at any point and they can build off of the existing systems and code implemented. Practices established for leveraging multisite can readily be extended to more sites.

Drawbacks

The main drawback is failure at scale. Code updates can be problematic, especially given Drupal’s value proposition is its extensibility. Updates that introduce regressions are not caught on just one or two sites, they're deployed to all of them. And, once the code is updated, the Drupal application needs to be updated. This must happen immediately. It is impossible to manage failures in just one site; each site needs to be remediated. And, it’s common that a code-level failure applies to one if not all, sites.

To do any level of testing before deploying to a large number of sites, it is important to use environments and perform rigorous testing against multiple sites. Check logs for anomalies and run automated tests. All of these steps should be done before a production deployment to mitigate risk.

A similar approach is leveraging a shared codebase with orchestration but without multisite. Developers often use Git repositories to manage Drupal codebases...

Automating deployments across many sites

When leveraging multisite, it is important to consider automation. Updating every site in a large-scale Drupal multisite implementation would be difficult, especially given the frequency with which updates happen.

Drush provides helpful commands to manage this.

$ drush site:alias > list-of-sites.txt

The preceding command prints a list of site aliases for a Drupal application (https://www.drush.org/12.x/commands/site_alias/).

$ while read s; do \
drush sql-dump > backup-$s.sql \
drush "@$s" deploy \
done <list-of-sites.txt

This small script takes the results of each alias from the previous command and performs a deployment. While it is a simple example, a script could then invoke rollback logic upon error.

$ if grep -Fxq "error" list-of-sites.txt \
then \
while read s; do \
drush "@$s" sql-import -y < backup-$s.sql \
done <list-of-sites.txt \
fi

It is highly recommended that you stage...

Summary

Drupal multisite can be an option if you wish to run a large number of similar sites with the same codebase. The benefits of consistency and centralized management of multisite can be appealing over maintaining a large number of single Drupal applications. However, code deployments and testing can become complicated, especially if regressions are introduced.

That concludes this book. Drupal is a powerful tool that covers different personas, such as a site builder, developer, site administrator, and even user. It has many features that can be enabled and configured based on the needs of an application. It also has an underlying framework that can be used to extend for custom modules and themes. While the book would not effectively be able to cover every topic and every technology in depth, hopefully, the book offered a broad overview that proved useful.

We express our sincere gratitude for accompanying us to the end of this book. Again, thank you and wishing you success...