vendredi 25 septembre 2026

À propos

Contact

FSE

Versionner les styles globaux : du panneau Styles au dépôt Git

Un réglage de couleur fait en production et jamais réintégré dans le thème versionné finit toujours par créer un écart silencieux entre les environnements.

Par Clément Hadrot • 8 avril 2026 • 4 min de lecture • Aucun commentaire
Versionner les styles globaux : du panneau Styles au dépôt Git

Un développeur d’équipe modifie theme.json en local, le commite, le déploie en production — et découvre que rien ne change visuellement, parce qu’un client a, entretemps, ajusté la palette de couleurs depuis le panneau Styles directement en production. Cette situation, fréquente sur les projets où le client garde la main sur les styles, vient d’un principe simple mais souvent oublié : les réglages faits depuis l’éditeur ne sont jamais écrits dans theme.json, ils sont stockés à part, en base, dans un article du type wp_global_styles, qui prend systématiquement le pas sur le fichier du thème.

Étape 1 : identifier l’article de styles globaux actif

  1. Connectez-vous en SSH à l’environnement dont les styles doivent être extraits (typiquement la production, si c’est elle que le client modifie).
  2. Listez les articles de styles globaux existants avec WP-CLI :
wp post list --post_type=wp_global_styles --format=table --fields=ID,post_title,post_modified

Un seul article de ce type est actif à la fois par thème installé — repérable à son titre reprenant le nom du thème actif et à sa date de dernière modification, qui doit correspondre au moment où le client se souvient avoir touché aux styles.

Étape 2 : extraire le contenu JSON de cet article

wp post get <ID> --field=post_content > styles-production.json

Le contenu récupéré est un objet JSON structuré de la même façon que la section styles et settings de theme.json, mais sans les métadonnées propres au thème (aucune information de version ni de nom de thème) : c’est un instantané brut des réglages actifs, prêt à être comparé au fichier versionné.

L'essentiel à retenir : Les réglages du panneau Styles vivent en base, pas dans theme.json ; Une extraction régulière évite l'écart entre production et dépôt ; WP-CLI permet de récupérer proprement le contenu à réintégrer

Étape 3 : comparer avec le theme.json versionné et réintégrer les écarts

  1. Ouvrez côte à côte styles-production.json et le theme.json du dépôt Git.
  2. Repérez les propriétés modifiées en production (couleurs de la palette, tailles de police, espacement par défaut) absentes ou différentes du fichier versionné.
  3. Reportez manuellement ces valeurs dans les sections correspondantes de theme.json — il n’existe pas de fusion automatique fiable entre les deux structures, la comparaison reste un travail manuel de relecture.
  4. Commitez ce theme.json mis à jour, avec un message explicite mentionnant l’origine du changement (« réintégration des styles ajustés en production le 8 avril »).
  5. Déployez cette version : au prochain chargement, si l’article wp_global_styles n’a pas changé, les valeurs identiques ne produisent aucune différence visible ; le fichier versionné est désormais simplement redevenu la source de vérité alignée avec ce que le client voit réellement.

Étape 4 : réduire la récurrence de l’écart

  • Restreindre l’accès au panneau Styles aux seules personnes formées à signaler tout changement à l’équipe technique, via les capacités abordées par ailleurs pour restreindre l’éditeur de site par rôle.
  • Programmer une extraction régulière (mensuelle, ou après chaque changement de contenu majeur) plutôt que d’attendre une divergence visible pour s’en rendre compte.
  • Documenter, dans le dépôt du projet, la procédure d’extraction elle-même — un simple script shell reprenant les deux commandes WP-CLI ci-dessus, versionné aux côtés du thème, évite de la retrouver à chaque fois par tâtonnement.

Limite de cette approche

Cette procédure ne fusionne jamais automatiquement deux sources de styles concurrentes : si le thème versionné et la production ont chacun évolué de leur côté depuis la dernière synchronisation, la comparaison manuelle devient plus longue et plus sujette à erreur. Sur un projet où les styles changent souvent des deux côtés, il vaut mieux se poser la question de qui, en réalité, doit avoir la main sur les styles globaux, plutôt que de multiplier les allers-retours de réintégration.

En résumé

Le panneau Styles et theme.json ne sont jamais automatiquement synchronisés : l’un vit en base, l’autre en fichier. Sans procédure explicite d’extraction régulière via WP-CLI, un projet géré à plusieurs mains — développeur et client final — finit presque toujours par diverger silencieusement entre ce que montre la production et ce que contient le dépôt Git.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi