Un client opérant à la fois une boutique en ligne et un blog éditorial sur le même site nous a demandé quelque chose d’assez classique mais pas totalement trivial avec un thème bloc : un en-tête différent pour la partie boutique, plus orienté vers la mise en avant du panier, et un en-tête plus sobre pour le blog. Avec un thème classique, on aurait dupliqué header.php en header-shop.php et conditionné son appel. Avec l’éditeur de site, la logique passe par les zones de template parts.
Voici comment cette fonctionnalité a été mise en place, et les limites rencontrées au passage.
Déclarer une zone dans theme.json
Les template parts peuvent être classés par zone fonctionnelle grâce à l’entrée templateParts de theme.json. Chaque zone correspond généralement à un rôle reconnu par l’éditeur, comme header ou footer :
{
"templateParts": [
{
"name": "header",
"title": "En-tête standard",
"area": "header"
},
{
"name": "header-boutique",
"title": "En-tête boutique",
"area": "header"
}
]
}Proposer plusieurs variantes échangeables
Une fois les deux template parts déclarés dans la même zone, l’éditeur de site propose, lors de la sélection d’un template part dans un gabarit, un choix entre les différentes variantes disponibles pour cette zone. Sur le template archive-produit.html, on peut ainsi assigner header-boutique, tandis que le template single.html du blog conserve le template part header standard.
Ce que cela change pour l’équipe éditoriale
L’avantage principal, au-delà du confort de développement, tient à la visibilité offerte à l’équipe éditoriale : depuis l’éditeur, il devient possible de voir quel en-tête est utilisé sur quel gabarit, et même de le remplacer ponctuellement sans intervention technique, ce qui aurait nécessité une demande de développement avec un thème classique.
Les limites rencontrées
- Les zones reconnues nativement par l’éditeur restent limitées à
header,footeretuncategorized. - Un grand nombre de variantes dans une même zone peut rendre l’interface de sélection confuse pour un utilisateur non technique.
- Le nommage cohérent des template parts devient essentiel dès qu’on dépasse deux ou trois variantes par zone.
Une convention de nommage utile
Sur ce projet, on a adopté une convention simple : le nom du template part commence toujours par sa zone, suivi d’un suffixe décrivant son usage (header, header-boutique, footer, footer-minimal). Cela facilite grandement la maintenance, en particulier lorsque le nombre de variantes augmente avec le temps.
Sur les sites à sections multiples, on documente systématiquement, dans un fichier à part du dépôt Git, la correspondance entre chaque gabarit et le template part de zone qu’il utilise : cela évite bien des allers-retours de support.
Automatiser l’assignation par type de contenu
Pour éviter qu’un rédacteur oublie de sélectionner le bon en-tête sur un nouveau gabarit de page produit, on a pris l’habitude de préassigner directement le bon template part depuis le code du template lui-même, plutôt que de compter sur une sélection manuelle systématique :
<!-- wp:template-part {"slug":"header-boutique","tagName":"header"} /-->Cette précaution simple évite qu’un template fraîchement dupliqué hérite, par erreur, du template part générique plutôt que de la variante attendue pour sa zone d’usage.
En résumé
Les zones de template parts répondent élégamment à un besoin qui, avec un thème classique, se traduisait presque toujours par de la duplication de fichiers PHP et des conditions imbriquées. Le mécanisme reste jeune et mériterait sans doute davantage de zones reconnues nativement, mais il ouvre déjà la voie à une gestion plus fine des variations d’un site multi-sections.
