# 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.

- Source canonique : [https://allaux.fr/guides/activer-mode-debug-wordpress](https://allaux.fr/guides/activer-mode-debug-wordpress)
- Langue : FR
- Dernière mise à jour : 2026-07-26

## Réponse directe

> Ajoutez ou modifiez trois constantes dans wp-config.php : WP_DEBUG à true, WP_DEBUG_LOG à true, et WP_DEBUG_DISPLAY à false. Les erreurs s’écrivent alors dans wp-content/debug.log sans jamais s’afficher publiquement.

## wp-config.php

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

## Activer le mode debug sans exposer le site

1. **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.
2. **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. */.
3. **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.
4. **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.
5. **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.
6. **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.

## Un réglage à revoir après chaque intervention

> Si un prestataire ou une extension a modifié wp-config.php par le passé, il arrive que WP_DEBUG soit resté actif à l’écran sans que personne ne s’en aperçoive. Un contrôle rapide de ce fichier fait partie des vérifications de routine sur une boutique reprise en gestion, au même titre que la version de PHP ou l’état des sauvegardes.

## FAQ

### Le mode debug peut-il aggraver l’erreur critique ?

Non, il ne modifie aucune donnée ni aucun fichier autre que le journal. Il change uniquement la façon dont WordPress traite et affiche ses propres erreurs.

### wp-config.php n’existe pas ou je ne le trouve pas, que faire ?

Ce fichier existe sur toute installation WordPress fonctionnelle, à la racine du site. S’il est introuvable, il est possible que l’installation soit incomplète ou que l’accès FTP pointe vers le mauvais dossier.

### Le débogueur affiche plusieurs erreurs différentes, laquelle traiter en premier ?

En général la première erreur chronologique dans le journal : les suivantes sont souvent des conséquences en cascade de la première, par exemple un plugin qui échoue à se charger puis d’autres qui dépendent de lui.

### Faut-il activer le mode debug sur un site multisite WordPress ?

Oui, la méthode est identique : les constantes se déclarent dans le même wp-config.php partagé par l’ensemble du réseau de sites.

### Existe-t-il un outil plus complet que debug.log pour diagnostiquer WordPress ?

L’extension Query Monitor ajoute une barre de débogage directement dans l’administration et le front, avec le détail des requêtes SQL exécutées, les hooks déclenchés et les extensions responsables de chaque ralentissement ou erreur, en complément de WP_DEBUG.