Depuis l’arrivée du panneau Styles dans l’éditeur de site, modifier l’apparence globale d’un site WordPress ne demande plus systématiquement de rouvrir style.css. Couleurs, typographies, espacements, bordures : tout devient réglable visuellement, avec un système de calques qui va du thème vers les réglages personnalisés de chaque bloc. Ce système porte un nom précis, les styles globaux, et il repose entièrement sur un fichier central : theme.json.
Comprendre l’articulation entre ce fichier et le panneau Styles évite bien des confusions, notamment quand un client modifie une couleur depuis l’éditeur et se demande pourquoi elle ne se retrouve pas dans le code source du thème. La réponse tient en un mot : ces réglages ne vivent pas au même endroit selon qui les a définis.
La hiérarchie des styles : thème puis utilisateur
Le fichier theme.json, placé à la racine du thème, définit la base : palette de couleurs autorisée, tailles de police disponibles, espacements par défaut, styles par bloc. Ces réglages constituent le socle, celui que tous les visiteurs voient tant que personne n’a modifié quoi que ce soit depuis l’éditeur.
Par-dessus ce socle vient une seconde couche, dite « styles utilisateur », alimentée par les modifications faites dans le panneau Styles de l’éditeur de site. Cette couche ne modifie jamais le fichier theme.json sur le disque : elle est stockée en base de données, et vient surcharger les réglages du thème au moment du rendu, sans jamais les écraser définitivement.
Éditer visuellement couleurs, typographie et espacements
Le panneau Styles s’ouvre depuis l’éditeur de site via l’icône en forme de demi-cercle. Il propose plusieurs niveaux de réglage, du plus général au plus précis :
- Général : palette de couleurs du site, typographie par défaut, mise en page (largeur de contenu, largeur large).
- Par bloc : chaque type de bloc (Titre, Bouton, Citation…) peut recevoir ses propres couleurs, sa propre typographie, indépendamment du reste du site.
- Éléments : réglages transversaux pour les liens, les légendes, les boutons, appliqués partout où ces éléments apparaissent.
Où atterrissent réellement ces réglages
Techniquement, chaque modification faite dans le panneau Styles est enregistrée dans un type de contenu personnalisé et masqué, wp_global_styles, visible dans la base de données mais absent des écrans classiques de gestion de contenu. Son contenu est un objet JSON qui reprend la même structure que theme.json, limité aux propriétés effectivement modifiées par l’utilisateur.
Cette séparation a une conséquence pratique importante pour toute agence qui livre des sites : les réglages faits par un client depuis le panneau Styles survivent à une mise à jour du thème, puisqu’ils sont stockés en base et non dans les fichiers du thème. À l’inverse, ils ne sont pas non plus versionnés avec le code, ce qui peut surprendre lors d’une migration d’un environnement à un autre.
Comparatif : réglage via l’interface ou via theme.json
| Critère | Panneau Styles (interface) | theme.json (code) |
|---|---|---|
| Stockage | Base de données (wp_global_styles) | Fichier du thème, versionné avec Git |
| Auteur habituel | Client ou rédacteur | Développeur du thème |
| Survit à une mise à jour du thème | Oui | Oui, tant que le fichier n’est pas réécrit |
| Portabilité vers un autre site | Faible, nécessite un export | Élevée, copie du fichier suffisante |
| Usage recommandé | Ajustements ponctuels et réversibles | Fondations visuelles du thème |
Exporter les réglages du panneau vers theme.json
Quand les ajustements faits en interface deviennent la nouvelle référence attendue par le client (par exemple après validation finale d’une charte graphique), il est recommandé de les rapatrier dans le fichier theme.json du thème plutôt que de les laisser vivre uniquement en base. L’éditeur de site propose pour cela une option d’export, accessible depuis le menu des options de l’éditeur, qui télécharge une archive contenant un theme.json à jour avec les styles globaux actuels.
Un extrait typique de ce que l’on retrouve dans ce fichier, pour une palette de couleurs personnalisée :
{
"version": 2,
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#1e3a5f", "name": "Primaire" },
{ "slug": "accent", "color": "#e07a3f", "name": "Accent" }
]
},
"typography": {
"fontSizes": [
{ "slug": "small", "size": "0.875rem", "name": "Petit" },
{ "slug": "large", "size": "1.5rem", "name": "Grand" }
]
}
}
}Sur un projet livré à un client autonome, mieux vaut geler tôt une base solide dans
theme.json(palette, échelle typographique, espacements) plutôt que de laisser le panneau Styles devenir le seul dépositaire de l’identité visuelle. Le jour où il faut recréer le site ailleurs, un fichier versionné se récupère en une commande, pas une ligne de base de données.
En résumé
Le panneau Styles et theme.json ne sont pas deux systèmes concurrents, mais deux couches d’un même mécanisme : le thème pose les fondations, l’utilisateur ajuste par-dessus sans jamais toucher au code. Comprendre cette hiérarchie évite les fausses alertes lors d’une mise à jour de thème, et permet de choisir en connaissance de cause où doit vivre chaque réglage : dans le code pour ce qui doit rester stable et versionné, dans l’interface pour ce qui reste au client de personnaliser.
