# Un multisite de 500 sites : rollback d’un theme.json cassé sur tout le réseau > 500 sites affichent la même erreur en même temps après une mise à jour de thème réseau. Retour sur la procédure de retour arrière qui a permis de tout restaurer en moins d'une heure. - Auteur : WordPress Développement - Publié le : 2024-12-20 - Mis à jour le : 2024-12-20 - Catégorie : Éditeur de site (FSE) - URL : https://www.wpmoderne.fr/fse/rollback-theme-json-multisite-500-sites/ ## L’essentiel - L'erreur touche les 500 sites en quelques minutes - Le rollback passe par WP-CLI en boucle sur tous les sites - Le cache objet a retardé la propagation du correctif 500 sites qui affichent d'un coup le même écran blanc : c'est le genre d'alerte qui réveille une équipe technique un vendredi après-midi. Le réseau en question héberge des micro-sites vitrines pour un réseau de franchises, tous construits sur le même thème bloc partagé, activé au niveau du réseau. La cause remonte à une mise à jour du thème poussée en fin de matinée : un `theme.json` modifié pour ajouter une nouvelle variation de style contenait une virgule surnuméraire dans le tableau `settings.color.palette`. Le fichier JSON était invalide, et l'éditeur de site comme le rendu front en ont payé le prix immédiatement. ## Une propagation instantanée par nature Sur un multisite, un thème activé au niveau du réseau (`network_enable_theme`) n'est pas dupliqué par site : tous les sous-sites pointent vers le même dossier de thème sur le disque. Une modification de `theme.json` se répercute donc instantanément partout, sans avoir besoin d'une mise à jour individuelle. C'est un avantage énorme pour la maintenance courante, et un risque tout aussi énorme en cas d'erreur. Dans ce cas précis, WordPress ne plante pas franchement : un `theme.json` invalide fait retomber l'éditeur de site sur les valeurs par défaut du cœur, ce qui casse toutes les variations de style personnalisées et fait disparaître la quasi-totalité des couleurs de marque sur chaque site du réseau. ## Rollback : revenir à la dernière version connue saine Le thème étant versionné dans un dépôt Git séparé du répertoire de plugins, la première étape a consisté à identifier le dernier commit fonctionnel : > L'essentiel à retenir : L'erreur touche les 500 sites en quelques minutes ; Le rollback passe par WP-CLI en boucle sur tous les sites ; Le cache objet a retardé la propagation du correctif ``` cd wp-content/themes/theme-reseau git log --oneline -- theme.json git diff HEAD~1 HEAD -- theme.json ``` Le diff confirme immédiatement la virgule en trop dans le tableau des couleurs. Plutôt que de corriger en direct sur la version en production, la décision a été de revenir purement et simplement au commit précédent : ``` git revert HEAD --no-edit git push origin main ``` Le déploiement, géré par un hook de déploiement continu, redéploie le thème sur le serveur en quelques secondes. Mais revenir au bon fichier ne suffit pas : il reste à vider les caches qui ont mémorisé la version cassée. ## Vider le cache sur 500 sites sans y passer la nuit Le réseau utilise un cache objet Redis partagé, avec des groupes de cache par site. Un simple `wp cache flush` exécuté à la racine ne suffit pas sur un multisite : il faut cibler chaque site individuellement pour que les transients liés aux styles globaux soient bien recalculés. La commande WP-CLI suivante, exécutée avec l'option `--url` en boucle sur la liste des sites, a permis d'automatiser l'opération : ``` wp site list --field=url | while read url; do wp cache flush --url="$url" wp cli cache clear --url="$url" done ``` Sur 500 sites, cette boucle a mis un peu plus de vingt minutes à s'exécuter, essentiellement limitée par la latence réseau entre le serveur d'exécution et la base de données. En parallèle, une purge du CDN a été déclenchée par API pour éviter que les pages en cache HTML ne continuent de servir la version cassée pendant plusieurs heures. ## Ce que l'incident a changé dans le processus Plusieurs ajustements ont suivi cet épisode : - Toute modification de `theme.json` passe désormais par une validation JSON automatique dans la pipeline d'intégration continue, avant même le merge. - Un environnement de recette réplique un sous-ensemble de dix sites représentatifs du réseau, pour valider visuellement avant chaque déploiement réseau. - La commande de purge de cache est désormais scriptée et documentée, plutôt que réinventée dans l'urgence. > Sur un multisite de cette taille, le thème partagé n'est jamais un détail technique secondaire : chaque modification doit être traitée comme un déploiement de production à part entière, avec sa propre validation. ## Notre verdict La mutualisation d'un thème bloc sur un multisite de grande taille est un choix pertinent pour la maintenance, mais elle transforme chaque erreur de configuration en incident de grande ampleur. La validation automatique du `theme.json` avant merge, couplée à une procédure de rollback documentée et à un script de purge de cache prêt à l'emploi, a permis de ramener le temps de résolution de plusieurs heures à moins d'une heure. La leçon la plus utile de cet incident tient en une phrase : ce n'est pas la panne qui coûte cher, c'est l'absence de procédure pour en sortir vite.