Cómo implementar un sistema de layout builder y contenidos flexibles con paragraphs en Drupal para editores no técnicos

Imagina esta escena: tu equipo de marketing necesita publicar una landing page urgente. El diseño ya está listo, pero el desarrollador Drupal está de vacaciones. Resultado: la página se retrasa una semana, la campaña pierde impulso y alguien en dirección pregunta por qué la web no puede ser tan fácil de editar como un documento de Word.

¿Te suena? Porque a mí me lo cuentan constantemente.

Como diseñadora UX especializada en experiencias editoriales dentro de CMS, este tipo de situación me toca la fibra. Según el informe State of CMS 2025 de Forrester, el 67% de los equipos de contenido en empresas medianas y grandes considera que la rigidez de su CMS es el principal cuello de botella para publicar a tiempo. Y aquí es donde Drupal, con su ecosistema de Paragraphs y Layout Builder, ofrece algo que muy pocos CMS pueden igualar: flexibilidad total para el desarrollador sin sacrificar la usabilidad para el editor no técnico.

Voy a contarte cómo diseñar e implementar un sistema de contenidos flexibles en Drupal que empodere a tu equipo editorial, reduzca la dependencia técnica y mantenga la coherencia visual de tu marca. Con ejemplos concretos y decisiones de arquitectura que puedes aplicar mañana.

Por qué los editores no técnicos abandonan Drupal (y cómo evitarlo)

Drupal tiene una reputación ambivalente. Los desarrolladores lo adoran por su potencia; los editores, muchas veces, lo temen. Y el problema no es Drupal en sí, sino cómo se configura. Un Drupal mal planteado obliga al editor a navegar por formularios interminables, campos cruzados y una experiencia de edición que recuerda más a un ERP que a una herramienta de contenidos. He visto editores con los ojos vidriosos delante de formularios con treinta campos. Eso no es usabilidad; es tortura.

La clave está en invertir la lógica: en lugar de construir tipos de contenido monolíticos con 30 campos fijos, creas componentes reutilizables que el editor combina libremente. Como piezas de Lego, pero con las instrucciones justas para que nadie construya un desastre. Eso es exactamente lo que permiten Paragraphs y Layout Builder.

Paragraphs: el concepto de componente editorial

El módulo Paragraphs transforma la forma en que Drupal gestiona el contenido. En lugar de un único campo de texto largo (el clásico body), defines tipos de párrafo independientes:

• Texto enriquecido: un bloque de texto con formato básico.
• Imagen con pie: imagen, alt text y caption.
• CTA (llamada a la acción): título, texto breve, enlace y estilo visual.
• Acordeón: preguntas y respuestas desplegables.
• Vídeo embebido: URL de YouTube o Vimeo con miniatura personalizada.
• Tabla de datos: filas y columnas editables sin tocar HTML.
• Testimonio: foto, nombre, cargo y cita textual.

Cada tipo de párrafo es un mini-formulario con solo los campos necesarios. El editor no ve 30 campos a la vez; ve un botón "Añadir componente", elige el tipo y rellena tres o cuatro campos. Así de simple. Y cuando ves la cara de alivio del equipo de contenido al descubrirlo, entiendes por qué merece la pena invertir en esto.

Layout Builder: el control visual de la maquetación

Mientras Paragraphs resuelve el "qué" (los componentes de contenido), Layout Builder resuelve el "dónde" (la disposición en página). Introducido en Drupal core a partir de la versión 8.7, Layout Builder permite definir secciones con diferentes distribuciones de columnas y arrastrar bloques dentro de ellas.

Para el editor significa poder decidir si un testimonio va a ancho completo o en una columna lateral, si la CTA aparece después del segundo párrafo o al final. Todo sin escribir una línea de CSS.

Arquitectura recomendada: Paragraphs + Layout Builder trabajando juntos

Aquí es donde muchos proyectos se complican innecesariamente. Hay dos enfoques y es fundamental elegir el correcto desde el principio.

Enfoque 1: Paragraphs como motor principal, Layout Builder como complemento

Este es el que recomiendo para la inmensa mayoría de sitios corporativos. Funciona así:

1. Defines los tipos de contenido con un campo Paragraphs principal (field_components).
2. Creas 10-15 tipos de párrafo que cubren el 95% de las necesidades editoriales.
3. Usas Layout Builder solo para las landing pages o secciones donde la libertad de maquetación es crítica.
4. Restringes Layout Builder por rol: solo los editores senior o el equipo de diseño acceden a la edición de layouts.

La ventaja: el editor medio trabaja siempre con la misma interfaz predecible (añadir paragraphs), mientras que los power users personalizan layouts cuando es necesario. Predecibilidad para la mayoría, potencia para quien la necesita. Eso es buen diseño UX.

Enfoque 2: Layout Builder como motor único

Drupal permite usar Layout Builder como sistema principal de composición. Es viable, pero presenta riesgos:

• Curva de aprendizaje mayor para editores no técnicos.
• Menor control sobre la consistencia visual si no se restringen las opciones de layout.
• Complejidad en la migración si más adelante necesitas cambiar la estructura.

Para la mayoría de proyectos empresariales en España, el enfoque 1 es la recomendación más segura. Reserva el enfoque 2 para equipos editoriales con formación técnica avanzada.

Implementación paso a paso

Vamos al grano. Estos son los pasos concretos para montar el sistema en un proyecto Drupal 10 u 11.

Paso 1: instalar y configurar los módulos necesarios

Los módulos esenciales:

• paragraphs: el módulo base, la estrella del show.
• paragraphs_ee (Entity Embed para Paragraphs): mejora la experiencia de edición.
• layout_builder (incluido en core): actívalo en Extend.
• layout_builder_restrictions: limita qué bloques y layouts están disponibles por tipo de contenido. Imprescindible.
• field_group: organiza los campos en pestañas o grupos lógicos.
• admin_toolbar: no es obligatorio, pero tus editores te lo agradecerán.

Instalación vía Composer:

composer require drupal/paragraphs drupal/layout_builder_restrictions drupal/field_group drupal/admin_toolbar
drush en paragraphs layout_builder layout_builder_restrictions field_group admin_toolbar admin_toolbar_tools -y

Paso 2: diseñar los tipos de párrafo

Mi parte favorita. Antes de tocar Drupal, siéntate con tu equipo editorial y haz un inventario de componentes. Pregunta directamente: ¿qué tipos de bloques usáis en vuestras páginas actuales? La respuesta suele converger en estos patrones:

Tipo de párrafo	Campos principales	Uso típico
Texto rico	Body (formatted long)	Bloques de texto narrativo
Imagen destacada	Imagen, alt, caption, alineación	Contenido visual
CTA Banner	Título, subtítulo, enlace, estilo	Conversión y navegación
Listado de iconos	Título del grupo, items (título + icono + descripción)	Features y beneficios
Vídeo	URL externa, miniatura override	Contenido multimedia
Acordeón FAQ	Items (pregunta + respuesta)	Preguntas frecuentes
Columnas	2-3 sub-paragraphs anidados	Layouts internos
Separador	Estilo (línea, espacio, decorativo)	Ritmo visual

Consejo que vale oro: no crees más de 15 tipos de párrafo en la primera iteración. Empieza con 8-10, mide el uso real durante tres meses y añade solo lo que el equipo demande con datos. He visto proyectos con 30 tipos donde solo se usaban 7. Todo ese exceso es ruido que confunde al editor.

Paso 3: configurar la experiencia del editor

Esta fase marca la diferencia entre un Drupal que el editor usa con gusto y uno que le genera rechazo.

Etiquetas claras, no técnicas. En lugar de "field_paragraph_cta_link", el editor debe ver "Enlace del botón". Configura las etiquetas en "Manage form display" de cada tipo de párrafo.

Previsualización en el formulario. Activa el modo "Preview" en los widgets de Paragraphs. El editor ve una representación visual del componente directamente en el formulario, sin necesidad de guardar y visitar la página. Esto cambia completamente la experiencia.

Drag and drop para reordenar. Paragraphs permite reordenar arrastrando. Asegúrate de que el widget está configurado como "Classic" o "Experimental" para habilitar esta funcionalidad.

Limitar opciones por tipo de contenido. Un tipo "Página de servicio" puede ofrecer 12 componentes, mientras que un "Post del blog" solo necesita 5. Configura esto en la definición del campo Paragraphs. Menos opciones, mejores decisiones.

Paso 4: configurar Layout Builder con restricciones

Si activas Layout Builder para ciertos tipos de contenido:

1. Actívalo en la pestaña "Manage display" del tipo de contenido.
2. Marca "Allow each content item to have its layout customized" solo si realmente se necesita.
3. Instala layout_builder_restrictions para:
   • Limitar los layouts disponibles (por ejemplo, solo 1 columna, 2 columnas 50/50 y 2 columnas 33/66).
   • Restringir los bloques que se pueden colocar en cada sección.
   • Asignar permisos por rol de usuario.

Paso 5: crear una guía editorial interna

No es técnico, pero es absolutamente imprescindible. He visto proyectos técnicamente perfectos fracasar por no tener un simple documento de referencia. Documenta:

• Qué tipo de párrafo usar para cada necesidad.
• Ejemplos visuales de cada componente con datos reales, no Lorem Ipsum.
• Buenas prácticas: tamaño de imágenes, longitud de títulos, cuándo usar un acordeón vs. texto corrido.
• Un flujo de publicación: borrador, revisión, publicación.

Sin esta guía, los editores terminarán usando solo "texto rico" para todo y perderás todas las ventajas del sistema.

Errores comunes que debes evitar

Después de participar en decenas de implementaciones de Paragraphs para empresas españolas, estos son los que aparecen con más frecuencia:

• Exceso de tipos de párrafo. 25 tipos en la primera versión es receta para la confusión. Menos es más.
• No restringir Layout Builder. Si dejas todas las opciones abiertas, los editores crearán páginas visualmente inconsistentes. La libertad sin límites no es usabilidad; es caos.
• Ignorar el rendimiento. Cada tipo de párrafo añade queries a la base de datos. En páginas con 20+ componentes, necesitas caché agresivo (Internal Page Cache + Dynamic Page Cache + BigPipe). Monitoriza desde el primer día.
• No formar al equipo. Una sesión de 90 minutos al arrancar el proyecto ahorra semanas de soporte posterior. Grábala y deja el vídeo accesible.
• Olvidar la accesibilidad. Los acordeones necesitan atributos ARIA, las imágenes necesitan alt text obligatorio, los vídeos necesitan subtítulos. Configúralo como campos requeridos desde el principio. La accesibilidad no es un extra, es un requisito.

Resultados reales: qué puedes esperar

Cuando el sistema está bien implementado, los números hablan solos:

• Reducción del 60-70% en tickets al equipo de desarrollo para cambios de contenido, según datos de agencias Drupal europeas.
• Tiempo medio de publicación de una landing page: de 5 días a 4 horas. El editor no necesita esperar a nadie.
• Consistencia visual garantizada. Cada componente tiene un diseño predefinido. El editor elige qué contenido poner, pero el diseño lo controla el tema de Drupal.
• SEO mejorado. Los tipos de párrafo bien construidos generan HTML limpio, con heading hierarchy correcta y datos estructurados si los configuras vía Schema.org Metatag.

Cuándo tiene sentido buscar ayuda especializada

Implementar Paragraphs y Layout Builder no es complicado para un desarrollador Drupal con experiencia. Pero la diferencia entre una implementación correcta y una excelente está en los detalles: la elección de los tipos de párrafo, las restricciones de Layout Builder, la optimización del rendimiento, la formación editorial y la integración con el flujo de trabajo de tu empresa.

Si tu equipo no tiene experiencia previa con este tipo de arquitectura, o si el proyecto es crítico para tu negocio, contar con un equipo que haya resuelto estos problemas antes puede ahorrarte meses de iteración. En Tangram Consulting trabajamos con empresas que necesitan que su Drupal deje de ser un freno y pase a ser una ventaja competitiva.

Conclusión: la flexibilidad que tu equipo necesita ya existe

No necesitas cambiar de CMS, no necesitas una plataforma no-code y no necesitas que cada cambio de contenido pase por desarrollo. Drupal, con Paragraphs y Layout Builder bien configurados, te da exactamente lo que buscan tus editores: libertad creativa dentro de un marco controlado.

La clave no está en la tecnología -- que ya existe y está madura --, sino en cómo la configuras y en cómo preparas a tu equipo para sacarle partido. Empieza con pocos componentes, mide el uso real, itera y escala. Ese es el camino que funciona.