Cuando se trata de personalización, puedes hacer mucho daño
mirando qué plantillas se están renderizando y utilizando el sistema de temas para anularlas.
Pero hay algunos casos en los que necesitarás ser aún más específico.
Por ejemplo, supongamos que queremos modificar la plantilla "elemento "
para ver cómo se muestra la cuadrícula de habilidades en la página de inicio.
Si compruebas aquí la barra de herramientas de depuración web y te desplazas hacia abajo...
Buscaré "contentful"...
ah, ya está.
Puedes ver grid.html.twig...
que muestra item/contentful_entry.html.twig.
Para personalizar el elemento, podríamos anular esa plantilla.
Muy fácil.
El problema es que, en Contentful, tenemos varios tipos de contenido:
tenemos Habilidades y Anuncios.
Así que si modificamos esta plantilla, la modificaremos
tanto para Habilidades como para Anuncios...
y probablemente queramos que tengan un aspecto diferente.
Entonces, ¿cómo podemos resolver esto?
Antes hemos ejecutado debug:config netgen_layouts view y hemos hablado de las dos secciones principales que hay
aquí debajo: block_view (que controla cómo se muestran los bloques) y item_view.
Como ya he dicho varias veces, algunos bloques, como Grid y List, muestran elementos individuales.
En esta configuración de item_view es donde definimos esas plantillas.
Y verás algunas claves raíz familiares: default para el frontend,
ajax para las llamadas AJAX y app para el admin.
Una vez más, esto utiliza la configuración match y...
¡eh! ¡Vemos nuestra entrada aquí!
¿Recuerdas recipes_default?
Lo configuramos dentro de nuestro archivo de configuración,
y es una de las dos plantillas de elementos reales que tenemos ahora:
Hay una para recetas, y luego Contentful tiene una para todos los elementos de Contentful.
Así que, de nuevo, podríamos anular esta plantilla a través del sistema de temas y listo.
Pero nuestro objetivo es anular esta plantilla sólo cuando el artículo sea una habilidad, como éste.
¿Y cómo lo hacemos?
Añadiendo nuestro propio item_view a esta lista que coincide con ese único tipo de contenido.
Hagámoslo
Por aquí... estamos
en item_view, default para el frontend
y tenemos la única entrada de antes: recipes_default.
Añadamos otra.
Llámala contentful_entry/skill, aunque esta clave en concreto no supone ninguna diferencia.
Debajo, pon template
a @nglayouts/item/contentful_entry, seguido de skill.html.twig:
Antes, utilizábamos nglayouts sin el @...
sólo porque te dije que nglayouts/ era un buen directorio para organizar cosas.
Internamente, Layouts utiliza @nglayouts en las rutas de sus plantillas.
¿Cuál es la diferencia?
Al añadir el @, nos estamos enganchando al sistema de temas.
Así, como tenemos un directorio templates/nglayouts/
con themes/standard/ dentro, utilizará nuestra plantilla.
Puedes utilizar @nglayouts o simplemente nglayouts.
Sólo quería que entendieras la diferencia
porque verás la sintaxis @nglayouts por todas partes.
La clave realmente importante aquí es match.
Queremos que coincida sólo cuando estemos trabajando con un contentful_entry.
Vale, copia match del config...
y pégalo.
Pero tenemos que ser más específicos.
También necesitamos coincidir sólo cuando el tipo de contenido sea una habilidad.
Pero, ¿cómo lo hacemos?
¿Qué comparadores hay disponibles?
Hay una lista básica...
pero ¿ha añadido Contentful algún comparador adicional que podamos aprovechar?
He aquí un pequeño truco para ver la verdadera lista de elementos de match.
Es un poco técnico, pero funciona de maravilla.
Ejecuta: php ./bin/console debug:container
--tag=netgen_layouts.view_matcher ¿Qué hace esto?
Bueno, cualquiera puede crear un comparador personalizado, como foo\bar.
Para ello, creas una clase y le das esta etiqueta.
Buscando todos los servicios con esa etiqueta,
podemos encontrar todos los matchers existentes en el sistema.
Y... ¡mira qué lista!
Aquí hay uno interesante: contentful\content_type.
Seguro que podemos utilizarlo.
Inténtalo: contentful\content_type ajustado a skill:
Bien, vamos a crear la plantilla.
Dentro de themes/standard/, en lugar de block/, esta vez, crea un directorio llamado item/...
luego contentful_entry/, y luego skill.html.twig.
De momento pon un texto ficticio:
Vale, si esto funciona, cuando actualicemos, estos elementos -que son habilidades de Contentful-
deberían volver a renderizarse utilizando nuestra nueva plantilla.
Pero cuando lo intentamos...
no cambia absolutamente nada.
¿Qué ha ocurrido?
Vuelve a tu terminal y ejecuta de nuevo php
./bin/console debug:config netgen_layouts view.item_view .
Todo parece correcto...
excepto por el orden.
Éste de Contentful está al principio de la lista...
y los nuevos están al final.
¿Y adivina qué?
Cuando Layouts intenta averiguar qué plantilla debe mostrar, lee la lista de arriba a abajo
y encuentra la primera que coincide: exactamente como funciona el sistema de enrutamiento de Symfony.
Así, primero mira contentful_entry, ve que la value_type es contentful_entry...
y lo utiliza.
Nunca llega al contentful_entry/skill de la parte inferior.
Para solucionarlo, vamos a utilizar un elegante truco de configuración de prefijo.
Hagámoslo a continuación.