Twig Suggestions en Drupal

 Bienvenido o bienvenida aquí otra semana más a Drupalizate. Hoy quiero hablar, gracias a la idea de una persona que me contactó por LinkedIn, poner mayor foco en el tema de sobre escribir twigs, sobre todo los que vienen de los módulos contribuidos, qué son las suggestions en Drupal, y cómo usar un poco el twig debug, aunque eso ya lo comenté muy por encima en episodios pasados y no hace mucho, a raíz de ese episodio me contactó y dijo que quería saber un poco más en concreto temas de los módulos y las sugestiones y estas cosas. Así que, pues mi chapo, así que vamos con el tema. Intentaré que este episodio sea tirando al nivel básico, básico un poco medio, pero tirando a básico, ¿vale? O sea que intentaré bajar un poco a tierra todos los conceptos. No expliqué muy detalladamente, expliqué conceptos un poco más genéricos y que si tienes dudas las puedes buscar por Google, que siempre tienes código de ejemplo buscando en Google, como siempre. Dicho todo esto, ¿qué es tweak? Es el sistema de plantillas que tiene Drupal 8, 9 y 10. A partir de Drupal 8 se implementó el sistema de plantillas tweak. Hasta Drupal 7 era todo PHP, o sea, podías meter PHP en las plantillas y en Drupal 8 y 9 ya no puedes. Cosa que es una bendición, porque habían cosas horrendas ahí metidas. Habían proyectos que la gente la alejaba mucho. Dicho esto, con tweak es muy simple de usar. Hacer un if, un bucles ahí en medio, o modificar el 7ml, o añadir clases o tal, es muy simple, mucho más fácil que lo que hay en Drupal 7 en su momento. O sea, es mucho más legible el código en tweak. Pero tienes algunos problemillas, como puede ser de que te has instalado un módulo contribuido por alguien y ese módulo ya tiene su propia plantilla y tú la quieres sobreescribir porque tú quieres modificar cosas para que tu tema, tu frontend, sea un poco distinto a lo que viene por defecto en Drupal o para ese módulo en concreto. ¿Cómo puedes sobreescribir una plantilla existente? Digamos que los pesos en Drupal básicamente es, tiene prioridad el tema visual y después tiene prioridad el módulo. Así que es bastante simple. Si tú tienes una plantilla con el mismo nombre exacto, o sea, el mismo fichero con el mismo nombre exacto lo tienes en tu tema, el tema tiene preferencia y va a cargar esa plantilla. Si no tienes esa plantilla con el mismo nombre, va a cargar la del módulo. Así que la forma simple de sobreescribir algo es ir al módulo, normalmente tiene un director que es templates dentro del módulo, copias el fichero con el mismo nombre y lo duplicas dentro de tu tema, también nuevamente en el director de templates. Y con eso ya está, modificas ese fichero y ya tienes tu plantilla sobreescribiendo a la original. Si fuera el caso de que esa plantilla es imposible, imaginemos que queramos modificar plantillas de todos los nodos, pues vamos a la plantilla del módulo node que está en el core, duplicamos esa plantilla en nuestro tema y editamos ahí, y va a modificar a todos los nodos. Pero si queremos que solo altere esa plantilla nuestra custom los nodos de un tipo de contenido específico, solo que son los suggestions. En Drupal, el nombre de plantilla identifica cuándo se ha de aplicar. Por ejemplo, una cosa es tener node.tweak, o sea,.html.tweak, porque la extensión es.html.tweak. Podemos tener uno que sea node y podemos tener uno que sea node-el-tipocontenido.html.tweak. Al final, la sugestión nos especificará que, en un caso, la plantilla node es para todos y la plantilla node-el-tipocontenido solo va a afectar a ese tipo de contenido. O si queremos que eso afecte a un tipo de contenido y a un view mode en concreto, pues lo mismo, con dos guiones, el tipo de contenido y el view mode, estamos usando el suggestion especificando que esta plantilla solo va a afectar a un caso muy concreto. Y lo mismo va para los campos, para los formularios, para el HTML genético de toda la página. Puedes sobreescribir básicamente casi cualquier cosa de Drupal con las plantillas. Pequeño problema, los suggestions no vienen muchos por defecto. O sea, vienen, digamos, el 70% quizá de lo que te hacen falta, pero siempre te hace falta alguno más que a veces no tienes. Los suggestions vienen por defecto y puedes crear tú los tuyos propios. Si buscas en Drupal, en Google, Suggestion Hooks o Hooks de Suggestion en Drupal, te van a salir ejemplos de cómo crearlos y modificarlos. Lo digo de memoria, creo que era hook-tm-suggestion o-suggestion-alter o algo así. Y con eso básicamente puedes especificar para qué tipos de entidades, o sea, por ejemplo, para que tengas una Suggestion Customs de los bloques, o una Suggestion Customs de los campos o de los formularios o de lo que tú quieras básicamente. ¿Cómo puedes saber el nombre de la Suggestion? En vez de estar haciendo pruebas, poniendo guiones y nombres. Puedes activar el debug de Twig. En Drupal tenemos dentro de la carpeta, si tenemos un Drupal por defecto, se llama dentro de web barra sites, ahí hay un fichero que es el devel o development.services, es un fichero de services básicamente. Ahí se especifica, lo que viene por defecto es no hay debug de Twig, bueno, al final si tú buscas en Google cómo activar el debug de Twig en Drupal 8 o Drupal 9, te va a salir, es modificar ese fichero, poner una línea de que queremos activar Twig, y pocos más, y si aprovechas para desactivar las cachés y estas cosas de Twig también. El tema es que con esto activado, en el HTML de tu web, vas a ver muchos comentarios HTML que te va a decir de este bloque empieza aquí y acaba aquí, y en donde empieza el bloque te van a salir recomendaciones de nombres de fichero que son más específicos que los que tienes tú ahora. Y también te va a especificar la ruta del fichero actual. Poniendo el caso de ejemplo de que queremos modificar la plantilla del nodo, te va a decir de que se usa la plantilla node.html.twig, que es la plantilla que viene por defecto en Drupal, y que está en el módulo node barra templates, lo que sea. Esto va muy bien también, porque cuando, y es una web que no has hecho tú, sino que la ha hecho alguien más, puedes ver las plantillas donde están, si está cogiendo la de un tema, o la de un módulo custom, o qué coño está pintando ahí en medio. Así que recomiendo mucho, sobre todo en local, tener el Twig de Book, solo en local. No tenerlo esto ni en pre-producción ni en producción. El de Book de Twig consume mucha CPU y RAM, va a ser que la web vaya bastante más lenta. Sobre todo si después, aparte del de Book, tienes el tema de las cachés inactivas de Twig. Pero esto, en local facilita mucho la vida el tema de desarrollar con esto. Así que tenemos el de Book de Twig, nos dice las sugestiones actuales disponibles. Hay algún fallo que por ejemplo con las views no las dice todas, o apenas dice alguna, pero para nodes, bloques, o sea, a final entidades, te las dice casi todas. Y para los campos igual, así que es muy recomendable tenerlo. Para las views, a final, puedes buscarlo por Google un poco, yo que sé, views un formate, guion-guion, el nombre de la views, o cosas así. Al final, como digo, cualquier cosa en Drupal puedes tener tu sugestión, con lo cual puedes tener tu plantilla específica solo para eso. Por poner un ejemplo, yo lo he usado bastante con views, para tener que una views con un formato específico, y que el nombre de la views sea este nombre en concreto, esta views tenga una plantilla en concreto modificada. Porque tenemos X motivos de que tenemos una o dos views que tienen ese nombre, y queremos que tengan plantillas independientes al resto de views, que son las que harán por defecto en la web. Y poco más, básicamente, como veis es muy simple, es básicamente duplicar ficheros y ya está. Recomendaciones para trabajar mejor con Twig. Aunque esto no es la pregunta que me hizo la persona por LinkedIn, pero lo añado en este episodio. Puedes añadir librerías de CSS y JavaScript directamente en Twig. En Drupal, digamos que en tu tema, en el punto info, tienes que especificar qué librerías estás cargando del fichero.libraries. En el fichero.libraries puedes tener una librería todo junto de CSS y JavaScript, y que eso se cargue en todas las páginas de toda tu web. Pero puede tener sentido de, por ejemplo, si tenemos una plantilla de un parágraf, de un tipo de parágraf en concreto, y en ese tipo de parágraf tenemos un slider, y queremos cargar una librería de slider, no tiene sentido que esa librería la estemos cargando en toda la web entera, porque habrán páginas que no tienen slider, por ejemplo. Con lo cual puede tener sentido que en la plantilla de ese parágraf, que es el parágraf de slider, allí se especifique que se debe usar esta librería de nuestro tema custom, pero que solo lo cargue en las páginas donde se va a mostrar esa plantilla Twig. Esto en Twig es muy simple de hacer. Si buscas en Google cómo añadir librerías en los Twig en Drupal, te va a salir. Básicamente es un attach barra baja library, y ahí especificas si es el nombre del módulo barra nombre de librería, o en este caso si es un tema, el nombre del tema custom barra el nombre de la librería que has especificado en el fichero libraries.yaml en tu tema. Esto lo favor mucho. La verdad es que para proyectos donde hay mucho código de JavaScript, o digamos muy compartimentado, por ejemplo para reutilizar parágraf de un proyecto a otro, puede ser muy útil. Al final tienes el CSS y el JavaScript compartimentado y no lo tienes todo mezclado para todo el proyecto. Así que lo encuentro en una buena práctica para trabajar así. Y al fin de cuentas Drupal después va a comprimir y a unificar los ficheros que hagan falta, y tú te despreocupas de eso totalmente. Y después también está el tema de que en las plantillas cuando es un diseño así modular o un diseño de patrones, puedes tener una plantilla, por ejemplo, yo lo he usado bastante también, para poner un ejemplo muy tonto, el formulario de login, el formulario de registro y el formulario de reiniciar contraseña. Básicamente es el mismo formulario pero que en un caso salen dos campos de uso de contraseña, el otro sale un formulario de registro con cuatro campos, y después sale el formulario de reseteo de contraseña donde solo sale el mail. Provisualmente eran idénticos, solo tenías que el formulario tenía más o menos campos. Y tenían un diseño distinto al resto de las páginas de administración. Pues en vez de tener tres plantillas, una para el login, una para el registro y otra para el reinicio de contraseña, quedas una única plantilla con el código HTML que te toca, y después las otras dos plantillas básicamente hacen un extend de Twig, o sea, en Twig puedes incluir o extender otras plantillas Twig, que básicamente incluyes, dices a la plantilla Twig de login está usando la plantilla Twig que tiene el registro. Y ya está, y una vez modificas esa plantilla de registro, se verán los cambios en todas las plantillas que la estén extendiendo. Lo mismo que comentaba antes con las views, podemos tener dos views, que son las de setjabby, por ejemplo, y queremos que visualmente se vean distintas. El código, digamos, visual HTML está en una plantilla, y la otra extienda esta primera. Con lo cual no tenemos código duplicado, tenemos una única plantilla donde está todo el código importante, y las otras solo lo van extendiendo para usar ese código, y ya está. En temas de que puedas extender en Twig, y en concreto en Drupal, se usa mucho lo que son los bloques de Twig. Esto permite, por ejemplo, que en la plantilla de las páginas, por ejemplo, o de las regiones, podemos tener que cada región tenga su bloque interno. No confundir los bloques de Twig con los bloques de Drupal, son dos cosas distintas. El bloque de Twig es un bloque de código que cuando es extendido desde otra plantilla, te permite solo modificar lo dentro de ese código, o sea, lo dentro de ese bloque. Por ejemplo, tenemos la página, digamos, genérica, donde están todas las regiones de Drupal. Tenemos que salir el header, el contenido principal, el sidebar y el footer. Podemos extender esa plantilla, y después solo sobreescribir la parte del bloque, yo que sé, del sidebar, para que sea algo distinto por X motivo. Pues que el tipo de contenido, yo que sé, block, no tiene que tener sidebar, o sí que tiene que tener sidebar. O sea, el cambio es que un tipo de contenido en concreto se ve distinto. Lo que nos permite esto es tener el código bastante compartimentado y evitar tener código duplicado. Y eso al final, yo lo encuentro muy buena práctica. Por eso te recomiendo aprender a añadir librerías directamente en plantillas Twig, sin que haga falta tocar PHP, ¿vale? O sea, es solo añadir el CSS y el JavaScript en librerías, y después en el Twig, decirle que use esa librería cuando se cargue ese Twig, que como te digo es literalmente una línea, o sea, es muy simple de usar. Y después está el tema de extender plantillas existentes y modificar solo las partes de los bloques de esas plantillas, para evitar tener mucho código redundante. Y ya está, y más que nada tener en cuenta que los temas es lo que manda, y si no, mandarán lo de los módulos. Y ya está, poca cosa más. Perdón, me dejaba un par de cosas, no, más que cosas, recomendaciones. ¿Qué módulos puedes recomendar que te ayudan en el tema de trabajar con Twig? Primero habría lo que es el twig-twig, twig-twig, voy a dejar el link porque es difícil de pronunciar. Pero bueno, también si lo buscas en Google lo acabas contando. Básicamente te da funcionalidades como por ejemplo, rendeizar bloques directamente en Twig. En vez de usar PHP, digamos que usan una función de, pues aquí queremos esta entidad, y puedes poner un nodo, puedes poner un bloque, puedes poner un formulario, o una views, por ejemplo, puedes básicamente incrustar cualquier cosa en Twig, así que es muy útil. O por ejemplo, rendeizar enlaces con temas de idioma. Para web multidiomas es muy útil tener que, te generen duplas en la misma URL y no picarla a fuego a mano. O por temas de las alias de la URL, es como total, es un módulo que recomiendo mucho, es muy estable, y yo lo he usado muchísimo, el twig-twig. Después hay otro que ese ya no es tan estable, que es el twig-suggest. Esto para los que no os queráis liar a crear vuestras propias sugestiones, este módulo te da ya muchas hechas, ¿vale? Desde campos, formularios, de bloques, te da muchas hechas que por defecto en tu pal no vienen. El problema es que está en beta, no es estable este módulo. Yo lo he usado solo en una web, que es la mía personal para trastear con ello, no, perdón, en un proyecto, en un set de twig lo he usado en dos webs. Funciona bien, pero está en beta, no es estable, así que en producción lo recomiendo cogido con pinzas. Lo que sí que os recomiendo es que podéis descargarlo y ver cómo has hecho las sugestiones de este módulo, ¿vale? os puede servir como ejemplo. Sobre todo también para ver qué sugestiones no están en el Drupal Core, y quizás con este módulo veis, ah, pues está ya bien aquí, quizá me haría falta. Para que tengáis ideas de qué sugestiones os pueden hacer falta. Y después hay un par de módulos más, que en verdad es uno, que es el UI Patterns y el UI Patterns Settings. Lo uso en algún módulo, en algún proyecto, perdón, y básicamente te permite hacer, es para diseño con patrones, o diseño modular, ¿vale? o por componentes. Lo que decía antes, reutilizar plantillas y esas plantillas las puedes usar en varios sitios de la web y, digamos, tener el código más ordenado. Es una forma de trabajar, depende de qué proyecto tengas, creo que puede ser más engorroso que otra cosa, pero para proyectos muy grandes es muy útil, porque al final lo tienes todo muy ordenado y evitas tener un caos de plantillas por ahí población. Y también con el UI Patterns Settings te permite que el usuario, desde Frontend, pueda especificar qué plantilla quiere en un bloque, que este bloque use esta plantilla, o que este ViewMode use esta plantilla. Te permite que la configuración afecte a qué plantillas se cargan y cuáles no, lo cual también es interesante. Y ya está, nada más, ninguna recomendación más. Si te pones con Twig, verás que para temas de Frontend es muy simple, es HTML y el CSS y JavaScript es lo de siempre con Drupal, así que ningún problema. La verdad es que hacer Frontend en Drupal, a menos para mí, yo encuentro, muy fácil de hacer servir. Y aún más comparado con lo que era antes en Drupal 7, que hacía falta que el de Frontend supiese PHP. Hoy en día esto ya no es así. Y nada, no sé qué episodio voy a poner la semana que viene, así que atento a lo que ponga en LinkedIn.