Multisite Drupal considerations

The primary reason for using a multisite Drupal setup is to save your time when you manage more than one Drupal site running the same version of Drupal core. Each time a new Drupal core update is released, you would only have to perform that update on one codebase set instead of doing it for each site. But there are drawbacks.  These are mitigated, however, if you're using the Aegir hosting system.

Otherwise, the complexities and potential problems of trying to manage a multisite setup manually require fairly advanced technical skills. Users with that level of expertise are usually familiar with using the 'command line', and from the command line, you can update each site you administer in less than 2-minutes.  With Aegir, it's even faster as all sites can be queued for updates in a point-and-click fashion by migrating the entire platform (Aegir-speak for a multisite codebase) to a newer one.  Any sites that fail will be automatically rolled back.

Multisite basics

Although a Drupal site requires a web server program (Eg. Apache or IIS), a database program (Eg. MySQL or MSSql), and a PHP interpreter to run, everything that is unique to your site is contained in your database and codebase.

A Drupal core update is essentially a replacement of your codebase. Your database is left unchanged, with the exception that after you replace your codebase, you need to run the 'update script' [YOURSITE/update.php] for each site.

Reasons to use one database per site

The databases work in the background and are tended to by the codebase. Typically you will never have a need to bother with a database at all.

There is little, if anything, to be gained by trying to use only one database for multiple sites. The small savings in disc-storage you might get from having only one database is greatly overshadowed by the potential problems you can have from doing that.

• If data from one site is corrupted, either accidentally by you or other users, or is corrupted by a malicious attack, all sites can be affected.

• A database is made up of a multitude of 'tables'. If you decide to migrate one of your sites out of a multisite setup, you will have a difficult time determining exactly which tables belong to each site, and which tables are shared by all sites.

One codebase per site

In theory, having one codebase for all sites running the same version of Drupal would be a time and disk-space saving thing.

Disk-space is cheap, and so let's forget that as a consideration.

As mentioned above, updating each Drupal site when a new core version is released, can be done in a few minutes from the command line, and so your time might be better spent learning that skill instead of trying to tangle with learning how to implement and troubleshoot a multisite setup.

A shared codebase setup would be most beneficial only if all of your sites are using the exact same modules and settings, as for example, if you were managing all of the separate and distinctive sites for each sports team in a league.

If the multiple sites you administer are using different modules, however, then you face the hazard of a bug in a module that not all sites use, disrupting all sites.

Updates on multisites

If you do an update, remember also to update the database (yoursite/update.php).

• This is valid not only for core updates, but also for shared modules (which is by default).
• It is required for every site on your multisite system, which also has the same modules installed. As example: if you have installed the "slick" module on 10 sites and did an update on 1, you have to use update.php on all other 9 sites too.

Setting up a Drupal 8 multisite

If you want to set up your Drupal sites in a multisite configuration, start here.