Efficient Multisite Management: Best Practices for Drupal Environments

DrupalTM Blog

Welcome to our Drupal blog! Stay up to date with the latest Drupal news, best practices, and techniques.

Transitioning to a multisite setup can streamline management and deployment for organizations with multiple web properties. By consolidating sites into a unified codebase, teams can achieve greater efficiency and consistency. The following recommendations and structure examples provide a clear pathway for setting up and maintaining a Drupal multisite environment, ensuring seamless integration, domain management, and independent deployment capabilities for both developers and site maintainers.

Recommendations:

  1. Multisite Configuration:
    • Start with configuring the main site as a multisite.
    • Set up sites.php and other necessary configurations.
    • Deploy this setup initially as a single-site multisite.
  2. Ensuring Uniformity:
    • Ensure all sites use identical modules and versions before integration.
  3. Domain Management:
    • Use custom subdomains for non-production environments instead of Acquia's default domain.
    • Example: Set up mysite.comfor non-live sites and utilize subdomains like site1-dev.mysite.com, site2-dev.mysite.com.
    • Follow the same pattern for test environments: site1-test.mysite.com, site2-test.mysite.com.
    • This approach provides control over non-prod domains, allowing for the addition of a wildcard SSL and other configurations.

Implementation Steps:

  • Setup for Additional Sites:
    • Create a temporary domain for each additional site.
    • Add these domains to sites.php.
    • Create respective site folders and set up new databases and settings files.
    • Ensure each site operates correctly within the multisite using its temporary domain.
  • Transition to Production:
    • Once thoroughly tested:
      • Migrate each site's live domain to the multisite application.
      • Update sites.php to reflect the real domain for each site.

Example of Multisite Structure with Drupal:

For simplicity, other Drupal core folders and files are not listed.

Multisite Structure:

-- core

-- modules
   -- contrib
   -- custom

-- themes
   -- contrib
   -- custom

-- sites
   -- site1
         -- modules
            -- custom
            -- contrib
         -- themes
            -- custom
            -- contrib
         -- files
   -- site2
         -- modules
            -- custom
            -- contrib
         -- themes
            -- custom
            -- contrib
        -- files
   -- site3
         -- modules
            -- custom
            -- contrib
         -- themes
            -- custom
            -- contrib
        -- files

Shared Folders in a Drupal Multisite

The modules folder at the Drupal root level is indeed shared among all subsites.

This means that:

  • Modules placed in the drupal_root/modules directory are accessible to all sites within the multisite setup.
  • Changes made to these modules will affect all sites.

Why Shared Modules?

  • Code Reusability: Common functionalities can be shared across multiple sites.
  • Efficiency: Avoids redundant code for shared features.
  • Centralized Management: Easier to update or maintain modules used by multiple sites.

When to Use Shared Modules:

  • Core functionalities: Modules that provide essential features for all sites.
  • Common modules: Modules that are used by multiple sites and share similar requirements.

When to Use Site-Specific Modules:

  • Unique functionalities: Features specific to a particular site.
  • Customizations: Modifications to shared modules that should not affect other sites.

     

By understanding the difference between shared and site-specific modules, you can effectively manage your Drupal multisite environment.
In a scenario where the entire multisite is maintained by a single person, only the files directories will normally exist in the directory structure below "sites." The modules and themes directories are only created in the webroot.

For more complex multisite environments where multiple maintainers manage their own site code, this structure may not apply.

Similar to modules, themes placed in the drupal_root/themes directory are accessible to all sites within the multisite setup. Changes made to these themes will affect all sites.

Reasons for Shared Themes:

  • Consistent branding: Maintain a unified look and feel across all sites.
  • Efficient management: Easier to update or modify the theme for all sites from a single location.
  • Resource optimization: Reduces the need for duplicate theme files.

When to Use Shared Themes:

  • Core branding: A consistent theme for all sites under a single brand.
  • Common design elements: Shared layout, color schemes, or typography.

When to Use Site-Specific Themes:

  • Unique branding: Different visual identity for each site.
  • Custom layouts: Site-specific content arrangements.
  • Isolated customizations: Modifications to the shared theme without affecting other sites.

By understanding the shared nature of the root-level theme directory, you can effectively manage and design your Drupal multisite environment.

Domain based vs Path based

When setting up a Drupal multisite, organizations must choose between domain-based and path-based approaches, each with distinct implications. The domain-based approach assigns unique URLs to each site (e.g., `site1.mysite.com`), simplifying content management and leveraging Drupal's internal path handling, though it requires managing multiple domains and SSL certificates. Conversely, the path-based approach uses URL paths to differentiate sites (e.g., `mysite.com/nursing`), potentially boosting SEO by treating sub-sites as part of the main domain but complicating content management by reserving paths for specific sites, limiting the default site's content accessibility.
 

Domain-Based Multisite:

  • Structure: Each site has its own unique URL (e.g., mysite.com, site1.mysite.com, site2.mysite.com).
  • Advantages:
    • Easier long-term management.
    • Clear separation of content and paths.
    • Let Drupal handle paths and content internally.
  • Challenges:
    • Requires managing and registering multiple domains.
    • Needs individual or wildcard SSL certificates for each domain.
  • Example: mysite.com (default site), site1.mysite.com (site 1), site2.mysite.com (site 2).

Path-Based Multisite:

  • Structure: Sites are differentiated by URL paths (e.g., mysite.com/site1, mysite.com/site2).
  • Advantages:
    • Potential SEO benefits as sub-sites are seen as part of the main site by search engines.
    • Easier to manage a single domain.
  • Challenges:
    • Complex content management as paths are reserved for specific sites.
    • Default site loses access to certain paths.
    • Can cause confusion over content ownership and accessibility.
  • Example: mysite.com (default site), mysite.com/site1(site 1), mysite.com/site2.