Deja de luchar contra los conflictos de plugins de WordPress Multisite: dale a cada cliente su propio stack de plugins

WordPress Multisite a menudo se vende como la forma de ejecutar muchos sitios de clientes desde una sola instalación. Para los plugins, silenciosamente hace lo contrario de lo que esperan las agencias. Multisite comparte UN directorio wp-content y UNA database entre todos los subsitios. Los archivos de los plugins viven en un solo lugar para toda la red. Esa única capa compartida es donde comienzan los conflictos, y ninguna cantidad de activaciones por sitio hace que desaparezcan.

Por qué la gestión de plugins de Multisite causa conflictos

En Multisite, los plugins se instalan en toda la red. Después de eso, tienes dos opciones: activar un plugin en toda la red para que se ejecute en todas partes, o dejarlo inactivo y permitir que los sitios individuales lo habiliten. De cualquier manera, los ARCHIVOS de los plugins se comparten. Todo el código de los plugins vive en la misma base de código para cada subsitio.

Esa distinción importa más de lo que parece. “Habilitado por sitio” no significa “aislado”. Significa que el mismo código físico está presente para todos los tenants y simplemente se enciende para algunos de ellos. No puedes darles a dos subsitios dos conjuntos de plugins genuinamente diferentes y aislados. Si el Cliente A necesita la versión 4 de un plugin y el Cliente B necesita la versión 6, Multisite no tiene dónde poner ambos. Una versión gana, y gana para todos.

Escenarios reales donde esto causa problemas

La capa compartida convierte problemas pequeños y locales en problemas de toda la red:

• Plugins incompatibles. El Cliente A quiere un plugin de reservas que se engancha a los mismos filtros que el plugin de membresía del Cliente B. En instalaciones separadas esto no es un problema. En Multisite, ambos plugins se cargan en el mismo espacio de proceso, y el error fatal que lanza uno de ellos se siente en toda la red.
• Fijar versiones. Un cliente que ejecuta un stack más antiguo y estable se niega a actualizar un plugin porque rompe su flujo personalizado. Otro cliente necesita la versión más nueva para una corrección de seguridad. En una base de código compartida no puedes cumplir con ambas peticiones.
• Superficie de seguridad. Cada archivo de plugin presente en la red es código que puede ser explotado, incluso en sitios que nunca lo activaron. Un plugin vulnerable inactivo en el wp-content compartido igual se incluye en cada subsitio. La superficie de ataque es la unión de los plugins de todos, no la de cada cliente.

Cada uno de estos casos se remonta a la misma causa raíz: una capa compartida de plugins y themes.

Cómo debería verse realmente el aislamiento por cliente

El aislamiento real significa que el plugin de un cliente es código cargado solo para ese cliente. Si el Cliente A instala, actualiza o rompe un plugin, nada cambia para el Cliente B. Concretamente, eso requiere:

• Un directorio de plugins separado por cliente, no uno compartido con interruptores por sitio.
• Un directorio de themes separado por cliente, para que los conflictos de themes y las diferencias de versiones se mantengan contenidos.
• Versiones independientes, por lo que fijar el stack de un cliente nunca bloquea la actualización de otro.
• Un radio de impacto de uno, por lo que un error fatal de un plugin afecta a un solo tenant en lugar de a toda la red.

La opción de habilitar por sitio de Multisite no puede ofrecer nada de esto, porque los archivos nunca dejan de compartirse.

Cómo el wp-content por tenant ofrece stacks separados

Esta es la brecha que GrabWP Tenancy Pro está construido para cerrar. En lugar de un wp-content compartido, Pro le da a cada tenant una separación COMPLETA de wp-content: su propio directorio aislado de themes y plugins bajo su propio directorio de contenido. Cada cliente termina con un stack de plugins y themes genuinamente separado, no una base de código compartida que se enciende y apaga.

Debido a que los archivos están físicamente separados, los escenarios de conflicto anteriores simplemente dejan de ocurrir. El Cliente A puede ejecutar la versión 4 del plugin mientras que el Cliente B ejecuta la versión 6. Un plugin incompatible solo se carga para el tenant que lo instaló. Un plugin vulnerable que se encuentra en el directorio de un tenant no forma parte de la superficie de ataque de ningún otro tenant. Pro también combina esto con una database dedicada de MySQL o SQLite por tenant y un backup y restore por tenant, por lo que el aislamiento de datos coincide con el aislamiento de código.

El plugin gratuito GrabWP Tenancy plugin ya aísla los uploads, los prefijos de las tablas y el enrutamiento de domain o path, y te da un único dashboard para crear y gestionar tenants. El wp-content completo por tenant, es decir, plugins y themes aislados, es la característica Pro. La versión base gratuita aísla los uploads y los prefijos, no los archivos de los plugins y themes, así que elige la versión Pro específicamente cuando la capa de plugins es donde residen tus conflictos.

Gestionar muchos stacks aislados desde un solo dashboard

La preocupación obvia con el aislamiento es que cambias un problema por otro: en lugar de pelear contra conflictos, ahora tienes que cuidar docenas de carpetas de plugins separadas. GrabWP está diseñado para que eso no suceda.

Incluso con stacks completamente aislados, sigues gestionando cada tenant desde UNA instalación de WordPress y un solo dashboard. La página de gestión de Extensiones de Pro muestra el estado en vivo de los plugins y themes por tenant, para que puedas ver exactamente qué está ejecutando cada cliente sin iniciar sesión en cada sitio. Una cola de directivas desde el sitio principal puede activar o desactivar plugins, cambiar themes y actualizar opciones en cualquier tenant. El aislamiento no te cuesta el control central: obtienes stacks separados y un lugar para controlarlos todos. Los controles de Rendimiento y Seguridad por tenant completan este flujo de trabajo en un único panel.

Migrar a un cliente propenso a conflictos a su propio stack

Aquí tienes un flujo de trabajo concreto para ese cliente cuyos plugins siguen rompiendo tu red:

1. Instala el plugin gratuito GrabWP Tenancy plugin en tu instalación de WordPress y confirma que el aislamiento de uploads y prefijos esté funcionando.
2. Actualiza a Tenancy Pro para desbloquear el wp-content completo por tenant, y luego crea un tenant para el cliente problemático.
3. Haz un backup por tenant primero usando el backup guiado y listo para el restore de Pro, para que tengas un punto de reversión limpio.
4. Mueve los plugins y el theme del cliente al propio directorio aislado de plugins y themes de ese tenant, en las versiones exactas que necesitan.
5. Fija sus versiones de forma independiente, sin preocuparte por lo que ejecute cualquier otro tenant.
6. Verifica desde la página de Extensiones que el estado en vivo de los plugins y themes del tenant coincida con lo que pretendías.
7. Usa la cola de directivas desde el sitio principal para activar los plugins correctos y cambiar el theme, y luego confirma que el resto de tus tenants estén intactos.

El cliente que solía amenazar a toda la red ahora vive en una caja sellada que todavía controlas centralmente.

Compromisos y cuándo importa

Los stacks por tenant usan más disco que un único wp-content compartido, porque cada tenant lleva sus propios archivos de plugins y themes. Para un puñado de sitios casi idénticos que ejecutan los mismos plugins, el Multisite tradicional puede ser suficiente. Si eso te describe, lee cuándo no usar WordPress Multisite antes de agregar cualquier capa de aislamiento.

En el momento en que tus clientes necesitan plugins diferentes, versiones diferentes o una superficie de seguridad compartida más pequeña, la capa compartida se convierte en el cuello de botella, y el aislamiento se paga solo. Para una mirada más amplia sobre cómo mantener separados los sitios de los clientes, consulta cómo aislar sitios de clientes de WordPress sin Multisite.

Comienza con el plugin gratuito GrabWP Tenancy para aislar los uploads, prefijos y enrutamiento desde un solo dashboard. Cuando la capa de plugins y themes es donde viven tus conflictos, actualiza a GrabWP Tenancy Pro a $9.99/month por un wp-content completo por tenant, para que cada cliente obtenga un stack de plugins y themes genuinamente separado que aún gestionas de forma centralizada.