Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

WhatsApp contact@allaux.fr
FR EN TR
allaux.
Urgence Parler de mon projet

Où trouver et comment lire les logs WordPress et WooCommerce

Une boutique WooCommerce écrit ses erreurs dans plusieurs journaux distincts selon leur origine : le cœur de WordPress, l’extension WooCommerce elle-même, et le serveur. Savoir où chercher évite de perdre du temps sur le mauvais fichier.

Décrire mon problème Discuter sur WhatsApp

Les trois journaux à connaître

  1. wp-content/debug.log

    Une fois WP_DEBUG_LOG activé dans wp-config.php, WordPress y écrit toutes les erreurs, avertissements et notices PHP générés par le cœur, les extensions et le thème, avec le fichier et la ligne en cause.

  2. WooCommerce > Statut > Journaux

    Depuis l’administration WordPress, cet écran liste des journaux séparés par source : paiement, webhook, envoi d’e-mails, synchronisation de stock. C’est le premier endroit à consulter pour un problème de commande ou de paiement.

  3. Les journaux du serveur

    Accessibles via le panneau d’hébergement ou en SSH, ils consignent les erreurs PHP au niveau serveur (error_log) ainsi que les journaux Apache ou Nginx, utiles quand le site est inaccessible avant même que WordPress ne se charge.

  4. Repérer l’heure exacte

    Comme pour tout diagnostic multi-source, l’heure précise de l’incident permet de retrouver la même erreur dans plusieurs journaux et de confirmer si plusieurs symptômes ont la même cause.

  5. Isoler la source si plusieurs extensions écrivent des erreurs

    Sur un site avec de nombreuses extensions actives, debug.log peut contenir du bruit sans rapport avec le problème en cours ; le nom du plugin ou son chemin dans wp-content/plugins apparaît en général dans la ligne d’erreur elle-même.

Pourquoi WooCommerce a ses propres journaux

WooCommerce enregistre certains événements séparément de debug.log parce qu’ils ne sont pas toujours des erreurs PHP à proprement parler : un webhook de paiement reçu mais rejeté, une tentative de synchronisation avec une passerelle qui échoue silencieusement, ou un e-mail de confirmation de commande qui n’a pas pu être envoyé. Ces événements sont visibles uniquement depuis WooCommerce, Statut, Journaux.

Le fichier debug.log, lui, capture tout ce qui relève d’une erreur ou d’un avertissement PHP au sens strict : une fonction dépréciée appelée par une extension mal maintenue, une valeur nulle utilisée là où un tableau était attendu, ou une erreur fatale qui interrompt le chargement de la page. C’est la source la plus utile face à une erreur critique WordPress.

wp-content/debug.log (extrait typique)
[24-Jul-2026 09:14:02 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function some_removed_function() in /wp-content/plugins/exemple-extension/exemple.php:42

Le niveau de sévérité change la marche à suivre

Toutes les lignes de debug.log ne se traitent pas avec la même urgence. Une erreur de niveau PHP Fatal error interrompt l’exécution de la page et explique en général directement l’écran blanc ou le message d’erreur critique. Une PHP Warning ou une PHP Deprecated n’empêche généralement pas la page de s’afficher, mais signale un code qui deviendra incompatible à la prochaine montée de version de PHP ou de WordPress.

Sur une boutique active, il est courant de trouver plusieurs centaines de lignes de notices ou d’avertissements sans lien avec le problème du moment. Se concentrer d’abord sur les erreurs fatales, puis sur les avertissements dont l’horodatage correspond précisément à l’incident, évite de perdre du temps à corriger des messages sans rapport avec le symptôme observé.

Questions fréquentes

debug.log est vide alors que le site plante, pourquoi ?
Le fichier n’est créé qu’après activation de WP_DEBUG_LOG et la survenue d’une première erreur. S’il reste vide, l’erreur se produit probablement avant le chargement de WordPress, par exemple un problème serveur ou un .htaccess invalide : il faut alors consulter les journaux du serveur.
Puis-je supprimer debug.log sans risque ?
Oui, ce fichier est purement informatif et peut être supprimé à tout moment. WordPress en recrée un nouveau dès la prochaine erreur si WP_DEBUG_LOG reste actif.
Les journaux WooCommerce concernent-ils aussi les extensions tierces de paiement ?
En grande partie oui, la majorité des extensions de paiement WooCommerce utilisent le système de journalisation natif (WC_Logger), donc leurs erreurs apparaissent dans WooCommerce > Statut > Journaux au même endroit que les journaux natifs.
Comment savoir quelle extension a écrit une ligne dans WooCommerce > Statut > Journaux ?
Chaque fichier de journal porte le nom de sa source (par exemple le nom de la passerelle de paiement) et un horodatage, visibles dans le menu déroulant en haut de l’écran des journaux.

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle est l’ampleur du problème ?
Quel type de message s’affiche ?
Qu’est-ce qui a changé juste avant ?

Neuf fois sur dix, une extension ou un thème récemment mis à jour est en cause.

WP_DEBUG est-il activé dans wp-config.php ? (facultatif)

Cette option révèle le fichier et la ligne exacts en cause, au lieu du message générique affiché aux visiteurs.

De quels accès disposez-vous ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Pages liées