Un thème bloc qui efface les styles globaux du client après une mise à jour

Un mardi matin, un client m’a appelé affolé : la palette de couleurs personnalisée de son site, travaillée pendant des semaines avec son graphiste, avait « disparu » après une mise à jour du thème effectuée automatiquement dans la nuit. Les couleurs par défaut du thème s’affichaient partout, boutons compris, comme si le site venait d’être installé.

Le réflexe immédiat aurait été d’accuser la mise à jour du thème d’avoir écrasé le fichier theme.json. Mais ce diagnostic était incomplet, et comprendre pourquoi m’a pris un peu de temps avant de retrouver les bonnes couleurs.

Symptôme : des styles personnalisés disparus du jour au lendemain

Le site affichait la palette par défaut du thème, un vert et un beige génériques, alors que le client travaillait depuis des mois avec un bleu marine et un orange spécifiques à sa marque. Aucune erreur PHP, aucun message dans les logs, le site fonctionnait normalement — seules les couleurs avaient changé. La zone Styles de l’éditeur de site montrait bien la palette par défaut, comme si les personnalisations n’avaient jamais existé.

Diagnostic : où vivent vraiment les styles personnalisés

Le point essentiel à comprendre ici, souvent mal connu même de développeurs expérimentés : les styles personnalisés effectués depuis l’onglet Styles de l’éditeur de site ne sont jamais écrits dans le fichier theme.json du thème. Ils sont stockés en base de données, dans un post de type wp_global_styles, lié au thème actif via son slug. Une mise à jour de thème ne devrait donc jamais les affecter, sauf changement du slug du thème lui-même.

En creusant les logs d’hébergement, j’ai découvert que la mise à jour automatique avait en réalité renommé légèrement le dossier du thème enfant, suite à une réinstallation via un gestionnaire de déploiement mal configuré côté hébergeur. Le nouveau slug ne correspondait plus exactement à l’ancien, ce qui a fait pointer WordPress vers un post wp_global_styles vide, nouvellement créé pour ce « nouveau » thème aux yeux du système.

global $wpdb;
$wpdb->get_results(
    "SELECT ID, post_title, post_modified
     FROM {$wpdb->posts}
     WHERE post_type = 'wp_global_styles'
     ORDER BY post_modified DESC"
);

Cette requête, exécutée directement en base via WP-CLI, a permis de lister tous les posts de styles globaux existants, y compris ceux laissés orphelins par d’anciens slugs de thème. Le post correspondant à l’ancien slug existait toujours, intact, simplement déconnecté du thème actuellement actif.

Correctif : reconnecter le bon post de styles globaux

La correction a consisté à renommer le dossier du thème pour revenir exactement au slug d’origine, ce qui a immédiatement reconnecté WordPress au bon post wp_global_styles et restauré les couleurs personnalisées du client. Aucune donnée n’avait donc été perdue : le problème était un problème de correspondance, pas de suppression.

wp theme list --status=active --field=name
mv wp-content/themes/theme-client-v2 wp-content/themes/theme-client

Dans les cas où le post d’origine a réellement été perdu ou corrompu, l’historique des révisions de styles globaux, accessible depuis la zone Styles via l’icône d’horloge, permet de remonter dans le temps et de restaurer une version antérieure sans intervention en base de données.

Vérifier qu’on regarde la bonne révision

Sur ce dossier, il a fallu parcourir quatre révisions de styles globaux avant de retrouver la bonne combinaison de couleurs, l’historique conservant aussi des essais intermédiaires du graphiste qui n’avaient jamais été retenus. La date de modification affichée à côté de chaque révision a suffi à identifier la bonne version sans ambiguïté.

Prévention : exporter les styles avant toute opération de déploiement

Depuis cet incident, j’exporte systématiquement les styles globaux avant toute opération de déploiement ou de mise à jour de thème sur un projet client, via la fonction wp_get_global_styles() couplée à un export JSON stocké hors base de données, en complément du versioning Git déjà en place sur le code.

• Un export JSON des styles globaux avant chaque déploiement en production.
• Un contrôle systématique du slug de thème après toute opération de renommage ou de réinstallation.
• Une vérification visuelle rapide de la page d’accueil dans les cinq minutes suivant toute mise à jour automatique.

Ne jamais renommer le dossier d’un thème actif sans vérifier au préalable le slug utilisé par les styles globaux en base : c’est la cause la plus fréquente de personnalisations « perdues » qui ne le sont en réalité jamais.

En résumé

Des styles globaux qui disparaissent après une mise à jour ne signifient presque jamais une perte de données. Le problème vient le plus souvent d’une rupture de correspondance entre le slug du thème actif et le post wp_global_styles associé. Vérifier cette correspondance avant de paniquer, et conserver un export régulier des styles en dehors de la base, évite bien des sueurs froides côté client.