A Drupal 8 multisite is like an upscale condominium complex. The different units may have different layouts, different square footage and may be decorated by their owners in completely different ways, but certain things are the same throughout: the types of windows, the floors, architectural aspects, common areas. I hope you'll forgive the slightly goofy analogy. The different condos are sites on the platform. Each site or condo has its own creative identity, so much so that one to one they may look completely different, but all are built on an infrastructure of shared components.
One of the reasons why an organization might use a multisite is that it allows them to spin up new sites quickly and inexpensively. A common use-case is a larger company that oversees marketing for a collection of subsidiaries. Using shared components and libraries, a shared UI kit, single sign-on, and shared content, a new site that conforms with the brand is possible in days not months. Another use-case for a multisite may be a single brand that operates in different global markets. In this case each of the sites might be more or less the same but with certain regional differences. Whatever the goal, planned correctly, a Drupal multisite can simplify and consolidate digital marketing operations and website maintenance, and operate as a sound platform for the future digital growth of the organization.
How does it work?
In a Drupal 8 multisite installation each site has its own database and therefore its own entire set of configuration (which modules are enabled, what theme it is using, what content it has and which users can edit). Web requests coming in to Drupal are routed to the appropriate site based either on domain (ex. site1.theawesome.com, site2.theawesome.com, theexcellent.com) or path (ex. theawesome.com/site1, theawesome.com/site2).
Since all of the sites share a codebase they inherit access to all of the themes and modules therein and can turn on/off functionality as meets their needs on a particular site. What this entails for the dev team is that instead of thinking in terms of a single site we think of building components and features for a community of sites. Planned and executed correctly a Drupal 8 multisite gives an organization a platform with some punch: a powerful shared library of reusable integrations, functionality, UI components and workflows.
How to plan
First ask the question: why we building a multisite or what outcome does the organization hope to accomplish with a multisite? Keeping this goal in mind will help guide the decisions that need to be made during the planning process.
Here are five important checkpoints when designing a new Drupal 8 multisite platform.
- Reusability starts at the design table. It doesn’t naturally happen on its own. In order to build a Drupal 8 multisite platform that is useful to an organization the Design, UI/UX and Engineering teams all need to make practical decisions about which front end components should be built for all sites on the platform and which components should just be a customization to a specific site. This isn’t strictly limited to frontend components. There is an equal opportunity to share backend components such as content types, admin workflows and integrations (Salesforce, Marketo). Be creative, but also don’t try to make everything reusable. It is perfectly acceptable to make site specific customizations.
- Build a UI kit. Decide what page components the multisite will offer to all of its tenants. Document the platform application's UI features. If you are working with an agency, ask them to do this for you. An example multisite might have a hero component, a video component, a blog component et. al. Come up with creative names for your reusable components that resonate with the marketing team. A few months ago, one of our clients who is building a multisite designed a reusable CTA component that could be configured to display with different degrees subtlety (ranging from a big bold button a less prominent link). The marketing team had a bit of fun with it and now when editors make a CTA on their platform they can select a “whisper”, a “buzz” or a “shout”. Thoughtful naming of components helps encourage editor engagement as well as editing uniformity throughout the platform.
- Build reusable features as Drupal modules. Use themes for site-specific customizations. As the name implies, modules in Drupal are intended to be independent units that can be used to construct a more complex structure. Most organizations will build a new theme for their website every couple of years but only make minor updates to their modules during the same period of time. Looking at modules and themes this way helps clearly delineate what code is for reuse and what are one-offs.
- Plan on using single sign-on (SSO) throughout the platform whether that be using Drupal itself as the identity provider (IdP) or another system available to the organization. Managing access and permissions throughout a multisite platform in a decentralized manner quickly becomes untenable. Fortunately Drupal 8 is very mature in regard to SSO and has robust support for common protocols like SAML.
- Decide whether you’ll need to share content between the sites. This is actually quite feasible in Drupal 8 using its native REST services combined with the Deploy module. On a multisite with Deploy, admins can share menus, sets of categories, landing pages et. al. with each other as needed via Drupal without contacting a developer. Deploy can also be used as a content moderation tool where Admins can control content on all of the sites in a multisite platform from a single Drupal “Content Hub” instance.