Écran blanc WordPress : réactiver le mode debug pour voir l'erreur

Q: Que faire si mon site WordPress affiche une page blanche ?

Activer le mode debug via wp-config.php pour faire apparaître le message d'erreur PHP, puis désactiver les extensions une par une via FTP si le tableau de bord est inaccessible. Le fichier wp-content/debug.log conserve la trace de l'erreur même quand l'écran reste vide.

Q: Comment puis-je déboguer WordPress ?

Placer define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true); dans wp-config.php. Chaque erreur, avertissement ou notice PHP s'enregistre alors dans debug.log. La page Debugging in WordPress du manuel officiel détaille les constantes disponibles et leur effet.

Un écran blanc WordPress masque toute information sur l'erreur tant que le mode debug reste désactivé

À la une

L’écran blanc de la mort WordPress masque toute information utile : le serveur renvoie une page vide, sans message d’erreur ni code HTTP exploitable. Activer la constante WP_DEBUG dans le fichier wp-config.php suffit dans la majorité des cas à faire apparaître le nom du fichier fautif, le type d’erreur PHP et le numéro de ligne, ce qui transforme un blocage opaque en diagnostic lisible.

Ce comportement par défaut vient d’un choix de sécurité : la documentation officielle de WordPress recommande de désactiver l’affichage des erreurs en production pour ne pas exposer de chemins de fichiers ou de noms de tables aux visiteurs. Le revers, c’est qu’un conflit PHP passe alors totalement inaperçu côté navigateur.

Sommaire

Trois lignes dans wp-config.php pour rendre l’erreur visible
Conflit d’extension ou de thème : identifier le coupable sans accès à l’admin
Limite mémoire PHP dépassée : le cas le plus fréquent après une mise à jour
Que faire si le debug n’affiche rien du tout
Questions fréquentes

Trois lignes dans wp-config.php pour rendre l’erreur visible

Le fichier wp-config.php, situé à la racine de l’installation WordPress, contient une ligne define('WP_DEBUG', false); qu’il faut modifier. L’opération se fait par FTP, par le gestionnaire de fichiers de l’hébergeur ou en SSH. Voici les trois constantes à placer juste avant le commentaire /* That's all, stop editing! */ :

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

WP_DEBUG active le mode débogage. WP_DEBUG_LOG écrit chaque erreur dans le fichier wp-content/debug.log, consultable même si le navigateur reste blanc. WP_DEBUG_DISPLAY force l’affichage à l’écran. Pour un site en ligne visité par des utilisateurs, mieux vaut passer WP_DEBUG_DISPLAY à false et lire uniquement le fichier debug.log, afin de ne pas exposer les chemins serveur. Les réglages utiles de wp-config.php vont bien au-delà du debug, on y revient dans un article dédié.

Une fois le mode debug activé, recharger la page blanche fait apparaître un message du type Fatal error: Uncaught Error: Call to undefined function suivi du chemin complet du fichier PHP concerné. Ce chemin indique s’il s’agit d’une extension, du thème actif ou du cœur de WordPress.

Conflit d’extension ou de thème : identifier le coupable sans accès à l’admin

Si le message pointe vers le dossier wp-content/plugins/, renommer le dossier de l’extension incriminée (par exemple mon-plugin en mon-plugin-off) désactive immédiatement cette extension. Le site redevient accessible, ce qui confirme la responsabilité du plugin. Quand le message d’erreur est absent ou ambigu, renommer le dossier plugins entier en plugins-off désactive toutes les extensions d’un coup. Si le site réapparaît, il reste à les réactiver une par une pour isoler celle qui pose problème.

La même logique s’applique aux thèmes. Renommer le dossier du thème actif dans wp-content/themes/ force WordPress à basculer sur un thème par défaut (Twenty Twenty-Four ou le dernier thème installé par le cœur). Si l’écran blanc disparaît, le thème contient le code fautif. Il est alors prudent de travailler avec un thème enfant pour ne pas perdre les personnalisations à la prochaine correction.

Avant de supprimer quoi que ce soit, une sauvegarde complète (fichiers et base de données) permet de revenir en arrière si la manipulation aggrave la situation.

Voir aussi wp-config.php : les réglages utiles que peu de gens activent

Limite mémoire PHP dépassée : le cas le plus fréquent après une mise à jour

Le message Fatal error: Allowed memory size of 67108864 bytes exhausted signale que PHP a atteint sa limite de mémoire (ici 64 Mo). WordPress recommande un minimum de 128 Mo pour le back-office et 256 Mo pour les sites utilisant WooCommerce ou des constructeurs de pages. Deux endroits permettent de relever cette valeur.

Dans wp-config.php :

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

Cette directive ne fonctionne que si l’hébergeur autorise une valeur égale ou supérieure dans sa configuration PHP. Sur un hébergement mutualisé, la limite imposée par le serveur prime. Il faut alors vérifier le php.ini ou le panneau de l’hébergeur pour ajuster memory_limit. La documentation PHP officielle détaille le fonctionnement de cette directive.

Si la consommation mémoire a bondi après l’ajout ou la mise à jour d’une extension, c’est souvent le signe d’un plugin mal optimisé ou redondant. Réduire le nombre d’extensions actives reste le levier le plus durable.

Que faire si le debug n’affiche rien du tout

Il arrive que la page reste blanche même avec WP_DEBUG activé. Plusieurs pistes expliquent ce silence.

Le cache serveur ou applicatif sert une version figée de la page. Vider le cache de l’hébergeur (Varnish, LiteSpeed Cache, OPcache) force le serveur à exécuter réellement le code PHP. Un plugin de cache côté WordPress peut aussi masquer l’erreur : le renommer via FTP, comme vu plus haut, règle ce cas.

Une erreur de syntaxe dans wp-config.php lui-même (guillemet manquant, point-virgule oublié) empêche PHP de démarrer. Le fichier debug.log n’est alors jamais créé. Vérifier la syntaxe du fichier avec un éditeur qui colore le code PHP permet de repérer l’erreur avant même de recharger la page.

Si le serveur renvoie en réalité une erreur 500 (visible dans l’onglet Réseau des outils développeur du navigateur), le problème se situe au niveau du serveur web, pas de WordPress. Les logs d’erreur Apache ou Nginx, accessibles depuis le panneau de l’hébergeur, contiennent alors l’information manquante.

Tester la manipulation sur un environnement de préproduction évite d’exposer les visiteurs à une page cassée pendant le diagnostic.

À retenir

Activer WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY dans wp-config.php avant toute autre manipulation.
Lire le chemin indiqué dans le message d’erreur pour savoir si le problème vient d’un plugin, du thème ou du cœur.
Renommer les dossiers d’extensions ou de thème par FTP quand l’administration est inaccessible.
Vérifier la limite memory_limit de PHP si l’erreur mentionne « memory size exhausted ».
Remettre WP_DEBUG à false une fois le problème résolu pour ne pas ralentir le site ni exposer des informations techniques.

Questions fréquentes

Que faire si mon site WordPress affiche une page blanche ?

Activer le mode debug via wp-config.php pour faire apparaître le message d’erreur PHP, puis désactiver les extensions une par une via FTP si le tableau de bord est inaccessible. Le fichier wp-content/debug.log conserve la trace de l’erreur même quand l’écran reste vide.

Comment puis-je déboguer WordPress ?

Placer define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true); dans wp-config.php. Chaque erreur, avertissement ou notice PHP s’enregistre alors dans debug.log. La page Debugging in WordPress du manuel officiel détaille les constantes disponibles et leur effet.

Comment puis-je corriger un bug WordPress ?

Identifier d’abord la source (extension, thème, cœur) grâce au debug, puis appliquer la correction adaptée : mise à jour, remplacement du fichier concerné ou augmentation de la mémoire PHP. En cas de doute, restaurer une sauvegarde antérieure au bug reste la voie la plus sûre.

Que faire si WordPress est en panne ?

Vérifier que le serveur répond (code HTTP dans les outils développeur du navigateur). Si le serveur renvoie un code 500, consulter les logs Apache ou Nginx. Si la page est blanche sans code d’erreur HTTP, suivre la procédure de debug décrite dans cet article. En dernier recours, contacter le support de l’hébergeur avec le contenu du fichier debug.log et les logs serveur.

Damien Roux

Damien Roux est l'hébergement web. de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress