Debug WordPress : logs et mode debug

Écran blanc, There has been a critical error, erreur 500 : sur WordPress, ces messages remontent rarement la vraie cause. Le mode debug expose les erreurs PHP sous-jacentes et transforme une recherche à l'aveugle en dépannage méthodique.

Activer le mode debug

Le mode debug se pilote dans wp-config.php, à la racine de votre site. Ouvrez le fichier et repérez la ligne :

/* That's all, stop editing! Happy publishing. */

Juste avant cette ligne, ajoutez :

// Active le debug
define('WP_DEBUG', true);

// Logue les erreurs dans wp-content/debug.log
define('WP_DEBUG_LOG', true);

// N'affiche PAS les erreurs à l'écran (sécurité)
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

// Utilise les versions non minifiées de JS/CSS core
define('SCRIPT_DEBUG', true);

Ou via WP-CLI :

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set SCRIPT_DEBUG true --raw

Lire le log

Le fichier se trouve dans wp-content/debug.log :

tail -f /var/www/vhosts/mon-domaine.fr/httpdocs/wp-content/debug.log

En suivi continu (-f), rechargez votre site dans un autre onglet et observez en temps réel.

Exemples d'erreurs courantes

[23-Apr-2026 10:15:32 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/.../mon-plugin/init.php:42

→ Fatal error. Le plugin mon-plugin essaie d'utiliser une fonction WooCommerce qui n'est pas chargée. WooCommerce est désactivé ou le plugin a oublié de le déclarer en dépendance.

[23-Apr-2026 10:16:02 UTC] PHP Deprecated:  Return type of Some_Class::method() should either be compatible with...

→ Deprecated. Non bloquant. Le code utilise une fonctionnalité dépréciée par PHP 8+. À signaler à l'auteur du plugin, souvent corrigé dans les versions récentes.

[23-Apr-2026 10:17:15 UTC] PHP Notice:  Undefined index: user_id in ...

→ Notice. Mauvaise pratique de code, généralement sans impact. Masque le signal utile, donc à corriger.

Erreur 500 : marche à suivre

Une erreur 500 peut venir de PHP, d'Apache, ou de .htaccess. Dans l'ordre :

1. Activer WP_DEBUG_LOG et regarder le log

Souvent, c'est un plugin incompatible avec la version PHP. Nom du plugin dans la stack trace.

2. Vérifier le .htaccess

cd /var/www/vhosts/mon-domaine.fr/httpdocs
cp .htaccess .htaccess.bak
# Remet les règles WP par défaut
wp rewrite flush --hard

Si le site remonte, votre .htaccess contenait une règle incompatible avec le serveur (module manquant, syntaxe invalide).

3. Augmenter memory_limit

Si le log contient Allowed memory size exhausted, ajoutez dans wp-config.php :

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

Si la limite est plafonnée par PHP côté serveur (valeur inférieure à celle demandée par WordPress), ouvrez un ticket Datacampus pour qu'on remonte la limite PHP globale.

4. Isoler un plugin fautif

La technique universelle : tout désactiver, réactiver un à un.

cd /var/www/vhosts/mon-domaine.fr/httpdocs

# Désactive tous les plugins d'un coup
wp plugin deactivate --all

# Rechargez le site — s'il remonte, c'est un plugin

# Réactivez un par un
wp plugin activate mon-premier-plugin
# testez
wp plugin activate mon-deuxieme-plugin
# testez
# ...

Dès que l'activation casse le site, vous avez votre coupable.

5. Repasser au thème par défaut

wp theme activate twentytwentyfour

Si le site remonte, le thème (ou un hook dans functions.php) est en cause.

Query Monitor

Query Monitor (wordpress.org/plugins/query-monitor) est le couteau suisse du debug WordPress. Une fois installé et activé, une barre apparaît dans l'admin et permet de voir, pour chaque page :

• Toutes les requêtes SQL, leur durée, le plugin qui les a déclenchées.
• Les hooks appelés, dans l'ordre.
• Les scripts et styles chargés.
• Les appels HTTP sortants.
• Les erreurs PHP, notices et warnings.
• Les capabilities vérifiées pour l'utilisateur courant.

Indispensable pour identifier un plugin lent ou une requête qui prend 2 secondes. À désactiver en production (l'activer uniquement le temps du diagnostic, ou en admin sur un compte spécifique).

Mode récupération (WordPress 5.2+)

Depuis WP 5.2, quand une erreur fatale se produit, WordPress :

1. Affiche au visiteur la page There has been a critical error.
2. Envoie un email à admin_email (Réglages → Général) avec un lien Accéder à votre site en mode récupération.

Ce lien vous connecte à l'admin avec le plugin ou le thème fautif isolé. Vous pouvez alors le désactiver proprement, ou corriger le code.

Logs côté serveur

Le log PHP est séparé du debug.log WordPress. Sur Plesk :

• Logs → Error log dans l'interface Plesk.
• En SSH : /var/www/vhosts/mon-domaine.fr/logs/error_log.

Pour une erreur 500 survenue avant même que WordPress se charge (problème .htaccess, module PHP manquant), c'est ici qu'il faut chercher.

Checklist avant de repasser en prod

• WP_DEBUG repassé à false.
• WP_DEBUG_DISPLAY à false (même si WP_DEBUG reste actif).
• SCRIPT_DEBUG à false.
• wp-content/debug.log supprimé (il peut fuiter des chemins) ou rendu inaccessible en HTTP par .htaccess.
• Query Monitor désactivé ou limité à un rôle admin.

# Bloquer l'accès HTTP à debug.log
# Dans wp-content/.htaccess
<Files debug.log>
    Require all denied
</Files>