Dos webs que comparten tema y widgets piden a gritos un WordPress MultisiteGlosarioMultisiteModo de WordPress que ejecuta varios sitios sobre una misma instalación, con un único código y una base de datos compartida por la red. Cada sitio de la red puede tener su propio dominio mediante mapeo de dominios. El código, los plugins y el tema se instalan una vez y se activan por sitio o en toda la red. La contrapartida es que los sitios comparten contenedor, base de datos y ciclo de actualizaciones.Ver término completo →. Yo también lo propuse. Un código, un contenedor PHP, una base de datos y dominios mapeados. Siete semanas después, Libelium e iris360 salen de un monorepoGlosarioMonorepoRepositorio de control de versiones que aloja varios proyectos, paquetes o sitios en un único árbol de código. Aplicado a WordPress con varias marcas, un monorepo guarda una sola copia del tema, del motor y de los widgets compartidos, y una carpeta por sitio con lo que es propio de cada uno. Evita las copias divergentes de los repositorios clonados y los commits de actualización de puntero de los submódulos de Git.Ver término completo → y cada sitio vive en su propio stack Docker, con su propia base de datos.
Libelium vende hardware IoT de extremo a extremo e iris360 es su plataforma de software como servicio. Comparten tema, motor y widgets de Elementor, y tienen dominios, funciones y equipos distintos. El proyecto entero está en el caso de éxito Libelium + iris360: De un cambio estético a un cambio de arquitectura. Aquí va una sola pregunta. Cuando dos marcas comparten código, ¿comparten también la infraestructura?
Una cocina para dos restaurantes
Dos restaurantes del mismo grupo pueden compartir recetario, proveedores y formación del personal. Si además comparten fogones, un fallo de gas cierra los dos locales el mismo sábado.
Con las dos webs pasa igual. El recetario, es decir el código, se comparte. Los fogones, es decir contenedores y datos, conviene que sean de cada local.
Por qué el multisite parecía la respuesta
Sobre el papel, el multisite ganaba o empataba en todo. Mantenimiento unificado, widgets compartidos, un super administrador para saltar entre sitios y SEO con dominios independientes, cada uno con su robots.txt y sus sitemaps. Una sola MySQL y un solo contenedor PHP para toda la red.
Mi propuesta no llegó a ejecutarse. Entre medias probé un camino intermedio, y la comparación de los tres explica la decisión.
| Criterio | Multisite | Dos repositorios y submódulo | Monorepo |
|---|---|---|---|
| Copias del motor | 1 | 2, una plana en cada repositorio | 1 |
| Widgets | 1, activados en red | 1, como submódulo en ambos | 1, carpeta del propio árbol |
| Base de datos | Compartida por la red | Una por sitio | Una por sitio |
| Contenedores | Uno para toda la red | Un stack por sitio | Un stack por sitio y entorno |
El atajo que dejó el trabajo a medias
Para arrancar iris360 clonó el repositorio de Libelium. Compartían casi todo y clonar era lo más rápido. La primera jornada se fue en purgar contenido de Libelium que arrastraba el clon.
Ese mismo día extraje los widgets a un repositorio común y lo enganché como submódulo. Antes de unificar encontré dos divergencias que muestran el riesgo de copiar. Un contador animado que solo existía en Libelium y una corrección de pestañas que solo existía en iris360. Dos copias, dos arreglos que nunca se habían cruzado.
El submódulo resolvió los widgets y dejó el resto a medias. El motor seguía duplicado y lo homogeneicé a mano. Cada entrega de widgets exigía además actualizar el puntero del submódulo en cada repositorio. Una tarea pequeña repetida sin parar, y esas son las que se olvidan.
Un árbol, una carpeta por sitio
El monorepo cerró el problema. Una sola copia de tema, motor y widgets, y una carpeta por sitio para lo propio de cada uno. Al comparar los dos árboles el día del cambio, los widgets no tenían ninguna diferencia. Ya estaban unificados.
La marca activa es una opción de WordPress, y todo lo que cambia entre marcas cuelga de ella o de un filtro que rellena el paquete del sitio. El peso de los encabezados, el color de acento, la tipografía, la navegación móvil, el catálogo de productos y la cabecera del llms.txt salen de ahí. Los plugins de terceros no viajan en el repositorio y cada entorno instala los suyos.
Cuatro reglas sostienen el reparto. Una sola copia de cada paquete compartido, y antes de portar algo de otro árbol se compara y se aplica solo la diferencia. Sin hosts, IDs ni secretos en el código compartido. El paquete de sitio solo fija valores por defecto, y lo guardado en la configuración manda. Y los identificadores de posts, plantillas y tipos de contenido pertenecen a cada sitio y nunca se mezclan.
La última regla es la que más rompe cuando se incumple. Un ID de plantilla copiado de un sitio a otro apunta a un post que no existe o a otro distinto, y el fallo aparece lejos del origen. El patrón general está en la referencia sobre monorepo multi-marca y aislamiento.
Lo que no compartí
Del multisite abandoné el contenedor y la base de datos compartidos. Cada sitio y cada entorno tiene un stack autocontenido, sin contenedores, redes, volúmenes ni variables de entorno comunes. Si algo hace falta en los dos, se copia en los dos. Esa duplicación deliberada es el precio de que un fallo se quede en su sitio.
Cada servidor carga un único conjunto de contenido, montado con los paquetes compartidos y el del sitio, y una batería de comprobaciones tiene que pasar para los dos sitios antes de cada entrega. El contenido real de cada sitio se guarda en copias propias, un sistema que sustituyó a los generadores de landings que retiré.
Lo que me llevo
No medí cuánto tiempo ahorra el monorepo frente al submódulo ni lo que cuesta duplicar contenedores frente al multisite. Sí sé que el submódulo pedía un commit de puntero por repositorio en cada entrega y que el monorepo lo reduce a uno.
Compartir código y compartir infraestructura son decisiones separadas, y mi error fue tratarlas como una sola. Comparte lo que cambia a la vez en las dos marcas y aísla lo que puede fallar en una. La duplicación pequeña y consciente sale más barata que un fallo que arrastra a las dos.