Découvrez nos offres pour faire du digital le levier de votre croissance !
.png)
.png)
Le Blog Digital
Modèles
Téléchargez le Guide Ultime de gestion de projet digitale pour vous aider à piloter vos transformations et faire les bons choix !
En règle générale, nous le considérons comme le pipeline de rendu Drupal, mais en réalité, c’est simplement intégré au pipeline de rendu Symfony.
Dans cet article, je vous donne des explications et des exemples pour mieux comprendre ce qu’est le pipeline de rendu et comment il fonctionne avec le cache de Drupal.
Processus de haut niveau
À un niveau élevé, le système comprend les étapes suivantes :
- Le contrôleur reçoit une requête http sous forme d’objet Request et retourne un tableau de rendu,
- Lorsque le contrôleur a renvoyé un tableau de rendu, l’évènement View est déclenché par le HttpKernel,
- La class MainContentViewSubscriber (abonné à l’évènement View), vérifie si le résultat du contrôleur est bien un tableau de rendu. Si c’est bien le cas, il garantira de générer un objet Response,
- Par la suite, la class MainContentViewSubscriber vérifie si le format de requête négocié est en charge (HTML, JSON, etc.). Tout format pour lequel un service de rendu de contenu principal existe (toute class implémentant MainContentRendererInterface) est pris en charge,
- Ensuite 2 possibilités :
- Si le format de requête négocié n’est pas pris en charge, une réponse JSON 406 (Not acceptable response) est générée.
- Sinon, lorsque le format de demande négocié est pris en charge, le service de rendu de contenu principal correspondant est initialisé. Une réponse est générée en appelant la fonction MainContentRendererInterface ::renderResponse().
Drupal, dans ses versions 8 et 9 et certainement dans sa version 10 qui sortira le 14 décembre 2022, est livré avec les rendus de contenu principaux suivants et prend donc en charge le rendu de tout tableau de rendu dans l’un des formats/types MIME suivants :
- HTML : HtmlRenderer – text/html ;
- AJAX : AjaxRenderer – application/vnd.drupal-ajax ;
- Boîte de dialogue : DialogRenderer – application/vnd.drupal-dialog ;
- Modale : ModalRenderer – application/vnd.drupal-modal.
Le moteur de rendu du contenu principal HTML
Ce qui précède est le flux de haut niveau. Intéressons-nous au moteur de rendu du contenu principal HTML (HtmlRenderer), qui sera le plus souvent utilisé. Cela se passe dans deux fonctions de la class.
HtmlRenderer ::prepare()
Il reçoit le tableau de rendu du contenu principal et s’assure que le tableau soit un tableau de rendu de type page (‘#type’ =>’page’), ce qui correspond au contenu de la balise <body>.
Si le tableau de rendu du contenu principal est un type page, il n’y aura pas d’action sur le tableau de rendu. Dans le cas contraire un tableau de rendu de type page englobant le contenu principal sera construit.
Ensuite, un évènement SELECT_PAGE_DISPLAY_VARIANT sera déclenché. Ce qui permet à Drupal de générer des variants d’une même page. Par défaut, le plugin SimplePageVariant est utilisé, lequel n’appliquant aucune modification particulière à notre tableau de rendu.
Mais par exemple, lorsque le module Block est activé, c’est le plugin BlockPageVariant qui est utilisé à la place. Les sites builders pourront alors placer des blocs pour afficher le contenu dans l’une des régions de la page. Ce qui aura pour effet de « décorer » le contenu principal avec du html propre aux blocs/régions.
Lorsque le tableau de rendu est prêt, HtmlRenderer ::prepare() invoque les hooks hook_page_attachments() et hook_page_attachments_alter() pour permettre à d’autres modules d’altérer le tableau.
HtmlRenderer ::renderResponse()
Le HtmlRenderer ::renderResponse() reprend le tableau renvoyé par HtmlRenderer ::prepare() et l’enveloppe dans un tableau de rendu de type html (‘#type’ => ‘html’), ce qui correspond à la balise <html>. Puis il invoque les hooks « hook_page_top() » et « hook_page_bottom() ». Enfin, le tableau de rendu est converti en html ( RendererInteface ::render() ) puis renvoyé en tant qu’objet Response.
Les TWIGS dans Drupal
En lisant le processus de rendu, vous vous demandez peut-être d’où vient le HTML généré (balises <html>, <body>, etc.) ?
Dans la majorité des cas, le rendu de chaque élément d’une page provient d’un template Twig. Alors Twig est un moteur de template pour PHP qu’on écrit dans un langage compilé qui lui est propre.
Le fichier page.html.twig (étape 1 <body>), en simplifiant un peu le code, ressemble à ceci :
Le HTML présent dans le squelette du template (pour info, le même template pourra être utilisé pour d’autres pages) et est une variable Twig contenant un ou plusieurs tableaux de rendu, qui eux-mêmes, en fonction de leur type, auront leur propre template.
Le fichier html.html.twig (étape 2 <html>), toujours en simplifiant un peu, ressemble à ceci :
Nous avons toujours un squelette HTML et la variable qui est en fait le fichier page.html.twig de notre l’étape 1. Vous l’avez compris, cela fonctionne par imbrication.
Une chose importante à savoir, Drupal utilise beaucoup les caches, notamment pour le rendu des pages. Les tableaux de rendu sont associés à une durée de validité et à un contexte de cache.
Ce qu’il faut retenir, c’est que Drupal ne reconstruira pas le HTML à chaque fois qu’on appellera une page. Au premier appel, lorsque le rendu est terminé, il est mis en cache pour être afficher plus rapidement lors des prochaines visites.
Notez bien également qu’il y existe des mécanismes qui pourront invalider le cache pour forcer la reconstruction d’une page. Cela sera opportun, essentiellement lorsque le contenu de la page change depuis le dernier affiche.
Pour finir, voici un schéma qui illustre le rendu HTML :
Vous avez aimé cet article, je vous conseille de lire également notre article sur la nouvelle fonctionnalité de Drupal 9.3 : les Bundle classes.
Crédit photo : Andrey Suslov
25 mars 2024
4 minutes
