« Une erreur critique est survenue sur votre site » : réparer WordPress

« Erreur critique » ou page blanche : la même panne

Une page blanche est le plus souvent une erreur fatale de PHP : un fichier du site a demandé quelque chose d'impossible, et l'exécution s'est arrêtée avant d'afficher quoi que ce soit. Depuis WordPress 5.2, WordPress intercepte ces erreurs : au lieu d'une page vide, il affiche « Une erreur critique est survenue sur votre site. » et envoie un courriel à l'adresse d'administration du site.

La page reste entièrement blanche dans quelques cas : une version de WordPress plus ancienne, une erreur survenue avant le chargement de ce mécanisme, la constante WP_DISABLE_FATAL_ERROR_HANDLER réglée à true, ou une extension de cache qui sert une page vide enregistrée pendant la panne. La méthode qui suit vaut pour tous ces cas.

Trois gestes peuvent attendre d'avoir lu l'erreur : réinstaller WordPress, supprimer des extensions, restaurer une ancienne sauvegarde. Chacun peut effacer des réglages ou des données récentes, alors que le message d'erreur dit en général quel composant désactiver, sans rien perdre.

Le raccourci : le mode de récupération

Quand WordPress intercepte l'erreur, il envoie à l'adresse courriel d'administration du site un message intitulé « [Nom du site] Votre site connaît un problème technique ». Il nomme l'extension ou le thème en cause, et contient un lien qui ouvre l'administration en mode de récupération.

• Dans ce mode, le composant fautif est mis en pause pour vous seul : vos visiteurs voient toujours l'erreur.
• Depuis Extensions ou Apparence > Thèmes, désactivez le composant signalé, puis cliquez sur « Sortir du mode de récupération » dans la barre d'administration.
• Le lien reste valable 24 heures, et WordPress envoie au plus un courriel de ce type par jour. Si le courriel n'arrive pas, regardez dans les courriels indésirables, puis passez à la méthode suivante.

Lire l'erreur : le journal de débogage

Connectez-vous au site en SFTP ou par le gestionnaire de fichiers de votre hébergeur, ouvrez wp-config.php à la racine, et remplacez la ligne define( 'WP_DEBUG', false ); par ces quatre lignes :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Elles se placent au-dessus du commentaire qui clôt la zone modifiable du fichier, /* That's all, stop editing! Happy publishing. */. Rechargez la page en erreur, puis ouvrez wp-content/debug.log. WP_DEBUG_DISPLAY à false garde les messages dans le fichier, hors de la page que voient vos visiteurs.

Si debug.log reste vide ou n'apparaît pas, l'erreur a été consignée par PHP directement : cherchez un fichier error_log à la racine du site ou dans wp-admin, ou la rubrique des journaux d'erreurs dans le panneau de votre hébergeur.

Ce que dit le message, et le geste qui va avec

Une erreur fatale tient en une ligne : le type d'erreur, sa description, puis in suivi du chemin complet du fichier et du numéro de ligne. Le chemin est l'information la plus utile : wp-content/plugins/nom/ désigne une extension, wp-content/themes/nom/ un thème.

define( 'WP_MEMORY_LIMIT', '256M' );

Désactiver le composant en cause sans l'administration

Par SFTP ou le gestionnaire de fichiers

Renommez le dossier de l'extension nommée dans le message, par exemple wp-content/plugins/nom-extension en nom-extension.off. WordPress ne trouve plus l'extension et cesse de la charger ; ses réglages restent enregistrés dans la base de données, et WordPress la désactive à la prochaine ouverture de l'écran des extensions.

Pour un thème, renommer son dossier dans wp-content/themes rend l'administration de nouveau accessible, mais les visiteurs voient une page vide tant qu'aucun thème n'est actif. Ouvrez aussitôt Apparence > Thèmes : WordPress constate que le thème actif est endommagé et revient à un thème par défaut installé.

Avec WP-CLI

wp plugin list --status=active
wp plugin deactivate nom-extension
wp theme list
wp theme activate twentytwentyfive

La première commande garde la liste des extensions actives, utile avant toute désactivation groupée. Si WP-CLI s'arrête lui-même sur l'erreur, ajoutez --skip-plugins --skip-themes à la commande : il se lance alors sans charger les extensions ni le thème. Les extensions du dossier wp-content/mu-plugins se chargent malgré tout ; si l'erreur vient de l'une d'elles, renommez son fichier.

Quand le message ne désigne aucun composant, wp plugin deactivate --all désactive toutes les extensions. Si le site revient, réactivez-les une à une, en rechargeant le site entre chaque : la dernière réactivée avant le retour de l'erreur est la bonne.

Une fois le site revenu

1. Remettez define( 'WP_DEBUG', false ); et retirez WP_DEBUG_LOG de wp-config.php.
2. Supprimez wp-content/debug.log : placé dans un dossier accessible depuis le Web, il peut être lu par n'importe qui et contient des chemins du serveur.
3. Mettez à jour ou remplacez le composant en cause, en lisant son journal des modifications.
4. Videz le cache de l'extension de cache et celui de l'hébergeur, s'il en a un.
5. Pour la prochaine fois : testez les mises à jour sur une copie du site avant de les appliquer en ligne.