Le thème WordPress a cassé votre site : basculer vers un thème par défaut sans wp-admin

Ce qui se passe réellement quand un thème casse WordPress

Quand un thème casse un site WordPress, ce n’est que rarement mystique. C’est généralement une défaillance opérationnelle simple : PHP ne peut pas exécuter un code dont dépend le thème, WordPress ne peut pas charger le template actif, ou quelque chose dans le chemin de la requête (cache, CDN, PHP-FPM, base de données) masque l’erreur réelle.

Les mécanismes courants

• Erreur fatale dans le PHP du thème (souvent functions.php ou un framework empaqueté) : PHP s’arrête et WordPress ne peut ni rendre le frontend ni l’admin.
• Dépendances manquantes : le thème attend un plugin, une extension PHP ou une fonctionnalité d’une version PHP spécifique.
• Désalignement du système de fichiers : dossier du thème renommé, upload incomplet, permissions incorrectes, ou un déploiement qui vous laisse à moitié ancien/à moitié nouveau.
• Le template pointe vers un thème qui n’existe pas : WordPress stocke la sélection du thème actif dans la base ; si elle pointe vers quelque chose d’inexistant, c’est le chaos.
• Le cache vous ment : le cache de page sert l’ancienne page bonne pendant que l’admin meurt — ou l’inverse, ce qui explique pourquoi on vous appelle à 02:13.

L’objectif ici n’est pas de « réparer le thème ». L’objectif est de « restaurer le service rapidement ». Une fois en ligne avec un thème par défaut, vous pouvez déboguer le thème cassé sans incident de production sur le dos.

Une citation à garder sous la main, surtout quand vous êtes tenté de bricoler en production : « Idée paraphrasée » — Gene Kranz : dur et compétent ; restez discipliné sous pression.

Blague n°1 : un thème cassé, c’est comme une mauvaise coupe de cheveux — on peut faire semblant que tout va bien, mais vos utilisateurs le remarqueront quand même.

Guide de diagnostic rapide (premiers/seconds/troisièmes contrôles)

Si vous avez cinq minutes avant qu’on n’escalade, ne vous égarez pas. Exécutez ce guide. Vous cherchez à répondre à une question : S’agit-il d’une défaillance PHP au niveau du thème, ou d’un goulot d’étranglement d’infrastructure qui s’en fait passer ?

Premier : confirmez que c’est vraiment le thème et pas la plateforme

1. Vérifiez les logs du serveur web pour des fatals PHP (Nginx/Apache + PHP-FPM). Si vous voyez un fichier de thème dans la trace de pile, vous avez terminé le diagnostic.
2. Vérifiez le code HTTP et le corps de réponse. 500 avec « erreur critique » ou sortie vide suggère fortement un fatal PHP. 502/504 suggère un upstream (PHP-FPM) en panne ou un timeout, ce qui peut quand même être causé par le thème.
3. Vérifiez l’état / slowlog de PHP-FPM. Un thème peut déclencher une CPU runaway ou de la récursion jusqu’à rencontrer des timeouts.

Deuxième : vérifiez la sélection de thème active

1. Interrogez wp_options pour template et stylesheet. S’ils pointent vers un répertoire de thème qui n’existe pas, corrigez cela en priorité.
2. Listez les thèmes installés avec WP-CLI (si disponible). Si WP-CLI ne peut pas bootstrapper, passez à l’édition de la base ou au renommage du système de fichiers.

Troisième : restaurez le service par la méthode la moins invasive

1. WP-CLI : activer un thème par défaut (rapide, propre, réversible).
2. Modification DB des deux options de thème (fonctionne même quand PHP est trop cassé pour WP-CLI).
3. Renommer le dossier du thème cassé (rudimentaire, mais force WordPress à retomber sur un autre thème installé).

Règle de décision : si vous pouvez exécuter WP-CLI sans qu’il plante, utilisez WP-CLI. Si le bootstrap WordPress explose, allez directement sur la base de données. Si vous n’avez pas accès à la base, renommez les fichiers du thème. Ne passez pas 40 minutes à « tenter encore une chose » pendant que le site est indisponible.

Faits et contexte intéressants (oui, les thèmes ont une histoire)

• Le choix du thème vit dans la base de données : WordPress le stocke dans des options nommées template et stylesheet. C’est pourquoi un dossier manquant peut briquer le site.
• Les thèmes par défaut « Twenty * » sont plus que de la décoration : ils constituent une baseline supportée pour la compatibilité et la récupération. Ce sont l’équivalent de la roue de secours pour WordPress.
• WordPress a introduit une fonction de « protection contre les erreurs fatales » qui peut parfois désactiver un plugin/thème cassé et envoyer un e‑mail à un admin. C’est utile, mais ce n’est pas garanti — surtout si le mail est cassé ou si l’erreur survient trop tôt.
• Le mécanisme de thème enfant n’est que des pointeurs de répertoire : le « parent » est référencé dans le style.css du thème enfant. Un parent manquant peut faire tomber tout le thème.
• Les écosystèmes de thèmes anciens encourageaient l’empaquetage de tout (frameworks personnalisés, builders). C’est pourquoi les pannes modernes des thèmes ressemblent souvent à des explosions de dépendances.
• WP-CLI existe parce que gérer WordPress via l’UI web ne scale pas. Il est un incontournable pour les opérations type SRE sur WordPress depuis des années.
• Beaucoup d’hébergeurs gérés désactivent l’édition directe des fichiers dans l’admin pour la sécurité. L’avantage : moins d’erreurs auto‑infligées. L’inconvénient : il faut des compétences SSH/CLI quand ça casse.
• Les couches de cache peuvent « préserver » un déploiement cassé pendant des minutes à des heures. Cela rend les incidents confus : certains utilisateurs voient un site sain, d’autres frappent l’origine cassée.

Avant de toucher à quoi que ce soit : accès, sauvegardes et garde-fous

Basculez de thème semble anodin jusqu’à ce que vous réalisiez que cela peut déclencher des réinitialisations de widgets, des changements de menus, des mésappariements de paramètres du customizer et des régressions de mise en page. Vous le ferez quand même. Parce que la disponibilité vaut plus que l’esthétique. Mais faites-le avec des garde-fous.

Ce dont vous avez besoin

• Accès SSH au serveur ou au conteneur qui exécute WordPress, ou au moins au shell de l’hébergement mutualisé.
• Accès à la base de données (identifiants MySQL/MariaDB depuis wp-config.php ou variables d’environnement).
• Un thème par défaut connu et fonctionnel installé (par ex., twentytwentyfour, twentytwentythree). S’il n’est pas installé et que l’admin est mort, vous devrez peut‑être l’uploader manuellement.
• Permissions suffisantes pour renommer des répertoires dans wp-content/themes ou pour exécuter WP-CLI.

Garde-fous que vous remercierez plus tard

• Snapshot/sauvegarde de la base et de wp-content avant les modifications. Si vous ne pouvez pas snapshotter, au moins dumppez les deux valeurs d’option avant de les éditer.
• État d’esprit lecture seule d’abord : confirmez ce qui est actif, ce qui existe sur le disque, quelles erreurs sont levées. Puis changez une seule chose.
• Consignez ce que vous avez fait (note de ticket, mise à jour de chat ou fichier texte local). Votre vous futur compte comme un intervenant.

Voie A : réparer avec WP-CLI (meilleur cas)

WP-CLI est la manière la plus propre de basculer le thème actif parce qu’il met à jour les bonnes options et peut valider ce qui est installé. Le piège : WP-CLI bootstrappe WordPress. Si votre erreur fatale de thème survient pendant le bootstrap, WP-CLI peut aussi planter. Essayez quand même ; si ça échoue, ne vous obstinez pas — changez de méthode.

À quoi ressemble le « succès »

• Vous pouvez exécuter wp theme list sans erreur fatale.
• Vous activez un thème par défaut et le site revient (même s’il est moche).
• Vous confirmez que le frontend et /wp-admin/ se chargent.

Voie B : réparer en éditant la base de données (phpMyAdmin ou CLI)

Si WordPress ne peut pas exécuter suffisamment de PHP pour que WP-CLI tourne, la base de données est votre plan de contrôle. WordPress lit le nom du thème actif depuis wp_options (ou un préfixe différent) puis charge le répertoire correspondant sous wp-content/themes.

En pratique, vous changez deux options :

• template — le nom du répertoire du thème parent
• stylesheet — le nom du répertoire du thème actif (thème enfant si utilisé)

Définissez les deux sur un nom de répertoire de thème par défaut comme twentytwentyfour. Si vous n’êtes pas sûr de ce qui est installé, listez d’abord les répertoires sur le disque.

Voie C : réparer en déplaçant les fichiers du thème (dernier recours mais efficace)

Si vous ne pouvez pas accéder rapidement à la base (ou si les identifiants manquent dans le feu de l’action), vous pouvez forcer WordPress à cesser de charger le thème cassé en renommant son répertoire. Quand WordPress ne trouve pas le dossier du thème actif, il retombe généralement sur un autre thème installé.

Ce n’est pas élégant. C’est efficace. Les opérations regorgent de ces vérités inconfortables.

Particularités Multisite et hébergement géré

Multisite : thèmes activés réseau vs thèmes activés site par site

Dans le multisite, les thèmes sont « activés » au niveau du réseau, mais les sites individuels choisissent quel thème activé utiliser. Le thème actif pour chaque site est stocké dans la table d’options de ce site (par ex., wp_2_options pour l’ID de site 2) sauf si vous avez un mapping de tables inhabituel.

Règle de décision : si un sous‑site seul est cassé, vous éditez les options pour cet ID de blog, pas le site principal. Si tout le réseau est cassé, commencez par les options du site principal et vérifiez si un MU-plugin ou une personnalisation réseau est en cause.

Hébergement géré : shells limités et cache agressif

Certaines plateformes vous donnent WP-CLI mais pas un MySQL CLI brut. D’autres vous donnent phpMyAdmin mais pas SSH. Certaines se trouvent derrière des couches de cache qui ignorent vos changements jusqu’à purge. Votre méthode dépend de ce qui est disponible. Ne soyez pas sentimental vis‑à‑vis des outils.

Tâches pratiques (12+) : commandes, sorties et ce que vous décidez ensuite

Ci‑dessous les tâches que j’exécute réellement lors d’incidents en production. Chacune inclut : une commande, ce que signifie une sortie typique, et la décision suivante. Ce ne sont pas des « options agréables ». C’est comme ça qu’on arrête de deviner.

Task 1: Confirm you’re on the right host and in the right directory

cr0x@server:~$ hostname -f; pwd; ls -la
wp01.prod.example.internal
/home/cr0x
total 32
drwxr-xr-x  4 cr0x cr0x 4096 Jan 12 09:10 .
drwxr-xr-x  3 root root 4096 Jan 10 18:22 ..
drwx------  2 cr0x cr0x 4096 Jan 12 09:10 .ssh
-rw-r--r--  1 cr0x cr0x  220 Jan 10 18:22 .bash_logout
-rw-r--r--  1 cr0x cr0x 3771 Jan 10 18:22 .bashrc
-rw-r--r--  1 cr0x cr0x  807 Jan 10 18:22 .profile

Ce que ça signifie : Vous n’êtes pas en train d’opérer accidentellement sur la staging ou une VM oubliée.

Décision : Si l’hôte est incorrect, arrêtez. Si c’est le bon, cd vers le docroot WordPress ensuite.

Task 2: Find the WordPress root (docroot) quickly

cr0x@server:~$ sudo find /var/www -maxdepth 3 -name wp-config.php -print
/var/www/html/wp-config.php

Ce que ça signifie : Vous avez trouvé la config WordPress. Ce répertoire est presque toujours votre root.

Décision : cd /var/www/html et travaillez depuis là.

Task 3: Verify the active theme folders exist on disk

cr0x@server:~$ cd /var/www/html && ls -1 wp-content/themes
broken-agency-theme
twentytwentythree
twentytwentyfour

Ce que ça signifie : Vous avez au moins un thème par défaut installé. Bien — la récupération ne nécessitera pas d’uploads.

Décision : Si aucun thème par défaut n’existe, vous devrez peut‑être en uploader ou en installer un via WP-CLI (si possible) avant de basculer.

Task 4: Check the site response and status code from the origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head
HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Sat, 27 Dec 2025 10:42:18 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Ce que ça signifie : C’est une défaillance côté origine, pas juste un glitch CDN. 500 suggère un fatal PHP ou une erreur applicative.

Décision : Allez voir les logs pour trouver le fatal et confirmer qu’il est lié au thème.

Task 5: Read the web server error log for the smoking gun

cr0x@server:~$ sudo tail -n 30 /var/log/nginx/error.log
2025/12/27 10:42:17 [error] 22140#22140: *1047 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-blog-header.php(13): require_once('...')
#4 /var/www/html/index.php(17): require('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19" while reading response header from upstream, client: 10.0.4.12, server: _, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Ce que ça signifie : Le thème actif s’exécute avant que WordPress ne soit complètement chargé ou fait quelque chose de fondamentalement incorrect. La trace de pile pointe vers le thème.

Décision : Basculez vers un thème par défaut. Ne déboguez pas le thème pendant que le site est en panne.

Task 6: Confirm PHP-FPM is alive (avoid misdiagnosing a platform outage)

cr0x@server:~$ systemctl status php8.2-fpm --no-pager | sed -n '1,12p'
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2025-12-27 09:50:11 UTC; 52min ago
       Docs: man:php-fpm8.2(8)
   Main PID: 1183 (php-fpm8.2)
     Status: "Processes active: 2, idle: 6, Requests: 14321, slow: 0, Traffic: 0req/sec"

Ce que ça signifie : PHP-FPM est en cours. Le 500 est probablement au niveau applicatif, pas un backend mort.

Décision : Poursuivez le changement de thème plutôt que de redémarrer aveuglément les services.

Task 7: Try WP-CLI bootstrap (quick health check)

cr0x@server:~$ cd /var/www/html && wp core version
Error: PHP Fatal error:  Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-content/themes/broken-agency-theme/functions.php:19
Stack trace:
#0 /var/www/html/wp-settings.php(591): include()
#1 /var/www/html/wp-config.php(90): require_once('...')
#2 /var/www/html/wp-load.php(50): require_once('...')
#3 /var/www/html/wp-cli.php(134): require_once('...')
#4 /usr/local/bin/wp(4): include('...')
#5 {main}
  thrown in /var/www/html/wp-content/themes/broken-agency-theme/functions.php on line 19

Ce que ça signifie : WP-CLI ne peut pas tourner parce que le bootstrap WordPress charge le thème cassé assez tôt pour planter.

Décision : Sautez WP-CLI pour la bascule. Utilisez l’édition de la base ou le renommage du système de fichiers.

Task 8: Pull DB credentials from wp-config.php (without leaking them into your scrollback)

cr0x@server:~$ cd /var/www/html && sudo sed -n "1,140p" wp-config.php | sed -n 's/.*DB_.*//p'

Ce que ça signifie : Vous n’avez intentionnellement pas affiché les secrets. Bien. Extrayez‑les ensuite plus prudemment.

Décision : Utilisez une approche plus sûre : lisez le fichier localement dans un éditeur de confiance, ou utilisez un grep ciblé et gardez la sortie privée.

Task 9: Read the table prefix so you don’t edit the wrong table

cr0x@server:~$ cd /var/www/html && grep -n "table_prefix" wp-config.php
78:$table_prefix = 'wp_';

Ce que ça signifie : Votre table d’options est probablement wp_options. Si elle est différente, ajustez toutes les requêtes.

Décision : Utilisez le bon nom de table. Deviner est la façon dont vous « réparez » rien et perdez une heure.

Task 10: Query current active theme from the database (read-only first)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+----------------------+
| option_name | option_value         |
+-------------+----------------------+
| template    | broken-agency-theme  |
| stylesheet  | broken-agency-theme  |
+-------------+----------------------+

Ce que ça signifie : WordPress est explicitement configuré pour utiliser le thème cassé.

Décision : Basculez les deux valeurs vers un répertoire de thème par défaut connu.

Task 11: Update the active theme to a default (the actual fix)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Ce que ça signifie : La base pointe maintenant vers twentytwentyfour.

Décision : Retestez le site depuis l’origine. S’il échoue encore, le thème n’était pas le seul problème.

Task 12: Re-test frontend and wp-admin from the origin

cr0x@server:~$ curl -sS -D- -o /dev/null http://127.0.0.1/ | head -n 5
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 27 Dec 2025 10:45:51 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

Ce que ça signifie : Le site est revenu. Vous n’avez pas fini, mais vous n’êtes plus en feu.

Décision : Vérifiez /wp-admin/. Puis purgeez les caches pour que les utilisateurs ne voient plus d’erreurs obsolètes.

Task 13: Purge/clear common caches (server-side page cache example)

cr0x@server:~$ sudo rm -rf /var/cache/nginx/*

Ce que ça signifie : Vous avez vidé le cache Nginx si vous l’utilisez. Votre environnement peut différer.

Décision : Si vous êtes derrière un reverse proxy ou un CDN, purgez aussi là‑bas avec les contrôles de votre plateforme.

Task 14: If you must use filesystem rename (no DB access)

cr0x@server:~$ cd /var/www/html/wp-content/themes && sudo mv broken-agency-theme broken-agency-theme.disabled

Ce que ça signifie : WordPress ne peut plus charger ce répertoire de thème.

Décision : Rechargez le site. S’il revient, définissez immédiatement un thème par défaut valide via DB/WP-CLI pour ne pas dépendre du comportement de repli implicite.

Task 15: Confirm which theme WordPress thinks is active (after recovery)

cr0x@server:~$ mysql -u wpuser -p -h 127.0.0.1 wordpress -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
Enter password:
+-------------+------------------+
| option_name | option_value     |
+-------------+------------------+
| template    | twentytwentyfour |
| stylesheet  | twentytwentyfour |
+-------------+------------------+

Ce que ça signifie : Vous avez une configuration explicite et stable.

Décision : Maintenant vous pouvez déboguer le thème cassé hors production ou en staging.

Task 16: Turn on debug logging (briefly) to catch remaining errors

cr0x@server:~$ cd /var/www/html && sudo grep -n "WP_DEBUG" wp-config.php
91:define('WP_DEBUG', false);
92:define('WP_DEBUG_LOG', false);
93:define('WP_DEBUG_DISPLAY', false);

Ce que ça signifie : Le débogage est désactivé, ce qui est normal en production.

Décision : Si vous voyez encore des problèmes après la bascule, activez temporairement WP_DEBUG_LOG et taillez wp-content/debug.log. N’activez pas l’affichage en production.

Blague n°2 : Activer WP_DEBUG_DISPLAY en production est une stratégie audacieuse — surtout pour ceux qui aiment partager des traces de pile avec des inconnus.

Listes de contrôle / plan étape par étape

Checklist de restauration d’urgence (objectif : 5–15 minutes)

1. Confirmez le symptôme : frontend down, admin down, codes de statut.
2. Vérifiez les logs d’erreur pour un fichier de thème dans la trace de pile.
3. Listez les thèmes installés sur le disque ; confirmez qu’un thème par défaut existe.
4. Tentez WP-CLI (wp theme list). S’il fonctionne, activez le thème par défaut via WP-CLI.
5. Si WP-CLI échoue, éditez les options DB : mettez template et stylesheet sur le répertoire du thème par défaut.
6. Retestez depuis l’origine avec curl : attendez 200.
7. Retestez wp-admin (ou au moins la page de connexion).
8. Purgez les caches qui pourraient continuer à servir des erreurs.
9. Communiquez le statut : « Service restauré avec un thème de repli ; investigation en cours. »

Stabiliser après la restauration (objectif : 30–90 minutes)

1. Identifiez exactement ce qui a changé (mise à jour de thème, mise à jour PHP, mise à jour de plugin, artefact de déploiement).
2. Capturez la trace d’erreur fatale et enregistrez-la dans le ticket d’incident.
3. Reproduisez en staging avec la même version de PHP et le même ensemble de plugins.
4. Décidez : corriger le thème, revenir en arrière sur le thème, ou remplacer le thème.
5. Ajoutez un contrôle pré-déploiement : WordPress peut‑il rendre /wp-login.php et la page d’accueil après les changements de thème ?

Contrôles préventifs (ennuyeux, efficaces)

1. Gardez au moins un thème Twenty par défaut installé en permanence.
2. Automatisez les sauvegardes DB et vérifiez que la restauration fonctionne.
3. Utilisez un environnement de staging qui correspond à la version PHP de production.
4. Exécutez des commandes de santé WP-CLI dans le CI/CD (ou au moins sur les hôtes de déploiement).
5. Traquez les changements de thèmes et plugins comme du code : changelog, approbations, plan de rollback.

Erreurs fréquentes : symptômes → cause racine → correction

1) Symptom: blank white page (frontend and admin)

Cause racine : Erreur fatale PHP avec affichage d’erreur désactivé ; le code du thème plante tôt.

Correction : Vérifiez les logs Nginx/Apache + PHP-FPM. Basculez le thème via DB ou WP-CLI. Puis inspectez le fatal dans les logs.

2) Symptom: “There has been a critical error on this website”

Cause racine : Exception non gérée / fatal ; le mode de récupération de WordPress peut ne pas s’engager ou l’e‑mail échoue.

Correction : N’attendez pas l’e‑mail de récupération. Forcez un thème par défaut ; puis vérifiez le mail et le mode de récupération plus tard.

3) Symptom: 502/504 from proxy, intermittent availability

Cause racine : Le thème déclenche une exécution lente (boucle infinie, requêtes lourdes), épuisant les workers PHP-FPM.

Correction : Basculez vers le thème par défaut et observez la stabilisation de PHP-FPM. Ensuite profilez le thème en staging ; envisagez le slowlog.

4) Symptom: frontend works but /wp-admin/ is broken

Cause racine : L’admin charge des chemins de code différents ; le thème hooke dans l’admin ou charge des assets cassés.

Correction : Basculez quand même le thème. Si l’admin reste cassé, désactivez les MU-plugins ou suspectez un conflit de plugin — pas seulement le thème.

5) Symptom: after switching, site loads but layout is mangled

Cause racine : Widgets/paramètres du customizer et shortcodes spécifiques au thème ne se traduisent pas vers le thème par défaut.

Correction : Acceptez‑le temporairement. Votre objectif est de restaurer le service. Planifiez un rollback contrôlé du thème ou une réparation.

6) Symptom: you updated template/stylesheet but nothing changed

Cause racine : Mauvais préfixe de table, mauvaise base, mismatch d’ID de blog multisite, ou cache objet servant des options obsolètes.

Correction : Confirmez table_prefix, confirmez le nom de la base, et en multisite confirmez wp_<blogid>_options. Videz le cache objet si utilisé.

7) Symptom: theme directory exists but WordPress says it’s missing

Cause racine : Permissions/ownership, mismatch de casse, ou symlink/artefact de déploiement.

Correction : Vérifiez les permissions et les noms réels de répertoires. Normalisez la casse et la propriété ; assurez‑vous que l’utilisateur PHP peut lire.

8) Symptom: switching theme causes immediate redirect loops

Cause racine : Le thème ou un plugin impose des URL canoniques ou HTTPS incorrectement ; les caches amplifient le phénomène.

Correction : Vérifiez les options siteurl et home, contrôlez les en‑têtes proxy, et purgez les caches. Le changement de thème est nécessaire mais peut ne pas suffire.

Trois mini-histoires d’entreprise du terrain

Incident causé par une mauvaise hypothèse : « C’est juste un thème, qu’est-ce que ça peut faire ? »

Une entreprise de taille moyenne faisait tourner un site marketing WordPress sur une stack assez standard : Nginx, PHP-FPM, MariaDB. L’équipe marketing a acheté un thème premium et a poussé une « petite mise à jour » juste avant le lancement d’une campagne. Personne n’attendait de drame car, dans leur esprit, les thèmes étaient « CSS et quelques templates ».

La mise à jour embarquait une nouvelle librairie PHP et commençait à appeler des fonctions disponibles uniquement dans une version mineure PHP plus récente. La production était une version en retard parce que l’équipe ops coordonnait une fenêtre de montée de version plus large avec plusieurs applications non liées. Le thème n’a pas échoué gracieusement ; il a lancé un fatal pendant l’initialisation et a mis hors service le frontend et wp-admin.

La première réponse a été classique : redémarrer PHP-FPM, redémarrer Nginx, purger le cache. Ça a fait fluctuer les choses mais n’a rien réparé. Le site revenait brièvement parce que des pages en cache étaient servies, puis s’effondrait à nouveau quand des URLs non mises en cache atteignaient PHP. La confusion a suivi, parce que différentes personnes voyaient des comportements différents selon les pages consultées.

La solution finale a été simple : éditer wp_options pour activer un thème Twenty par défaut. Le service est revenu immédiatement. Ce n’est qu’ensuite que l’équipe a remarqué que la mise à jour du thème incluait aussi une fonctionnalité d’auto‑mise à jour qui avait réécrit certains assets empaquetés lors du déploiement, laissant la release à moitié mise à jour.

Par la suite, ils ont changé de processus : les mises à jour de thème exigent une validation en staging contre la version PHP de production actuelle, pas ce que le vendeur du thème a testé la semaine précédente. Aussi : le thème par défaut reste installé pour toujours. La cause racine n’était pas « thème mauvais ». C’était l’hypothèse erronée que les thèmes sont inoffensifs.

Optimisation qui s’est retournée contre eux : le cache qui cache la vérité

Un site d’entreprise avait un cache agressif : un reverse proxy, un plugin de cache et un CDN. C’était rapide, et tout le monde s’en attribuait le mérite. Puis une release d’un thème personnalisé a introduit une erreur fatale sur un template de page spécifique utilisé par la page d’accueil.

Pour certains utilisateurs, le site semblait correct parce que le CDN avait encore la page d’accueil en cache. Pour d’autres, surtout ceux qui tapaient un edge froid ou un chemin de locale différent, l’origine était contactée et retournait un 500. En interne, les ingénieurs se sont divisés en deux camps : « c’est OK » et « c’est en panne », ce qui est une excellente façon de perdre une heure.

Pendant ce temps, le monitoring était trompeur parce que l’endpoint de health check était une URL statique restée mise en cache. Le tableau de bord restait vert alors que les métriques de revenu partaient en vrille. Le cache n’a pas causé le bug, mais il a rendu l’incident plus difficile à voir, plus difficile à reproduire et plus difficile à croire.

La correction, encore une fois, fut la méthode ennuyeuse : basculer vers un thème par défaut via mise à jour DB, purger les caches dans le bon ordre (origine d’abord, puis CDN), et ajuster temporairement le monitoring pour bypasser le cache. Ensuite, ils ont modifié les health checks pour inclure une requête non mise en cache avec headers anti-cache et pour valider la joignabilité de l’admin séparément.

Le cache n’est pas le méchant. Mais si votre cache peut vous rendre aveugle, ce n’est pas une optimisation ; c’est un risque qui porte un badge performance.

Pratique ennuyeuse mais correcte qui a sauvé la mise : thème par défaut + rollback répété

Une organisation globale utilisait WordPress comme partie d’une plateforme de contenu plus large. Rien de fancy : hôtes durcis, gestion de configuration, releases prévisibles. Leur runbook pour les changements de thème semblait presque comiquement strict pour « un site CMS ».

Ils gardaient toujours deux thèmes Twenty par défaut installés. Ils avaient toujours WP-CLI disponible sur l’hôte. Ils avaient un snippet SQL pré-écrit dans le runbook pour basculer template et stylesheet. Et ils avaient une politique : les releases de thème avaient lieu en heures ouvrées avec une personne on-call pouvant SSHer et effectuer le rollback.

Un jour, un thème enfant a cassé parce que le nom du répertoire du thème parent avait changé lors d’un refactor de déploiement. C’était le genre d’erreur qui semble stupide après coup et facile à faire pendant un nettoyage. L’admin est mort instantanément. Le frontend renvoyait des 500 sur les pages non mises en cache.

L’ingénieur on-call a suivi le runbook : confirmer le fatal, définir les deux options sur twentytwentyfour, purger le cache proxy et annoncer le service restauré. La perturbation totale a été courte. Le postmortem a été tout aussi ennuyeux : ajouter une vérification de déploiement vérifiant que le répertoire du thème actif existe et que le parent du thème enfant est présent.

Ce n’étaient pas des exploits héroïques. C’était de la répétition. En opérations, l’ennuyeux est souvent la forme la plus élevée de compétence.

FAQ

1) Quelles valeurs de la base contrôlent réellement le thème actif ?

template et stylesheet dans la table d’options. En général wp_options, sauf si le préfixe de table diffère ou si vous êtes en multisite.

2) Sur quoi dois‑je définir template et stylesheet ?

Définissez les deux sur le nom du répertoire d’un thème connu et fonctionnel sous wp-content/themes, par exemple twentytwentyfour. Nom du répertoire, pas le nom affiché du thème.

3) Puis‑je réparer cela en supprimant le thème ?

Vous pouvez, mais renommer est plus sûr. Supprimer détruit des preuves et rend le rollback plus difficile. Renommez le dossier en theme-name.disabled et basculez explicitement via la DB ensuite.

4) WP-CLI plante avec une erreur fatale. WP-CLI est‑il inutile ici ?

WP-CLI dépend du bootstrap WordPress. Si le thème actif plante pendant le bootstrap, WP-CLI peut aussi planter. C’est là que l’édition de la base brille.

5) J’ai basculé les thèmes dans la DB mais le site affiche encore la page cassée. Pourquoi ?

Cache. Purgez le cache serveur, le cache plugin, le reverse proxy et le CDN selon le cas. Pensez aussi au cache objet (Redis/Memcached) qui garde des options obsolètes.

6) Basculer vers un thème par défaut va‑t‑il supprimer mon contenu ?

Non. Les posts et pages restent dans la base. Mais votre présentation peut changer drastiquement : menus, widgets et options de thème peuvent ne pas se traduire.

7) Et si aucun thème Twenty par défaut n’est installé et que l’admin est down ?

Uploadez un thème par défaut dans wp-content/themes depuis une source de confiance via SCP/SFTP ou votre mécanisme de déploiement. Puis définissez template/stylesheet sur ce nom de répertoire.

8) Comment ça marche en multisite ?

Chaque site a sa propre table d’options (par ex., wp_2_options). Changez les options de thème pour l’ID de blog affecté. Assurez‑vous aussi que le thème cible est activé réseau.

9) Un plugin pourrait‑il être le vrai problème plutôt que le thème ?

Oui. Mais si les logs pointent des fichiers de thème, basculez d’abord le thème pour restaurer le service. Si le problème persiste après la bascule, commencez à désactiver les plugins (idéalement via WP-CLI ou la base) de façon systématique.

10) Dois‑je aussi mettre à jour les options theme_mods_* ?

En général non pour la récupération. Elles stockent les réglages du customizer pour un thème spécifique. Laissez‑les tranquilles jusqu’à stabilisation et investigation des nettoyages ou reconfigurations de données.

Conclusion : prochaines étapes pour prévenir la récidive

La manière la plus rapide de sortir d’une panne causée par un thème est d’arrêter d’essayer de « réparer le thème » pendant que vos utilisateurs regardent la page d’erreur. Basculez vers un thème par défaut. Restaurez le service. Puis déboguez avec un esprit clair.

Faites ceci ensuite, dans l’ordre

1. Verrouillez la récupération : vérifiez que template/stylesheet pointent vers un thème par défaut et que le répertoire existe sur le disque.
2. Capturez les preuves : enregistrez la trace d’erreur fatale et la version exacte du thème qui l’a causée.
3. Reproduisez en sécurité : testez le thème cassé en staging avec la même version PHP et les mêmes plugins.
4. Décidez de l’action long terme : rollback du thème, patch du thème, ou remplacement. Ne négociez pas avec un thème qui prend la production en otage.
5. Ajoutez des mesures préventives : gardez un thème par défaut installé, ajoutez un contrôle de déploiement pour l’existence des répertoires de thèmes, et mettez en place des health checks conscients du cache.

Si vous ne faites rien d’autre, faites ceci : gardez un thème Twenty par défaut installé pour toujours. C’est une assurance bon marché et, contrairement à la plupart des assurances, elle rapporte quand vous en avez besoin.