Drupal multisite con Config Split: la arquitectura que escalamos en Cotesa y Sopra Steria

Cuando un cliente corporativo tiene que servir varios portales con contenido parcialmente compartido — por ejemplo, una marca con presencia en cinco países, o una entidad pública con portales especializados por área — la pregunta inevitable es: ¿multisite Drupal o sitios independientes?

Esta es la arquitectura que aplicamos cuando la respuesta es multisite, basada en proyectos reales para Cotesa (Segittur) y Sopra Steria (Planeta Formación).

Cuándo elegir multisite (y cuándo no)

Multisite tiene sentido cuando:

• Los sitios comparten al menos un 60% de la lógica: tipos de contenido, módulos custom, sistema de diseño
• El equipo editorial es uno o pocos (no equipos completamente separados)
• Hay contenido reutilizable entre sites (productos, noticias, equipo, taxonomías)
• El presupuesto de infraestructura está optimizado (una sola base de código que mantener)

Multisite no tiene sentido cuando los sitios son productos completamente distintos. En ese caso, repositorios separados con librerías Composer compartidas funcionan mejor.

La pieza clave: Config Split

Drupal almacena toda su configuración en YAML exportable. Por defecto, en un setup single-site, hay un solo config/sync/. En multisite necesitas configuración compartida + configuración específica por site.

Config Split te permite definir splits:

config/
├── sync/                    # Configuración compartida (todos los sites)
├── splits/
│   ├── site_a/              # Solo site A
│   ├── site_b/              # Solo site B
│   └── dev/                 # Solo entornos de desarrollo

Cada split puede ser complete (sustituye la config del módulo entero), partial (añade/quita campos a config existente) o conditional (se activa solo si se cumple condición).

Ejemplo real: en Cotesa, el módulo views tenía vistas comunes (lista de noticias, calendario) en config/sync/ y vistas específicas (mapa interactivo solo para uno de los sites) en config/splits/site_a/. El despliegue de cada site importa los splits que le corresponden, ignorando los demás.

Estructura de directorios

sites/
├── default/                 # Site principal o site común
│   ├── settings.php
│   └── settings.local.php
├── site_a/
│   ├── settings.php         # ConfigSplit activado para "site_a"
│   ├── files/
│   └── private/
├── site_b/
│   ├── settings.php         # ConfigSplit activado para "site_b"
│   ├── files/
│   └── private/
└── sites.php                # Mapeo dominio → directorio

sites.php mapea dominios a directorios sin tocar Apache/nginx:

$sites['site-a.example.com'] = 'site_a';
$sites['site-b.example.com'] = 'site_b';

Base de datos: compartida o separada

Dos opciones, cada una con su trade-off:

Bases de datos separadas (recomendado para producción)

Cada site tiene su propia DB. Aislamiento total: si una migración rompe site_a, site_b no se entera. Backups independientes. Permisos granulares.

Coste: para compartir contenido entre sites hay que usar Entity Share (publish-subscribe vía API).

Base de datos compartida con prefijos de tabla

Una sola DB con node__site_a__* y node__site_b__*. Compartir contenido es trivial (mismo schema, mismo DB).

Coste: cualquier corrupción afecta a todos los sites. Backups y permisos compartidos.

En todos nuestros proyectos corporativos elegimos bases separadas + Entity Share.

Entity Share: publicar entre sites

Entity Share expone endpoints REST por site y permite que un site “consumidor” sincronice entidades desde otro site “productor”.

Caso real Sopra Steria: el portal principal publicaba noticias que se replicaban en 3 sub-portales especializados con un tag específico. Sin Entity Share habría que mantener triple alta de contenidos. Con Entity Share, los editores publican una vez y un cron job nocturno sincroniza.

CI/CD para multisite

El pipeline tiene que correr una sola build y desplegar a múltiples sites. Pasos típicos:

1. composer install — una sola vez para todos los sites
2. npm run build — frontend compartido
3. Por cada site: drush -l https://site-x.example.com cim -y (config import del split correspondiente)
4. Por cada site: drush -l https://site-x.example.com updatedb -y
5. Por cada site: drush -l https://site-x.example.com cr (cache rebuild)

Para CI/CD aplicamos Jenkins o Azure DevOps según el cliente, con un solo job que itera sobre el array de sites declarado.

Gotchas conocidas

• Cron por site: cron.php se ejecuta por cada site separadamente. En crontab necesitas N entradas (una por site), no una sola.
• Búsqueda Solr: cada site debe tener su core Solr aislado, o todos los resultados se mezclan.
• Sesiones: si compartes dominio raíz entre subdominios y quieres SSO entre sites, hay que tunear el cookie domain en settings.php.
• Sitemap.xml: el módulo simple_sitemap por defecto genera uno global; configurar el variant por site.

Cuándo migrar de multisite a sitios independientes

Si pasados 2-3 años:

• Los sites han divergido tanto que más del 60% del código es específico
• Un equipo editorial completamente distinto necesita autonomía total
• Los plazos de despliegue se hacen pesados porque cualquier cambio afecta a todos

Entonces toca refactor: extraer cada site a su propio repo, conservar librerías comunes en paquetes Composer. Es un refactor planificable a 6 meses con bajo riesgo si la arquitectura multisite estaba bien hecha de origen.

---

¿Necesitas un equipo Drupal senior que conozca bien multisite, Config Split y Entity Share? Cuéntanos tu caso — te respondemos en 24h con propuesta concreta.