Objectif
Rétablir rapidement un site WordPress bloqué par une erreur fatale tout en identifiant le composant responsable, en utilisant Recovery Mode ou une désactivation ciblée, en collectant le message exact dans les logs et en revenant à une version compatible sans laisser le debug public actif.
Prérequis
- Accès wp-admin Recovery Mode si l’e-mail WordPress est disponible, ou accès SSH/SFTP/gestionnaire de fichiers.
- Sauvegarde récente des fichiers et base avant modification importante.
- Heure de début et dernier changement : plugin, thème, PHP, WordPress ou code personnalisé.
- Accès aux logs PHP/hébergement ou possibilité d’activer temporairement WP_DEBUG_LOG.
- Version PHP et WordPress connues.
Procédure pas à pas
Identifier le dernier changement
Demandez ce qui a changé juste avant l’erreur : activation, mise à jour, snippet, thème, version PHP ou restauration. Testez front et /wp-admin séparément et notez le texte exact « erreur critique » ou le code HTTP. Cette chronologie réduit fortement le périmètre.
- Le symptôme, l’heure et le changement probable sont documentés.
Utiliser Recovery Mode si disponible
Depuis WordPress 5.2, le gestionnaire d’erreurs fatales peut envoyer un lien Recovery Mode à l’adresse administrateur. Dans ce mode, l’extension ou le thème fautif peut être mis en pause pour cette session. Utilisez-le pour récupérer wp-admin et confirmer le composant, sans considérer la pause comme une résolution définitive.
- wp-admin redevient accessible ou la méthode Recovery Mode est écartée.
Consulter les logs avant de désactiver
Lisez le log PHP de l’hébergeur et les événements à l’heure précise. Si nécessaire, activez temporairement WP_DEBUG et WP_DEBUG_LOG avec WP_DEBUG_DISPLAY=false. Reproduisez une seule fois l’erreur puis relevez type, fichier, ligne et stack trace utile.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );- Le fichier et le composant responsables sont identifiés ou le diagnostic est suffisamment réduit.
Désactiver uniquement le plugin suspect
Si wp-admin est inaccessible, utilisez WP-CLI ou renommez le dossier du plugin suspect. Avec WP-CLI, vous pouvez charger WordPress en sautant des plugins si nécessaire. Évitez une désactivation globale tant qu’un composant précis est suspect, car cela complique la reproduction.
wp plugin deactivate <PLUGIN>wp plugin status <PLUGIN>- Le site revient sans l’extension suspecte et l’erreur fatale disparaît.
Tester le thème si aucun plugin n’est responsable
Si la stack trace pointe vers le thème ou si les plugins sont écartés, activez temporairement un thème WordPress
wp theme listwp theme activate <THEME-DE-SECOURS>- Le diagnostic confirme ou écarte le thème.
Vérifier PHP, mémoire et prérequis
Comparez la version PHP aux exigences du plugin/thème et à la version précédente du serveur. Recherchez Allowed memory size exhausted, fonctions supprimées ou TypeError liés à une mise à niveau. N’augmentez pas indéfiniment la mémoire si une boucle applicative la consomme.
php -vwp core versionwp plugin list --update=available- La plateforme respecte les versions supportées du composant retenu.
Vérifier l’intégrité du cœur si nécessaire
Si la stack trace touche wp-admin/wp-includes sans plugin identifiable ou après une mise à jour interrompue, comparez les fichiers cœur aux checksums officiels. Une différence peut signaler corruption ou compromission et doit être traitée avant de réactiver les extensions.
wp core verify-checksums --include-root --version=$(wp core version)- Le cœur est conforme ou les fichiers incohérents sont identifiés.
Appliquer une correction durable
Mettez à jour vers une version compatible, revenez à la version précédente connue saine ou corrigez le code custom dans un environnement de test. Réactivez ensuite le composant et testez les fonctions qu’il fournit. Ne réactivez pas un plugin simplement parce que le front se charge.
- Le composant peut être actif sans reproduire l’erreur.
Désactiver le debug public et surveiller
Remettez WP_DEBUG/WP_DEBUG_LOG selon votre politique de production et gardez WP_DEBUG_DISPLAY désactivé. Purgez le debug.log s’il contient des données sensibles après avoir conservé l’extrait utile. Surveillez les erreurs PHP après remise en ligne et documentez cause/version corrigée.
- Le site et wp-admin fonctionnent sans nouvelle erreur fatale et aucune information de debug n’est exposée.
Validation
La procédure est validée lorsque :
- Le front et wp-admin répondent normalement avec le composant corrigé ou remplacé.
- Le message fatal initial ne réapparaît plus dans les logs.
- La version PHP et les extensions sont compatibles avec la configuration finale.
- WP_DEBUG_DISPLAY est désactivé en production et les logs sensibles sont maîtrisés.
Retour arrière
- Réactiver l’ancienne version du plugin/thème connue saine si la nouvelle correction échoue.
- Revenir à la version PHP précédente uniquement si elle reste supportée et que le changement était bien la cause.
- Restaurer la sauvegarde complète si une mise à jour a modifié la base de manière incompatible.
- Conserver le composant fautif désactivé plutôt que remettre le site en erreur critique.
Dépannage / erreurs fréquentes
- Pas d’e-mail Recovery Mode : passer aux logs/hébergement et vérifier l’adresse admin.
- wp plugin deactivate échoue car WordPress ne charge pas : utiliser –skip-plugins/–skip-themes ou renommer le dossier ciblé.
- Erreur memory exhausted : identifier le plugin/processus avant d’augmenter la limite.
- Le site revient après désactivation mais plante à la réactivation : vérifier version et dépendances du composant.
- Checksums cœur incorrects : réinstaller le cœur de la même version depuis WordPress.org et vérifier une éventuelle compromission.