Cómo usar Layout Builder y Paragraphs en Drupal para crear páginas flexibles sin necesidad de código

Si llevas tiempo trabajando con Drupal sabes cuál es la pelea de siempre: el equipo editorial quiere montar landings sin abrir un ticket por cada cambio, y el equipo de desarrollo quiere evitar que alguien suba HTML pegado de Word que rompa el diseño en mitad de un viernes. Durante años la única salida pasaba por dos extremos muy malos: o templates rígidos donde el editor solo rellena cuatro campos, o un campo de texto enriquecido convertido en zona franca de divs que se cargaba la accesibilidad y la coherencia visual.

Drupal tiene dos respuestas serias a ese problema, y casi siempre se enfrentan como si fueran opciones excluyentes: Layout Builder y Paragraphs. Ambas dejan al editor componer páginas a base de piezas predefinidas, pero parten de filosofías muy distintas. Elegir bien (o saber combinarlas) marca la diferencia entre un CMS que tu equipo editorial usa con soltura y uno que termina abandonado porque "es más fácil pedirlo al de IT".

Layout Builder: el sistema nativo de Drupal core

Layout Builder vive en el core de Drupal desde la 8.7. Es básicamente una interfaz visual de arrastrar y soltar donde el editor organiza bloques en secciones con distintos layouts de columnas, trabajando directamente sobre la propia página y viendo cómo queda en contexto.

Cómo funciona. La página se trocea en secciones. Cada sección tiene un layout (una columna, dos al 50/50, dos al 33/67, tres columnas, etc.) y dentro de cada región puedes colocar bloques. Y bloques aquí significan cosas muy variadas: campos del propio contenido, bloques personalizados reutilizables, vistas con listados dinámicos, o cualquier bloque que aporte un módulo contribuido.

Dos modos de uso, y la diferencia importa.

El modo default te permite configurar el layout de un tipo de contenido como si fuera un display mode con esteroides. Todos los nodos de ese tipo comparten la misma estructura. Funciona muy bien para contenido predecible: artículos de blog, fichas de producto, casos de éxito con la misma anatomía.

El modo override (per-entity) es donde aparece la magia (y el peligro). Cada nodo individual puede tener su propio layout personalizado. Aquí los editores ganan libertad total para componer landings únicas, páginas corporativas con personalidad propia, microsites internos dentro del mismo Drupal. También es donde empiezan a aparecer cosas raras si no pones límites; sí, esa página de 17 hero banners apilados que nadie recuerda haber pedido.

Lo bueno. Está en el core, así que no dependes de mantenedores externos. La interfaz visual con previsualización en contexto se entiende rápido. Se enchufa de forma nativa con el sistema de permisos y revisiones de Drupal, y el render lo hace Drupal con sus templates Twig, que puedes sobrescribir cuando lo necesites.

Lo menos bueno. Con muchas secciones y bloques anidados la interfaz se vuelve densa. El rendimiento sufre en páginas con decenas de bloques inline si no afinas caché. Y el responsive no viene gratis: vas a necesitar trabajo de CSS para que tus secciones se comporten bien en móvil.

Paragraphs: composición basada en campos

Paragraphs es un módulo contribuido con una filosofía distinta. En vez de colocar bloques sobre un lienzo visual, defines un campo de tipo paragraphs en un tipo de contenido. Ese campo acepta una lista ordenada de componentes que el editor añade, reordena y configura desde el propio formulario de edición del nodo.

Cómo funciona. Defines tipos de párrafo (Paragraph types) como mini-entidades, cada una con sus propios campos. Un tipo "Hero Banner" tendrá imagen, título, subtítulo y CTA. Un tipo "Columnas con iconos" tendrá tres o cuatro ítems, cada uno con icono, título y texto. Un tipo "Testimonios" puede referenciar entidades de testimonios que ya existen en el sistema.

Cuando el editor entra a crear o editar un nodo, el campo de párrafos aparece como una lista a la que añade componentes eligiendo del catálogo disponible, los reordena arrastrando, configura cada uno con sus campos específicos y previsualiza el resultado antes de publicar.

Lo bueno. Control quirúrgico sobre qué componentes están disponibles en cada tipo de contenido. Datos completamente estructurados: cada campo es tipado, consultable y exportable, lo que lo hace ideal para arquitecturas decoupled donde el frontend pide JSON, no HTML. El editor trabaja con formularios claros, predecibles, sin sorpresas visuales.

Lo menos bueno. La edición no es visual: hasta que no le das a previsualizar no ves cómo queda. El formulario de edición puede crecer mucho con páginas largas. Y los párrafos anidados (párrafos dentro de párrafos) son potentes pero meten una capa extra de complejidad que tu equipo editorial puede no agradecer.

Comparativa detallada: cuándo usar cada uno

La elección entre Layout Builder y Paragraphs depende del tipo de proyecto, del perfil de tu equipo editorial y de la arquitectura técnica que tengas (o que estés diseñando).

Tira de Layout Builder cuando: tus editores necesitan libertad visual para componer layouts únicos, el frontend lo sirve Drupal con Twig, te interesa minimizar dependencias de módulos contribuidos, y el grueso del contenido son landing pages o piezas editoriales con personalidad propia.

Tira de Paragraphs cuando: necesitas datos altamente estructurados para una arquitectura decoupled (headless), quieres limitar al milímetro qué componentes puede usar cada perfil editorial, el contenido se va a servir a varios canales (web, app móvil, newsletters, partners) o necesitas componentes anidables con lógica compleja por encima.

Combina ambos cuando: quieres Layout Builder para el layout general de la página (secciones y columnas) y Paragraphs para los contenidos ricos dentro de esas secciones. Este enfoque híbrido se ha vuelto la norma en proyectos enterprise grandes, y es probablemente la respuesta correcta más veces de lo que parece.

Configuración práctica de Layout Builder

Para habilitar Layout Builder en un tipo de contenido, entra a la configuración del display mode de ese tipo de contenido y activa "Use Layout Builder". Si además quieres permitir overrides por entidad, marca "Allow each content item to have its layout customized". Ese segundo check es el que abre la puerta al modo libre por nodo.

Crea secciones personalizadas. Drupal trae layouts básicos (1, 2 y 3 columnas), pero rara vez te bastan. Lo habitual es montar un módulo custom con plugins de layout que reproduzcan tu sistema de diseño: las proporciones que usa tu equipo de diseño, los espaciados de tu grid, las variantes con o sin contenedor. Hacerlo bien al principio te evita que cada landing termine siendo un experimento distinto.

Custom blocks para componentes reutilizables. Define tipos de bloque personalizado (Block Content types) para todo lo que se va a repetir: CTAs, banners, tarjetas de servicio, testimonios destacados. Cada tipo lleva sus campos, y una vez creado se reutiliza en todas las páginas que quieras sin volver a teclear.

Restricción de bloques por sección. Aquí entra Layout Builder Restrictions, que controla qué tipos de bloque pueden caer en cada región de cada layout. Es la diferencia entre un editor que coloca un CTA donde tiene sentido y uno que mete un formulario de contacto dentro del footer porque "cabía ahí".

Estilos de sección y bloque. Layout Builder Styles te permite ofrecer clases CSS predefinidas como opciones desplegables: fondo oscuro, fondo claro, padding generoso, separador inferior. El editor elige una etiqueta legible y tu diseño sigue intacto, sin que nadie tenga que escribir CSS ni recordarse de qué clase tocaba.

Configuración práctica de Paragraphs

Con Paragraphs el punto de partida es decidir tu catálogo de componentes. Ese inventario inicial define la experiencia editorial durante meses, así que merece tiempo.

Definición de componentes. Siéntate con quien edita a diario y haz inventario: hero, texto con imagen lateral, galería, acordeón FAQ, grid de tarjetas, bloque de CTA, testimonios, vídeo embebido, tabla de precios, formulario embebido. Cada elemento de esa lista se convierte en un Paragraph type con sus campos exactos, sus validaciones y su propio template.

Campo Paragraphs en tipos de contenido. Añade un campo de tipo "Entity reference revisions" (lo proporciona el propio módulo Paragraphs) en los tipos de contenido que vayan a usarlo. Configura ahí qué tipos de párrafo están permitidos y, si te interesa, un límite de cantidad por nodo para evitar páginas-río de tres kilómetros.

Mejora la UX editorial con Paragraphs Browser. La experiencia por defecto (un select desplegable con los nombres técnicos de los tipos) es funcional pero antipática. Paragraphs Browser sustituye eso por una modal con previsualizaciones visuales de cada tipo disponible. Es un cambio pequeño que reduce drásticamente la curva de aprendizaje del equipo editorial.

Templates Twig por tipo de párrafo. Cada Paragraph type tiene su template específico (paragraph--hero.html.twig, paragraph--text-image.html.twig) donde defines el markup HTML y enganchas tus clases CSS. Esto separa de verdad la lógica de presentación del contenido: el editor mete datos, el desarrollador controla cómo se renderiza, y nadie pisa el terreno del otro.

Mejores prácticas para equipos editoriales

Da igual qué herramienta elijas: la experiencia editorial se gana o se pierde en decisiones de diseño que están por encima de la configuración técnica.

Limita las opciones disponibles. Más opciones no es más libertad; es más decisiones que tomar y más sitios donde meter la pata. Un editor con cinco componentes bien diseñados y bien documentados produce más y mejor que uno con treinta opciones medio documentadas. Empieza corto, amplía cuando aparezca una necesidad real, no porque "igual viene bien tenerlo".

Crea una guía de estilo editorial. Documenta con capturas cuándo se usa cada componente: "El Hero va solo como primer elemento de landing pages", "Las columnas con iconos sirven para listar beneficios, máximo cuatro ítems", "El acordeón es para FAQs, no para esconder contenido importante". Los editores necesitan contexto, no solo herramientas.

Previsualización siempre disponible. Asegúrate de que tu equipo puede ver cómo queda la página antes de publicar. Con Layout Builder esto es prácticamente nativo; con Paragraphs vas a tener que configurar un display mode de previsualización o integrar algo tipo Content Preview. No es opcional: publicar a ciegas es la forma más rápida de generar deuda editorial.

Revisiones y workflows. Activa Content Moderation para que los cambios de layout pasen por aprobación antes de aparecer en producción. Editor junior monta el borrador, editor senior valida, y el lunes por la mañana no descubres que la home tiene un Hero con la imagen sin recortar. Especialmente útil si compartes el CMS con equipos de marketing y de producto a la vez.

Formación continua. Cada vez que introduzcas un componente nuevo, dedica media hora a explicarlo. Esa sesión te ahorra semanas de tickets de soporte y mensajes en Slack del tipo "no me sale el banner". Graba las sesiones, súbelas a un Drive interno y enlázalas desde la propia guía editorial.

Rendimiento y optimización

Las dos soluciones pueden cargarse el rendimiento si no las vigilas.

Con Layout Builder. Cada bloque inline añade queries. En páginas con muchos bloques, Big Pipe (que viene en core) ayuda enviando los bloques en streaming: el navegador empieza a pintar mientras los bloques pesados se generan por detrás. La diferencia en LCP en páginas largas es notable.

Con Paragraphs. Las consultas con muchos párrafos anidados acaban generando N+1 queries clásicas. El módulo Entity Reference Revisions con eager loading bien configurado es tu primera defensa para que la base de datos no se quede pensando.

En los dos casos. Caché agresiva a nivel de página con Varnish o Fastly, cache tags bien aplicados para que un cambio en un párrafo solo invalide las páginas que lo contienen (no toda la web), y las imágenes con lazy loading y formatos modernos como WebP o AVIF. Nada nuevo bajo el sol, pero es donde se ganan o pierden los Core Web Vitals.

Migrando de un enfoque a otro

Si ya tienes producción funcionando con uno de los dos y necesitas saltar al otro (o a una combinación de ambos), la migración es viable pero hay que planificarla con calma.

El salto de Paragraphs a Layout Builder (o al revés) pasa por mapear los tipos de párrafo existentes a bloques equivalentes, migrar el contenido con scripts que transformen una estructura en otra, rehacer los templates de presentación y, lo que más cuesta, reformar al equipo editorial en la nueva interfaz. No subestimes esta última parte: la migración técnica suele tardar menos que la curva de adaptación del equipo.

Si quieres una segunda opinión para decidir qué enfoque encaja con tu proyecto Drupal, configurar la solución elegida o preparar la formación del equipo editorial, puedes hablar con nuestro equipo de desarrollo Drupal y definir juntos la estrategia que mejor se ajuste a tu caso.

Cómo decidir sin quedarte bloqueado

Layout Builder y Paragraphs son soluciones maduras, probadas en miles de proyectos reales y con comunidades activas detrás. La pregunta correcta no es cuál es mejor en abstracto (esa conversación no lleva a ninguna parte), sino cuál encaja mejor con tu equipo editorial concreto, tu arquitectura actual y los objetivos que tienes para los próximos dos o tres años. Decide pensando en quién va a usar esto cada día, no en qué queda mejor en una slide de arquitectura.