Drupal Multisite

Classic Drupal Multisite architecture

Websites share code (the Drupal core, modules, and themes), but each website has its own database so they do not share content, configuration, or settings. Each website can also have some extra modules / themes under its own subdirectory in the same codebase. A multisite is accomplished by forming different folders for various websites in the /sites/ folder of the Drupal system. For example:

/sites/Site 1/

/sites/Site 2/

/sites/Site n/

We can control which website can use which modules and themes, by putting them into correct folders accessible only for specific sites.

Advantages

1. Autonomous Content and Users
2. Drupal core code and library updates only need to be done once.
3. Some degree of customization is possible, because each site can have its own custom theme and modules.
4. New contrib or custom modules can be shared across the sites, and then individual sites can enable it and import the configuration from it.
5. Config Split module may be used to segment what configuration is shared across sites and what should be overridden per site.

Disadvantages

1. All developers working in the team have access to the codebase that affects all of the sites
2. Updates of configuration and contrib modules, which are not shared across the sites, still need to be run once per site.
3. Complex Options For Content Sharing
4. Single point of failure:
   Since there is a single server hosting all of the sites, failure of server or traffic spike on one of the sites can affect all of the other sites.
   Bug in one site can affect all sites

Typical scenarios

Classic Drupal Multisite would be most beneficial if all of the sites have the same features and are using similar modules and settings but different content and users.

Business case.

A company maintains many brands. Each brand requires a website. Websites are visually different (each brand has its guidelines), but functional requirements are mostly the same (banners, videos, sliders, contact forms, etc.) The same development team maintains and develops all sites. But each site may have its own marketing or content team which manages content for the site.

Multi-Domain Architecture

This architecture consists of a single codebase and single database/installation. The Domain Access suite of modules provide functionality that allows serving multiple sites (domains) from this setup. 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.

Advantages

1. Less Development Effort
2. Maintaining and updating a single Drupal installation
3. Admin users can effortlessly manage all content from one platform.
4. Content and users can be shared across multiple sites.
5. Thame features and functionality at all sites.

Disadvantages

1. Single point of failure
2. If a site needs to be “taken away” into its own hosting plan, it’s not straightforward.
3. Requires strict governance enforcing a policy of no-exceptions (an exception is a functionality on a site that doesn’t follow the rest.)

Typical scenarios

Multi-Domain setup makes sense if sites will share content and/or users, and if all of the sites will have the same functionality, content types/data structures but might have some slight visual changes.

Business case

E-commerce site with one product catalog, single checkout and common users but separate domains for different product categories.

Multi-Locale Architecture

Multi-Locale allows for using language-based regional targeting. Utilizing the power of multilingual capabilities for multiregional targeting. This is recommended for sites targeting multiple regions.

Using the Drupal multilingual system you can translate any piece of content to different languages. The admin interface has built-in translations for 94 languages. Domain name may be used to determine the language. Specifying "example.com" as language domain for English and "example.de" as language domain for German will result that only content in the respective language will be shown for each domain.

Advantages

1. Minimal development effort
2. Maintaining and updating a single Drupal installation

Disadvantages

1. Single point of failure
2. Same visual look and functionality for all sites.

Typical scenarios

Multi-Locale Architecture would be useful if you want to show content to your site visitors in their native language. Multilingual sites can dynamically show translated content to their visitors based on customisable factors like browser language.

Business case

Corporate website for small and medium businesses with clients from different countries.

Distribution Profile Architecture

Drupal distribution is 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.

A Drupal distribution focusses on a certain business and adds features specific to them into one installation so it takes lesser time to configure the most certain elements of a Drupal website.

For example, if you’re looking to build Drupal websites for hospital management, your Drupal developers can pre-configure modules for patient registrations, investigations, pharmacy management etc. and also configure roles for admins, doctors, patients, nurses, etc. So now when you want to deploy the same or similar Drupal solution for a different hospital, the work is much lesser and can be done faster.

Advantages

1. Sites are independent: Code errors or traffic spikes on one site don’t affect other sites.
2. Flexibility: They can be customized more easily (as long as they don’t override configuration provided by the base distribution, so they could still receive functionality updates).

Disadvantages

1. This architecture involves maintaining the distribution codebase, plus each of the sites.
2. Maintaining a distribution is also hard work.

Typical scenarios

A distribution profile works well if the sites are all starting out the same, but they are expected to grow in different directions. Maintenance work is expected to be independent for each of the sites.

Business case

A multinational corporation maintains many brands or services. Each brand (service) requires a website in a separate country or region. Websites are visually different (each brand has its guidelines), the languages vary per country, but functional requirements are mostly the same (banners, videos, sliders, news, articles, contact forms, user registration and personal account, etc.) Each country has its own development and marketing or content team which manages codebase and content for the country site.