if ( wp_is_block_theme() ) { … } — cette condition, disponible depuis WordPress 6.1 sorti en novembre dernier, a réglé un problème récurrent pour une extension maison distribuée à une dizaine de clients aux thèmes très différents les uns des autres : certains encore sur des thèmes classiques bien installés, d’autres déjà passés à un thème de blocs complet.
Cette extension ajoutait un bandeau d’information légale en pied de page, injecté jusqu’ici via le hook wp_footer, méthode fiable sur un thème classique mais redondante sur un thème de blocs où le pied de page est déjà entièrement piloté par un template part dédié. Sur deux sites clients passés récemment à un thème de blocs, le bandeau apparaissait en double, une fois via le hook PHP historique, une fois via un bloc ajouté manuellement dans le template part de pied de page.
Ce que fait exactement cette fonction
La fonction wp_is_block_theme() renvoie un simple booléen, en interrogeant les capacités déclarées par le thème actif. Elle ne regarde ni la présence d’un fichier theme.json isolé, ni un réglage manuel, mais bien la déclaration effective du thème comme thème de blocs.
- Elle retourne vrai uniquement pour un thème de blocs complet, pas pour un thème classique enrichi d’un
theme.jsonpartiel. - Elle s’utilise côté PHP, pendant le chargement normal du thème, sans dépendance à un hook particulier au-delà de
after_setup_theme. - Elle ne renseigne rien sur la présence de blocs spécifiques : elle indique seulement la nature globale du thème actif.
La correction appliquée à l’extension
add_action( 'after_setup_theme', function () {
if ( wp_is_block_theme() ) {
// Le pied de page du thème de blocs gère déjà sa propre zone :
// on laisse un simple filtre disponible pour l'injection manuelle.
add_filter( 'mon_extension_mention_legale', 'mon_extension_rendu_mention', 10, 1 );
} else {
// Sur un thème classique, on garde l'injection automatique historique.
add_action( 'wp_footer', 'mon_extension_affichage_wp_footer' );
}
} );
Sur les thèmes de blocs, l’extension expose désormais un filtre que le client peut appeler explicitement depuis un bloc HTML personnalisé dans son propre template part de pied de page, plutôt que d’imposer une injection automatique potentiellement redondante avec ce que le thème affiche déjà.
Pourquoi une condition JavaScript n’aurait pas suffi
Une détection côté client, par exemple en observant la présence de certaines classes CSS générées par l’éditeur de site, aurait été fragile et dépendante de l’implémentation précise de chaque thème. La détection côté serveur via wp_is_block_theme() s’appuie directement sur la déclaration officielle du thème, bien plus fiable et stable dans le temps.
Les cas restés à surveiller
- Un thème hybride, ni totalement classique ni totalement thème de blocs, peut encore renvoyer un résultat surprenant selon la façon dont il déclare son support.
- Un changement de thème en cours de vie du site nécessite de revérifier le comportement de l’extension, la fonction étant évaluée à chaque chargement.
Le résultat sur le parc de clients
Sur les dix sites concernés par cette extension, la mise à jour a supprimé les doublons observés sur les deux clients passés à un thème de blocs, sans rien changer au comportement des huit autres restés sur un thème classique. Aucun ticket de support n’a été rouvert depuis ce correctif.
Une extension distribuée à plusieurs clients doit s’adapter au terrain qu’elle rencontre, pas imposer un seul mode de fonctionnement à des thèmes qui n’ont plus grand-chose en commun.
En résumé
La fonction wp_is_block_theme(), introduite avec WordPress 6.1, offre un moyen simple et fiable de faire bifurquer le comportement d’une extension selon la nature réelle du thème actif. Pour une extension distribuée largement, cette bifurcation évite des doublons d’affichage et laisse au client la main sur l’intégration côté thème de blocs, plutôt que de lui imposer une injection automatique héritée d’un monde purement classique.
