Cómo aislar sitios de clientes en WordPress sin Multisite

El aislamiento es una de esas palabras que parece estar resuelta hasta que un cliente te hace la pregunta difícil: si otro sitio en esta instalación es hackeado o corrompe sus datos, ¿el mío también se cae? Si tu respuesta depende de una base de datos compartida, la respuesta honesta es “tal vez”. Esta guía te muestra un flujo de trabajo para darle a cada sitio de cliente un aislamiento real (datos separados, código separado y dominio de fallos separado) mientras sigues administrando una sola instalación de WordPress.

Qué significa realmente el aislamiento

El aislamiento no es una sola propiedad. Son tres, y Multisite ofrece aproximadamente una de ellas.

• Aislamiento de datos: las filas, usuarios y opciones de un tenant no pueden leerse ni corromperse a través del contexto de otro tenant.
• Aislamiento de código: cada tenant puede ejecutar sus propios themes y plugins en sus propias versiones, de modo que una actualización o un plugin defectuoso en el Cliente A nunca afecte al Cliente B.
• Aislamiento del dominio de fallos: cuando un tenant se rompe (un error fatal, una tabla corrupta, un restore fallido), el radio de impacto se detiene en ese tenant.

Multisite comparte una sola base de datos y un solo directorio wp-content para todos los subsitios. Los subsitios se separan únicamente por un ID de blog y un prefijo de tabla dentro de esa misma base de datos. Eso te da una forma débil de separación de datos y nada más: cada subsitio ejecuta los mismos plugins y themes desde el mismo directorio, y una sola tabla corrupta o un error fatal de un plugin recae en el mismo dominio de fallos que todos los demás. Los prefijos separan filas, no separan el riesgo.

Aislamiento de base de datos: prefijo, MySQL dedicado o SQLite

El aislamiento de la base de datos es el eje con más opciones, así que elige con cuidado.

• MySQL compartido, prefijo único por tenant (plugin gratuito): GrabWP Tenancy le da a cada tenant un prefijo de tabla único en la base de datos compartida, además de un directorio de uploads separado. Esto es una separación real a nivel de filas y es la forma más rápida de montar muchos sitios de clientes, pero los tenants siguen viviendo en una sola base de datos, por lo que es un aislamiento parcial.
• Base de datos MySQL dedicada por tenant (Pro): GrabWP Tenancy Pro le da a cada tenant su propia base de datos MySQL. Este es un aislamiento de datos completo con cero riesgo cruzado entre tenants en la capa de la base de datos: un bloqueo (lock), una tabla sobrecargada o un índice corrupto se mantiene dentro de la base de datos de ese cliente específico.
• SQLite por tenant (Pro): para tenants ligeros o portátiles, la versión Pro puede respaldar a un tenant con su propio archivo de base de datos SQLite, lo que hace que el tenant sea autónomo y muy fácil de mover.

Dado que Pro soporta la migración entre bases de datos, estas no son decisiones sin vuelta atrás. Puedes comenzar con un cliente en el modelo de prefijo compartido y mover ese tenant a una base de datos MySQL o SQLite dedicada más adelante sin tener que reconstruirlo.

Aislamiento de código mediante wp-content por tenant

El aislamiento de datos es solo la mitad de la historia. Si dos clientes comparten un mismo directorio wp-content, comparten un mismo conjunto de archivos de plugins y themes, lo que significa que la actualización de un plugin de un cliente o un theme incompatible se convierte en el problema de todos.

El plugin gratuito aísla los uploads por tenant. Pro va más allá con la separación completa del wp-content: themes, plugins y uploads aislados por tenant, cada uno en su propio directorio de contenido. Eso es lo que permite que el Cliente A ejecute una versión antigua y fijada de un page builder mientras el Cliente B ejecuta la más reciente, sin archivos compartidos y sin colisiones de versiones. Pro también puede ubicar los datos de un tenant totalmente fuera de wp-content/uploads, lo cual es útil cuando quieres el almacenamiento del tenant en un volumen separado.

Enrutamiento de cada tenant sin DNS

El aislamiento no sirve de nada si los clientes no pueden acceder a sus sitios, y no deberías tener que tocar los DNS por cada tenant nuevo. GrabWP Tenancy enruta los tenants de dos maneras:

• Enrutamiento basado en rutas (subdirectorio): accede a un tenant en tusitio.com/site/cliente-a sin hacer ningún cambio de DNS. El prefijo site se puede configurar mediante la constante GRABWP_TENANCY_PATH_PREFIX si quieres un segmento diferente.
• Enrutamiento de dominio personalizado: apunta el propio dominio de un cliente al tenant cuando estén listos para usar una URL con su propia marca.

El enrutamiento basado en rutas es el superpoder silencioso del flujo de trabajo de aislamiento: puedes provisionar, probar y entregar un sitio de cliente completamente aislado antes de que exista cualquier registro DNS. También viene con aislamiento de caché integrado, para que los tenants no choquen en una infraestructura compartida. El plugin desactiva los drop-ins de page-cache por petición y añade el ID del tenant como prefijo en las claves del object-cache, lo que previene colisiones de caché entre tenants en un backend compartido de Redis o Memcached.

Aislamiento del dominio de fallos mediante backup y restore por tenant

El dominio de fallos es el eje del que la gente se olvida hasta que ocurre un incidente. El verdadero aislamiento significa que puedes hacer un backup y un restore de un cliente sin tocar a ningún otro.

Pro ofrece un backup de 7 pasos y un restore de 8 pasos por tenant con progreso por AJAX, por lo que recuperar al Cliente A es una operación independiente. Puedes programar backups automáticos (cada hora, dos veces al día, diario, semanal, quincenal o mensual) con configuraciones específicas por tenant, y enviarlos a S3. Esa combinación es lo que transforma la palabra “aislado” de una simple promesa de arquitectura a una realidad operativa: puedes devolver un tenant al estado de ayer mientras los demás siguen funcionando sin problemas.

Cómo montar un tenant aislado, paso a paso

Aquí tienes el flujo de trabajo concreto para un sitio de cliente genuinamente aislado:

1. Instala GrabWP Tenancy en tu única instalación de WordPress y actívalo.
2. Crea el tenant para el cliente. En el plugin gratuito, esto provisiona automáticamente un prefijo de tabla único y un directorio de uploads separado.
3. Sube el tenant a un aislamiento completo con Pro: asígnale una base de datos MySQL o SQLite dedicada y su propio directorio wp-content para que tanto los datos como el código queden separados.
4. Enruta el tenant usando el enrutamiento basado en rutas (tusitio.com/site/cliente-a) para que puedas construir y probar sin DNS, y luego conecta el dominio personalizado del cliente al momento de la entrega.
5. Configura la programación de backups para ese tenant, añade un destino en S3, y ejecuta un backup manual y una prueba de restore para confirmar que el dominio de fallos está verdaderamente aislado.
6. Clona desde un tenant base cuando necesites un punto de partida repetible: clonar copia las tablas de la base de datos y los uploads con reemplazo automático de URL (omite los symlinks), para que un nuevo cliente empiece desde tu stack estándar.

El resultado es una sola instalación para actualizar y monitorear, donde cada cliente se encuentra en su propio límite de datos, código y recuperación.

Cuándo es más importante el aislamiento

No todos los proyectos necesitan bases de datos dedicadas. Pero el aislamiento deja de ser opcional cuando:

• Alojas trabajos de clientes de los que eres contractualmente responsable, donde no se puede permitir que el incidente de un cliente afecte a otro.
• Los clientes ejecutan versiones conflictivas de plugins o themes que no pueden coexistir en un mismo wp-content compartido.
• Necesitas un límite claro de fallos y recuperación por cliente, para que un mal restore o una tabla corrupta sea el problema de un solo cliente, y no de todos tus sitios.
• Quieres una arquitectura de aislamiento de datos que puedas describirle con honestidad a los clientes que pregunten dónde viven sus datos.

Para echar un vistazo más profundo a dónde falla el modelo compartido, mira cuándo no usar WordPress Multisite y la comparación completa entre Multisite y multi-tenancy.

Empieza ahora

Empieza con el plugin gratuito de GrabWP Tenancy para tener prefijos de tabla únicos, uploads separados y enrutamiento por rutas sin DNS. Cuando un cliente necesite aislamiento completo (MySQL o SQLite dedicado, separación total de wp-content y backup y restore por tenant), actualiza a GrabWP Tenancy Pro por $9.99/month.