Why would you still want to opt for a Drupal multisite setup? What strong reasons are there for using this Drupal 8 feature?

I mean when there are so many other tempting options, as well:
 

  • you could use Git, for instance, and still have full control of all your different websites, via a single codebase
  • you could go with a Composer workflow for managing your different websites
     

On one hand, everyone's talking about the savings you'd make — of both time and money — for keeping your “cluster” of websites properly updated. And yet, this convenience comes bundled with certain security risks that are far from negligible.

Just think single point of failure...

Now, to lend you a hand with solving your dilemma, let's go over the key Drupal multisite pros and cons. So that, depending on your:
 

  • developers' skill level
  • current infrastructure 
  • project budget
  • hierarchy of priorities
  • host capabilities
  • multi-site infrastructure's specific needs
     

… you can decide for yourself whether a Drupal multisite setup does suit your situation or you'd better off with one of its valid alternatives.

And whether you agree that it should eventually get removed from Drupal 9.x or not.
 

1. Drawbacks for Using the Multisite Feature/Arguments for Removing It

Now, let us expose this built-in Drupal feature's main limitations. Those that might just make you think twice before using it:

 

  • there's no way to update the core of just one Drupal website from your setup; you're constrained to update them all at once, every single time
     
  • it becomes quite challenging to assign a team with working on one (or some) of your websites only
     
  • it's not as richly documented as other built-in features (especially if we consider its “age”)
     
  • it exposes your Drupal multisite setup to security vulnerabilities; it's enough for one website from the “cluster” to get corrupted (accidentally or intentionally) for all the other ones to get infected
     
  • reviewing code becomes a major challenge: you can't “get away with” writing code for one website only; instead, you'll need to rewrite code on all your websites included in the setup, to test it against all breakpoints and so on...
     
  • putting together test and state environments gets a bit more cumbersome
     
  • in order to efficiently manage such an infrastructure of websites strong technical skills are required; are there any command-line experts in your team?
     
  • having a single codebase for all your Drupal websites works fine if and only if they all use the same settings, same modules; if not, things get a bit... chaotic when, for instance, there's a security issue with one module, used on all your websites, that affects your entire ecosystem
     
  • also, since your shared database is made of a wide range of tables, when you need to migrate one site only, you'll have “the time of your life” trying to identify those tables that belong to some websites and those that they all share

     

2. Top 3 Reasons to Go With a Drupal Multisite Setup

Now that we've taken stock of the main drawbacks for leveraging this Drupal feature, let's try to identify the main reasons for still using it:
 

  1. A heavy-weighing reason is given by the time and money you'd save on updating your “cluster” of sites. With the right experience in using the command-line you can run the due updates in just one codebase and have them run across all your websites simultaneously
     
  2. It's an approach that becomes particularly convenient if you need self-hosting for your setup (e.g. take the case of a university hosting all its different websites or a Drupal distribution provider...)
     
  3. You'd be using less memory for OpCache and this benefit becomes particularly tempting if you're dealing with RAM constraints on your servers
     

3. In Conclusion...

There still are solid reasons to opt for a Drupal multisite setup. Reasons that could easily turn into strong arguments for not having it removed in Drupal 9.x...

But there are also equally strong reasons for getting discouraged by the idea of leveraging this age-old feature. And where do you add that from Docker to Composer and GIT, you're not running out of options for managing your “cluster” of websites.

In the end, the decision depends on your situation, that's made of specific factors like budget, hosting capabilities, whether your websites are using the same modules, etc.

The answer to your “Are there any valid reasons for using the Drupal multisite feature?” cannot be but:
 

Yes there are, but counterbalanced by certain disadvantages to consider.”


 

Image by Arek Socha from Pixabay

Development

We do Drupal development

Go to our Drupal page!

Visit page!

Recommended Stories

React.js vs Node.js: What Are the Main Differences? Which One to Choose for Building Your Next Web App?
They're both widely used, subsets of JavaScripts, high performing and yet... they're technically different. But… (Read more)
RADU SIMILEANU / Aug 1 '2019
Best of July: Top 5 Drupal Blog Posts that We Have Bookmarked this Month
It's that time of the month again! The time when we express our thanks to those Drupal teams who've generously (… (Read more)
Adriana Cacoveanu / Jul 31 '2019
What Are the Best Google Site Search Alternatives? Top Reasons to Consider Cludo
What are some powerful Google Site Search alternatives? On-site search solutions that should be:   flexible… (Read more)
Adriana Cacoveanu / Jul 29 '2019