No hace falta reinventar la web para crear un CMS moderno
Las nuevas tecnologías web son apasionantes. Nuevos marcos, modelos de renderizado, sistemas de construcción y capas de abstracción resuelven periódicamente problemas reales.
Pero no todas las aplicaciones nuevas necesitan una nueva arquitectura de aplicación.
WebBlocks CMS partió de una pregunta bastante simple:
¿Hasta dónde puede llegar un CMS moderno si seguimos utilizando tecnologías web familiares que ya funcionan bien?
Eso significa PHP y Laravel para la aplicación. Una base de datos relacional para contenido estructurado. HTML para marcado. CSS para presentación. JavaScript donde el comportamiento del navegador realmente requiere JavaScript.
Ninguna de esas ideas es nueva.
Eso es intencional.
WebBlocks CMS no es un intento de reinventar MVC, inventar bloques, reemplazar Laravel o introducir otra arquitectura de interfaz. Es un intento de crear un CMS moderno capaz manteniendo al mismo tiempo la aplicación subyacente comprensible y bajo el control del desarrollador.
Y, cada vez más, eso también significa hacer que el mismo CMS estructurado sea accesible de forma segura para la IA y las herramientas de automatización.
Un CMS que se suma a tu aplicación Laravel
Una suposición habitual sobre los CMS es que el CMS es la aplicación.
Lo instalas, construyes todo dentro de su mundo, sigues sus convenciones de enrutamiento, usas su modelo de extensión y adaptas el resto de tu proyecto a su alrededor.
WebBlocks adopta un enfoque diferente.
Se distribuye como un paquete Composer y se puede instalar en una aplicación Laravel que ya posee.
La aplicación Laravel sigue siendo la aplicación.
Continúa poseyendo cosas como:
- autenticación
- configuración de base de datos
- colas
- correo
- despliegue
- rutas de aplicación
- infraestructura
- lógica de negocios específica del dominio
WebBlocks agrega la capa de gestión de contenido: páginas, diseños, bloques, medios, navegación, localización, revisiones, flujos de trabajo de publicación y el espacio de trabajo /webadmin.
La instalación sigue siendo deliberadamente familiar:
composer require fklavyenet/webblocks-cms
seguido de php artisan webblocks:install.
No es necesario crear una segunda aplicación frontend sólo porque el proyecto ahora necesita contenido editable.
Su producto Laravel y su sitio web pueden convivir
Esto resulta particularmente útil cuando el sitio web es sólo una parte de una aplicación más grande.
Imagina que ya tienes:
- un producto SaaS
- un portal de clientes
- una solicitud de reserva
- un sistema empresarial interno
- una plataforma de membresía
- una aplicación Laravel relacionada con el comercio electrónico
- o simplemente un proyecto Laravel con una importante lógica empresarial personalizada
Es posible que el producto en sí ya funcione perfectamente.
Lo que necesita es una forma para que los editores administren la parte pública: la página de inicio, las páginas de productos, la documentación, las páginas de destino, el contenido de ayuda, las páginas legales, las páginas de campaña u otro contenido editorial.
Una solución es agregar otra aplicación.
Un CMS independiente. Una interfaz separada. Quizás otro marco, otro proceso de implementación y otro límite de integración entre el producto y el sitio web.
En cambio, WebBlocks puede convertirse en el sitio web opcional y la capa de contenido de la aplicación Laravel existente.
La lógica del producto permanece donde pertenece.
En Laravel.
El CMS gestiona las partes orientadas al contenido.
Para esto está destinado el modelo de convivencia .
WebBlocks también puede funcionar como el CMS principal para un sitio web convencional. El punto importante es que no obliga a todos los proyectos Laravel a utilizar la misma arquitectura.
También puede representar el sitio web público.
WebBlocks no se limita a actuar como una base de datos de contenido headless.
Puede gestionar y representar el propio sitio web público.
Las páginas tienen rutas públicas reales como:
/features/contact/docs/internal-content-api
El renderizador público funciona desde el mismo modelo estructurado Página → Diseño → Ranura → Bloque que los editores administran en el CMS.
Eso significa que una aplicación Laravel puede contener tanto rutas de aplicaciones como páginas públicas administradas por CMS sin introducir otro tiempo de ejecución de interfaz únicamente para la entrega de contenido.
El paquete CMS en sí no requiere Node, npm, Vite o un marco de interfaz de usuario separado.
Eso no significa que JavaScript esté prohibido.
Significa que JavaScript se usa cuando algo realmente necesita JavaScript en lugar de convertirse en un requisito previo para representar el sitio web.
El mismo principio se aplica en todo el proyecto:
utilizar cada tecnología donde aporte algo útil.
Página → Diseño → Ranura → Bloquear no es un invento nuevo
Los sistemas de contenidos basados en bloques existen desde hace muchos años.
Drupal tiene regiones y bloques. Otros productos CMS tienen sus propias versiones de secciones, componentes, módulos, widgets y contenido reutilizable.
WebBlocks no afirma haber inventado este concepto.
Su modelo de contenido es deliberadamente comprensible:
Página → Diseño → Ranura → Bloque
Una página selecciona un diseño.
El diseño define áreas con nombre.
Esas ranuras contienen bloques.
Los bloques contienen contenido estructurado y ellos mismos pueden soportar estructuras anidadas cuando sea apropiado.
El valor no es que las palabras sean nuevas.
El valor es que un editor, un desarrollador Laravel y una herramienta de automatización pueden razonar sobre la misma estructura explícita.
No es necesario que haya un modelo de aplicación frontend oculto entre el CMS y la página renderizada.
El contenido reutilizable debe ser normal.
Los encabezados, pies de página, barras laterales, llamadas a la acción y otras estructuras repetidas no deberían tener que reconstruirse en cada página.
WebBlocks usa Shared Slots para eso.
Una vez más, el contenido reutilizable no se presenta como una invención revolucionaria de los CMS. Es algo que debería ofrecer un CMS práctico.
Pero el contenido reutilizable también introduce un importante problema editorial: cambiar el contenido compartido puede afectar a muchas páginas simultáneamente.
Es por eso que Shared Slots participa en su propio contenido controlado y flujos de trabajo de revisión en lugar de ser tratados como fragmentos globales invisibles.
La reutilización es útil.
La reutilización gobernada es más segura.
Publicar no es sólo un interruptor de encendido/apagado
Un CMS se vuelve más interesante cuando más de una persona (o más de un tipo de actor) puede modificar el contenido.
WebBlocks separa el estado de la página de la publicación del bloque en lugar de asumir silenciosamente que la publicación de una página debería hacer públicos todos los bloques no publicados.
Las páginas pueden moverse a través de estados editoriales.
Revisions proporciona instantáneas de seguridad a nivel de página.
El contenido compartido tiene su propio historial de revisiones.
La publicación puede ser explícita sobre si los bloques de propiedad de la página también deben hacerse públicos.
Esto es importante para los equipos editoriales humanos.
Se vuelve aún más importante una vez que la automatización y la IA entran en el flujo de trabajo.
El multisitio y la localización son parte del modelo de contenidos
Una instalación de WebBlocks puede administrar distintos sitios, dominios e idiomas manteniendo explícita la propiedad del sitio.
La localización no es simplemente “duplicar la página y traducirla”.
El contenido, las rutas y los datos de SEO se pueden localizar mientras la estructura de la página revisada sigue siendo comprensible.
Esto resulta útil para organizaciones que ejecutan varios sitios de productos, sitios regionales o propiedades multilingües pero no desean una instalación de CMS separada para cada uno.
Nuevamente, esto no significa que el multisitio o la localización sean conceptos nuevos.
Son responsabilidades establecidas de CMS.
El objetivo es proporcionarlos sin necesidad de que la aplicación Laravel ceda el control de su arquitectura.
Los medios también pertenecen al CMS
El contenido editorial es más que texto.
WebBlocks incluye administración de medios y variantes de imágenes para que los medios puedan participar en el mismo entorno de publicación estructurado que las páginas y los bloques.
Combinado con navegación, búsqueda, revisiones, copias de seguridad, transferencia de sitios y publicación controlada, la intención es cubrir las responsabilidades operativas normales que se esperan de un CMS en lugar de demostrar un pequeño prototipo de editor de bloques.
Esa distinción importa.
Un editor de bloques es una característica.
Un CMS también debe gestionar el ciclo de vida del contenido.
Entonces la IA cambia el problema
Aquí es donde la arquitectura convencional adquiere especial interés.
Actualmente, muchos productos agregan IA colocando un cuadro de texto en algún lugar de la interfaz de administración y conectándolo a un modelo.
Esto puede ser útil, pero no es la dirección que está explorando WebBlocks.
La pregunta más interesante es:
¿Qué sucede si una herramienta de IA puede comprender y operar el CMS real de forma segura?
WebBlocks expone capacidades estructuradas de CMS a través de su Internal Content API.
Una IA confiable o una herramienta de operador pueden inspeccionar la instalación real en lugar de adivinar cómo funciona el CMS.
Puede descubrir sitios, configuraciones regionales, diseños, tipos de bloques y contratos de contenido disponibles.
Puede inspeccionar el contenido estructurado existente.
Puede preparar un plan de página completo.
Puede validar ese plan antes de cambiar el contenido.
Puede crear o modificar borradores de contenido.
Y la publicación sigue siendo una capacidad separada que requiere un permiso explícito.
Esta distinción es importante.
La IA no necesita raspar la interfaz de administración.
No es necesario simular clics del mouse.
No necesita inventar HTML y esperar que el CMS lo acepte.
Puede funcionar con el mismo modelo de contenido estructurado que entiende el propio CMS.
El acceso a IA no tiene por qué significar acceso ilimitado
Dar acceso a una herramienta de inteligencia artificial a un CMS plantea una pregunta obvia:
¿Qué se le permite hacer?
El Internal Content API tiene deliberadamente un alcance de permisos.
La validación de contenido y la aplicación de contenido son operaciones separadas.
La aplicación del contenido se realiza primero como borrador.
La publicación requiere una capacidad content.publish independiente.
La API rechaza operaciones fuera de sus contratos definidos en lugar de tratar la automatización como un administrador con libertad ilimitada.
La intención no es:
“Deja que la IA controle el sitio web.”
Está más cerca de:
“Permita que herramientas confiables realicen operaciones CMS bien definidas bajo el mismo tipo de límites que esperaríamos de otros actores de aplicaciones”.
Esto crea posibilidades interesantes.
Una herramienta de inteligencia artificial podría preparar una nueva página de destino y dejar la decisión final de publicación a un editor.
Podría actualizar secciones de borrador seleccionadas sin reemplazar toda la página.
Podría comprender qué estructuras de bloques admite la instalación real antes de proponer contenido.
Podría funcionar en un sitio multilingüe respetando los límites del sitio y la configuración regional.
Y debido a que se trata de capacidades de CMS en lugar de una integración de IA específica del proveedor, el núcleo del CMS no tiene por qué depender de un proveedor de modelo.
Convencional no significa estático
Utilizar tecnologías establecidas no significa rechazar nuevas capacidades.
Puede significar poner esas capacidades en una capa diferente.
HTML no queda obsoleto porque una IA ayudó a crear el contenido.
Laravel no necesita convertirse en una aplicación JavaScript porque un editor quiere bloques interactivos.
Una base de datos relacional no deja de ser adecuada porque una herramienta de automatización escriba contenido estructurado a través de una API.
La renderización del lado del servidor no impide los flujos de trabajo editoriales modernos.
Y una aplicación Laravel convencional aún puede exponer contratos legibles por máquina lo suficientemente sofisticados como para que las herramientas de inteligencia artificial funcionen de manera segura.
Esa combinación es el experimento detrás del WebBlocks CMS.
Lo que WebBlocks no intenta demostrar
WebBlocks no intenta demostrar que:
- MVC es nuevo
- Las aplicaciones monolíticas son nuevas.
- los bloques son nuevos
- Las regiones reutilizables son nuevas.
- La representación del lado del servidor es nueva.
- Los flujos de trabajo de CMS son nuevos
Claramente no lo son.
El proyecto tampoco argumenta que los marcos frontend, las arquitecturas headless o las aplicaciones con mucho JavaScript sean inherentemente incorrectas.
Resuelven problemas reales y son la elección correcta para muchas aplicaciones.
La pregunta más concreta es si deberían ser un requisito automático para cada proyecto Laravel respaldado por CMS.
La respuesta de WebBlocks es hacerlos opcionales en lugar de fundamentales.
Una base deliberadamente aburrida
Existe una tendencia en el software a describir la “tecnología aburrida” como si fuera una disculpa.
También puede ser una ventaja.
Un desarrollador Laravel que abra un proyecto WebBlocks aún debería reconocer una aplicación Laravel.
Un desarrollador frontend aún debería ver HTML, CSS y JavaScript.
Un editor debería ver páginas y contenido en lugar de arquitectura de implementación.
Y una herramienta de IA debería ver esquemas explícitos, permisos y operaciones estructuradas en lugar de tener que realizar ingeniería inversa en una interfaz de administración.
Hay mucho espacio para la innovación por encima de esa base.
La fundación en sí no tiene por qué ser desconocida.
Pruebe el enfoque en lugar de la terminología
Los conceptos individuales de WebBlocks CMS son intencionadamente reconocibles.
Lo interesante es cómo trabajan juntos:
- un CMS Laravel instalable por Composer,
- una capa de contenido opcional para un producto existente,
- representación de sitios web públicos,
- páginas estructuradas y contenido reutilizable,
- multisitio y localización,
- medios y navegación,
- revisiones y publicaciones controladas,
- y API con alcance de permisos que permiten que las herramientas modernas de inteligencia artificial participen en flujos de trabajo reales de CMS.
Si esa combinación es útil es una pregunta mucho más interesante que si MVC, bloques o aplicaciones monolíticas existieron antes.
Lo hicieron.
El proyecto es de código abierto, la documentación es pública y hay una demostración en vivo.
Así que la mejor manera de evaluar la idea no es preguntar si los ingredientes son nuevos.
Pruebe el CMS y vea qué se puede crear con ellos.