Las entidades de Drupal

Bienvenido otra semana más a este podcast donde te hablo de cosas Drupal. Este podcast de Drupal ST, la semana pasada ya te comenté por qué te interesa estar en Drupal VRG y si no te has apuntado, pues no sé por qué tardas tanto la verdad, has tenido una semana entera. Y bueno, en ese episodio también hice un poco de spoiler de qué iba a hablar esta misma semana y es básicamente de entidades. Las entidades Drupal que son, por qué se deben usar y por qué quieres saber qué son básicamente. Primero de todo, empecemos por qué quieres saber qué son las entidades o por qué te va bien saber de lo que hablas un poco. Si es un usuario que tiene una web, un cliente o una persona no técnica porque tiene que gestionar una web y tiene que hablar con un departamento técnico o un informático para que lo entienda, no está de más saber un poco el vocabulario con el que se trabaja en Drupal y no está de más saber un poco las limitaciones que tiene trabajar con Drupal porque la base son las entidades. Y después, si lo que tú eres, eres básicamente un programador junior, porque si fueras senior realmente no sé para qué estás escuchando esto porque debías saber lo que son entidades ya. Pero si eres un junior, no está de más saber qué son las entidades, cómo se trabaja en Drupal. Para temas de backend, cuáles son buenas prácticas y cuáles son malas, o muy malas mejor dicho. Y básicamente esto, que tanto si eres un junior como si eres una persona que gestiona la web, te interesa saber los conocimientos mínimos de qué son las entidades y cómo se trabaja con ellas. Primero de todo, vamos a explicar qué son las entidades. Las entidades son un grupo de datos, un conjunto de datos que se agrupan para formar parte de la misma cosa. Por poner el ejemplo más tonto, cuando tenemos una página, una URL, o sea una página, no me refiero a una web entera, sino únicamente una URL que tiene una página en concreto, tenemos la URL, tenemos el título, un texto, un campo imagen y la fecha de creación. Esos cuatro datos forman parte del mismo conjunto de datos que son esta página. No forman parte de cuatro páginas distintas, forman parte de la misma página, del mismo conjunto de datos. Eso de forma muy simplista es una entidad. En Drupal, digamos que tenemos dos tipos de entidades muy separadas, muy distinguidas entre ellas. Las entidades de contenido y las entidades de configuración. Para explicarte más o menos qué es cada cosa, tengo que explicar que Drupal trabaja todo con base de datos. Tenemos el PHP, que digamos que es el cerebro, el que está totalmente, constantemente calculando cosas, y pasándolo a front-end para mostrarlo visualmente. Básicamente, que data con que PHP calcula cosas. Y después tenemos la base de datos, que digamos que es el almacén donde PHP va a buscar las cosas que ha de calcular y mostrar. Por ejemplo, con el tema de la página, si tenemos una página con una URL, cuando un usuario entra en esta URL, PHP recibe, ah, vale, ha ido a esta URL, vale, voy a base de datos, busco esta URL, qué título le corresponde, qué texto le corresponde, qué imagen le corresponde y qué fecha de creación le corresponde. Hago unos cálculos, lo junto todo y lo devuelvo al front-end. Y ahí se va a mostrar, pues, el título, la imagen, el texto y la fecha de creación se recalcula para mostrar, por ejemplo, el mes y el año. No se muestra el día, porque por configuración, en este caso, no se quiere mostrar el día. Al final, PHP puede alterar los datos que coge de base de datos, vale, no sé si me estoy poniendo demasiado técnico o no. Pero digamos que esto, tenemos el almacén de datos, que es la base de datos, y tenemos lo que calcula o lo que solicita obtener la información, que en este caso es PHP, que es el servidor web también. Vale, en el caso de la página, es una entidad de tipo contenido, vale. En el caso de una entidad tipo configuración, también está en base de datos, porque al final en Drupal hay formularios de configuración y cada vez que se modifica un dato, pues se guarda en base de datos. Pero tenemos la opción, que recomiendo mucho que la uses si eres un programador, que es que esta configuración que está en base de datos la puedes exportar a código, de forma muy simple, y básicamente lo metes dentro del Git, en el repositorio, lo subes a distintos servidores y haces el deploy en cada uno de los servidores. Esto básicamente te ahorra el tiempo de aplicar la misma configuración manualmente en varios entornos de la misma web, por ejemplo en desarrollo, pre-producción y producción, y también te ahorra el tiempo, mejor dicho el tiempo no, te ahorra los errores humanos que puedes provocar al hacer esto manualmente. Y a ti como cliente también, si tú no eres un programador sino que eres el que tiene la web, te da tranquilidad de una cosa que funciona en desarrollo, sabes que te va a funcionar en producción, porque se va a aplicar la misma configuración exacta. Esto en otros CMS como webpress, esto no va así. Y realmente no se le da el bombo que debería, en Drupal es la hostia tener esto, literalmente, es lo que más me gusta de esta tecnología. En Drupal 7 se tenían que hacer un poco de piruetas, en Drupal 8 se implementó, en Drupal 9 va de coña, y se va a mantener en todas las versiones futuras, porque realmente es una solicitud que se hizo desde parte de la comunidad, de esto tiene que estar. Para proyectos serios no puede ser que trabajes sin temas de configuración exportable. Bueno, no me quiero alargar mucho con el tema de entidades de configuración, me voy a alargar más en otro episodio hablando de este tema y de cómo trabajar con ello. Pero solo quiero que te quedes con el concepto de, tenemos entidades de configuración que se exportan a código. Y tenemos entidades de contenido, que son cosas que no se exportan a código, pero que nos permite, o nos facilita la vida, trabajar con ellas desde código o también de forma un poco más conceptual. Volviendo al ejemplo de la página con el título, la URL y el texto, en Drupal todo se guarda en base de datos, pero no tenemos una tabla donde se guarda todo allí. Tenemos muchas, pero muchas tablas, pero muchísimas tablas. Por cada tipo de contenido, por cada tipo de página, tenemos una tabla para cada uno de los campos. Con lo cual si tenemos un tipo de contenido que tiene 20 campos, tendremos 20 tablas. Bueno, si tú lo sabes gestionar, pues bien, pero imagínate que tienes una web de medida, no en Drupal, sino hecha a pelo en PHP, IMEI, SQL, cuando tengas 150 tablas, empieza a ser un poco ingestionable esto. Sobre todo cuando aún no se ha acabado el proyecto y se añaden campos, se quitan campos, con lo cual se añaden tablas, se quitan tablas. En Drupal esto, como se añaden y quitan campos de forma sin programar nada, solo por configuración, y automáticamente se quedan o eliminan las tablas correspondientes, no tiene mucho sentido que desde código hagas consultas directamente base de datos. Lo que tiene sentido es trabajar con la API que tiene Drupal, que tú le pasas un ID de la entidad y Drupal ya internamente hace las consultas que le corresponden y lo gestiona por rendimiento, por el tema de cachés, lo cachéa si puede o si está bien configurado, y te devuelve la información ya de toda la misma entidad, pues todos los campos que tiene esa entidad. Lo que facilita mucho trabajar con ello, como programador te facilita muchísimo la vida, te despreocupa totalmente de cómo está la base de datos. Es un gran punto a favor, la verdad. Y vale, más o menos creo que te ha quedado claro que es una entidad y más o menos cómo funciona Drupal. Ahora vamos a hablar de los tipos de entidades, en este caso de contenido, que tenemos en el core y cuáles no son del core, pero recomiendo o a menos que sepas cuáles son. Primero de todo, los nodos, porque es la palabra que más vas a escuchar si tienes una web en Drupal. ¿Qué es un nodo? Los nodos son las páginas. La mayoría de páginas que tienen una URL en Drupal, la mayoría, el 90%, son nodos. Creo que venía de Drupal 6, de cuando se implementó esto, no sé bien de dónde viene el nombre, pero bueno, en vez de poner páginas, le dijeron nodos y ahí se ha quedado. Dentro del tipo de entidad nodo, tenemos tipos de nodos. Todo esto es desde configuración, no es código, vale, o sea, tú puedes instalar un Drupal y crear tipos de nodos nuevos o eliminar tipos de nodos antiguos. Y dentro de cada tipo de nodo, puedes crear campos nuevos o eliminar campos existentes o modificar campos existentes. Esto da una flexibilidad y una potencia increíble. Por ponerte un ejemplo, si tenemos un blog simple, una página, una web que es un blog, pues básicamente tenemos un tipo de nodo, que es un tipo de contenido, que será página del blog. Que tendrá pues el título, un texto y una imagen destacada. Y cada página que se cree nueva va a pedir esos tres campos y tendremos un formulario que sale esos tres campos. Ahora imagínate que tenemos en vez de un blog, tenemos una web que es de una empresa que tiene páginas básicas de términos de uso y temas legales, que es un título y un texto. A parte tiene una sección del blog, que es lo que ya comentado antes, un blog normal con sus campos. Y también tiene, por ejemplo, páginas landing page con configuraciones varias para páginas más visuales, que no es una página básica de solo texto. Perdón. Total. Cuando son webs más complejas, da la flexibilidad de crear tantos tipos de contenido como tan complejas sea la web. Y por ponerte otro ejemplo, si en vez de tener una página de servicios o una página de empresa o un blog, tenemos un directorio de, yo qué sé, de empresas, de venta de coches, de cosas de segunda mano. O un escaparate de una tienda que no vende productos, o directamente tenemos un e-commerce que sí que vende productos. Todo esto son entidades y te permite gestionarlo entre ellos y tenerlo compartimentado. Y saber que los campos que están en el blog son distintos que los campos que están en, por ejemplo, en el producto del e-commerce. Que en un 
caso vas a pedir una imagen para la destacada del blog y en otro vas a pedir, por ejemplo, máximo 20 imágenes para la galería del producto. O que el producto tenga un campo de precio o tenga un campo de, yo qué sé, archivo adjunto para añadir la garantía en PDF y el blog esto no lo va a tener. O sea, al final te permite poner tantos campos tan distintos como tú quieras y gestionar cómo se van a ver o si se van a mostrar visualmente en la web o solo van a ser para gestión interna de, por ejemplo, el modelador o administrador de la web. ¿Qué más? Estos son los tipos de nodo. Después tenemos lo que son taxonomías. Es otro tipo de entidad y básicamente son taxonomías o vocabularios de taxonomía y son las categorías de toda la vida. Digamos que tiene la flexibilidad de o no usarlo porque hay webs que nos hace falta tener taxonomías o vocabularios. Hay proyectos que no son tan complejos como que te haga falta esto. Pero en otros, por ejemplo, en blog, tiene sentido tener, pues al menos, un único vocabulario. Si tienes un vocabulario de taxonomía, por ejemplo, tax, los tax son una taxonomía. Al final, si tienes términos de taxonomía donde tienes, por ejemplo, solo el nombre y tendrás, pues, por ejemplo, en mi blog, pues tengo Drupal 7, Drupal 8, rendimiento, migraciones y al final son tax de los artículos del blog. Otro caso distinto puede ser, por ejemplo, para una e-commerce tendremos varios vocabularios. Podemos tener, por ejemplo, uno que sea características del producto, si es sinifugo, si es resistente al agua, si es lo que sea, características del producto. Otro vocabulario puede ser el color y tendremos una lista de colores y ya se ha añadido como un vocabulario. En otro caso, podemos tener, yo que sé, las tallas. Si en vez de que sea un e-commerce como tal, queremos que sea un escapadero, se puede añadir como si fuera, en vez de unos atributos, que sea como taxonomía. Por lo cual, podemos tener las tallas de la ropa como categorías, como taxonomías. ¿Qué más? Básicamente, cosas a tener en cuenta, en las entidades, en el tipo de entidad, hay campos que son obligatorios y depende de cada tipo de entidad. Por ejemplo, las urls y los títulos en los nodos son obligatorios y el campo de autor y el campo de fecha también. Son campos que no puedes eliminar. En algunos casos, si no quieres que tenga urls, quizá no tiene sentido que sea un nodo. De la misma forma, taxonomías no tienen título, sino que tienen campo nombre, aunque viene a ser lo mismo, y campo descripción, que en la taxonomía es obligatorio. Es un campo que no puedes eliminar en la taxonomía. Lo puedes ocultar, pero no puedes eliminarlo. Y la taxonomía también tiene url. Hay un módulo como reddit.org que te permite quitar las urls de las taxonomías, por ejemplo. Que depende del proyecto, no quieres que se indexen en Google las taxonomías. Pero esto ya es otro tema. Total, volviendo al tema. Tenemos nodos y taxonomías. ¿Qué más tipos de entidad tenemos en Trupal? Los usuarios, por ejemplo, son un tipo de entidad. El usuario me refiero como la persona que se ha dado de alta en la web, que se ha registrado y que pueda hacer login en la web. Es un tipo de entidad que tiene sus campos, por ejemplo, el mail, la contraseña, la fecha de dada de alta, el nombre del usuario y algún campo más. Al mismo tiempo, puedes añadir campos nuevos, que son, por ejemplo, el nombre y apellidos, DNI, un campo de imagen para el perfil, un campo de PDF para que suba un certificado de no sé qué. Y que después de un moderador de la web valide que este usuario tiene este certificado. Esto ya depende de cada proyecto y de qué campos hagan falta o no para tu proyecto. Como digo, lo he hecho antes creo, Trupal es hiper flexible. Te permite poner aquí la cantidad de campos que tú quieras. Y puedes tener, por ejemplo, distintos tipos de perfil de usuario. Esto te hace falta un módulo aparte, que es el Profile. Pero puedes tener campos distintos dependiendo de si este usuario tiene un rol o tiene otro. Por ejemplo, un usuario moderador puede tener campos distintos que un usuario de a pie que se registra para usar la plataforma como tal. Como digo, en usuarios, por ejemplo, te hace falta el módulo Profile para gestionar campos distintos. ¿Qué más? Tenemos, por ejemplo, los tipos de entidad fichero y los tipos de entidad tipo media. Son distintos. Los dos son para tratamiento de ficheros, o sea, imágenes, PDFs, documentos web, ficheros que se suben a la web. Pero digamos que, a ver cómo te lo explico. Originalmente, Trupal en el core solo venía con el entidad tipo fichero. Que básicamente estuvo en el, por ejemplo, en un nodo, añades un campo tipo fichero porque quieres subir una imagen, por ejemplo. Quieres permitir que los usuarios suban imágenes a las páginas. Pues, bueno, pues el entidad tipo fichero, cuando añaden la imagen, ya sea buscando un fichero y subiéndolo, o arrastrando en la web, o sea, en el formulario y dejándolo suelto allí, se sube. Cogen el nombre del fichero, lo ponen como nombre de la entidad, como título de la entidad. Trupal sube el fichero a una ruta, le asigna un ID y guarda esa ruta con ese ID. Con lo cual, en base de datos, si tú al Trupal le dices, eh, quiero fichero con ID 1400, Trupal sabe que ese fichero 1400 está guardado en esta ruta, en este directorio. Y también sabe el nombre, el file name de ese fichero. Hasta cierto punto, esto va perfecto, pero se vio, con el tiempo, de que, bueno, hacía falta un poco más de flexibilidad. Porque ese tipo de entidad es un tipo de entidad muy limitada que no permite configuración alguna. Vale. Y claro, había gente que decía, vale, pues que yo quiero tener, por ejemplo, en el blog, la imagen de cabecera, muchas veces pongo la misma. O, por ejemplo, en los productos, el campo fichero PDF de garantía de uso, o características técnicas, quizá uso el mismo PDF en varios productos al mismo tiempo. No quiero tener que subir el mismo PDF o la misma imagen 25 veces para todos los productos. Quiero subirlo una vez, y el siguiente producto, que haya un botón de añadir una existente. Ah, vale, esta, ya está. Que no me haga falta subir el mismo fichero tantas veces. Y que si en un futuro tengo que modificar el fichero, no tenga que modificar ese fichero todas las veces que lo he subido. Si lo he subido en 50 productos, no quiero modificar el mismo fichero 50 veces. Aquí viene lo que es una entidad media. Una entidad media es una entidad que está a medio camino entre la relación que viene del nodo y lo que va hasta la entidad tipo fichero. Y la entidad media permite añadir otros campos, por ejemplo, otro fichero secundario, o un campo de texto o nombre, o un checkbox que, dependiendo del checkbox, se va a mostrar visualmente distinta la URL del fichero o lo que sea, dependiendo del proyecto. Pero permite añadir campos. Por ejemplo, en algún proyecto he añadido campos booleanos, campos de fecha, que hace que caduca el fichero que no se muestre en la web, o, a finales, depende de la flexibilidad del proyecto. Pero quédate con que las entidades media permiten ser reutilizadas en varias páginas, o en varias entidades, mejor dicho, y que permiten añadir campos, lo que da una flexibilidad mucho mayor que las entidades tipo fichero, que son las que vienen por defecto, que son las más básicas. Eso no significa que no debas usar nunca las tipo fichero. O sea, básicamente, las entidades media, por debajo, en el campo fichero, usan la entidad tipo fichero. Y en proyectos más simples, o en proyectos complejos, pero en zonas muy concretas, tiene más sentido usar el campo de tipo fichero, no el campo tipo media. Pues, por ejemplo, porque quiera asegurarte que suben una imagen y que no reúsen una existente. O que cuando se dice una imagen, dice un PDF, o un Word. O sea, quieres que el usuario suba uno nuevo hecho por él. O sea, por ejemplo, si tienes un campo que tiene que subir una foto de, yo qué sé, de un certificado, que es de un extraño que han hecho ellos, no tiene sentido, depende del caso, pero no tendría sentido, que puedan acceder a otros certificados de otra gente y añadirlo como si fuera suyo. No tendría ningún tipo de sentido. Quieres que sea un campo tipo fichero y que no tengan acceso a reutilizar ningún fichero antiguo. Creo que con este ejemplo se puede más o menos entender la diferencia entre uno y el otro. Vale, estas básicamente son las entidades que vienen por defecto en Drupal. Los notos, taxonomías, o subadios, medias y files, o ficheros. Que es lo mismo en inglés. Y después, ¿cuáles son los recomendados que no están en el code, pero que en muchos casos se pueden usar? Y para qué se usan cada uno de ellos. Digamos que yo destaco dos. El primero, si quieres un e-commerce, pues vas a poner el módulo de Drupal, que es el Drupal Commerce, que te viene con la entidad tipo producto y la entidad tipo variación de producto. Vale. Bueno, no creo que haga falta explicar mucho, pues un producto es un producto y la variación es una variación del mismo producto. Por ejemplo, las tallas. Cada una de las tallas con un precio distinto será una variación del mismo producto. Que tenga una relación entre ellos. Si no quieres tener un e-commerce, pues no te hace falta nada de esto. Si quieres tener un e-commerce o quieres tener un escapate de productos, recomiendo encarecidamente que uses el módulo Commerce. No los nodos como tal, haciendo apaños y cosas con código para hacer un e-commerce sin el módulo Commerce. He visto cosas muy raras hechas en Drupal. Otro módulo que te añade un tipo de entidad muy recomendable es el módulo Paragraph. El módulo Paragraph, digamos que son párrafos, la traducción sería, aunque es rara la traducción, si cuando sabes lo que hace exactamente el módulo, digamos que permite incustar bloques de contenido en medio de una página y reordenarlos entre ellos. Por ejemplo, lo más típico es usarlo para hacer landings. Una página landing, que es tener una imagen de cabecera, un texto, al lado del texto una imagen, de 
abajo una imagen panorámica, después dos columnas de texto, una tabla y una incustación de no sé qué, con Paragraph bien configurado puedes montar landings muy flexibles. Y la idea de esto es que al editor no le haga falta saber nada de código, que solo arrastrando, o más que arrastrando es añadiendo con el botón, añadir nueva sección texto, añadir nueva sección imagen, añadir nueva sección imagen con texto, pues que el editor de texto, o sea el editor de la web pueda crear páginas sin que le haga falta saber nada de HTML, ni CSS, ni nada de código. Y realmente es un modo que también recomiendo. Y también se puede usar para otras cosas, como por ejemplo, cuando tenemos un producto, se puede añadir un tipo Paragraph, un campo tipo Paragraph, para añadir por ejemplo características técnicas del producto. Y tener allí pues un título y un texto descriptivo y una imagen. Y cada Paragraph tendrás dos o tres campos y puedes añadir tantas características técnicas como tú quieras en el producto. En final se usa mucho para temas de campos múltiples con datos dentro de cada uno de los campos. Para estructurar mejor los datos. Y ya está, básicamente recomiendo mucho que te mires el tema de los Paragraph, tanto si es usuario, o sea alguien tiene una web, como si es desarrollador, que sepas a menos que es un Paragraph y cómo usarlo. Y también esto de nodos, taxonomías, la diferencia entre ellos, que hay gente que no sabe la diferencia aún, cuando es mejor usar un nodo o cuando es mejor usar una página de taxonomía. Saber que los usuarios son entidades y que pueden tener campos y puedes añadirles campos a los usuarios es muy importante. Que he visto cosas muy raras también, para añadir información relevante del usuario, hacerlo mediante un nodo que se le asigna al nodo líder del usuario, cosa que es una... Es muy recombolesco esto para hacer una cosa que es mucho más simple. Y poca cosa más, básicamente, creo que queda claro que Drupal es súper flexible, tanta flexibilidad a veces quizás hace las cosas un poco más complejas o más difíciles de entender, pero que una vez que te adaptas y más o menos tienes los conocimientos básicos, ves que se da cuenta trabajar con Drupal, más que con otras tecnologías. Aquí me vende gente decir que se pueden hacer cosas sin CMS mucho más personalizables. Pues sí, Drupal está medio camino entre lo que es un web más básico y lo que puede ser, por ejemplo, una web hecha con Symfony a pelo. Pero está medio camino, te da muchas cosas hechas y te facilita la vida para, digamos, proyectos que no son hiper complejos, pero que sí tienen una complejidad alta comparada con webs más simples. Al final es una herramienta más que tienes que saber en qué momento se puede usar y en qué momento no sale tan a cuenta usarla. Y nada más, el siguiente episodio no tengo claro de qué voy a hablarlo, así que va a ser sorpresa. Si te ha gustado la temática esta, pues dame cinco estrellitas en Apple Podcast o en Spotify, que ahora en Spotify se puede poner puntuación, y también por LinkedIn o por Twitter, me comentas si te hace falta algo más, o una duda o lo que tú quieras. Encantado de estar aquí. Chao.