Cómo añadir un CMS a una aplicación Symfony que ya está en producción

La situación es casi siempre la misma. Tienes una aplicación a medida en Symfony, con su lógica de negocio, su login y sus usuarios. Funciona. Y entonces alguien de marketing pregunta si puede cambiar el texto de la landing sin abrir un ticket.

Piensa en LinkedIn. Cuando entras, tienes la red social entera con toda su funcionalidad. Antes de entrar, hay una serie de páginas que explican qué es LinkedIn, para qué sirve y por qué deberías registrarte. Esas páginas son las que casi ningún equipo técnico contempla cuando diseña la arquitectura, y son justo las que el equipo de marketing quiere tocar cada semana.

La salida habitual es montar un WordPress aparte, en otro servidor y a menudo en otro dominio o subdominio. No es una barbaridad: a veces es lo más rápido y cada equipo trabaja con lo que conoce. Pero acabas con dos sistemas, dos despliegues, dos superficies que parchear y dos sitios donde buscar cuando algo se rompe.

Este artículo va de la otra opción: meter el CMS dentro de la aplicación que ya tienes. Sin replataformar, sin tocar tu arquitectura y sin que el equipo de contenido dependa de ti para cada coma.

Si lo que necesitas es decidir qué CMS, la comparativa completa entre Armonic, Sulu, Ibexa, Drupal y Grav está en CMS para Symfony. Aquí damos por hecha esa decisión y vamos al cómo.

La diferencia con Drupal o WordPress no es de tamaño, es de dirección. Con una plataforma, tú entras en su mundo: sus rutas, sus entidades, sus formularios, su capa de renderizado, su sistema de permisos. Aunque use componentes de Symfony por debajo, no programas con Symfony, programas dentro de Drupal.

Un CMS que es un bundle funciona al revés. Se instala con Composer dentro de tu aplicación, se ejecuta con tu mismo runtime y usa tu misma conexión de base de datos. Tus rutas siguen siendo tuyas. Tus plantillas siguen siendo tuyas. Tu capa de dominio no se entera. Lo que ganas es un conjunto de entidades, controladores y pantallas de administración para gestionar contenido, integradas en el panel que ya tienes.

En la práctica, al terminar tendrás un solo panel de administración: por un lado las funcionalidades de tu aplicación —usuarios, pedidos o lo que sea— y, por otro, para quien tenga el rol adecuado, las de gestión de contenido.

Instalar el bundle es un comando. Lo que da trabajo es lo que hay alrededor, y conviene mirarlo antes de empezar.

1. Tu plantilla base. Un CMS integrado necesita que sus vistas hereden de un layout compatible. Si tu templates/base.html.twig está muy personalizado, este es el punto donde vas a tener que decidir qué extiende a qué. No es complicado, pero es el paso que más gente pilla por sorpresa.

2. Los idiomas. Un CMS multiidioma necesita que Symfony sepa qué locales están habilitados (framework.enabled_locales). Si tu aplicación hoy es monoidioma y el contenido va a ser bilingüe, defínelo antes, no después de tener 40 páginas creadas.

3. Las migraciones. El CMS añade sus propias tablas a tu base de datos. Si tienes un flujo de migraciones ordenado, esto es trivial. Si llevas tiempo aplicando cambios de esquema a mano en producción, arregla eso primero. Hablo por experiencia.

4. Los roles. Vas a abrir un panel de administración a personas que hasta ahora no entraban en tu aplicación. Define qué rol da acceso al CMS y qué rol no, antes de dar la primera credencial.

Los comandos que circulan hoy en el README y en Packagist apuntan a la rama 5.4 en dev, mientras que la documentación anuncia la 6.0 y la última release es la 5.5.9. Hay que fijar la versión que recomendamos y actualizar el bloque con los comandos exactos. Publicar un tutorial con comandos que no funcionan es peor que no publicarlo.

El flujo, en cualquier caso, es este:

1. Instalar el bundle con Composer en tu aplicación Symfony existente.
2. Dejar que Symfony Flex registre la receta y genere la configuración base.
3. Ejecutar las migraciones para crear las tablas del CMS.
4. Ajustar la plantilla base y los locales habilitados.
5. Entrar en la ruta de administración del CMS y crear la primera página.

Si quieres verlo funcionando antes de tocar tu proyecto, la edición standalone levanta una instalación limpia para trastear sin riesgo.

Una página en Armonic no es un campo de texto enorme. Es una composición de módulos: defines layouts con la estructura de bloques que necesitas, y el equipo de contenido monta las páginas combinando esos módulos. Los bloques que se repiten entre páginas —una cabecera, un bloque de contacto o un aviso— se definen una vez y se reutilizan.

Los tipos de contenido se declaran en archivos YAML que viven en tu repositorio. Eso significa que un cambio en la estructura de contenido pasa por Git, por revisión y por tu pipeline de CI, igual que cualquier otro cambio de código. Y que los entornos no se desincronizan entre sí.

El versionado guarda una versión en cada cambio, no solo al publicar. Se puede previsualizar antes de publicar y volver atrás sin drama. Para un equipo de marketing que trabaja solo, esa red de seguridad es lo que hace que se atrevan a tocar la web.

Lo que no vas a encontrar

Armonic es un CMS acoplado, y eso tiene un precio que conviene conocer antes de instalarlo:

• No es headless de serie. Si necesitas servir el mismo contenido a una aplicación nativa o a un frontend desacoplado, hay que construir esa capa.
• No trae buscador de frontend.
• Los flujos de aprobación son básicos: versionado y publicar o despublicar, sin motor de revisión de varios pasos.

Si esas tres cosas son requisitos y no caprichos, mira Sulu o Ibexa en la comparativa. Nos ahorramos los dos el disgusto.

Este camino compensa cuando tu aplicación a medida es la protagonista y el contenido la acompaña, cuando el equipo que mantiene la aplicación es el mismo que va a mantener el CMS, y cuando quieres que el contenido pueda relacionarse con tus entidades de negocio sin pasar por una API intermedia.

Si tu proyecto encaja ahí, Armonic es open source y está en GitHub. Instálalo, rómpelo y cuéntanos qué te ha faltado. La documentación está publicada y las issues están abiertas.

Y si prefieres que lo miremos contigo antes de mover nada en producción, escríbenos a hola@softspring.es.