Symptôme. Sur un thème bloc en cours de construction, la palette de couleurs personnalisée déclarée dans theme.json s’affiche correctement dans le sélecteur de couleurs de l’éditeur pour la plupart des blocs. Mais un bloc particulier, ici un bloc personnalisé développé en interne pour afficher un encart promotionnel, refuse obstinément d’appliquer la couleur de fond choisie : le sélecteur reste grisé, inactif, comme si le bloc ne savait tout simplement pas gérer les couleurs.
Le client, qui avait pourtant validé la palette générale du site en réunion, s’est légitimement inquiété de voir un encart rester d’une couleur neutre par défaut malgré ses choix répétés dans l’inspecteur.
Diagnostic : un support de bloc non déclaré
Dans le modèle d’API des blocs de WordPress, chaque fonctionnalité visuelle proposée dans l’inspecteur — couleur de fond, couleur de texte, typographie, espacement — doit être explicitement déclarée par le bloc lui-même via la clé supports de son fichier block.json. Sans cette déclaration, l’interface ne propose tout simplement pas le réglage correspondant, quelle que soit la richesse de la palette définie par ailleurs dans theme.json.
En inspectant le fichier block.json du bloc promotionnel maison, la cause est apparue immédiatement : la clé supports ne contenait aucune entrée color, alors que le développeur d’origine pensait, à tort, que la palette globale du thème s’appliquerait automatiquement à tout bloc, sans configuration supplémentaire de sa part.
Correctif : déclarer le support attendu
{
"apiVersion": 2,
"name": "agence/encart-promo",
"title": "Encart promotionnel",
"supports": {
"color": {
"background": true,
"text": true
},
"spacing": {
"padding": true
}
}
}
Après ajout de cette section supports et un rechargement complet de l’éditeur, le sélecteur de couleur de fond est immédiatement devenu actif, proposant la palette exacte définie dans theme.json. Le bloc a également hérité automatiquement des classes CSS utilitaires générées par WordPress, comme has-primary-background-color, sans code CSS supplémentaire à écrire côté thème.
Prévention : une checklist avant de livrer un bloc personnalisé
- Vérifier systématiquement la présence d’une clé
supportscohérente avec les besoins réels du bloc, dès sa création, plutôt qu’après une remontée client. - Tester chaque nouveau bloc avec au moins deux couleurs différentes de la palette pour confirmer visuellement l’application correcte des classes générées.
- Inspecter le HTML final produit dans le navigateur pour confirmer la présence des classes
has-*-background-colorattendues, un réflexe rapide qui évite bien des suppositions erronées.
Cette vérification prend moins de cinq minutes par bloc et devrait, selon moi, faire partie intégrante de toute checklist de recette technique avant livraison d’un thème bloc personnalisé à un client.
Un cas voisin à ne pas confondre
Un support de couleur mal configuré ne doit pas être confondu avec une palette elle-même mal déclarée dans theme.json, sous la clé settings.color.palette. Dans ce second cas, c’est l’ensemble des blocs du site qui serait affecté, pas un bloc isolé comme dans l’exemple traité ici. Distinguer ces deux causes évite de perdre du temps à corriger le mauvais fichier.
Un bloc qui « ignore » une palette n’ignore jamais rien : il n’a simplement pas été informé qu’il devait s’y intéresser. La nuance change tout dans la manière de chercher la cause.
En résumé
Ce genre de symptôme, déroutant au premier abord, se résume presque toujours à une déclaration manquante dans block.json. Prendre le réflexe de vérifier ce fichier avant toute hypothèse plus complexe évite de perdre un temps précieux à chercher du côté de theme.json ou d’un éventuel bug du cœur de WordPress, qui n’est presque jamais en cause dans ce type de situation.
Depuis cet incident, la déclaration des supports de bloc fait partie d’un modèle de fichier block.json que nous réutilisons systématiquement pour tout nouveau bloc personnalisé, avec les entrées les plus courantes déjà présentes en commentaire, à activer ou supprimer selon le besoin réel du composant en cours de développement.
