WP_DEBUG : L’outil qui vous aide à diagnostiquer vos problèmes WordPress

Quand un site WordPress a un problème, il n’y a pas toujours de message d’erreur. On peut avoir une page blanche, une simple séquence indiquant qu’il y a une erreur 500 ou tout bêtement qu’il y a une erreur critique. Sans pour autant qu’on puisse en savoir plus. En somme, on a des symptômes, mais pas la cause du problème.

Ce qui est frustrant et déstabilisant. Parce que le site est souvent partiellement planté ou pire encore, complètement hors service et inaccessible.

Bref, c’est comme avoir de la fièvre sans avoir le rhume ni de douleurs. On sait qu’il y a quelque chose qui cloche, mais on ne se pas où ni quoi.

C’est à ce titre que la fonctionnalité WP Debug devient un super allié pour nous aider. C’est l’outil qui tel un détective chevronné, va vous guider (vraiment beaucoup) dans votre enquête pour trouver le coupable du problème qui touche votre site web WordPress. Et ainsi résoudre ce problème !

Aussi, je propose aujourd’hui de découvrir avec un vrai cas d’un site dépanné en cette début septembre 2026, combien le WP DEBUG peut aider !

Le cas du site WordPress avec page blanche et erreur http 500

J’ai récemment eu un contact pour dépanner un site WordPress relativement simple. Un site vitrine classique sans e-commerce, sans grosse fonctionnalité lourde.

Le site en frontal pour les internautes affichait un message avec une erreur http 500 sur un fond blanc massif. Comme si le domaine n’avait pas été renouvelé. Comme si le problème ne venait pas de WordPress.

Aussi, pour justement en savoir plus sur ce qui se passe, j’ai commencé par activer et paramétrer l’outil pour afficher le WP DEBUG.

Les personnes qui l’utilisent déjà savent comment faire 🙂 Pour les autres voici comment procéder :

Activer le WP Debug, mode d’emploi

Le WP debug n’est pas un outil à proprement parler. Ce sont des lignes à ajouter à une déjà présente dans un fichier pilier de WordPress, à savoir le fichier wp-config.php. Le fichier wp-config.php se trouve à la racine de votre site sur une installation WordPress classique. Donc sous le répertoire www/. Voici une capture d’un WP-config.php :

Quand vous avez localisé ce fameux fichier wp-config, ouvrez le, et cherchez cette séquence :

/* C'est tout, ne touchez pas à ce qui suit ! Bonne publication. */

C’est justement sous cette séquence que vous verrez très probablement ce qui suit :

define( 'WP_DEBUG', false );

Pour activer le WP DEBUG, il suffit de remplacer false par true. Ce qui en français signifie remplacer faux par vrai. Et dans le cas de WordPress, cela veut dire qu’on remplace le mode désactivé par le mode activé 🙂

Et puisqu’on veut dépanner un site WordPress tout cassé, on va mettre true, mais aussi ajouter des lignes en plus comme suit :

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

Toutes les lignes doivent être collées ainsi. N’ajoutez pas d’espace, de guillemets ou de parenthèse.

WP DEBUG, ce que signifient les lignes de l’outil

Vous pourriez tout à fait juste coller ces lignes et passer à la suite. Mais l’idée est de comprendre ce que vous ajoutez.

Aussi voici à quoi chacune des trois lignes correspond :

• La première ligne WP DEBUG si vous la passez en « true » sert à activer l’outil qui sert à débuguer WordPress.
• La seconde ligne sert à déclencher la journalisation des messages d’erreur. En gros, ça va générer et créer un fichier appelé debug log sur votre serveur. Sous le répertoire/dossier WP CONTENT. En ouvrant ce fichier, vous verrez tout ce qui peut correspondrre à des erreurs et bugs sur votre site. Et pas toujours avec des symptômes visibles d’ailleurs !
• La troisième ligne va servir à afficher les messages d’erreur qui vous aident à comprendre pourquoi votre site plante. Sur le tableau de bord et aussi sur le frontal (=ce que voient les internautes).

Le cas de l’erreur 500 avec page blanche

J’aurais pu faire ce que beaucoup font et qui est recommandé en cas de dépannage et commencer à renommer les répertoires des extensions/plugins WordPress. Mais vu la page blanche, j’ai senti que ça ne venait pas de quelque chose de standard. D’où l’idée de déclencher le détective wp debug.

Avant d’aller voir ce qu’affichait le wp debug ou même d’aller le fichier de journalisation de WP DEBUG, je suis allée voir quelle était la version de WordPress sur le serveur.

Pour voir la version de WordPress, quand vous n’avez pas accès au tableau de bord parce qu’i lest planté, vous pouvez allez via ce chemin vérifier dans le fichier version.php qui est disponible dans le dossier /wp-includes, comme suit :

Ouvrez le fichier et regardez comme suit :

Notre WordPress cassé est donc a priori en version 7.0.4.

Bref, ensuite je vais regarder ce que dit l’outil WP DEBUG dans ses logs, à savoir donc la version texte avec date et heures des erreurs qu’il détecte :

PHP Fatal error: Uncaught Error: Class "WP_HTML_Tag_Processor" not found

Pour beaucoup, ce message ne va pas beaucoup aider, mais la plupart du temps, vous aurez des messages bien plus précis. Vous indiquant que tel plugin nécessite telle version de PHP ou n’est pas compatible avec votre version PHP actuelle.

Dans notre cas, il s’agit d’une erreur causée par l’absence d’une classe. Et cette classe, elle fait partie d’une version récente de WordPress. Plus récente encore que la version 7.0.4.

Si je me rends sur la page de connexion au tableau de bord, une autre erreur apparaît grâce à la fonction d’affichage du débug :

Fatal error: Uncaught Error: Call to undefined function wp_get_toggletip()

Ailleurs, je vois aussi ce qui suit :

Notice: La fonction WP_Styles::add a été appelée de façon incorrecte...

Bref, tout ça sent la mise à jour de WordPress faite à distance. C’est à dire la mise à jour forcée qui déclenche notamment des emails que vous recevez sûrement quelques fois par an. Avec pour objet :

Votre site a été mis à jour vers WordPress 7.1

Cela peut aussi si vous laisser des mises à jour automatiques se faire toutes seules. Sachez que pour les extensions et les thèmes, vous pouvez désactiver les mises à jour automatiques. Pour rester maîtresse/maître de vos MAJ.

Bref, une version de WordPress pas complètement faite, ça peut casser un site. Et ça, pour le savoir juste avec un erreur 500 en frontal, ce n’est pas simple. Même quand on a l’habitude !

Le détective WP DEBUG a donc largement contribué à trouver le coupable du gros plantage de ce site.

Résoudre le problème de mise à jour incomplète

Pour la petite histoire et donc la chute, dans tel cas, je vais télécharger la dernière version de WordPress sur le site officiel français. Ensuite je le dézippe et je le téléverse sur le site via un outil comme Filezilla.

Et là, plus de message d’erreur !

Désactiver le wp debug

Une fois que vous avez tout réparé sur votre site, on ne peut évidemment pas laisser l’outil en route. On retourne donc dans le fichier wp-config.php et on remet tout comme avant. Remplacez simplement vos 3 lignes par l’ancienne comme suit, enregistrez et sortez du fichier :

define( 'WP_DEBUG', false );

Ainsi, le détective peut se rendormir pour on l’espère, ne pas vous aider avant longtemps 🙂 Cela voudra dire que le site ne plante pas !

Un peu d’histoire

La fonctionnalité WP DEBUG est très ancienne sur WordPress. D’ailleurs, un autre mode très utile appelé le mode RECOVERY est bien plus récent. Le « Recovery mode » date en effet de février 2019 et de la version 5.2 de WordPress. Ce mode sert à accéder à votre site même quand dans de nombreux cas, il est cassé. Vous recevez alors un email en tant qu’administrateur WordPress, avec un lien de récupération.

Ce mode de récupération (dans la version française) permet notamment d’accéder à un WordPress pour pas mal de cas d’erreur critiques.

Les deux « modes » sont différents et ont des anciennetés différentes dans WordPress. Mais ils restent très complémentaires.

Un peu de culture WordPress

WP DEBUG est ce qu’on appelle une constante, dans WordPress. Le mode WP DEBUG sert à vous afficher des erreurs de type PHP ou encore des absences de fichiers sur l’installation WordPress concernée. Lorsque les logs sont activés, l’outil à savoir la constante, va enregistrer les erreurs avec leurs date et heures de survenance, dans le fichier appelé debug.log.

En voici l’image :

En bref

On pense parfois qu’un site est piraté ou planté et qu’il va être long et complexe de le dépanner. Parfois oui, même en toute transparence, c’est loin d’être souvent le cas. Cela reste à la marge. Et par ailleurs, des outils comme le WP DEBUG sont justement là pour aider au diagnostic. Autant en profiter !