How do you design Drupal multi-site/multilingual that scales?

Long Answer

Designing Drupal for multi-site or multilingual needs means drawing a hard line between what is global and what may vary by site or locale. The target is a single, testable codebase with predictable deployments, while editors enjoy localized UX and brand-specific presentation without duplication.

1) Single codebase, many sites
Adopt a single repository containing core, contrib, custom modules, and themes. Each site lives under web/sites/[site_id] with its settings.php/services.yml, domain mapping, and file paths. Use Composer for dependency pinning and a lockfile to ensure all sites run identical versions. CI builds the artifact once, then deploys to all environments; environment variables and per-site settings control differences (database, files, trusted host patterns).

2) Config governance with Config Split
Treat configuration as code. Export the canonical set with Configuration Management. Use Configuration Split to carve overrides:

• Global split: shared content types, fields, view modes, workflows, roles that apply to all sites.
  
• Site split(s): site-specific vocabularies, blocks, view displays, search facets, and enabled modules that are truly unique.
  
• Environment split: dev/stage toggles (Devel, Stage File Proxy).
  This model avoids forking content model definitions and stops “drift” caused by ad-hoc changes on a single site.
  

3) Multilingual model: only translate what matters
Enable Language, Content Translation, and Interface Translation. Define a primary language per site and add locales needed by that site. On each content type, mark only truly human-facing fields as translatable (title, body, teasers); keep structural toggles, references, and booleans non-translatable. For navigation and UI strings, rely on interface translation and string overrides in config, not custom code. When multiple sites share languages, centralize translation memory by exporting and reusing PO files or using Translation Management Tool (TMGMT).

4) Theme system: base theme + sub-themes
Create a base theme providing tokens, layout, typography, and components (Twig/Storybook). For each brand/site, add a thin sub-theme that sets colors, logos, and limited templates. Keep components data-driven: render using view modes and field formatters so editors don’t fork content to get different looks. Store breakpoints and design tokens in the base theme to guarantee consistency; extend sparingly in sub-themes.

5) Modules: custom where it counts, contrib where safe
House custom code in /modules/custom. Write cross-site capabilities (SAML/SSO, editorial widgets, tracking) as reusable modules with config defaults; toggle per site via Config Split. Prefer stable contrib modules for standard features (Pathauto, Metatag, Redirect, XML Sitemap, Media, Paragraphs), but fence them with tests to prevent regressions on mass updates.

6) Content model & editorial workflows
Keep a unified set of content types across sites whenever possible (Page, Article, Landing). If one site needs variant fields, prefer field display per view mode over creating new content types. Enable Content Moderation and Workflows with roles mapped globally; site-specific permissions can be layered with per-site roles or Group/Workbench Access where section isolation is needed. For multilingual, ensure editors cannot publish untranslated critical fields by using required per-language validations and editorial checklists.

7) Caching, performance, and search
Use Drupal’s page/fragment caching with Dynamic Page Cache and Internal Page Cache; place a reverse proxy/CDN (Varnish/Fastly/CloudFront) in front. Cache contexts must include languages:language_interface and url.site (or domain) to avoid cross-site leakage. For search, prefer a shared Solr/Elasticsearch cluster with per-site cores/indexes; index language variants separately to improve relevance.

8) Files and media
Centralize media types (Image, Video, Document) and use Media library. Store files in site-specific directories (public://[site_id]/…) or buckets to simplify retention and legal requests. For image styles and translations, share styles globally; captions/alt texts remain per language.

9) Deployment lifecycle
Pipeline: Composer install → unit/kernel tests → config import validation → database updates → config import → cache rebuild → post-deploy smoke tests. Lock config imports: fail the deploy if splits are mis-configured or a config entity is missing. Blue-green or canary releases reduce risk across many sites.

10) Security and tenancy
Harden per site via trusted host patterns, HTTPS, and Content Security Policy. Use permissions by role kept global; override per site only when unavoidable. For multi-site hosting, isolate file systems and credentials; keep secrets outside repo. Audit with automated checks (core security updates, composer audit, update status). Log per site, tagging entries with site ID and language.

11) Operations and observability
Expose health routes, track cache hit ratios, and monitor slow routes. Alert when config imports diverge between environments or when a site strays from the shared module/theme version set.

This architecture gives you a future-proof Drupal multi-site/multilingual platform: one codebase, explicit config boundaries, reusable themes/modules, and disciplined deployments that keep editors productive and brands consistent.

‍

Table

‍

Common Mistakes

Forking themes per site instead of using a base theme with sub-themes; later, every tweak becomes five PRs. Making every field translatable, exploding editorial workload and creating partial translations. Disabling Configuration Management and editing config on live sites, leading to drift and broken deployments. Mixing environment toggles with site splits; dev-only modules accidentally enabled in prod. Creating new content types for small visual differences rather than view modes. No cache context for language or domain, so one site’s page leaks to another via CDN. Relying on global file paths that mingle assets across sites. Updating contrib modules per site rather than centrally—security patches fragment. Skipping smoke tests after config import. Lacking role hygiene—site admins granted global permissions unintentionally.

‍

Sample Answers

Junior:
“I’d keep one codebase and separate sites under sites/*. I’d use Configuration Management with Configuration Split for site-specific config. For Drupal multilingual, I’d enable Language and translate only human text fields. A base theme holds components; each site gets a sub-theme for colors and logos. Deployments import config and clear caches.”

Mid:
“My plan: single repo, Composer-locked deps, and per-site settings. Global content types and workflows live in the main config; per-site blocks and search facets live in a site split. Base theme provides components; sub-themes are thin. Caching varies by language and domain; Solr indexes per site/language. CI enforces config imports and smoke tests.”

Senior:
“I formalize global vs site config with Configuration Split (global/site/env). Multilingual: translate titles/body only; keep structural fields shared. Base theme + design tokens; sub-themes are brand veneers. Custom modules expose SSO, auditing, and analytics toggles per site. We ship via blue-green, block deploys if imports differ, and monitor cache hit/language contexts. Security uses trusted hosts, CSP, and secret stores.”

‍

Evaluation Criteria

• Architecture clarity: Single codebase; per-site overrides; Composer-locked dependencies; clear Drupal multi-site architecture boundary.
  
• Config strategy: Uses Configuration Management and Configuration Split to separate global/site/env; can explain what lives where and why.
  
• Multilingual depth: Enables Language + Content/Interface Translation; translates only necessary fields; handles navigation and UI strings cleanly.
  
• Theme discipline: Base theme with sub-themes; components reused across sites; view modes control presentation.
  
• Module policy: Contrib for standards, custom for cross-site features; tests guard upgrades.
  
• Performance: Caching with language/domain contexts; CDN in front; search indexed per site/language.
  
• Ops & deploy: Deterministic config imports, CI gates, smoke tests, blue-green or canary.
  
• Security: Trusted hosts, CSP, permissions hygiene, secrets outside repo.
  Red flags: Live-site config edits, theme forks, “translate everything,” no cache contexts, per-site module versions, or drift between environments.

‍

Preparation Tips

• Create a minimal repo with two sites (site_a, site_b) and shared content types. Wire Composer, lock versions, and document the folder layout.
  
• Add Configuration Split: global split for content model/workflows, site splits for blocks/menus/facets, and an environment split for dev tools. Rehearse full export/import across environments.
  
• Build a base theme with a few Twig components and tokens; create two sub-themes that only override variables and a stylesheet.
  
• Enable Drupal multilingual: pick two languages, mark only text fields translatable, and test editorial flow with Content Moderation.
  
• Configure cache contexts for language and domain; verify CDN shows the right variant.
  
• Stand up Solr/ES; create per-site, per-language collections and confirm relevance.
  
• Script blue-green deploy with config-import gating and smoke tests.
  
• Run a drill: change a global field and a site-specific block; ensure both deploy cleanly with splits respected.
  
  

Real-world Context

Higher-ed network: 12 departments, one codebase. Base theme + sub-themes reduced CSS/JS by 40%. Config Split separated global content types and site blocks; deployments stopped breaking individual departments. Multilingual enabled only on public-facing sites; editorial load stayed sane.

Retail group (EU/UK): Shared catalog model; country sites translated titles/descriptions only. CDN varied by language and domain; leak-free caching improved TTFB by 30%. Solr cores per site/language fixed search relevance issues.

Media portfolio: Previously forked themes per brand; consolidation into base+sub-themes cut maintenance PRs in half. Composer-locked updates and CI config-import gates eliminated “works on site A, fails on site B.”

Public sector: Strict security via trusted hosts, CSP, and secret storage. Blue-green deploys with smoke tests kept 99.95% availability across five multilingual portals.

‍

Key Takeaways

• One repo; per-site settings; Composer-locked dependencies.
  
• Configuration Split to separate global, site, and environment config.
  
• Translate only human-visible fields; keep structure shared.
  
• Base theme + thin sub-themes; reuse components via view modes.
  
• Cache with language/domain contexts; gate deploys on config imports.
  
  

Practice Exercise

Scenario:
You’re building a platform with three brand sites (A, B, C) and two languages per site. Marketing wants shared content types and workflows, brand-specific styling, and localized copy. Ops wants one pipeline and safe deployments.

Tasks:

1. Propose the repository layout: single codebase, web/sites/a|b|c, Composer, and a lockfile. Describe per-site settings.php and secrets handling.
   
2. Define Configuration Split sets: global (content types, fields, workflows, roles), site (blocks, menus, facets), env (dev tools). Explain which config belongs in each and why.
   
3. Outline multilingual: enable Language, Content/Interface Translation. For Articles, translate title/summary/body; keep taxonomy and booleans shared. Describe how editors publish only when translations for required fields exist.
   
4. Specify theming: base theme with tokens and components; sub-themes per brand changing palettes and logos only. Show how view modes deliver brand-specific cards without duplicating types.
   
5. Plan performance: CDN + Drupal caches with languages:language_interface and domain cache contexts; Solr cores per site/language.
   
6. Deployment: CI builds once, runs tests, validates config imports for each split, performs blue-green release, runs smoke tests.
   
7. Security: trusted hosts, CSP, permissions hygiene, secrets outside repo.
   
   

Deliverable:
A 1–2 page blueprint (diagram + bullets) showing config splits, theme inheritance, multilingual flow, and the deployment gate, proving your Drupal multi-site architecture is maintainable.