Drupal Multisite Guide: Less Work, More Output

Have you ever heard that a single business has a lot of different branches or mini-businesses? It’s pretty common in the day and age we live in. The business world has grown immensely and so have its needs. And a single website isn’t enough to fulfil those needs.

So, what do businesses do? They build multiple websites, which should have been a great solution, but is really more of a stressful trigger waiting to go off. This is because managing those multiple websites is a pain, for lack of a better word. It results in slower building process, increased overheads, lack of control and scarce visibility, so yeah, a pain describes it pretty well.

What is the solution then?

A multisite structure that allows you to create multiple websites using a commonality. It would require less work to build, yet provide the much needed autonomy for the individual sites on the setup. And that is what we are going to be discussing today, but in regards to Drupal.

Drupal, being a popular CMS, has a lot to offer, when web development is considered. The sites developed using Drupal are versatile, scalable and provide amazingly powerful digital experiences. And one such feature that contributes to that power is the Drupal multisite setup. So, for whoever asked, ‘Does Drupal support multisite?’, the answer is yes and it does so exceptionally well. Let’s find out how. 

Drupal Multisite: What is the setup about?

Have you ever baked a cake? The core ingredients being flour, eggs and sugar are all the same for every cake. It's just the flavour and the toppings that are different. Drupal multisite can be understood with the same analogy.

As the name suggests, you can have multiple websites, tens and hundreds of them, working for you with ease using the multisite feature. You can have Drupal multisite with different domains as many as you want.

What is going to be the same for every website in this setup? 

The codebase would remain constant throughout. You can have hundreds of sites without having to rewrite it. The Drupal core and the available modules and themes are also shared by the multiple websites. These form the flour, eggs and sugar batter in the Drupal cake.

And what is going to be different in the multiple sites?

Everything other than the codebase is different. You would have independently running websites that would serve the needs of its target demographic.

The sites would have their own database;
The sites would have their own configuration, in terms of enabled modules and themes, content and more; 
The sites would have their own files, inclusive of images, uploads, user profiles and more; 
And the sites would even have their own base domain or URL. 

So, in essence Drupal multisite would provide you the opportunity to create multiple websites using the same codebase, however, all the sites would be different from one another, serving different audiences. 

How is that possible?

Because of server requests. Let me clarify it a bit. All of the multi sites created using this setup are stored in separate folders. Drupal multi folder structure can be separated from multisite repositories, making deployments easy for site maintainers and front-end developers alike. On top of this, each of these folders would have its own personal php file with connectivity to its own personal database.

Now, add to this equation, Drupal’s fine ability to map a request based on the domain it came from, this ability is further enhanced by loading the right database and configuration based on the said domain. The result is the website that the requester wanted being served on a platter. Pretty cool, isn’t it?

What do you gain out of it?

After understanding the basic concept and working of Drupal multisite module, the next thing that pops up in our minds is its benefits. Why should you take it up? What’s to gain out of it? And that is where I come to tell you all about the amazingness that is Drupal multisite.

Benefit from faster launches 

The best part of Drupal’s multisite feature is its ability to create newer websites in a matter of minutes and without much support from IT and developers. 

The built-in installation profiles are the reason for the faster launches. It essentially holds the functionality and configuration into installable packages, which can be launched as many times as you want them to. And you would have a new website that’s fully ready for the content entries. 

Benefit from saying no to compromises 

The second multisite benefit comes in the footsteps of the first. Because multisite helps in creating faster launches, it allows you to not compromise when deadlines are looming.

For every project, there is a deadline that needs to be met and as this deadline starts to come closer, potentially lucrative features start to move farther and out the door. Developers start making compromises and technical debt starts to build up.
 
Now, you could let a feature or two go out the window in a single build, however, when there are close to a hundred websites in development, that thought won’t even cross your mind. It is suffice to say that multisite architecture boasts a higher quality standard and minimal technical debt. The primary reason for that is time, creating multiple systems at once gives you ample time to think about potential and the time to make them part of the project in reality.

You create long term solutions with a multisite setup that come with a higher refactoring potential from the management because there are multiple sites involved. 

Benefit from lower maintenance and reduced costs 

Another advantage of a single code for multiple websites is that you have to spend less time on maintaining it as compared to multiple codebases for multiple websites. Wouldn’t you agree? 

If you encounter a bug on any one of these sites, you would fix it for all of them. This considerably reduces the time spent on maintenance and consequently the costs that accompany it. With Drupal multisite, you can keep track of updating and reviewing at one place, thereby, keeping a convenient grip on maintenance.

Benefit from saving your efforts 

I saved the best for last; with Drupal multisite, you actually save yourself a lot of time and effort because you can reuse your code or components of it. You would only have to build a feature once and thereon, you’d only have re-use, no wasted effort for building the same thing over again.

A reusable code with a shared library entails; 

Reusable integrations; 
Reusable functionality; 
Reusable UI components; 
Reusable workflows; 

And you can also reuse a theme with Drupal’s theme inheritance mechanism, allowing you to create a base theme for other themes to inherit the basics from. 

All of this saves a ton of effort in the development process. You should know that you can also try to reuse components for sites not on the same platform, it would be extremely difficult, but possible.

What options does Drupal multisite offer?

While setting up for Drupal 9 multisite, there are a few choices available. The essence in all of these choices is the same, which is a strong commonality through a single codebase. Moreover, you will get all the benefits we just talked about in the previous section in all of them.

So, let’s understand the kind of range Drupal multisite comes with.

Conventional approach: Classic Drupal multisite architecture

The conventional approach essentially sums up the meaning of Drupal multisite, as we talked about while understanding the concept. There would be multiple sites in this option, with multiple configurations and multiple databases, however, there would only be one codebase shared amongst all. The diagram below describes the architecture pretty aptly.

I would be wrong, if I said that it's only the codebase that is shared. Technically, out-of-the-box that is the case. However, if you want your multisites to share more than that, you have an option. The Features module, a unique trait of the conventional architecture in Drupal, can help you in that. It allows sites to have shared features by importing the configuration from it. Config Split further eases the workload by segregating which configuration needs to be shared and which needs to be quashed.

Contrastingly, I have mentioned that you can create independent and somewhat unique websites using Drupal multisite, if that is what you wish for. This is possible because it allows you to customise because of isolated configurations. As such you can create your own custom themes and modules for each of your websites.

Multi-domain architecture

The multi-domain architecture isn’t all that different from the multisite. There is a single codebase, however, along with that there is also a single and shared database, which isn’t the case in multisite. Here is a diagram for better understanding.

Through the multi-domain architecture, you’ll be maintaining a single Drupal installation, which is quite easy; on top of this, you will also be able to maintain the configuration and functionality with ease. 

The Domain Access modules are at the heart of this architecture, as it makes it possible to serve multiple sites. It also allows you to categorise your content as shared and unique, you can decide a specific piece of content for one particular domain, then you can also share it across all sites, if that is what you want.

With more sharing in this architectural design of Drupal in terms of features, functionality, content and even users, updating a single site is a walk in the park. 

In terms of the drawbacks, the one that outshines the rest is that you can’t have any exceptions. In multisite, you could add additional functionality to individual websites, but you can’t do it here. Well, you can, if you wanted to, but you see, the intention behind multi-domain architecture is simplicity. And adding exceptions to each site would contradict that big time. Even while using contrib modules you would have to be extra careful in checking their compatibility with Domain Access.

Other notable architectures

There are three other multiple site architectures in Drupal, let’s shed some light on these as well.

Based on Drupal distribution

Have you ever bought a cake mix? It's a ready-made mixture of everything that goes into the cake and all you have to do is make it into a batter and put it in the oven and you’ll have your very own baked cake. Easy, isn’t it? This is basically what a Drupal distribution is. 

You get a mix of everything you would need to start your web projects, from the required modules and libraries to custom themes and modules and from the configuration to possibly the default content. It’s a website starter pack. There are popular Drupal distributions to choose from, like Commerce Kickstart and Lightning, but you can also make your own custom distributions. Take a look at this complete list of major Drupal distributions that you must try out.

The way these are different from multisite and multi-domain is through the codebase, each site would have its own and each site would also have its own hosting account.

The major drawback here is that it requires extra work. It’s kind of ironic for a cake mix, I know. You would have to maintain the distribution codebase as well as each of the sites. Security updates and bug fixes need all the more attention, if your distribution is published on Drupal.org.

Based on data silos

A multisite architecture on data silos is similar to Drupal distributions, in the sense that the codebase is different for each site, providing greater autonomy and better security. For businesses with multiple branches and departments that seek decentralization, yet a kind of uniformity, this is a great choice. 

Based on multilingual needs

This one has a similarity to the multi-domain architecture, as there is a shared codebase and database. It allows sites to capitalise on language-based regional targeting. With less development efforts and less building costs, each site would have its own language and its own regional audience. Learn more about why Drupal is great for multilingual sites here.

When can you optimise the setup the most?

Now comes the part of knowing exactly when to optimise Drupal’s multisite architecture. There are particular use cases and considerations that make the setup an ideal choice, let’s understand them.

Do you have multiple sites?

As the name suggests, for Drupal multisite to work its charm, you have to have multiple sites as in two or more. The prime reason for this setup’s mere existence is to help you in saving time and effort in the management of multiple Drupal sites by making them run on the same Drupal core.

Think about it, if you have two or more sites not running on this setup, you’d be responsible for each code individually and it would differ drastically for each site. This difference can become a mammoth task for managing, so doesn’t choosing multisite and eliminating this worry sound like the better choice?

Are they similar to each other?

Now, you could have multiple websites, but they have to have a degree of similarity in order for the multisite setup to work. Dramatically different sites in terms of features and aesthetics are not ideal for this architecture. That’s not to say that each site has to be a clone of the next. No, every site would obviously have its own content, moreover, it could also have different functionality, but that difference cannot be dramatic, just a feature here and there.

Take a university for instance, it could need multiple sites for its varying departments. Now in this case, the university could opt for the multisite feature because despite different websites, it would most definitely maintain a sense of uniformity in them. 

In essence, Drupal multisite creates replica sites with different themes for each site, if that aligns with your requirements, you should definitely opt for it.

Do you have the technical infrastructure?

Drupal multisite is meant to make your job easy, but it can only do so if you have the right technological infrastructure and expertise to handle that. 

• The right hosting environment to manage multiple domains and deployment mechanisms. Your hosting provider should be proficient in knowing the exact requirements of your setup.
• The right DevOps processes that are compatible with your multisite setup. When it's said that multisite setup makes you work less, automated deployment is one reason for that, so, your DevOps need to be efficient at that. 
• Finally, the right testing environment because you deploy multiple sites at once, the chances of errors are on the higher side. A break in functionality can become colossal and checking for it manually is hard work. So, an automated testing environment that is equipped with tools to ensure higher quality standards is crucial.

Can going multisite pose challenges?

There is always a darker side of things, and Drupal multisite is no exception to that. There are certain drawbacks that accompany the setup that can leave a sour taste in our mouth. For many, these challenges have become the reason for not opting for the multisite architecture. 

The challenge of failure 

The frontrunner in the list of multisite challenges has to be its chances of failure, which to be honest are fairly high. There are two reasons for this.

One is the fact that there is a single codebase for all the sites. This means if there is a problem with one, there is a problem with all of them. Take traffic spikes for instance, they might be great for one website, but for multisites, that one site can pose significant risks to the others.

Second is the failure due to human error, which cannot be foreseen or avoided. There is plenty of risk associated with updating a single site, imagine the level of risk when there are tens of sites. A single syntax error can become the reason for the demise of your multisite setup quite quickly.

The challenge of individuality and innovation 

Yes, we do say that the multisite feature has room for individuality for each site. And then we also say that each site has to be the same or at least similar to a great extent in order for the architecture to work. Do you see where I am going with this challenge? 

The innovative flair often seen in development is somewhat lost in the multisite setup. Why? Simply because there is a standard to be adhered to. And when you deviate from that standard, you set yourself on the path of losing all the benefits of this architecture.

Reusing components, without extra efforts, is one of the fortes of the multisite setup, and adding innovation into this mix would make it tedious and exhausting. That is why it is advisable to avoid the multisite, if your sites differ from each other in terms of features and functionality or even if you would want them to differ in the near future.

The challenge of technical insufficiencies 

I mentioned in the previous section that optimising Drupal multisite is going to serve you best, if you have the technical infrastructure for it. And this can become somewhat of a challenge, I’ll tell you why.

Compare building one site or multiple sites separately to building and maintaining a multisite installation. Now tell me, which do you think would require more technical expertise? The latter, I’m sure. The reason is the complexity of the comprehensive web of multiple sites, the amount of settings alone could give a newbie developer a headache. 

So, along with the technical infrastructure, including a suitable host, DevOps and testing system, the need for a skilled multi-site development team can become quite a challenge.

The challenge of losing open source 

Finally, the last challenge relates to the loss of Drupal functionality. With a multisite architecture, you become an SaaS provider and consequently part with a number of open source solutions. You become responsible for every feature that needs improvement or innovation, unlike the usual way of open source software, wherein the community plays a part in innovation.

Learn more about open source here:

• Perks of being an open source contributor and the merits of contributing to Drupal
• Open source licensing
• Open source leadership
• Open source security
• Open source diversity
• Impact of large companies on open source
• Open source being recession-free
• Impact of open source during Covid-19 pandemic

Conclusion

I would say that the challenges that the multisite architecture comes with do make you rethink choosing this path. However, when you consider the benefits along with its use cases, there isn’t a more perfect solution. 

A university site would not need to add extra innovative features to one of its department’s sites and therefore, the multisite is best suited for it and for other enterprises that have similar needs. Provided that you check all the right boxes in terms of multisite’s optimisation, you’ll not regret choosing it.