« Comment reproduire ce bandeau et ce pied de page sans tout recoder en PHP ? » C’est la question posée par une petite imprimerie qui avait fait développer, des années plus tôt, une brochure institutionnelle sous Joomla. Le site n’avait plus été mis à jour depuis longtemps, l’hébergeur menaçait de couper le support PHP ancien, et la migration vers WordPress s’imposait sans discussion possible.
Ce qui rendait le projet intéressant, c’est le moment où il est arrivé : fin 2020, alors que la version de développement de l’extension Gutenberg commence tout juste à proposer, de façon très expérimentale, des fichiers de gabarits et de parties de gabarit écrits en HTML pur plutôt qu’en PHP. Rien n’est stabilisé, mais l’idée de sortir l’en-tête et le pied de page du thème dans des fichiers indépendants, lisibles par un éditeur de blocs, est déjà utilisable sur un thème classique rendu partiellement compatible.
Ce que contenait la brochure Joomla
La structure d’origine reposait sur un module Joomla pour l’en-tête (logo, menu horizontal, numéro de téléphone) et un autre pour le pied de page (coordonnées, mentions légales, réseaux sociaux). Ces deux blocs étaient injectés via le moteur de templates de Joomla, avec une syntaxe propre à ce CMS, totalement étrangère à WordPress.
- En-tête : logo, trois liens de menu, un numéro de téléphone cliquable.
- Pied de page : adresse postale, lien vers les mentions légales, trois icônes de réseaux sociaux.
- Aucune sidebar, aucun widget complexe à migrer.
Écrire les template parts à la main
Sur un thème classique existant, deux fichiers ont été ajoutés dans un dossier parts : header.html et footer.html. Ce ne sont pas des fichiers PHP, mais du balisage de blocs enregistrés directement en commentaires HTML, le même format que celui que l’éditeur de blocs génère lui-même.
<!-- wp:group {"tagName":"header"} -->
<header class="wp-block-group">
<!-- wp:site-logo /-->
<!-- wp:navigation /-->
</header>
<!-- /wp:group -->
Ces deux fichiers ont ensuite été appelés depuis header.php et footer.php grâce à la fonction expérimentale gutenberg_render_block_template_part() proposée à ce stade par le plugin, en attendant qu’une API stable soit un jour intégrée au cœur de WordPress. Ce point est important à garder en tête : rien de tout cela n’est destiné à durer sans adaptation, et le code devra être révisé quand la fonctionnalité passera en version stable.
Pourquoi ce choix plutôt qu’un thème sur mesure classique
Un thème PHP classique aurait très bien suffi pour reproduire ce même en-tête et ce même pied de page. Le choix d’expérimenter les template parts n’était pas motivé par un besoin fonctionnel immédiat, mais par une volonté de l’agence de commencer à se familiariser avec cette direction annoncée par le projet Gutenberg, sur un projet à faible enjeu où l’instabilité éventuelle ne posait pas de risque commercial.
Limites assumées de cette approche en 2020
- Aucun éditeur visuel de gabarits complet n’existe encore : les fichiers HTML se modifient dans un éditeur de code.
- La syntaxe des commentaires de blocs peut évoluer d’une version du plugin à l’autre.
- Le rendu dans l’éditeur de blocs standard ne reflète pas toujours fidèlement le résultat en façade.
Le résultat livré au client
La brochure imprimerie a été livrée avec un en-tête et un pied de page identiques à l’original Joomla au pixel près, mais construits dans une logique radicalement différente de tout ce que ce CMS avait pu proposer. Le client, qui ne s’intéressait qu’au rendu visuel, n’a rien perçu de ce changement d’architecture interne.
Sur un projet à faible risque, expérimenter une fonctionnalité instable est une façon peu coûteuse d’apprendre avant qu’elle ne devienne incontournable sur des projets plus exigeants.
Pour aller plus loin
Ce chantier n’a rien d’une recommandation générale : il ne convient qu’à des projets où l’agence peut absorber un futur besoin de réécriture. La documentation du projet Gutenberg, disponible sur son dépôt officiel, reste la seule source fiable pour suivre l’évolution de ces API tant qu’aucune version stable de WordPress ne les intègre. Sur un projet client à enjeu réel, il reste préférable, à ce stade, de s’en tenir à un thème classique éprouvé et d’observer l’avancée de ces travaux avant de les adopter en production.
