La hiérarchie des modèles permet à WordPress de savoir quel fichier charger en fonction de l’URL demandée. Pages, articles, archives… c’est le template hierarchy qui fait l’aiguillage depuis toujours, sauf que désormais avec le FSE, on remplace le PHP par du HTML !
Sommaire du cours
Nous allons maintenant attaquer la quatrième étape du Full Site Editing, et c’est ici que notre site va enfin commencer à prendre vie !
Après avoir configuré le theme.json, déclaré nos variations de styles de blocs, et créé nos compositions, on va désormais passer à la conception des principaux modèles de pages qui composent notre site.
À l’issue de ce chapitre, on aura un site digne de ce nom, quasiment prêt à l’emploi !
Pour en arriver là, on va passer pas mal de temps dans l’éditeur de site, dans la rubrique Éditeur > Modèles :
En effet, c’est ici qu’on va pouvoir concevoir le design de chacun des modèles de page qui composent notre site, de manière visuelle, avant bien sûr d’exporter le code HTML généré vers les fichiers de notre thème.
Mais avant de nous lancer dans la création de ces modèles, on va devoir parler du Template Hierarchy de WordPress, car même à l’heure du FSE, il est toujours d’actualité, avec quelques petites subtilités toutefois !
Le Template Hierarchy de WordPress
Ah, le fameux template hierarchy de WordPress, ce schéma qui donne des cauchemars la première fois qu’on le voit.
Si vous aviez suivi ma formation sur le développement de thèmes classiques, vous avez dû voir que j’avais dédié un cours au sujet du comportement de WordPress face aux modèles de pages.
La documentation officielle de WordPress met quant à elle à disposition ce schéma :
Pour l’expliquer simplement : en fonction de l’URL demandée par le visiteur, WordPress va être en mesure de savoir quel modèle de page afficher.
On commence la lecture du schéma par la gauche avec les différents cas de figure qui existent. Si on souhait afficher :
- La page d’accueil ? WordPress tentera de charger
front-page.php
; - Une page standard du site ? Ce sera
page.php
tout simplement ; - Le blog ? C’est
home.php
qui sera chargé ; - Une page du blog, qui liste les derniers articles ? Cette fois c’est
archive.php
; - Un article en particulier ? Ce sera enfin
single.php
.
Au final, la base du fonctionnement n’est pas très compliquée, mais ce sont les cas de figure intermédiaires, en orange et vert sur le schéma, qui peuvent complexifier sa compréhension.
Par exemple, si vous avez déclaré un Custom Post Type « Portfolio », WordPress tentera d’abord de charger archive-portfolio.php
, et si ce modèle n’existe pas, il se rabattra simplement sur archive.php
.
Ainsi, vous pouvez créer des apparences de pages différentes en fonction des cas de figure.
WordPress commence toujours par chercher les cas les plus spécifiques (à gauche du schéma) et continuera vers la droite vers des modèles plus généralistes.
Différence fondamentale pour le Full Site Editing
Le Full Site Editing, même s’il révolutionne WordPress, ne change pas tous les fonctionnements historiques pour autant. Du coup, le template hierarchy reste d’actualité même en FSE !
Il va toutefois y avoir une différence de taille avec le fonctionnement traditionnel : cette fois, on ne va pas utiliser des modèles de pages en PHP, mais en HTML.
De plus, on va devoir les placer dans le dossier templates
de notre thème, et non plus à la racine comme avant.
Voici, pour comparaison, l’architecture des fichiers dans mon thème classique, à gauche, ainsi que la nouvelle architecture avec le dossier templates
et les fichiers HTML, à droite :
Il est essentiel de respecter cette nouvelle structure afin que votre thème FSE fonctionne correctement. Elle est imposée par WordPress.
Les principaux modèles de pages
Afin de mieux s’y retrouver, on va continuer avec un schéma simplifié, car après tout, il est très rare d’avoir besoin des cas les plus spécifiques sur un site standard.
J’en ai profité pour changer les extensions de fichiers pour HTML, comme ça on est à jour.
Le voici :
Pour le moment, je vais simplement vous expliquer l’utilité de chacune de ces pages, car il existe des petites subtilités importantes. Ensuite, on décidera lesquelles on ajoutera à notre thème.
Pour imager mes explications, je vais prendre pour exemple le site de SEOPress dont le design est sexy et il illustre bien cette hiérarchie.
La page d’accueil
On commence avec la page d’accueil qui met en avant les avantages du produit et qui utilise le modèle de page front-page.html
.
Comme on va le voir juste après, on n’a plus besoin de créer un modèle de page dédié à la page d’accueil, puisqu’on va designer les pages à l’aide de l’éditeur de blocs. Du coup, on utilisera notre modèles de page standard.
Les pages de contenu
Concernant les pages classiques de contenu, c’est page.html
qui sera utilisé. Dans notre exemple, le modèle affiche simplement l’en-tête, le pied de page, le titre principal de la page et une zone centrale étroite pour afficher le contenu :
Ce sera justement l’un de nos prochains objectifs, juste après avoir réalisé l’en-tête et le pied de page du site.
Ce modèle de page est pratique pour les pages juridiques comme les mentions légales, mais ce n’est pas terrible pour créer les autres pages de notre site, les plus importantes.
Heureusement, on va pouvoir créer un modèle sur mesure et le déclarer dans notre theme.json
. L’objectif est de créer un modèle de page pleine largeur et sans titre principal, avec seulement l’en-tête, le pied de page et le contenu entre les deux.
On va en reparler très bientôt, dans un cours justement dédié aux modèles de pages personnalisés.
Les pages du blog
Le blog possède plusieurs modèles rien que pour lui :
Les archives
Les archives sont toutes les pages permettant de lister des publications, via archive.html
, que ce soit pour :
- Lister les articles chronologiquement (10 publications par page par défaut) ;
- Lister les publications d’une catégorie en particulier ;
- D’une étiquette ou toute autre taxonomie ;
- Ou encore les publications d’un auteur ;
Chacun de ces cas possède en réalité son propre modèle spécifique.
Par exemple, pour l’auteur, on a accès à author.html
si besoin. Cela permettrait d’avoir un design légèrement différent des archives avec une section en plus pour présenter l’auteur.
Mais au final c’est plutôt rare, c’est pour cela qu’on utilise surtout archive.html
.
Dans ce modèle, on utilisera le bloc « Boucle de requête » qui invoquera la WP Query pour afficher dynamiquement (et automatiquement) les dernières publications.
L’accueil du blog
Le blog possède également sa propre page d’accueil. Ce sera le rôle de home.html
.
En général, la première page d’un blog est plus étoffée que les archives et affiche à la fois les derniers articles, un article mis en avant et des appels à l’action…
Lorsqu’on clique sur le bouton « page suivante » pour naviguer entre les pages, ce sera cette fois le modèle archive.html
qui sera utilisé.
Si vous ne souhaitez pas avoir un modèle différent entre l’accueil et les archives, il suffira de créer un template part pour mettre en commun le HTML des deux modèles.
Les publications
Enfin, lorsqu’on clique sur le titre d’une publication pour la consulter, c’est cette fois single.html
qui prend le relai. On arrive alors sur une page dédiée à cet article.
La page de recherche
La page de recherche search.html
s’affiche lorsque le visiteur recherche une expression via le bloc « moteur de recherche » que vous pourrez placer dans votre en-tête par exemple.
Là aussi, on fera appel au bloc « Boucle de requête » pour afficher les résultats, WordPress sachant quoi afficher grâce à l’URL demandée.
La page 404
Enfin, la page 404.html
permet d’afficher un message d’erreur si un visiteur tente d’accéder à une URL non valide.
Avec le FSE, on peut éditer visuellement cette page ! Avant, ce n’était pas possible car elle n’avait pas d’existence propre dans l’interface d’administration de WordPress.
La page index
La page index.html
sert de solution de secours si WordPress n’a trouvé aucun autre modèle lorsqu’il a parcouru le schéma. C’est pour cela que c’est le seul modèle obligatoire dans votre thème.
Il peut toutefois être utilisé si votre site est extrêmement simple et ne nécessite qu’un seul modèle de page, comme un site one page par exemple.
Le template hierarchy optimisé pour le FSE
Maintenant que l’on sait à quoi sert chaque modèle, je vais profiter de mon expérience pour vous proposer une approche un peu plus critique de ce template hierarchy.
Car avec le FSE, certains cheminements et modèles vont désormais se montrer superflus. C’est une belle opportunité pour nous pour nous de simplifier tout cela.
Voici le nouveau schéma « optimal » :
Déjà, j’ai simplifié la partie « Archive » car en général, notre blog reste plutôt simple. Le modèle archive.html
suffira amplement pour la grande majorité de nos projets.
Retirer les modèles superflus
Ensuite, comme vous pouvez l’observer, j’ai éliminé 2 modèles, qui sont barrés et transparents sur le schéma car, au vu du fonctionnement du FSE, ils ne nous seront plus utiles.
Les modèles de page sur mesure ne sont plus nécessaires
Avec l’ancien fonctionnement, on pouvait créer des modèles de pages personnalisés, et on en créait pour chaque page principale de notre site.
En plus de page.php
, on pouvait ajouter des fichiers page-<nom>.php
et déclarer des informations dans les commentaires PHP.
Aujourd’hui le principe existe toujours mais différemment : on peut nommer notre fichier comme on le souhaite, tant qu’il est dans le dossier templates
, et on le déclarera dans theme.json
. On verra d’ailleurs comment déclarer un modèle sur-mesure très bientôt.
Mais comme on l’a vu, on n’aura besoin que de 2 modèles : le modèle classique pour les pages juridiques et de documentation, et un modèle pleine largeur pour toutes les pages principales.
Auparavant, on intégrait le design de chaque page dans un modèle dédié, mais ce n’est plus le cas aujourd’hui : C’est directement dans l’éditeur qu’on designera nos contenus.
Le modèle de page d’accueil n’est plus nécessaire non plus
Du coup, sur la même lignée, la page d’accueil n’aura pas besoin de son propre modèle. Il suffira d’utiliser le modèle page pleine largeur, et le tour sera joué !
Créer les modèles de pages dans notre thème
Avant de terminer ce cours, il ne nous reste plus qu’à créer nos modèles de pages dans notre thème. On va donc se contenter de créer uniquement ces fichiers :
index.html
, mais normalement vous l’aviez déjà créé au début de la formation ;archive.html
ethome.html
pour le blog ;single.html
pour les articles ;page.html
etpage-full-width.html
pour les pages standard du site ;404.html
pour la page d’erreur ;search.html
éventuellement, si vous prévoyez d’utiliser le moteur de recherche.
On verra plus tard dans ce chapitre comment déclarer des modèles spécifiques pour nos Custom Post Types.
Laissez les fichiers vides pour le moment car on s’en occupera dans les prochains cours, et placez-les bien dans le dossier templates
.
Le dossier de votre thème devrait maintenant ressembler à quelque chose comme ça :
C’est tout bon ! On est prêt pour la suite. Dans les prochains, cours, on va créer les modèles depuis l’éditeur FSE, puis exporter leur HTML vers ces fichiers.
Grâce à nos nouveaux modèles et à la compréhension du template hierarchy, nous allons enfin pouvoir enfin concevoir tous nos modèles de pages, ainsi que l’en-tête et le pied de page de notre site. Ce sera notre principal objectif dans ce chapitre.
Dans le prochain cours, on va commencer par créer l’en-tête et le pied de page du site.
Puis on enchainera sur la création de notre premier modèle de page via l’éditeur, pour ensuite exporter ensuite le HTML dans notre thème.
0
Questions, réponses et commentaires