Depuis la sortie de WordPress 6.9 en décembre 2025, une extension qui lit ou modifie la structure d’un gabarit doit revérifier certains points qui, jusque-là, étaient restés stables pendant plusieurs cycles de publication. Le format d’échange des templates a évolué à la marge, sans rupture brutale, mais avec assez de changements pour justifier une passe de vérification avant de recommander la mise à jour à des clients.
Cet article ne couvre pas la nouvelle Abilities API introduite dans la même version — un sujet à part entière — mais uniquement ce qui concerne directement la structure et la manipulation des gabarits du Site Editor.
Ce qui change, classé par impact
Impact élevé : les champs additionnels de l’objet template
Les objets renvoyés par les points de terminaison REST liés aux gabarits (wp/v2/templates et wp/v2/template-parts) exposent désormais des champs de métadonnées supplémentaires pensés pour l’interopérabilité avec des outils tiers, notamment autour de la description sémantique du contenu d’un gabarit. Une extension qui itère sur les clés d’un objet template retourné par rest_do_request() sans filtrer explicitement les clés attendues peut se retrouver à traiter des champs inconnus qu’elle stockait auparavant tels quels — un comportement à revérifier plutôt qu’à supposer stable.
Impact moyen : la résolution des parties de gabarit imbriquées
La fonction get_block_template() conserve sa signature, mais l’ordre de résolution en cas de parties de gabarit imbriquées à plusieurs niveaux (une partie qui insère elle-même une autre partie) a été précisé côté cœur pour éviter certains cas de boucle. Une extension qui reconstruit manuellement cette résolution — plutôt que de s’appuyer sur les fonctions du cœur — doit vérifier que son algorithme reste cohérent avec ce nouvel ordre.
Impact faible : les hooks d’enregistrement de gabarit
Les actions déclenchées à l’enregistrement d’un gabarit (autour de save_post_wp_template) restent inchangées dans leur déclenchement, mais transportent un objet WP_Post dont certaines métadonnées internes ont un contenu légèrement différent. Le risque est faible pour la plupart des extensions, sauf celles qui comparent ce contenu à une valeur mise en cache depuis une version antérieure.
Comment vérifier sa propre extension
La méthode la plus fiable reste empirique plutôt que théorique : comparer le résultat d’un appel réel avant et après mise à jour, sur une copie du site.
- Exporter la structure des gabarits actuels avec
wp template list --format=jsonavant toute mise à jour. - Mettre à jour un environnement de test vers WordPress 6.9.
- Relancer la même commande et comparer les deux exports, champ par champ.
- Rejouer les scénarios de l’extension qui touchent directement à la lecture ou à l’écriture de gabarits.
Le cas des extensions qui parsent le contenu brut
Les extensions les plus exposées restent celles qui analysent directement le contenu HTML d’un gabarit avec leurs propres expressions régulières, plutôt que de passer par le parseur de blocs du cœur (parse_blocks()). Ce type d’approche, déjà fragile avant WordPress 6.9, le devient un peu plus à chaque évolution du schéma, puisqu’aucune garantie de stabilité n’a jamais couvert le format brut du contenu d’un gabarit en dehors du parseur officiel.
- Toute extraction de contenu de gabarit devrait passer par
parse_blocks()plutôt que par une analyse de chaîne maison. - Les identifiants de bloc dans les attributs ne doivent jamais être supposés stables d’une version à l’autre.
- Un test de non-régression automatisé sur les gabarits critiques du site limite le risque à chaque montée de version du cœur.
La règle qu’on applique en interne avant chaque montée de version majeure : si une extension touche à la structure d’un gabarit, elle passe d’abord sur un environnement de test avant tout site de production, sans exception liée à l’ancienneté de l’extension.
En résumé
WordPress 6.9 ne bouleverse pas la structure des gabarits, mais l’affine suffisamment pour justifier une vérification ciblée des extensions qui en dépendent directement. Le réflexe le plus rentable reste le même depuis plusieurs versions : s’appuyer sur les fonctions du cœur pour lire et écrire des gabarits, plutôt que sur une lecture directe du contenu brut, qui reste le point le plus fragile face à chaque évolution du schéma.
