# theme.json et supports de couleur : quand un bloc ignore la palette

> Symptôme classique en début de projet FSE : un bloc qui n'affiche jamais les couleurs déclarées dans theme.json. Diagnostic des drapeaux de support manquants.

- Auteur : Clément Hadrot
- Publié le : 2022-04-19
- Mis à jour le : 2022-04-19
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/theme-json-supports-couleur-bloc-ignore-palette/

## L’essentiel

- Le bloc doit déclarer explicitement supporter la couleur
- Un drapeau manquant suffit à casser l'affichage
- Vérification via block.json et la console du navigateur

**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
        }
    }
}
```

> L'essentiel à retenir : Le bloc doit déclarer explicitement supporter la couleur ; Un drapeau manquant suffit à casser l'affichage ; Vérification via block.json et la console du navigateur

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é `supports` cohé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-color` attendues, 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.