Précision utile avant toute chose : à la date de ce billet, la fonction évoquée ici n’appartient pas encore au cœur de WordPress. Elle vit dans le plugin Gutenberg, sous une forme encore mouvante, et son nom pourrait changer avant un éventuel passage dans le cœur. Ce qui suit décrit donc le mécanisme tel qu’il existe aujourd’hui dans le plugin, pas une fonction figée du cœur.
Ce billet s’adresse à qui construit un outil d’audit et doit répondre à une question précise : pour un site donné, quels gabarits ont été modifiés par l’utilisateur, et lesquels sont restés strictement ceux fournis par le thème ? Il ne traite pas de l’export de ces gabarits vers des fichiers, seulement de leur lecture.
Deux sources possibles pour un même gabarit
Dans le modèle expérimental du plugin Gutenberg, un gabarit peut exister sous deux formes distinctes. La première est un fichier PHP ou HTML fourni par le thème, dans un dossier dédié. La seconde est une entrée du post type wp_template, créée quand quelqu’un modifie ce gabarit depuis l’éditeur de site expérimental. La seconde prime sur la première dès qu’elle existe, ce qui signifie qu’un même identifiant de gabarit peut, selon les sites, provenir d’un fichier ou d’une ligne en base de données.
Pour un outil d’audit, cette distinction est cruciale : elle permet de répondre à la question « ce gabarit a-t-il été personnalisé, ou est-ce toujours celui du thème ? » sans avoir à comparer manuellement des fichiers.
Interroger la liste complète
Le plugin Gutenberg fournit un mécanisme interne pour lister l’ensemble des gabarits disponibles, qu’ils viennent d’un fichier ou de la base de données. Un outil d’audit peut s’appuyer dessus plutôt que de parcourir le système de fichiers à la main :
function audit_lister_gabarits_personnalises() {
if ( ! function_exists( 'gutenberg_get_block_templates' ) ) {
return array();
}
$gabarits = gutenberg_get_block_templates();
$personnalises = array();
foreach ( $gabarits as $gabarit ) {
if ( 'custom' === $gabarit->source ) {
$personnalises[] = $gabarit->slug;
}
}
return $personnalises;
}
Le champ source est ici la clé de voûte de l’audit : une valeur theme signifie que le gabarit vient d’un fichier fourni par le thème et n’a jamais été modifié en base ; une valeur custom signifie qu’une entrée wp_template existe et prend le dessus.
Pourquoi la vérification par nom de fonction est indispensable
Comme le mécanisme reste propre au plugin, tout code d’audit doit vérifier l’existence de la fonction avant de l’appeler, sous peine de faire planter le site sur les installations qui n’ont pas activé le plugin Gutenberg ou qui tournent une version où cette fonction porte encore un autre nom. Cette prudence n’est pas un détail de style : elle conditionne la robustesse de l’outil sur un parc de sites hétérogène.
- Vérifier
function_exists()avant tout appel. - Ne jamais supposer que le nom de la fonction restera identique d’une version du plugin à l’autre.
- Prévoir un message clair dans l’outil d’audit quand le mécanisme n’est pas disponible, plutôt qu’une erreur fatale silencieuse.
Ce que révèle la comparaison des sources
Sur un site en cours de construction, il n’est pas rare de découvrir que la moitié des gabarits attendus n’ont en réalité jamais été touchés depuis leur création par le thème. Cette information, anodine en apparence, aide à prioriser une revue de contenu : inutile de faire relire un gabarit qui n’a jamais changé, mieux vaut concentrer l’attention sur ceux qui portent des modifications.
Un audit qui se contente de regarder l’écran de l’éditeur de site passe à côté de l’essentiel : la source réelle d’un gabarit ne se voit pas à l’œil nu, elle se lit dans les données.
Anticiper l’arrivée dans le cœur
Il est raisonnable de s’attendre à ce qu’un mécanisme équivalent rejoigne un jour le cœur de WordPress, probablement sous un nom plus sobre, une fois la fonctionnalité jugée suffisamment stable. En attendant, mieux vaut construire son outil d’audit autour d’une fine couche d’abstraction : une seule fonction interne qui encapsule l’appel réel, pour ne modifier qu’un point du code le jour où le nom changera.
En résumé
Lister les gabarits par le code permet de distinguer objectivement ce qui a été personnalisé de ce qui reste fourni par le thème, sans dépendre d’une inspection visuelle. Le mécanisme, encore expérimental et propre au plugin Gutenberg à ce jour, mérite d’être encapsulé proprement dans tout outil d’audit, en prévision de son évolution future.
