When large organizations build or rebuilt their sites, they may face a dilemma if they have divisions requiring their own web presence. It may be tempting to use Drupal’s multisite option for this, but the pros and cons need to be carefully weighed. There is a similar calculus when it comes to WordPress and its Network option, but this blog post is aimed at Drupal. Within Drupal the choice is usually between usinfg Drupal core’s multisite approach or the Domain Access module. The following applies roughly to both:
Let's define the two kinds of sub-sites in this context:
- Sub-sites without their own domain or subdomain, e.g. somedomain.com/subsiteurl:
- These will be styled using the Context module. This will determine which sub-theme to apply, or (more likely) which blocks and menus to display. This way each division can have its own menu showing, as well as a “return to main site” link somewhere in the header. We used this approach on https://www.rider.edu/, which has a subsite at https://www.rider.edu/wcc. They use the same theme, but based on the URL we display different things in the header, and we alter the styling a bit.
- Sub-sites with their own domains or sub-domains, e.g. subsite.somedomain.com or www.subsite.com.
- We should assume that if they have their own domain, these sites are different enough from the main site in terms of content and functionality that they warrant their own domain and their own, separate Drupal installation.
Pros/cons of using a separate Drupal installation per domain;
- Traffic spikes on one site won’t impact the others on the same server. This is a good thing.
- Security or code updates on one site won’t affect the other. This segmentation means that a faulty code or database update on one site won’t impact another site: this is good. It does, however, mean that such updates have to be run separately per site. That’s not a huge deal, though.
- User/admin access is separate from the other sites. In cases where someone from one site should have rights on another, it is not such a horrible thing for them to have a separate account on the other site. If we assume that a site with its own domain or subdomain is already going to have its own functionality and content needs, it is not a stretch of the imagination to say that they should have their own, separate users too.
- Content created on one site cannot be directly shared with the other.
- For example, if subsite.somedomain.com has news items, they won’t show in the somedomain.com news section by default. You could build in a workaround where subsite.somedomain.com has a news feed (RSS or XML) which somedomain.com uses to auto-generate its own news items for those subsite.somedomain.com news items, so that they can show alongside the other somedomain.com news items. You could also code this to auto-redirect to the subdomain.somedomain.com news items when users click those particular news items. This is just one example of how such edge cases might be handled. There can be other ways of handling that.
- You should limit how much content sharing there is between primary sites and their subsites (that have their own domain or subdomain). If they have their own domain, they are (or intend to be) substantially different in content/functionality. You can enforce design consistency by using a copy of the main site’s theme, and adjusting it for their specific division. If there are custom modules, those can also be copied to the other subsites (with their own domains / subdomains) to ensure all have the same basic custom functionality. This also affords an opportunity to review what is included in the code repository for each sub-site, and copy in / check in functionality changes per site.
Drupal multi-site setups (and the same would go for WordPress) are great for improving the efficiency of maintenance and code updates so long as the different domains in that setup do not deviate from the common code, i.e. they have no custom features. But when stakeholders decide their site needs its own domain, that almost always means they will also want some features that are not present in the main site… and then there’s no longer any point in using a multisite approach. Multisite installations really only work in situations where you know with relative certainty that all those subsites (with their own domains or sub-domains) will use exactly the same set of modules under the hood.