Datos estructurados en Drupal

 Hola, otra semana más, aquí en Drupal Icete, donde yo, Robert Menetray, te cuento cosillas de Drupal. Esa semana te quiero comentar lo que son contenidos estructurados y los contenidos no estructurados. Y que se vea bien que supieras cuál es la diferencia y en qué casos de uso es mejor tener una u otra forma los contenidos en tu web. A ver, primero, primero de todo definir qué es cada cosa. Los no estructurados, digamos que es, imagínate que tienes una página, que lo típico es el campo de título y el campo de texto, descripción, el body, donde ahí tienes todo, HTML, todo puesto ahí con subtítulos, textos, imágenes, de todo, puesto en el mismo, ahí como HTML puesto. Es, en la mayoría de casos, como se trabaja en WordPress, ¿vale? En Drupal también puedes trabajar así. Tienes, por ejemplo, muchos artículos de blogs se usan así, tienes un campo de título y un de texto donde ahí lo pones todo. Pero en muchos casos, en vez de tenerlo así, es mejor tenerlo separado. O sea, imagínate una página de un producto en vez de un blog, tiene más sentido que en vez de tener un campo de texto donde hayas puesto todas las características del producto y escribes categoría, dos puntos, número de categorías, características técnicas, potencia, lo que sea, todo ahí puesto a mano, es mejor tenerlo en campo separado. Un campo para la potencia, un campo para el color, un campo para las categorías, un campo para el precio, un campo para todo. Y no tenerlo todo en un campo de texto, todo junto y mixto. ¿Por qué? Primero, si está todo junto y... Ahí me sale en catalán ahora la palabra, bueno, está todo junto y mezclado, que me salía, me salía en catalán. Al tener todo mezclado no te sirve para usar esto después en los filtros. Por ejemplo, si tenemos un e-commerce, queremos poder filtrar por categorías, o por colores, o por características técnicas, o por lo que sea. En total, tener contenidos estructurados te permite después de forma muy simple usarlo en filtros y en listados, cosa que de otra forma es bastante más complejo. ¿Vale? Segundo, frontend. Si lo tenemos todo junto y mezclado, es bastante difícil que todas las páginas de la web se vean de una forma visual consistente, o sea, que todos siempre guarden el mismo estilo visual. Por ejemplo, que la imagen siempre esté arriba y que lo último que se vea sea el precio, y que por el medio hagan los colores uno al lado del otro. Puede ser que, dependiendo de cómo se haya levantado el editor, la persona que edita los contenidos haya un día que el color lo ponga el último o que los colores los ponga uno debajo del otro, en vez de uno al lado del otro. O que no pongan categorías y las olvide. O sea, al final, dependes de los guerreros humanos. En cambio, si lo tienes como contenido estructurado y tienes cada campo de forma independiente, en el formulario puedes marcar de que estos campos son obligatorios o no. Por lo cual, si el campo categoría es obligatorio, sabes que siempre va a tener valor y que el usuario, o sea, el editor de texto, el modelador de contenidos, como le quieras llamar, cuando entre en el formulario, rellenen los datos, si se ha olvidado alguno, no le va a dejar guardar y no se va a publicar la página. Es una forma de asegurarte que los contenidos, a menos, han pasado unos estándares mínimos de calidad. De la misma forma, sabes de que cuando tengas todos esos datos rellenados, cuando se mueste este contenido, o sea, se randiriza el nodo, se randiriza la página de forma visual, se va a usar las plantillas de estos campos y que todas las páginas se van a ver de la misma forma. Que todos los botones van a tener la misma característica, visualmente van a ser iguales, que el precio va a estar siempre debajo o arriba, y que la imagen, por ejemplo, va a tener siempre el mismo tamaño. Cosas de estas que visualmente, al final, importan. Que si tienes solo cuatro páginas, te es igual, porque al final, editas manualmente esas cuatro páginas y tienes todo en el texto y es pasable. Pero que tienes unos cientos de páginas, cientos de productos, digo productos porque creo que visualmente es lo que más se entiende, pues esto, llega un punto que la gestión de todo este contenido, digamos que es un poco más compleja, porque si tienes que modificar algo, has de modificarlo para las 100 páginas. Cosa que si estuviera todo el contenido estructurado, básicamente se modifica alguna plantilla y automáticamente se te modifiquen todas las páginas. En el sentido de que ahora el campo categoría, por ejemplo, lo queremos ocultar, porque por X motivo no queremos que se muestre. Pues en la plantilla o en la configuración, desactivas que ese campo sea visible. Pero si estuviera como todo el contenido mezclado ahí dentro con el HTML, tienes que ir a cada una de las páginas eliminando esa categoría. Y si de aquí a dos meses quieres volver a activarla, tendrás que volver a editar todas las 100 páginas y volver a poner la categoría. Cosa que si fuera estructurado, solo tienes que ir al fórmula de configuración y activar el display de ese campo para que se muestre. O, si lo tienes por plantilla, modificar la plantilla. Al final, dependiendo de la cantidad de datos que tengas, tiene más sentido que sean contenidos estructurados o no. Y sobre todo, que es lo que entre comienzo he visto más yo, si quieres que esté filtrado, que hayan filtros, que es el caso típico de lcms, pues quiero que la gente pueda encontrar mis productos. Quiero que cuando en los listados de productos salga el título, la imagen a un lado, con un formato en concreto, el texto al lado y debajo del texto las categorías, por ejemplo, y el precio con un botón gordo de comprar. Si esto no está estructurado, digamos que es muy complejo de hacerlo que visualmente se vea bien. Que me lo he encontrado. Me he encontrado páginas que pensaba que eran estructuradas y cuando entra dentro del proyecto he visto que básicamente es HTML a pelo, todo puesto allí. Con lo cual después, claro, normal que el editor cuando entra se vuelva loco. Porque es HTML, o sea, hay HTML, digamos, simple, que es texto, digamos, un texto de un blog, y después hay landing page muy bien maquetadas visualmente, pero que es HTML todo custom con CSS en línea. Que esto es una muy mala práctica, no lo pongáis en base de datos, pero me lo he encontrado. En este caso tiene más sentido usar datos estructurados. Y aquí quiero entrar con el tema de qué módulos te facilitan el tema de usar datos estructurados. Primero de todo, Drupal ya por defecto te permite usar datos estructurados. Básicamente es poner campos. Tienes un tipo de contenido, aquí es tipo de nodos, y en vez de tener solo título y texto, pues añades pues campo de imagen, campo de fichero, campo tipo link, campo precio, campo lo que sea, y vas montando el apartado visual con este puzzle de campos que tienes. Y el formulario de edición te van a aparecer todos estos campos. Pero, en determinados casos, por ejemplo, cuando quieres montar una landing page, que es una página de aterrizaje en otro idioma, básicamente en inglés, tú quieres de que dada flexibilidad a que el usuario que está creando esa página pueda especificar de no, no, yo quiero poner arriba de todo una imagen al 100% del ancho, y debajo quiero poner dos columnas de texto, y debajo una columna de texto y una imagen a la derecha, y debajo una imagen a la izquierda y el texto a la derecha, y debajo un carrusel, y debajo un formulario, y debajo, y ahí ir añadiendo en formato puzzle, ¿vale? Lo que básicamente es como un wizz-wizz de que al final vas arrasando elementos y los vas montando allí. Esto, en Drupal, la forma mejor para tenerlo estructurado es usar el módulo paragraf, que no sé si vale la pena hacer un episodio solo hablando de este módulo, pero básicamente te queda un tipo de entidad que después lo puedes meter en otras entidades, en este caso no lo normal, es meterlo en tipos de nodo, y básicamente en el formulario de edición el usuario va a ir a añadir tipo de paragraf, botón, añadir tipo de paragraf, galería, añadir tipo de paragraf, imagen con texto. Al final son los tipos de paragraf que el programador, en este caso yo, pero pueden ser otros, lo configure, ¿vale? Configuras tantos tipos de paragraf como elementos están en el diseño original de la web. Si ves que todas las landings han de tener galería, formulario, imagen-texto, solo texto, texto-dos columnas, pues quedan todos estos items de paragraf. Y después el que usa la web, o sea, el editor de contenidos, podrá crear tantas landing pages como él quiera juntando estas piezas. Si está bien pensado esto, es muy simple y es muy usable de usar, pero me he encontrado en algunos casos de que han quedado tantos tipos de paragraf y está tan mal pensado esto que al final el editor, el usuario que edita las páginas se vuelve loco, ¿vale? Porque si tiene 30 y pico tipos de paragraf llega un punto que no sabe todos los que hay y al final solo acaba usando dos o tres. Vale, eso es una cosa que ten en cuenta. Eso no es problema de paragraf, es problema de el concepto, cómo se ha diseñado esta landing page. Y, ¿qué más comentar? Ah, un módulo. Hay un módulo Gutenberg, que a la gente de Wepess quizá les suena. Digamos que es un editor visual que entre comillas simila a la paragraf te permite arrastrar elementos y bueno, pues, creo una imagen arriba, debajo dos columnas de texto, debajo otro texto, debajo añade un bloque incrustado de no sé qué y al final vas construyendo esa landing page un poco a tu gusto, ¿vale? Juntando piezas de un puzzle. El problema que Gutenberg, que al menos en Drupal, lo que hace realmente es meter código HTML comentado, digamos, es código HTML lo que al final pone, en un único campo que es en el campo body. Con lo cual realmente no es contenido estructurado. Es contenido que está todo puesto ahí y mezclado. Con lo cual hay los problemas que comentaba antes. Que no es útil para hacer listados, ni tampoco es útil si por ejemplo ese contenido, o sea, ese texto lo quieres usar después en formato de resumen en listados, porque ¿por dónde lo cortas? Si quieres mostrar el primer elemento de texto, quizá no, te saldrá simplemente la imagen que has puesto más arriba y no todas las páginas se van a ver igual. Digamos que, por ejemplo, usas a Gutenberg, si lo tuyo es un bloc, tiene sentido y en Drupal hay casos que tiene sentido. O páginas simples, las páginas básicas que son solo páginas de texto o como mucho que tienen alguna imagen por el medio, puede tener sentido usar a Gutenberg o directamente HTML en el body. Pero en el resto de casos yo creo que tiene más sentido que sea estructurado. Y nada más esto, que te quedes con estos dos módulos. Que existe Gutenberg, que existe el CK Editor que ya viene en el core, que esto no lo he comentado, pero básicamente es lo que viene por defecto en Drupal, o sea, no hace falta comentar mucho. Y después el módulo paragraph que es para cosas más estructuradas, muy personalizadas. Porque en casos más simples, solo con los campos que vienen por defecto en Drupal, para datos estructurados tendrías entre comillas de sobras. Hay muchos proyectos que no he puesto paragraph, no me ha hecho falta poner paragraph. Y nada más, hasta la semana que viene. Espero que os haya sido útil esta recomendación de módulos para gestión de contenidos.