WP_DEBUG
La constante de WordPress qui active le mode de débogage, c'est-à-dire l'affichage ou l'enregistrement de toutes les erreurs PHP, y compris les simples avertissements, pour diagnostiquer une panne.
Définition
WP_DEBUG est la constante de WordPress qui active le mode de débogage : toutes les erreurs PHP, jusqu’aux simples avertissements, sont affichées ou enregistrées pour diagnostiquer une panne. Elle se règle dans wp-config.php et vaut faux par défaut. Activée seule sur un site en ligne, elle montre les erreurs aux visiteurs : on l’associe donc à un journal protégé, et on la désactive dès le diagnostic posé.
wp-content/debug.log, se trouve dans un dossier accessible depuis le web.Qu’est-ce que WP_DEBUG ?
Un interrupteur, placé dans le fichier de configuration, qui règle le niveau de détail des erreurs PHP.
WordPress est écrit en PHP, et PHP classe ses messages par gravité : les erreurs fatales arrêtent la page, les avertissements et les notices signalent un code fragile qui fonctionne encore. En temps normal, WordPress ne fait remonter que les erreurs graves et les avertissements. Avec define( 'WP_DEBUG', true ); dans wp-config.php, il demande à PHP de tout signaler, notices et fonctions dépréciées comprises.
Le code de WordPress 7.1.3, lu pour cette fiche, ajoute une exception peu connue : si la constante n’est pas définie et que le site est déclaré comme environnement de développement, WP_DEBUG s’active tout seul. Une configuration de préproduction recopiée telle quelle sur le site en ligne peut donc le rallumer sans que personne l’ait écrit.
Quelles constantes accompagnent WP_DEBUG ?
WP_DEBUG décide si l’on débogue, deux autres constantes décident où vont les messages.
| Constante | Valeur par défaut | Ce qu’elle règle |
|---|---|---|
WP_DEBUG | faux, vrai en environnement de développement | Active le signalement de toutes les erreurs PHP |
WP_DEBUG_DISPLAY | vrai | Affiche les erreurs dans les pages, à la vue de tous |
WP_DEBUG_LOG | faux | Écrit les erreurs dans wp-content/debug.log, ou dans le fichier dont on lui donne le chemin |
SCRIPT_DEBUG | faux | Charge les versions non minifiées des scripts et styles de WordPress, sans rapport avec les erreurs PHP |
Les deux constantes d’affichage et de journal n’agissent que si WP_DEBUG est vrai. C’est la ligne la plus souvent mal lue : WP_DEBUG_DISPLAY valant vrai par défaut, activer WP_DEBUG sans rien d’autre affiche les messages d’erreur au milieu des pages, avec les chemins des fichiers sur le serveur. Pour un visiteur, c’est un site qui paraît cassé. Pour un attaquant, c’est une carte du serveur et la liste des extensions installées.
Comment activer WP_DEBUG sur un site en ligne ?
Rarement, brièvement, et toujours sans affichage.
Couper l’affichage
Poser WP_DEBUG_DISPLAY à faux en même temps que WP_DEBUG à vrai, jamais l’un sans l’autre.
Écrire le journal hors du web
Donner à WP_DEBUG_LOG un chemin de fichier situé en dehors du dossier public du site. À défaut, vérifier que debug.log répond bien par un refus quand on l’appelle depuis un navigateur.
Reproduire, lire, éteindre
Reproduire la panne, lire les dernières lignes du journal, puis remettre WP_DEBUG à faux. Le journal grossit à chaque page qui produit une erreur, il ne se vide jamais seul.
Notre position : sur un site en production, la question n’est pas d’activer WP_DEBUG mais de savoir où les erreurs sont déjà écrites. Le plus souvent, l’hébergeur tient un journal PHP sans que WordPress le sache, et c’est par lui qu’il faut commencer. WP_DEBUG reste l’outil de la préproduction, ou du dépannage court face à un écran blanc de la mort quand le mode de récupération ne s’est pas déclenché.
Un journal oublié est une fuite. Il contient les chemins du serveur, les noms des extensions, parfois des fragments de requêtes à la base de données. Un fichier debug.log laissé dans wp-content après un dépannage fait partie de ce qu’un audit de durcissement doit chercher.
Comment lire le fichier debug.log ?
En partant de la fin, et en regroupant ce qui se répète.
Chaque ligne commence par la date et l’heure en temps universel, puis le niveau du message, son texte, le fichier et la ligne en cause. Pour une erreur fatale, PHP ajoute la pile d’appels, c’est-à-dire la suite des fonctions qui ont mené à l’erreur. C’est elle qui désigne l’extension ou le thème fautif quand le message pointe vers un fichier du cœur. On lit le fichier par un accès aux fichiers ou en ligne de commande, en commençant par les dernières lignes, celles qui correspondent à la panne reproduite.
Un journal ancien se lit autrement : on compte les messages par type et par fichier d’origine. Quelques milliers d’avertissements venus d’une même extension disent plus sur l’état d’un site qu’une erreur isolée. L’extension Query Monitor affiche aussi les erreurs PHP de la page en cours dans la barre d’administration, sans écrire de journal : utile en préproduction, elle ne voit que les pages qu’on visite soi-même.
Ce que montre un site réel
Relevé du 14 octobre 2026, en lecture seule, sur un site vitrine WordPress 7.1.3 que nous maintenons, sur un hébergement mutualisé. WP_DEBUG y vaut faux, et aucun debug.log n’existe. Le site n’est pas silencieux pour autant : la configuration PHP de l’hébergeur journalise les erreurs dans un fichier error_log à la racine du site. Il pèse près de 8,8 Mo et compte 64 069 entrées datées depuis mai 2024 : 40 444 en 2024, 21 346 en 2025, 2 279 en 2026. On y trouve 15 erreurs fatales, chacune suivie de sa pile d’appels, dont deux du thème enfant le 4 septembre 2026, et 1 105 erreurs de base de données. Ce fichier répond par une 404 depuis le web, grâce à une règle de l’hébergeur qui bloque ce nom précis. La même règle ne couvre pas un fichier debug.log, et un autre journal déposé dans le dossier des médias par une extension maison est bien servi à quiconque connaît son adresse. Il ne contient ni adresse IP ni courriel, mais la protection tient au nom du fichier, pas à sa nature.
Questions fréquentes
Où se trouve le fichier debug.log ?
Par défaut dans le dossier wp-content, à condition que WP_DEBUG et WP_DEBUG_LOG soient tous deux vrais. Si WP_DEBUG_LOG contient un chemin, le journal est écrit à cet endroit. Sans fichier à ces emplacements, chercher le journal PHP de l’hébergeur, souvent nommé error_log.
WP_DEBUG ralentit-il le site ?
Il ajoute du travail à chaque erreur signalée, et une écriture dans le journal à chaque page qui en produit. Le surcoût dépend donc du nombre d’erreurs du site, nous ne l’avons pas mesuré. C’est surtout un risque d’exposition, ce qui suffit à ne pas le laisser actif.
Faut-il corriger tous les avertissements ?
Non. Un avertissement répété des milliers de fois signale une extension mal écrite ou mal adaptée à la version de PHP, et mérite d’être lu avant une mise à jour. Une notice isolée sans conséquence visible peut attendre. On commence par les erreurs fatales, puis par ce qui se répète.
Puis-je activer WP_DEBUG depuis le tableau de bord ?
WordPress ne le propose pas : la constante se modifie dans wp-config.php, par accès aux fichiers ou avec WP-CLI. Certaines extensions offrent un interrupteur, mais elles écrivent dans le même fichier de configuration, avec les mêmes précautions.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.