main content

< Volver a blog sobre aplicaciones móviles

Layout Builder y Paragraphs en Drupal: páginas flexibles

Cómo implementar Layout Builder y Paragraphs en Drupal para diseñar páginas flexibles sin necesidad de código

Hay una queja que se repite en todas las organizaciones que gestionan contenido web: el equipo editorial quiere montar páginas con diseños variados y no puede hacerlo sin abrir un ticket a desarrollo. Cada cambio, un ticket. Cada ticket, días de espera. Drupal ofrece dos herramientas maduras para resolver esto: Layout Builder (en el core desde Drupal 8.5) y Paragraphs (módulo contribuido con más de una década a sus espaldas).

Las dos permiten construir páginas con secciones y componentes reutilizables, pero lo hacen de maneras distintas. Y esa diferencia tiene implicaciones reales para editores, desarrolladores y rendimiento.

Layout Builder: maquetación visual desde el core de Drupal

Layout Builder permite a los editores organizar el contenido arrastrando bloques dentro de secciones con layouts predefinidos. Funciona como una capa de presentación que se superpone a la estructura de campos de un tipo de contenido.

Activación y configuración inicial

Layout Builder viene incluido en Drupal core. Solo necesitas activar dos módulos: layout_builder y, opcionalmente, layout_discovery. Para habilitarlo en un tipo de contenido concreto:

Ve a Estructura > Tipos de contenido > [tu tipo] > Gestionar visualización.
En la parte superior, marca "Usar Layout Builder" y guarda.
Si quieres que los editores puedan personalizar el layout por nodo individual (no solo por tipo de contenido), marca también "Permitir que cada contenido tenga su layout personalizado".

A partir de ahí, al editar un nodo de ese tipo aparecerá la opción "Layout" junto a las pestañas habituales de ver y editar. Asi de rápido.

Secciones y layouts

Cada página en Layout Builder se compone de secciones. Cada sección usa un layout que define su estructura de columnas. El core incluye layouts básicos de una, dos, tres y cuatro columnas. Para la mayoría de proyectos eso se queda corto, asi que querrás crear layouts personalizados mediante una plantilla Twig y un YAML de definición:

# mi_tema.layouts.yml
mi_layout_destacado:
  label: 'Sección destacada con sidebar'
  category: 'Layouts personalizados'
  template: layouts/destacado-con-sidebar
  regions:
    principal:
      label: 'Contenido principal'
    sidebar:
      label: 'Sidebar'
  default_region: principal
  icon_map:
    - [principal, principal, sidebar]

La plantilla Twig correspondiente recibe las regiones como variables:

{# layouts/destacado-con-sidebar.html.twig #}
<div class="layout-destacado">
  <div class="layout-destacado__principal">
    {{ content.principal }}
  </div>
  <div class="layout-destacado__sidebar">
    {{ content.sidebar }}
  </div>
</div>

Bloques en Layout Builder

Dentro de cada región, los editores pueden colocar bloques de distintos tipos:

Campos del propio contenido: título, cuerpo, imagen destacada, cualquier campo del tipo de contenido.
Bloques personalizados: bloques de contenido creados ad hoc (texto, HTML, imágenes) que se almacenan como entidades.
Bloques del sistema: menús, breadcrumbs, bloques de vistas, formularios de búsqueda.
Bloques contribuidos: cualquier bloque proporcionado por módulos instalados.

Esa combinación es lo que hace potente a Layout Builder. Una landing page puede mezclar campos estructurados con bloques de contenido libre y bloques dinámicos de vistas.

Paragraphs: componentes estructurados para editores

Paragraphs va por otro camino. En lugar de arrastrar bloques sobre un canvas visual, define tipos de componentes (paragraph types) que los editores añaden secuencialmente dentro de un campo de referencia. Cada tipo de paragraph tiene sus propios campos, y eso es precisamente lo que garantiza la consistencia.

Instalación y configuración

Paragraphs se instala como cualquier módulo contribuido:

composer require drupal/paragraphs
drush en paragraphs

La configuración pasa por tres pasos:

Crear tipos de paragraph: en Estructura > Tipos de Paragraphs, defines cada componente. Ejemplos típicos: "Bloque de texto", "Galería de imágenes", "CTA con botón", "Listado de características", "Testimonio de cliente".
Añadir campos a cada tipo: un paragraph de tipo "Testimonio" tendría campos como texto de la cita, nombre del autor, cargo, foto y empresa.
Añadir un campo de referencia en el tipo de contenido: en el tipo de contenido donde quieras usar paragraphs, añades un campo de tipo "Entity reference revisions" que apunte a los tipos de paragraph permitidos.

Crear tipos de paragraph que funcionen de verdad

La experiencia del editor depende directamente de cómo diseñes tus tipos de paragraph. Estas son pautas que veo funcionar una y otra vez en proyectos reales:

Granularidad media: ni un solo paragraph mastodóntico que intente cubrir todos los casos, ni veinte paragraphs tan específicos que el editor no sepa cuál usar. Entre 8 y 15 tipos suele ser el punto dulce para la mayoría de sitios corporativos.

Nombres descriptivos: "Sección de texto con imagen lateral" es mucho más claro que "Paragraph tipo C". Los editores tienen que entender qué hace cada componente solo leyendo su nombre.

Campos con valores por defecto y ayuda contextual: configura textos de ayuda y valores por defecto donde tenga sentido. Un campo de color de fondo con "blanco" por defecto ahorra clics innecesarios.

Preview en el formulario: el módulo paragraphs_previewer muestra una vista previa del paragraph renderizado dentro del formulario de edición. Esto reduce drásticamente los ciclos de "guardar, ver, volver a editar" que desesperan a cualquier redactor.

Cuándo usar Layout Builder, cuándo Paragraphs y cuándo ambos

No hay una respuesta universal. Depende del proyecto, del perfil de los editores y de los requisitos de diseño.

Layout Builder encaja mejor cuando:

Necesitas que los editores controlen la disposición espacial de los elementos: columnas, anchuras, posicionamiento.
El sitio tiene muchas landing pages con diseños variados que no siguen una estructura fija.
Quieres aprovechar el sistema de bloques existente de Drupal (vistas, menús, formularios).
El equipo editorial tiene experiencia con interfaces de arrastrar y soltar tipo page builder.

Paragraphs encaja mejor cuando:

Necesitas un control estricto sobre la estructura del contenido. No quieres que los editores tengan libertad total de maquetación porque sabes que eso acaba mal.
Cada componente requiere campos específicos con validaciones: un CTA siempre tiene título, texto y URL; un testimonio siempre tiene cita y autor.
El sitio tiene un design system cerrado con un catálogo definido de componentes.
Los editores prefieren un flujo de trabajo secuencial (añadir componentes uno tras otro) frente a una interfaz espacial.

Usar ambos tiene sentido cuando:

Quieres que Layout Builder gestione la distribución de columnas y secciones, y que dentro de cada sección los editores usen paragraphs como bloques de contenido estructurado.
El módulo layout_paragraphs facilita esta integración, añadiendo capacidades de layout (columnas, reordenación por arrastre) directamente al campo de paragraphs, sin necesidad de activar Layout Builder del core.

Permisos y roles: qué puede hacer cada perfil

El objetivo es que los editores tengan autonomía sin que puedan romper el diseño del sitio.

Permisos en Layout Builder

Usar Layout Builder: permite acceder a la interfaz de layout en los nodos.
Crear y editar bloques personalizados: controla si el editor puede crear nuevos bloques de contenido o solo usar los existentes.
Configurar el layout por defecto: este permiso suele reservarse a administradores o desarrolladores, porque afecta a todos los nodos del tipo de contenido.

Lo que mejor funciona: permitir que los editores modifiquen el layout de nodos individuales (landing pages, páginas de campaña) pero no el layout por defecto.

Permisos en Paragraphs

Los permisos se gestionan con paragraphs_type_permissions, que controla qué tipos de paragraph puede crear, editar o eliminar cada rol. Muy útil cuando ciertos componentes (como un bloque de HTML personalizado) solo deben estar disponibles para roles técnicos.

Diseño responsive y consideraciones de frontend

Layout Builder y responsive

Los layouts personalizados deben diseñarse pensando en responsive desde el primer dia. Layout Builder no genera automáticamente breakpoints ni media queries. Esa responsabilidad recae en el tema. Un layout de tres columnas debería colapsar a una columna en móvil:

.layout-tres-columnas {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 2rem;
}

@media (max-width: 768px) {
  .layout-tres-columnas {
    grid-template-columns: 1fr;
  }
}

Paragraphs y responsive

Los paragraphs se renderizan como bloques de contenido apilados, lo que simplifica bastante la responsividad. Cada paragraph type tiene su propia plantilla Twig. El módulo crea sugerencias de plantilla automáticas:

paragraph--testimonio.html.twig para el tipo "testimonio".
paragraph--galeria-imagenes.html.twig para el tipo "galería de imágenes".

Esto permite que el equipo de frontend diseñe cada componente de forma independiente, con sus propias reglas de responsive. Cada pieza en su caja.

Integración con design systems y bibliotecas de componentes

En proyectos empresariales, tanto Layout Builder como Paragraphs se integran con design systems existentes. Las dos estrategias más extendidas son:

Single Directory Components (SDC): desde Drupal 10.1, Drupal soporta de forma nativa componentes autodescriptivos que encapsulan plantilla Twig, CSS y JavaScript en un solo directorio. Tanto los layouts de Layout Builder como las plantillas de paragraph pueden hacer referencia a estos componentes.

Storybook + Drupal: el módulo cl_server conecta Storybook con los componentes Twig de Drupal. El equipo de frontend trabaja en los componentes de forma aislada y estos se integran como paragraph types o bloques de Layout Builder. Dos mundos que se encuentran.

Rendimiento: qué impacto tiene cada enfoque

Layout Builder

Layout Builder almacena la configuración de layout como parte de la entidad de contenido (para layouts por nodo) o como configuración (para layouts por defecto). Esto puede generar consultas adicionales a la base de datos para resolver los bloques de cada sección.

Para mitigar el impacto:

Activa el módulo big_pipe (core) para que los bloques pesados se carguen de forma asíncrona.
Usa la caché de render de Drupal, que almacena en caché cada bloque individualmente con sus etiquetas de caché.
Evita colocar demasiados bloques con vistas sin caché en una misma página. Es tentador, pero escala mal.

Paragraphs

Paragraphs almacena cada componente como una entidad de revisión vinculada al nodo padre. En páginas con muchos paragraphs (más de 20-30), el número de consultas a la base de datos puede crecer de forma notable.

Medidas de optimización:

El módulo entity_reference_revisions (dependencia de Paragraphs) ya implementa carga lazy de revisiones.
Configura la caché de vistas para que las listas de nodos con paragraphs no recarguen todos los paragraphs anidados.
Para sitios con mucho tráfico, jsonapi_extras permite servir los paragraphs desde una caché de API.

Módulos contribuidos que amplían las capacidades

Para Layout Builder

Layout Builder Styles: permite añadir clases CSS a secciones y bloques desde la interfaz de edición, sin tocar código.
Layout Builder Restrictions: controla qué bloques están disponibles en cada sección o tipo de contenido.
Layout Builder Component Attributes: añade opciones de accesibilidad y atributos HTML a los componentes.
Layout Builder Asymmetric Translation: resuelve la gestión de layouts en sitios multilingues donde cada idioma puede tener una estructura de página diferente.
Section Library: permite guardar secciones completas (con sus bloques) como plantillas reutilizables que los editores pueden insertar en otras páginas.

Para Paragraphs

Layout Paragraphs: añade capacidades de layout (columnas, rejillas) al campo de paragraphs con una interfaz de arrastre intuitiva.
Paragraphs Browser: reemplaza el selector de paragraph types por defecto con un navegador visual con iconos y descripciones.
Paragraphs Asymmetric Translation Widgets: gestiona traducciones donde cada idioma tiene un conjunto diferente de paragraphs.
Paragraphs Edit: mejora la experiencia de edición en línea.
Classy Paragraphs: permite asignar estilos visuales predefinidos (fondos, variantes de color) desde la interfaz editorial.

Migrar entre Layout Builder y Paragraphs

Si tienes un sitio que usa Paragraphs y quieres pasar a Layout Builder (o al revés), no existe un camino automatizado. La migración requiere:

Crear la estructura de destino (layouts y bloques, o paragraph types).
Escribir una migración personalizada con la Migrate API que lea los datos del enfoque actual y los transforme al nuevo formato.
Ajustar las plantillas de frontend.

En la práctica, este tipo de migración rara vez se justifica salvo que los requisitos del proyecto hayan cambiado de forma sustancial. Ambas herramientas son lo bastante maduras como para evolucionar con el proyecto a largo plazo.

Flujos editoriales en proyectos reales

Un flujo editorial bien montado con cualquiera de estas herramientas suele seguir esta estructura:

El equipo de desarrollo define los layouts o paragraph types disponibles, con sus campos, validaciones y plantillas de renderizado.
El equipo de diseño proporciona los estilos CSS y las variantes visuales de cada componente, idealmente documentadas en un Storybook o guía de estilos.
Los editores de contenido crean páginas combinando los componentes disponibles, rellenando los campos y reordenándolos según la necesidad de cada página.
El flujo de revisión (mediante Content Moderation del core de Drupal) permite que un editor senior revise y apruebe las páginas antes de publicarlas, verificando que el diseño es coherente y el contenido correcto.

Este reparto de responsabilidades funciona. Evita que los editores generen páginas inconsistentes y que dependan del equipo técnico para cada cambio menor. Cada uno hace lo que sabe hacer.

La herramienta correcta depende del equipo que la va a usar

La decisión entre Layout Builder y Paragraphs no es puramente técnica. Las dos resuelven el mismo problema con enfoques distintos. La pregunta real es: qué necesitan tus editores, qué nivel de control quieres darles y cuánto esfuerzo de frontend puedes asumir en la configuración inicial.

Un sitio con equipo editorial experimentado y maquetación diversa se beneficiará de Layout Builder. Un sitio corporativo con design system estricto y editores que rotan funcionará mejor con Paragraphs. Y en bastantes casos, la combinación de ambos es la respuesta correcta.

Si necesitas asesoramiento para elegir el enfoque adecuado a tu proyecto Drupal o evolucionar tu sistema de edición de páginas, contacta con Tangram Consulting y analizamos tu caso concreto.

Contacta con nosotros