Usar Paragraph o Layout Builder

 Aquí estamos, otra semana más, en Drupalizate, este podcast donde yo, Robert Menetray, te cuento pues recomendaciones, tips y mi forma de trabajar con esta tecnología que es la gran desconocida, que es Drupal. Esta semana no tenía pensado hacer el episodio de esta temática. Esto es culpa del feedback que me dio Salvador Santander a través de LinkedIn. Mil gracias Salvador por darme feedback. Antes de que se me olvide, me lo dio a través de LinkedIn porque está suscrito a la newsletter que tengo en LinkedIn. Es una newsletter con el mismo nombre de este podcast, Drupalizate, donde aparte de cada semana recordar que pongo un episodio nuevo del podcast, también comparto artículos relevantes que he encontrado por internet de webs que hablan de temática Drupal, ¿vale? Así que si te interesan estos temas, te recomendaría que vayas a LinkedIn, busques mi nombre, Robert Menetray, o busques Drupalizate y te va a salir la newsletter para que te suscribas. Y cada semana te llegará a tu bandeja un mensaje de LinkedIn que yo he puesto ahí, los artículos que he encontrado, ¿vale? Dicho todo esto y ya acabado con el spam, lo que me dijo Salvador fue a raíz del episodio de Datos Estructurados, que si no me falla la memoria, es de hace dos semanas en el momento de grabar este podcast. Allí pregunté si valía la pena hacer un episodio más en detalle de parágrafes, digamos, cómo gestionar, qué modos usar para gestionar los datos estructurados, y su feedback fue un, sí, sí, a mí me interesa, quiero saber más de Paragraph, quiero saber de Gutenberg y de Layout Builder, y en qué casos es recomendable usar uno o el otro o ninguno de ellos. Así que bueno, este episodio viene a raíz de esto. Bueno primero de todo, digamos que hay cuatro formas distintas para datos estructurados, hay cuatro formas de gestionar estos datos. La más simple y la que casi no se menciona porque es de lógica, es usar lo que tenemos en Drupal por defecto. Son los campos de Drupal, en Drupal ya por defecto tenemos varios campos de texto, imagen, numéricos, de fecha, lo que sea. Tú en tu tipo de contenido, por ejemplo, un artículo de un blog, podemos poner una imagen de cabecera, pues ponemos un campo imagen y le ponemos como título del campo imagen de cabecera. Tenemos un campo de texto y le podemos poner pues descripción o body del artículo, y es un campo que permitimos poner HTML, HTML simple, o sea poner un H2, H3, o sea títulos, y poner negritas y enlaces, ¿vale? Pues un seque editos que te permite poner un texto simple. Podemos querer poner otro campo de imagen distinto que no sea el de cabecera, que sea una imagen que usaremos en listados, y queremos poder poner un campo de categorías o taxonomías que nos permitirá poner que este artículo del blog es de determinada categoría, y esto en un futuro lo usamos para filtros en los listados o para mostrar artículos de la misma categoría a otros, ¿vale? Artículos relacionados. Al final esto es lo que viene por defecto en Drupal, puedes poner estos campos y generas esta especie de puzzle en el tipo de contenido con esos campos que has configurado. Con los campos los vamos a configurar en los viewmodes. Los viewmodes digamos que es cómo se representan estos campos en cada parte de la web. Lo más típico es tener solo el viewmode full, ¿vale? Que es la página de detalle. Cuando entras en la URL de un artículo estás en el viewmode full de ese artículo. La forma de representar los contenidos de ese artículo en el viewmode full va a ser distinto de cómo se va a representar en otro tipo de viewmode, por ejemplo el viewmode teaser o resumen, que lo normal es usar ese tipo de viewmode en los listados, por ejemplo, o en los artículos relacionados que se muestran en el footer, por ejemplo. Podemos crear tantos tipos de viewmode como queramos. Podemos por ejemplo usar una views que use más de un viewmode porque un viewmode tenga una imagen a la derecha y otro tendrá una imagen a la izquierda, por ejemplo. O uno tendrá el texto y el otro no tendrá el texto, por ejemplo. De esta forma podemos tener el viewmode donde se va a mostrar la página de detalle con la imagen de cabecera, una imagen grande y panorámica, el título de abajo y la descripción de abajo, y después en los listados vamos a usar solo el título, el campo de categoría y la imagen que no es de cabecera, la imagen que es para los listados. Con lo cual tenemos la misma información en el mismo nodo, en la misma entidad, pero la forma de representarlo es que en cada viewmode se van a mostrar unos campos u otros, y de una forma u otra. Por ejemplo, podemos mostrar un campo de texto recortado, o un campo de texto en modo defecto, o sea, que te lo muestre todo el texto. O que una imagen te la muestre con un estilo de imagen distinto. También se puede aplicar con los viewmodes. Todo esto es configuración, no hace falta tocar código en nada, ¿vale? Hasta aquí es la forma más simple de tocar esto. También hay determinados casos que hace falta jugar un poco más con los diseños, con lo cual te hace falta tocar código HTML o Twig de las plantillas visuales. Con lo cual esta primera parte es, configuraciones de campos, configuraciones del viewmode, y editar las plantillas si es que hace falta, que no siempre hace falta tocar plantillas. Esta es la forma que viene por defecto en topa. Es la más fácil y normalmente, digamos que en la mitad de los casos no te hace falta tocar código. Ni te hace falta ser un expert on topa para usar esto. Siguiente caso. Puede ser de que en algunos casos esto se quede corto. Porque si es un tipo de contenido artículo de un blog, sabemos que siempre van a tener esos cuatro campos siempre los mismos, pues título, imagen y texto. Pero puede ser de que en algunos diseños tengamos un tipo de contenido que es landing page o página de aterrizaje. Son páginas que básicamente cada página es distinta. Usan elementos en común, como serán una imagen de cabecera, un formulario, un listado de X, un texto, un listado de preguntas frecuentes, y mil cosas más. Un carrusel, por ejemplo. Pero al final la página landing page que se usará para la home, va a ser una página landing page muy distinta visualmente a la que se va a usar en la página de ventas de no sé qué. O sea, van a usar los mismos elementos pero de forma distinta. O sea, van a reorganizar el puzzle visualmente y en algunos casos un slider, una galería, la voy a tener en la home pero no lo voy a tener en la página de ventas. Y el formulario de contacto lo voy a tener en la página de ventas pero no lo voy a tener en la home. Claro, esto se complica porque el formato que he comentado antes de poner campos, jugar con las plantillas y con los view modes, en este caso no nos sirve. Para hacer ese tipo de landing page hace falta algo más potente. Aquí es un elemento del módulo paragraph. El módulo paragraph digamos que te permite crear un tipo de campo nuevo, que es un campo paragraph, que te permite tener campos dentro de campos. Con lo cual, juntándolo con lo que he comentado antes de que tenemos campos, plantillas y view modes, podemos añadir un campo nuevo que es paragraph, que tenga campos dentro y que tengan su propio view mode. Con lo cual podemos usar un view mode del artículo y dentro del artículo full usaremos el view mode del paragraph cuando se esté mostrando el paragraph con determinado estilo visual. Así que digamos que con el paragraph, con los paragraphs, tenemos mucha más flexibilidad en cómo montamos esta web. Digamos que tenemos más piezas del puzzle para tener mayor flexibilidad. La parte buena y mala de usar el paragraph, tienes que tener visión del diseño y del proyecto para pensar bien cómo vas a usar los paragraphs. Al final estás diseñando las piezas del puzzle para que la persona que va a editar el contenido le sea fácil hacer esta edición. Con lo cual por el diseño se ve que tenemos que tener 10 tipos de paragrafes distintos y en vez de tener dos paragrafes idénticos, uno que tiene un color de fondo azul y uno que tiene un color de fondo blanco, quizá tiene más sentido tener un solo tipo de paragrafes con un campo donde escoger el color, un explicable de blanco azul por ejemplo. O una galería de que tengas imagen y otra tengas imagen texto. Pues quizá tiene sentido que sea lo mismo y que si el texto está vacío pues solo mostré la imagen. Cosas así. Al final es simplificar la vida al editor de texto, o sea pensar muy bien cómo vas a usar estas piezas del puzzle que estás creando. Y lo remarco bastante porque me he encontrado en proyectos que está tan mal pensado que era inusable la experiencia del editor de contenidos. Al final tiene que ser para una persona que tiene conocimiento nulo de Drupal y conocimiento nulo de todo. O sea que solo tenga que ser login a la web, al botón de editar página y que tenga un formulario para editar y que sea simple de usar. Con Paragraph si tienes más o menos clara la estructura de cómo funciona es muy fácil tú como desarrollador montar algo muy usable. Vale, aquí problemas de paragrafes. ¿Qué es el problema de paragrafes? a ver cómo me explico. El primero sería si tenemos webs multidioma en algunos casos, en algunos clientes me han solicitado que la página en español que tenemos ya montado el puzzle este de arriba tenemos una imagen, debajo tenemos un texto y debajo tenemos un formulario pues que en inglés queremos poner el formulario encima del texto. Queremos redondar los ítems o que no tengamos formulario en inglés o que no tengamos imagen en inglés. O sea que la pieza de puzzle no es que sea la misma traducida a otro idioma, no, no, es que queremos piezas distintas. En este caso Paragraph no sirve, vale, o tenemos que hacer digamos guarradas para ocultar Paragraph dependiendo del idioma. Paragraph va bien, o sea es traducible pero te permite traducir lo que ya has puesto como piezas de puzzle, o sea te permitirá traducir los textos, vale, pero no te permitirá añadir otro Paragraph distinto en inglés que no está en español. Los dos idiomas tienen que tener las mismas piezas de puzzle, la estructura visual ha de ser la misma en los dos o tres o veinte idiomas que tenga la web. Eso en algunos casos puede ser un problema porque algunos clientes como digo quieren tener la página en alemán con un contenido totalmente distinto, solo un texto simple y en inglés quieren tener una landing page con veinte cosas distintas. Así que digamos que no es la mejor solución, se pueden hacer como digo ocultando, o sea poniendo un campo especificando para qué idioma queremos que esté activo ese Paragraph o no, pero tampoco es la mejor forma de trabajar, pero bueno. Si con esto de los idiomas, si queremos que la página sea muy distinta en cada una de sus versiones traducidas, podemos usar Gutenberg. Gutenberg no es para contenido estructurado, esto ya lo comenté en el episodio pasado de hace dos semanas, pero sí que visualmente ayuda mucho a la persona que edita los contenidos porque básicamente es arrasar bloques y poner una imagen, un texto y arrasar cosas y visualmente se ve cómo es. El problema es que no es contenido estructurado, esto ya lo comenté en el episodio pasado con sus desventajas, pero para crear landing page muy simples y que han de ser muy distintas entre idiomas, casi que prefiero usar Gutenberg que no Paragraph. Así que no te haga falta tener que tener búsquedas o tener que usar view modes muy distintos y muy estandarizados en distintas partes de la web. Después relacionado con esto, Paragraph tiene un inconveniente que visualmente es feo. La edición de textos en Paragraph es feo. Cuando tienes un Paragraph anidado, o sea, dentro de otro Paragraph, o sea, tienes hijos de Paragraph que tienen Paragraph que tienen Paragraph, la edición es horrenda. Tienes que confiabr un poco de que tengas el preview activo para que no te muestre todo Paragraph desplegado de golpe y llega un punto que puede llegar a ser inusable. Digamos que parámetros de textos se le complica la edición, el formulario se ve muy complejo y digamos que se satura. Los usuarios que no son técnicos se saturan cuando ven un formulario con muchos campos. Esto con Gutenberg no pasa, la edición es mucho más simple. Estás más limitado en qué cosas puedes hacer, pero digamos que la edición es mucho más simple. Y después tenemos la opción, la última, la cuarta, que es el Layout Builder. Quiero hacer una aclaración de este módulo primero. Yo este módulo en producción no lo he usado nunca, o en producción de clientes, lo he usado en cosas mías para trastar un poco. Pero así como Paragraph, lo he usado desde Drupal 7, pasando por Drupal 8 y Drupal 9, o sea, hace muchos años que toco Paragraph. Lo que viene en Core es Drupal, también hace muchos años que lo toco desde los inicios. Y lo que es Gutenberg, hace muy poco que lo he tocado, pero sí que está en alguna web en producción, porque cosas que pedían clientes. Pero Layout Builder no puedo dar la experiencia de una web en producción porque realmente yo no la he tenido. Esto es por varios motivos. El primero es que hasta finales de Drupal 8, Layout Builder estaba en modo experimental. No es recomendable tenerlo en producción, lo primero. Creo que fue en 8.8 que fue estable. En Drupal 9 ya es estable y se puede usar perfectamente. Y después está lo que a mí más me chirría de Layout Builder, que a ver cómo me explico. Layout Builder es los viewmodes que he contado antes, de que podemos configurar distintos tipos de viewmode, pues es lo mismo pero con esteroides. Nos permite tener un viewmode distinto para cada nodo, no para cada tipo de contenido. O sea, no un viewmode que afecte a todos los blocs, o sea, a todos los artículos del blog. No, no, tenemos un viewmode que crearemos o modificaremos solo para un artículo en concreto. Con lo cual a finales podemos crear landing pages personalizadas una a una. Digamos que es la parte buena, o sea, juntaríamos la parte buena del primer método junto con lo de los paragraphs, pero claro, tiene sus partes malas. La parte mala es que la configuración de todo ello se complica mucho, ¿vale? Y sobre todo si no sabes bien bien cosas de Drupal se complica muchísimo. Lo he encontrado demasiado complejo para lo que es. Segundo, el que edita contenidos, ha de tener conocimientos de cómo trabaja Drupal por debajo, cosa que no siempre es así. O sea, se tiene que formar la persona que use Layout Builder como editor de contenido. Yo no me refiero a la persona que programa o configura todo esto, me refiero a la persona que pausa día a día esta web para crear contenidos, lo cual en algunos casos puede ser un inconveniente. Yo soy de los que piensa que cuando la web más simple mejor, porque normalmente los clientes, no los clientes, la persona de cliente que tiene que editar los textos normalmente tiene conocimientos nulos o escasos de programación o gusto visual, digámoslo así. En Layout Builder le das control total al editor de textos. La persona que edita puede ser lo que le venga en gana. Esto es bueno si sabes lo que haces, pero en muchos casos es malo, porque por diseño te pueden romper el diseño que estaba planificado. Con Paragraph puedes controlar bastante más que se puede y que no se puede hacer, ¿vale? Así que, digamos, por mi opinión, Layout Builder solo lo usaría si la persona que tiene que editar esta web, o sea, que editar los textos, es una persona más o menos formada y más o menos con gusto visual y que sabe cómo gestionar un Drupal. Si no es el caso, yo no recomiendo usar Layout Builder para una web para una persona que no tenga ni idea de lo que es un Drupal. Yo solo quiero una web para poner textos, pues Layout Builder creo que no. Da mucha flexibilidad, pero es muy complejo y creo que va a dar más problemas que otra cosa. Y dicho todo esto, recapitulando, los cuatro o cinco puntos que tengo en cuenta para escoger cada una de estas tecnologías, dependiendo del proyecto, el primero sería si sirve para los requisitos del diseño que tenemos. Si es un blog o una página básica, donde sólo tenemos un texto o texto-imagen, pues realmente no hace falta complicarse la vida con Paragraph, Layout Builder o con Gutenberg, en el caso. Simplemente con lo que viene por defecto en Drupal, que es poner un campo de texto largo que permite un HTML simple, ya sirve. O quizá no te hace falta ni un campo de texto, sólo quieres un campo de imagen y un campo de enlace. Y estos nodos tendrán un logotipo y al hacer clic te vas a la web de la persona del logotipo. No en todos los proyectos hace falta unos módulos que añaden complejidad al proyecto. Lo primero es si cumple los requisitos del tipo de página que estás haciendo. Coge el que más simple sea. Si ya te sirve con los campos, usa los campos. Si te hace falta un poco más, quizá Gutenberg o Paragraph. Y si te hace falta mucha más flexibilidad, pues lida a Layout Builder. El siguiente punto que tengo en cuenta es la facilidad de implementación o programación. Drupal ya no es la primera implementación, sino las siguientes implementaciones. Ahora sí me explico. Si con Paragraph se ha montado todo correctamente, puedo decir algo, y para ser número redondo si que se entienda. En una semana te monto todo el sistema con Paragraph. Durante un año entero, después, la persona que va a editar los contenidos no hace falta que tenga puñete de idea de HTML ni CSS ni nada de programación ni nada de cómo funciona Drupal internamente. Si está bien montado lo que es Paragraph, la persona editada que edita contenidos, puede ser una persona sin conocimientos, de nada. Por contra, si estamos usando por ejemplo un campo HTML con todo puesto allí, con CSS en línea, la persona que tiene que editar esto tiene que tener unos conocimientos básicos de HTML y CSS. Me encuentro en proyectos que están bloqueados porque no tenían este conocimiento, y cada vez que tenían que modificar algo en la página, tenían miedo de romper la página. Y lo mismo con Layout Builder. Me da la sensación de que al tener tanta configuración puede ser abrumador y que tengan miedo de tocar depende de qué cosas. O que si no tienen miedo, quizás tocan y la rompen. Así que quizás hace falta alguien con conocimientos un poco más no avanzados, pero sí con unos conocimientos a menos básicos de cómo funciona Drupal. Y no siempre es el caso cuando, como digo, hay gente que edita webs que apenas sabe hacer login y poner textos. Porque es que realmente no debería ser falta saber nada más. Bueno, y me he avanzado, este sería el tercer punto, o sea, la facilidad de edición de las páginas. Tenemos la... Si te sirve para el diseño que tenemos, para los requisitos del proyecto que tenemos, te sirve esto. Perfecto. Segundo paso sería la dificultad de implementación. Tercer paso sería la dificultad de edición. Y aquí vendrían después el cuarto y quinto paso. El cuarto sería lo que es multidioma. Si ese sistema te sirve para temas multidioma, como he comentado antes, para depende de qué webs tipo multidioma, paragraph no te sirve. Y Site Builder en teoría tampoco. Ay, Site Builder, perdón, Layout Builder. Basicamente pues lo mismo. O sea, el mismo nodo, o sea, el mismo artículo del blog en un idioma u otro se va a mostrar de la misma forma. Así que digamos que estás más limitado. Creo recordar que había un sub módulo en Layout Builder para el tema de multidioma. Pues que me suena, pero no lo he probado, ¿vale? Pero bueno, esto, que para temas multidioma el requisito del proyecto es que las páginas de distintos idiomas se vean muy distintas entre ellas, pues quizá paragraph no es la mejor opción, ¿vale? Y por último, el último punto de todo sería el rendimiento. Porque claro, al final es, una cosa es directamente tener HTML apelo, otra vez usar unos campos y unas confusiones en Drupal, que al final hay más consultos a base de datos, con lo cual, quieras que no, pues la web tarda un poquito más en cargar. Otra cosa es usar paragraph con campos dentro de campos que tienen campos, con lo cual, lo que comentaba antes de que tarda un poquito más en cargar, pues lo multiplicas por cada paragraph que metas dentro, con lo cual tarda un poquito bastante más en cargar. Y después ya le sumas lo que es layout builder, que puede ser mucho más costoso. A ver, no estoy diciendo que la web tarda tres segundos en cargar, ¿vale? Pero cuando tienes muchas visitas en la web, o muchas páginas, o páginas muy complejas, puede ser que notes la diferencia. Que paragraph ralentiza la web, o que layout builder ralentiza la web. Si por temas de rendimiento, si estás preocupado por esos temas, quizá mejor intentar hacer todo lo que puedas con lo que viene por defecto en el code, en el sentido de que sean campos y plantillas. Ya puede ser directamente usar las plantillas y saltarte la configuración de lo que son los viewmodes. Porque cuantas menos consultas se hagan a base de datos, mayor se nota el rendimiento. Como digo, esto son milisegundos, ¿vale? Pero al final, es un suma y sigue, y sí que hay webs que se ha notado mucho el cambio de no usar paragraph a usar otro tipo de implementaciones, porque hay páginas que realmente no tenía sentido hacerlas con paragraph. ¿Y qué más que me olvidé? Y layout builder, que creo que esto no lo he contado, te permite primero hacer como plantillas para que se rehusen en distintas páginas, y después sobreescribir esas plantillas y que páginas en concreto, pues tengan una disposición de elementos distintas. O sea, mueves los elementos del puzzle para que visualmente sea distinta la página. Pero también te permite usarlo como si fuera los viewmodes, con lo cual en vez de usar el layout builder para gestionar el viewmode y poner a dos columnas, quizá en vez de esto teníamos sentido editar una plantilla y poner la plantilla en dos columnas y los campos de cada columna adentro, y ya está. Y no poner un módulo con sus configuraciones que realentice en la web. O sea, al final, con layout builder te da mucha más flexibilidad y te permite no depender de tocar código, en muchos casos. Es mucho más flexible y te evita tocar código en la mayoría de casos, por así llamarlo. Pero te recarga con mucha configuración y creo que en determinados casos, en la mayoría, mi opinión, no vale tanto la pena. Al menos si te importa el rendimiento y te importa sobre todo que no te la lia el cliente. O sea, que no te la lia la persona que edita textos. Porque como digo, normalmente la persona que edita textos no tiene gusto visual y no le importa que la web se vea uniforme en todas sus páginas. Y pocos más. Mi recomendación, contenido estructurado, para Gaff, si lo implementas bien. Después Gutenberg en casos muy concretos y si no, intenta siempre usar campos y plantillas, lo que viene por defecto en tu pal. Layout builder, si no sabes tocar código o por el tipo de proyecto que quieres evitar tocar código y desarrollar, lo más rápido posible, porque hay veces que no hace falta mirar tanto rendimiento y te importa más que el desarrollo sea rápido y al final solo son cuatro páginas en determinados proyectos. Pues puede tener sentido usar layout builder, pero cuando tienes muchas páginas con mucho contenido y te importa mucho el rendimiento, yo no lo recomendaría. Y nada más. Hasta la semana que viene.