Optistream combinó doce plugins personalizados de WordPress en una única base de código sin perder el SEO de ninguna de sus mil páginas públicas.
Por qué la fusión era importante
Un sitio de WordPress típico termina con un puñado de plugins; uno más grande parece un taller lleno de cables, cada uno zumbando pero ninguno fácil de desenchufar. El sitio de Optistream ejecutaba doce plugins hechos a medida que gestionaban perfiles de streamers, equipos de esports y datos de juegos. Esos plugins generaban mil páginas indexables. Mantener esas URLs intactas era innegociable: cualquier cambio habría hundido la migración.
Cómo era la configuración anterior
Los doce plugins vivían cada uno en su propia carpeta, registraban su propio tipo de contenido personalizado (custom post type) y se enganchaban (hooked) a WordPress en diferentes puntos. Los problemas se acumulaban:
- Los hooks y los assets estaban dispersos, lo que dificultaba predecir qué código se ejecutaba y cuándo.
- La lógica de enrutamiento residía en muchos archivos separados, por lo que una sola URL podía verse afectada por varios plugins.
- Los archivos CSS se cargaban en un orden impredecible, lo que provocaba conflictos de estilos.
- La depuración requería abrir doce directorios diferentes, una pérdida de tiempo para cualquier desarrollador.
El objetivo no era reducir el número de archivos; era dotar a todo el sistema de un único ciclo de vida y de un único lugar para gestionar las dependencias.
Cómo se planificó la migración
El equipo trató la interfaz pública —URLs, plantillas y metadatos— como un contrato que no podía romperse. Cualquier cambio en el front end se consideraría un fracaso. Con esa regla en mente, redactaron una lista de verificación para ejecutar después de cada paso.
1. Listar los contratos públicos
Se anotó cada ruta de URL con su tipo de contenido, su rewrite slug, su archivo de plantilla y las claves meta de las que dependía. Esta hoja de cálculo se convirtió en el reglamento: si una URL cambiaba después de mover un módulo, se revertía la migración.
2. Construir un cargador (loader) sencillo
Se creó un pequeño archivo bootstrap. Cada antiguo plugin ahora registra un único "dominio de contenido" a través de un nombre de función predecible. El loader no hace nada complejo: solo lo suficiente para cargar el módulo correcto en WordPress cuando sea necesario. La simplicidad hace que los fallos sean evidentes.
3. Proteger los datos
Renombrar las claves meta habría convertido un cambio de código en una migración de datos, añadiendo un riesgo innecesario. Las claves antiguas permanecieron intactas; nuevas funciones auxiliares (helper functions) las envuelven, manteniendo estable el esquema de la base de datos.
4. Corregir la propiedad del CSS
Los conflictos de estilo se resolvieron con tres medidas:
- Los archivos CSS de los módulos se encolan (enqueued) con una prioridad alta para que se carguen al final.
- Todos los selectores están limitados (scoped) a una clase envolvente única para cada módulo.
- Se utiliza
filemtime()al encolar para invalidar la caché del navegador si un archivo de estilos cambia.
5. Utilizar un bucle seguro
La migración procedió módulo a módulo. Tras mover un módulo, el equipo verificó el registro del tipo de contenido, el enrutamiento y el diseño móvil antes de pasar al siguiente. Los plugins originales permanecieron instalados pero inactivos, proporcionando una vía de reversión (rollback) instantánea.
Lista de verificación de producción
Tras cada intercambio de módulo, el equipo verificó:
- Cada URL de tipo de contenido devuelve un estado HTTP 200.
- El encabezado de la URL canónica coincide con la URL original.
- Los títulos de página y las meta descripciones no han cambiado.
- Todas las imágenes se cargan sin enlaces rotos.
- No aparece desbordamiento horizontal en pantallas móviles.
- La consola del navegador no muestra errores de JavaScript ni de CSS.
Solo cuando se completó la lista de verificación, el equipo desactivó el antiguo plugin de forma permanente.
Qué ofrece el nuevo plugin
El plugin único resultante no reduce la base de código; simplemente hace que los límites sean visibles. Las doce áreas funcionales comparten ahora un único ciclo de vida, un único conjunto de hooks y un único lugar para gestionar las dependencias. El nuevo plugin no hizo que el sistema fuera más pequeño. Hizo que los límites fueran visibles. Eso resultó más útil que tener menos plugins.
Riesgos y contraargumentos
El caso de Optistream demuestra que un enfoque disciplinado basado en contratos (contract-first) y un despliegue paso a paso pueden mantener los riesgos bajo control.
Qué tener en cuenta a continuación
Si está considerando una consolidación similar, comience con estos dos pilares:
- Estabilidad de las URLs – mapee cada ruta pública antes de escribir una sola línea de código.
- Estabilidad de los datos – evite renombrar campos de la base de datos a menos que esté preparado para una migración completa.
A partir de ahí, construya un cargador diminuto, mantenga el CSS limitado (scoped) y mueva los módulos uno a uno mientras ejecuta una lista de verificación de producción rigurosa.