Déboguer WordPress et WooCommerce proprement : WP_DEBUG, debug.log, Site Health et rapports WooCommerce (sans exposer vos erreurs)

Quand un site WordPress ralentit, affiche une erreur 500, ou qu’un checkout WooCommerce ne confirme plus les commandes, la tentation est de « toucher un peu partout ». Une méthode plus fiable consiste a activer un débogage temporaire, collecter des preuves (logs, état du site), puis isoler le coupable (plugin, thème, tâche planifiée). Cette approche marche autant pour une PME a Lausanne et Vevey (Vaud) qu’a Genève et Carouge (Genève), Fribourg et Bulle (Fribourg), Sion et Martigny (Valais), Neuchâtel et La Chaux-de-Fonds (Neuchâtel), Delémont et Porrentruy (Jura).

Liens officiels : WordPress (Debugging in WordPress) | WordPress.org (Site Health screen) | WooCommerce (System Status Report) | WooCommerce (Scheduled Actions) | PHP (error_log) | PHP (configuration des logs)

1) Règle de base : ne pas afficher les erreurs aux visiteurs

En production, afficher des erreurs peut révéler des chemins, versions, ou informations sensibles. L’objectif est de journaliser (loguer), puis de désactiver le débogage une fois le diagnostic terminé.

2) Activer WP_DEBUG et écrire dans debug.log (temporairement)

WordPress documente un système de débogage via des constantes dans wp-config.php. Le duo le plus utile : activer WP_DEBUG et enregistrer les erreurs dans un fichier debug.log. Gardez une fenêtre courte (le temps d’observer le bug), puis revenez a l’état normal.

// Exemple a adapter dans wp-config.php (temporaire)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // Ecrit dans wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // Evite l'affichage public

Conseil : ne partagez jamais debug.log publiquement. Ce fichier peut contenir des données techniques, voire des extraits liés a des requêtes.

3) Ajouter des traces ciblées avec error_log (sans noyer le log)

Quand le bug est intermittent (AJAX, wp-cron, paiement), une trace courte peut aider : « étape atteinte », « valeur reçue », « ID commande ». WordPress indique que WP_DEBUG_LOG permet aussi d’écrire via la fonction PHP error_log().

// Exemple : trace ciblée (a retirer ensuite)
error_log('DEBUG checkout: étape begin_checkout atteinte');

4) Exploiter Site Health : état du site et infos utiles en 2 minutes

L’écran Site Health se trouve dans Outils > Santé du site. L’onglet « Info » liste notamment : versions, serveur, base de données, constantes WordPress et permissions. C’est un bon point de départ avant d’accuser un plugin.

• Capturer l’info avant changement (baseline), puis après un changement (comparaison).
• Vérifier les permissions et les tailles de dossiers si des uploads échouent.
• Noter les constantes actives (utile quand WP_DEBUG reste activé par oubli).

5) WooCommerce : Status, Logs et Scheduled Actions (souvent la clé)

WooCommerce propose un rapport d’état (System Status Report) et des sections orientées diagnostic. En boutique, beaucoup de soucis viennent de tâches en arrière-plan (e-mails, renouvellements, mises a jour, traitements). L’onglet Scheduled Actions permet de voir les actions en attente, terminées, ou échouées, avec des détails d’erreur pour celles qui ont échoué.

• WooCommerce > Status : générer un rapport pour comprendre l’environnement.
• WooCommerce > Status > Logs : repérer un log lié au paiement, a l’e-mail, ou a une extension.
• WooCommerce > Status > Scheduled Actions : filtrer sur « Failed », ouvrir les logs d’erreur.

6) Méthode d’isolement rapide (sans tout casser)

• Reproduire : noter une action simple qui déclenche le bug (ex. ajouter au panier, valider un formulaire).
• Collecter : activer WP_DEBUG_LOG, reproduire une fois, puis récupérer l’extrait de debug.log correspondant.
• Confirmer : regarder Site Health (infos) et WooCommerce Status (logs, scheduled actions).
• Isoler : désactiver un seul plugin suspect a la fois (sur staging si possible), retester, puis conclure.
• Nettoyer : couper WP_DEBUG, archiver le diagnostic, corriger proprement.

FAQ Débogage WordPress et WooCommerce (Suisse romande)

Ou se trouve le fichier debug.log sur WordPress ?

Quand WP_DEBUG_LOG est activé, WordPress écrit par défaut dans wp-content/debug.log. Ensuite, il faut le désactiver après diagnostic.

Pourquoi une boutique WooCommerce en Valais ou a Fribourg n’envoie plus certains e-mails ?

Les e-mails peuvent dépendre de tâches en arrière-plan. Dans WooCommerce, la section Scheduled Actions permet de voir si des actions ont échoué et d’ouvrir les logs associés.

Site Health sert-il a autre chose qu’a afficher des recommandations ?

Oui. L’onglet « Info » fournit un état détaillé (versions, serveur, base de données, constantes, permissions), utile pour diagnostiquer une erreur ou préparer un ticket support.

Puis-je écrire des traces moi-même sans plugin ?

Oui. PHP documente error_log() pour écrire dans les routines de log configurées. Avec WP_DEBUG_LOG actif, cela sert a ajouter des traces ciblées, a retirer ensuite.

Besoin d’un diagnostic propre, puis d’une correction durable ?

Pour isoler rapidement l’origine d’un bug (plugin, thème, scheduled actions), sécuriser la collecte de logs, et remettre le site en état sans bricolage, contactez clickclick.ch.