« Register a block template that can be inserted into an existing block template area. » Cette phrase, tirée de la documentation officielle des fonctions WordPress, décrit sobrement register_block_template(), introduite dans WordPress 6.7 en novembre 2024. Elle permet à une extension de déclarer, entièrement en PHP, un modèle de bloc qui vient s’ajouter à la hiérarchie de templates d’un thème hybride, sans que ce dernier ait besoin de fournir lui-même le fichier correspondant.
Ce billet ne traite pas des thèmes entièrement construits en blocs, où la question ne se pose pas de la même façon puisque chaque modèle y est déjà défini explicitement. Il se concentre sur le cas d’un thème hybride, mêlant fichiers PHP classiques et zones de blocs, recevant un modèle enregistré par une extension tierce.
Ce que fait exactement register_block_template()
La fonction prend en premier argument un identifiant sous la forme plugin-uri//nom-du-modele, et en second un tableau d’arguments incluant un titre, une description, et le contenu du modèle exprimé en balisage de blocs. Une fonction complémentaire, unregister_block_template(), permet de retirer un modèle précédemment enregistré, utile lorsqu’une extension doit désactiver temporairement un modèle sans désinstallation complète.
register_block_template( 'mon-extension//archive-produit', array(
'title' => 'Archive produit personnalisée',
'description' => 'Modèle pour l\'archive du CPT produit',
'content' => '<!-- wp:query {"queryId":1,"query":{"postType":"produit"}} -->
<!-- wp:post-template -->
<!-- wp:post-title /-->
<!-- /wp:post-template -->
<!-- /wp:query -->',
) );
Ce modèle vient s’ajouter à la WP_Block_Templates_Registry, disponible pour être appliqué à l’archive du type de contenu concerné, exactement comme s’il avait été fourni par un fichier du thème.
Le piège : un H1 absent quand le modèle oublie le bon bloc
Un modèle de bloc enregistré par une extension, dans l’exemple ci-dessus, affiche bien le titre de chaque produit via le bloc post-title à l’intérieur de la boucle de requête. Mais rien, dans ce modèle, ne fournit de titre de page au niveau H1 pour la page d’archive elle-même. Un thème classique aurait inclus, dans son fichier archive.php, un appel à une fonction affichant ce titre de page. Un modèle de bloc déclaré par extension, s’il ne prévoit pas explicitement un bloc de titre d’archive, ne produit tout simplement aucun H1 sur la page.
Le résultat visuel reste correct : la page affiche ses produits, sa mise en forme paraît complète. Mais un audit du code source révèle l’absence totale de balise <h1>, un défaut qui affaiblit la structure sémantique de la page aux yeux d’un moteur de recherche, sans qu’aucune erreur ne soit visible pour un visiteur ou même pour l’administrateur du site tant qu’il ne vérifie pas le code source généré.
Pourquoi ce piège passe inaperçu
Ce défaut se glisse facilement parce que le modèle fonctionne visuellement dès son activation. L’équipe qui installe l’extension teste l’affichage, constate que les produits apparaissent correctement classés, et ne pousse pas la vérification jusqu’au code source pour confirmer la présence d’un titre de niveau un. Le problème se révèle en général bien plus tard, lors d’un audit de structure HTML plus large, souvent motivé par une stagnation du positionnement de la page d’archive concernée.
Comment vérifier après chaque activation d’extension
- Afficher le code source de la page d’archive concernée et rechercher la présence d’exactement une balise
<h1>. - Si aucun H1 n’est présent, vérifier si l’extension propose une option d’ajout du titre d’archive, ou envisager un ajout via un bloc de titre inséré manuellement dans le modèle depuis l’éditeur de site.
- Documenter ce contrôle dans la procédure de recette suivie à chaque activation ou mise à jour d’une extension modifiant la structure des modèles.
Corriger le modèle sans désactiver l’extension
Une fois le modèle enregistré par l’extension, l’éditeur de site permet généralement de le modifier depuis l’interface, en y insérant un bloc de titre d’archive natif avant le bloc de requête. Cette modification, effectuée une fois via l’éditeur, persiste indépendamment des futures mises à jour de l’extension tant que celle-ci ne réenregistre pas le modèle avec le même identifiant en écrasant la version personnalisée.
En résumé
register_block_template() donne aux extensions un moyen puissant d’enrichir un thème hybride sans toucher à ses fichiers, mais cette souplesse déplace la responsabilité de la structure sémantique complète, H1 inclus, vers celui qui écrit le modèle. Vérifier systématiquement la présence d’un titre de niveau un après l’activation de toute extension qui déclare ses propres modèles de bloc évite une régression silencieuse, invisible tant que personne n’ouvre le code source de la page.
