One Shoe | 11 dec 2015
This is the second article about 'Multi-site/Multi-domain' solutions.
With a multi-site or multi-domain solution it is possible to create, manage and deploy multiple websites from one Drupal CMS installation without needing Drupal developers or IT support. But what is a multi-site/multi-domain solution exactly and what are the differences?
With a multisite or multi-domain setup it’s possible to support the most basic multi domain form - which is websites that look similar with simple variations in the content of each website - to websites that are so different from each other that you wouldn’t know they are based one and the same CMS, just by looking at them. In this article we’ll share some of our insights about choosing, designing and developing Drupal multisite and / or multi-domain solutions.
Although for many content managers the difference between multisite and multi domain might be irrelevant, technically and from the developer standpoint, the differences between the two are a big deal. So what ís multi-site and what is multi-domain exactly? Well, although there’s a gray area where there’s a sliding scale between the two, it boils down to this;
A multisite setup allows for more individual freedom (differences) between sites and is mostly useful for sharing code (modules and themes) across multiple websites.
The main benefits in a multisite setup come from an IT standpoint and are derived from the fact that the multisite setup reduces maintenance efforts on both the Drupal end as well as on the infrastructure end. Updates for server OS, server applications, database software, Drupal core and Drupal modules - including their releases - only have to be implemented once instead of for each server and website individually. This also reduces testing efforts in theory, however, considering current testing-, maintenance- & deployment techniques, it’s debatable whether this benefit outweighs the extra investment that is needed to setup the multisite architecture.
A multi domain setup enforces more restrictions and uniformity between sites and is mostly useful for sharing users and content across multiple websites. Is is relevant to take in consideration though, that the most commonly used Drupal’s Domain Access module has major impact on the Drupal installation, making the entire system more fragile and prone to bugs.
* These are over-simplified generalizations. The multi-site setup may not need different physical databases site-specific tables within one physical database may apply. Case specific details will influence strategy and architecture decisions. Security, multilingual challenges, system integration and other factors may also be relevant.