Comment activer le mode debug sur WordPress
WP_DEBUG révèle le fichier, la ligne et le message exact derrière une « erreur critique sur ce site » ou un écran blanc. Bien réglé, il écrit ces informations dans un journal sans jamais les montrer aux visiteurs.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Activer le mode debug sans exposer le site
-
Accéder aux fichiers du site
wp-config.php se trouve à la racine de l’installation WordPress, au même niveau que les dossiers wp-content, wp-admin et wp-includes. Un accès FTP, SFTP ou au gestionnaire de fichiers de l’hébergeur est nécessaire.
-
Repérer la ligne à modifier
Cherchez la ligne define('WP_DEBUG', false); Si elle n’existe pas, ajoutez les trois constantes juste avant la ligne /* That's all, stop editing! Happy publishing. */.
-
Séparer affichage et journalisation
WP_DEBUG_DISPLAY à false empêche les messages d’apparaître sur les pages publiques. WP_DEBUG_LOG à true les écrit à la place dans un fichier, ce qui est la combinaison à utiliser sur un site en production.
-
Reproduire le problème
Rechargez la page ou l’action qui déclenche l’erreur pour que WordPress consigne l’événement dans le journal.
-
Lire wp-content/debug.log
Ce fichier liste les erreurs PHP dans l’ordre chronologique, avec le fichier, la ligne et souvent le plugin ou le thème en cause.
-
Revenir en mode normal
Une fois la cause identifiée, remettez WP_DEBUG et WP_DEBUG_LOG à false, et supprimez le fichier debug.log s’il contient des informations sensibles.
Pourquoi séparer affichage et journalisation
La configuration par défaut de WordPress cache toutes les erreurs derrière le message générique « Une erreur critique s’est produite sur ce site », introduit depuis WordPress 5.2 pour éviter d’exposer du code aux visiteurs. C’est une bonne protection, mais elle rend le diagnostic impossible sans accès aux fichiers.
Activer WP_DEBUG seul suffit à faire apparaître les erreurs directement sur la page, ce qui est pratique en local mais dangereux en production : n’importe quel visiteur verrait alors les mêmes messages, avec parfois des chemins de fichiers ou des noms de fonctions internes. La combinaison WP_DEBUG_LOG à true et WP_DEBUG_DISPLAY à false résout ce compromis : les erreurs continuent d’être enregistrées, mais seul quelqu’un ayant accès aux fichiers du serveur peut les consulter.
Sur une boutique WooCommerce, ce réglage se complète par la lecture des journaux propres à l’extension, accessibles depuis WooCommerce, Statut, Journaux dans l’administration, qui consignent séparément les erreurs de paiement, de webhook et de synchronisation de stock.
Les erreurs courantes
- Laisser WP_DEBUG_DISPLAY à true sur un site en ligne : les erreurs deviennent visibles par tous les visiteurs, y compris des informations techniques exploitables.
- Oublier que le fichier debug.log grossit indéfiniment une fois activé : sur un site qui génère beaucoup de notices PHP, il peut atteindre plusieurs centaines de mégaoctets en quelques semaines.
- Chercher wp-content/debug.log alors qu’il n’existe pas encore : WordPress ne le crée qu’au moment où une première erreur se produit après l’activation.
- Modifier wp-config.php sans sauvegarde préalable : une erreur de syntaxe dans ce fichier rend le site entièrement inaccessible, y compris wp-admin.
Questions fréquentes
Le mode debug peut-il aggraver l’erreur critique ?
wp-config.php n’existe pas ou je ne le trouve pas, que faire ?
Le débogueur affiche plusieurs erreurs différentes, laquelle traiter en premier ?
Faut-il activer le mode debug sur un site multisite WordPress ?
Existe-t-il un outil plus complet que debug.log pour diagnostiquer WordPress ?
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.