Un client nous a un jour demandé pourquoi la couleur qu’il changeait dans les réglages d’un bloc « Groupe » modifiait aussi trois autres endroits de la page. La réponse tenait en un mot : mutualisation. Depuis WordPress 5.9, un module discret appelé Style Engine centralise la génération du CSS issu de theme.json et des attributs de bloc. Il ne se contente pas de recopier vos réglages : il les transforme, les déduplique et les range dans des classes réutilisables.
Comprendre ce mécanisme n’est pas un exercice académique. Le jour où une couleur personnalisée n’apparaît pas à l’écran, où deux blocs identiques génèrent des classes différentes, ou où une feuille de style s’alourdit sans raison apparente, c’est le Style Engine qu’il faut interroger, pas theme.json lui-même.
Un point d’entrée unique pour le CSS des blocs
Avant WordPress 5.9, chaque bloc du cœur gérait à sa manière la conversion de ses attributs (couleur, marge, bordure) en styles CSS, avec des variations subtiles d’un bloc à l’autre. Le Style Engine a remplacé cette mosaïque par une API unique : la classe WP_Style_Engine et sa fonction publique wp_style_engine_get_styles(). Elle reçoit un tableau de propriétés de style (au format proche de theme.json) et retourne à la fois du CSS inline et des noms de classes.
Concrètement, quand vous définissez une couleur de fond dans l’éditeur pour un bloc « Paragraphe », WordPress ne génère pas un style inline arbitraire : il appelle le Style Engine, qui produit une classe du type has-vivid-red-background-color quand la couleur provient de la palette de theme.json, ou un style inline seulement quand la couleur est une valeur libre choisie au sélecteur de couleur.
Classes mutualisées contre styles inline dupliqués
C’est là que réside le vrai gain. Sans mutualisation, cent blocs partageant la même couleur de fond généreraient cent règles style="background-color: #cf2e2e" identiques. Le Style Engine détecte que la valeur correspond à une entrée de la palette déclarée dans theme.json et préfère une classe partagée, injectée une seule fois dans la feuille de style globale.
- Les valeurs qui correspondent à une entrée nommée de
theme.json(couleur, dégradé, taille de police) deviennent des classes. - Les valeurs libres, saisies à la main dans l’éditeur, restent en styles inline sur le bloc concerné.
- Le Style Engine peut aussi générer des règles pour des sélecteurs spécifiques via l’argument
selector, utile pour les auteurs de blocs personnalisés.
L’utiliser dans un bloc personnalisé
Le Style Engine n’est pas réservé aux blocs du cœur. Un développeur qui construit un bloc dynamique en PHP peut l’appeler directement pour bénéficier de la même cohérence :
$styles = wp_style_engine_get_styles(
array(
'color' => array(
'background' => '#1e1e1e',
),
'spacing' => array(
'padding' => array( 'top' => '2rem' ),
),
)
);
echo '<div style="' . esc_attr( $styles['css'] ) . '" class="' . esc_attr( $styles['classnames'] ) . '">';La fonction retourne un tableau avec deux clés utiles : css, la chaîne de styles inline à injecter, et classnames, les classes à ajouter au balisage. On évite ainsi de réinventer une logique de conversion couleur-vers-CSS déjà mûre et testée par le cœur.
Où chercher quand quelque chose ne colle pas
Trois pièges reviennent régulièrement dans nos audits. D’abord, une couleur définie dans theme.json mais absente du rendu : vérifiez que le slug de la couleur correspond exactement à celui utilisé côté classe CSS générée, sensible à la casse et aux tirets. Ensuite, un style qui « disparaît » après une mise à jour de thème : le Style Engine régénère parfois ses classes lors du rebuild du cache d’assets, et un cache de page en amont peut servir une version obsolète.
Enfin, une feuille de style globale qui grossit anormalement : cela signale souvent des valeurs de couleur libres saisies par les rédacteurs plutôt que puisées dans la palette du thème, chacune générant son propre style inline au lieu d’une classe mutualisée.
Sur nos projets, la première question face à un style de bloc « fantôme » n’est plus « le CSS est-il bien chargé ? » mais « le slug de la couleur correspond-il à celui de theme.json ? ». Neuf fois sur dix, c’est là que ça coince.
En résumé
Le Style Engine est la couche invisible qui rend theme.json réellement efficace en production : elle transforme des réglages déclaratifs en CSS optimisé, sans duplication inutile. Le connaître ne change rien à la façon dont vous configurez un thème, mais change radicalement votre façon de diagnostiquer un problème de rendu. La prochaine fois qu’une couleur se comporte bizarrement, pensez classes mutualisées avant de réécrire votre theme.json.
