« Le style s’applique partout, sauf sur l’en-tête. » Ce constat, formulé ainsi, revient régulièrement chez les développeurs de thèmes hybrides qui découvrent theme.json : un style global déclaré proprement, mais sans le moindre effet visible sur une zone de gabarit précise, comme si le fragment concerné vivait dans un univers à part.
Ce billet ne traite pas de wp_kses ni du filtrage de contenu HTML — un sujet différent, souvent confondu à tort avec celui-ci. Il s’agit ici de comprendre pourquoi un style global peut sembler ignoré par une zone de gabarit précise, en l’occurrence template-parts/header.html.
Symptôme
La couleur de fond déclarée dans theme.json s’applique correctement sur l’ensemble du site, y compris dans le corps des articles et le pied de page. Seule la zone d’en-tête, chargée depuis template-parts/header.html, conserve une couleur différente, comme si le style global n’avait jamais atteint ce fragment.
{
"styles": {
"color": {
"background": "#fdf6e3"
}
}
}Le fichier ci-dessus semble pourtant correct, et l’éditeur de style global confirme visuellement que la couleur est bien enregistrée.
Diagnostic
La première piste à explorer n’est pas theme.json lui-même, mais le contenu du fragment de gabarit concerné. Un examen du fichier template-parts/header.html révèle souvent la cause réelle :
<!-- wp:group {"style":{"color":{"background":"#ffffff"}}} -->
<div class="wp-block-group" style="background-color:#ffffff">
<!-- Contenu de l'en-tête -->
</div>
<!-- /wp:group -->Le bloc groupe qui enveloppe l’en-tête porte un style de couleur de fond directement appliqué en ligne, hérité d’une manipulation antérieure dans l’éditeur. Cette déclaration locale, plus spécifique qu’une règle CSS générale issue de theme.json, l’emporte systématiquement.
Comprendre la hiérarchie en jeu
Trois niveaux de spécificité coexistent dans ce système, et il est indispensable de les distinguer avant de conclure à un bug :
- Les styles globaux issus de
theme.json, qui s’appliquent le plus largement possible. - Les styles appliqués au niveau du fragment de gabarit lui-même, dans son fichier HTML.
- Les styles en ligne appliqués directement à un bloc particulier, qui gagnent presque toujours face aux deux niveaux précédents.
Dans le cas présent, c’est bien le troisième niveau, le plus local, qui écrase silencieusement le premier.
Correctif
La solution consiste à retirer le style local devenu superflu directement dans le fragment de gabarit, en éditant le bloc groupe depuis l’éditeur de site expérimental et en réinitialisant sa couleur de fond à « Aucune », plutôt qu’à une valeur figée. Le fragment hérite alors naturellement du style global déclaré dans theme.json, sans qu’aucune modification supplémentaire ne soit nécessaire côté fichier JSON.
Avant de remettre en cause un mécanisme global, il vaut toujours mieux vérifier ce qui a été appliqué localement, bloc par bloc — c’est souvent là, et non dans la configuration générale, que se cache la vraie cause.
Prévention
Pour éviter que ce type de situation ne se reproduise, il est utile d’adopter une discipline simple : chaque fois qu’un style est appliqué directement depuis l’éditeur sur un bloc d’un fragment de gabarit, se demander s’il ne devrait pas plutôt être déclaré une bonne fois pour toutes dans theme.json, où il restera cohérent et visible pour toute l’équipe.
Un examen régulier du contenu des fragments de gabarit, à la recherche de styles en ligne oubliés, permet également de repérer ce genre d’incohérence avant qu’un client ne la signale.
En résumé
Un style global qui semble ignoré par une zone de gabarit précise cache presque toujours un style plus spécifique, appliqué localement sur un bloc du fragment concerné. Vérifier la hiérarchie de spécificité, du global vers le local, reste le réflexe le plus efficace pour résoudre ce type de situation, bien avant de suspecter un défaut du mécanisme lui-même.
