Le journal WordPress ne se crée pas : retrouver où partent les erreurs

Un fichier absent ne signifie pas qu’aucune panne n’existe

Vous avez activé le débogage de WordPress, mais aucun fichier debug.log n’apparaît, ou le fichier reste vide pendant l’erreur. Ce constat ne prouve ni que WordPress fonctionne correctement ni que le problème vient forcément des permissions. Le message peut partir vers une autre destination, survenir avant l’activation du journal ou ne pas être une erreur PHP.

Un journal n’est pas un enregistrement de tous les clics. Une action réussie peut ne rien écrire, et un refus HTTP produit par un proxy peut ne jamais atteindre WordPress. Le fichier peut aussi porter un autre nom lorsque sa destination a été personnalisée. Chercher exclusivement wp-content/debug.log devient alors trompeur.

Le résultat attendu est plus précis que la création d’un fichier vide : vous devez savoir quelle requête atteint PHP, où ses messages sont envoyés et comment retrouver une trace datée pertinente. Nous allons vérifier cette chaîne sans afficher les erreurs aux visiteurs. Une fois le message obtenu, la réparation de sa cause relève du guide correspondant à l’erreur, pas d’un changement supplémentaire de journalisation.

Confirmer la requête, le site et le fichier consulté

Notez l’adresse qui pose problème, l’heure avec son fuseau et l’action réalisée. Pour un traitement susceptible d’envoyer un paiement ou un courriel, exploitez d’abord l’échec déjà enregistré. Rejouer une opération sensible pour remplir un journal peut créer un second effet alors que la première tentative a partiellement réussi.

Ce guide suppose un accès autorisé aux fichiers de l’installation ou aux journaux de son hébergement. Sur une plateforme gérée, la destination peut être un écran privé ou un collecteur plutôt qu’un fichier accessible par SFTP. Dans un réseau multisite, le code et certains journaux peuvent être partagés ; identifiez le sous-site sans supposer qu’il possède son propre fichier.

Sur WordPress.com, partez des outils de diagnostic et des accès effectivement disponibles pour votre site. Si vous ne pouvez pas ouvrir sa configuration, suivez la voie des journaux privés ou de l’assistance ; l’accès au tableau de bord WordPress ne donne pas à lui seul la possibilité de modifier les fichiers du serveur.

1. Relevez l’URL et le créneau exact de l’échec, puis confirmez quel domaine et quel environnement vous examinez.
2. Identifiez la racine des fichiers WordPress et sa configuration active dans le panneau d’hébergement.
3. Vérifiez le chemin réellement consulté et la date de modification du journal, s’il existe.
4. Distinguez une copie de test de la production et une réponse en cache d’une nouvelle exécution PHP.

Préserver la configuration et les informations privées

Avant de modifier wp-config.php, conservez sa copie dans un emplacement privé, hors de toutes les racines Web du compte. Ce fichier contient généralement des secrets. Une copie dont le nom finit par .bak laissée à côté de l’original peut devenir téléchargeable selon la configuration du serveur. Gardez également l’accès aux fichiers ouvert pour pouvoir annuler une erreur de syntaxe.

Préférez une copie de travail protégée, avec les envois et paiements neutralisés. La protection doit couvrir réellement cet environnement, pas seulement sa page d’accueil. Une sauvegarde des fichiers et de la base est utile avant une intervention plus large ; ici, gardez surtout les valeurs de journalisation précédentes et la manière de les restaurer.

Le journal peut contenir des chemins, adresses, fragments de requêtes ou données personnelles. Limitez la période de collecte et les personnes qui y accèdent. Masquer l’affichage des erreurs ne protège pas un fichier disponible par URL. Si vous ne disposez pas d’un emplacement privé accepté par PHP, utilisez le journal intégré de l’hébergement plutôt que de laisser une trace sensible dans un dossier public.

Vérifier les constantes avant le démarrage de WordPress

Dans le fichier actif, recherchez WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY. L’activation du journal WordPress dépend du mode de débogage. Ne confondez pas le réglage qui déclenche la collecte, celui qui choisit sa destination et celui qui autorise l’affichage dans la page.

L’exemple ci-dessous utilise un chemin privé illustratif à remplacer par un emplacement confirmé. Les booléens true et false restent sans guillemets ; le chemin est du texte et porte des guillemets. Modifiez les définitions existantes au lieu d’en ajouter d’autres. Une définition répétée ne remplace pas proprement la première valeur.

1. Ouvrez la configuration active avec un éditeur de texte et relevez les valeurs initiales.
2. Placez ou corrigez ces définitions avant le chargement de wp-settings.php, qui démarre WordPress.
3. Remplacez le chemin d’exemple par le chemin absolu privé réellement fourni pour ce site.
4. Enregistrez sans ajouter de nouvelle balise PHP au milieu du fichier, puis contrôlez que le site démarre encore.
5. Si une nouvelle erreur apparaît, restaurez la version précédente par l’accès aux fichiers.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/chemin/prive/autorise/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );

Chercher la bonne destination plutôt que le seul nom debug.log

Lorsque WP_DEBUG_LOG vaut le booléen true, WordPress utilise le dossier de contenus défini pour l’installation, avec le nom debug.log. Ce dossier peut avoir été déplacé. Lorsque la constante contient un chemin, c’est cette destination qu’il faut examiner. Une configuration qui vise un journal privé ne doit pas créer en plus une copie publique pour faciliter sa lecture.

Le dossier parent doit déjà exister et être accessible au processus PHP du site. Le droit de déposer un fichier par SFTP ne démontre pas que PHP peut y écrire : les deux opérations peuvent utiliser des identités différentes. Si le fichier existe déjà avec une autre propriété, une nouvelle trace peut également être refusée.

Dans l’accès aux fichiers, affichez le dossier privé exact puis actualisez sa liste après la requête. Vérifiez le nom, la taille et la date, sans prendre la date d’une copie téléchargée pour celle du fichier serveur. Si l’hébergement centralise les journaux ailleurs, demandez son écran de consultation et le filtre du domaine. Le résultat utile est une destination identifiée, pas la présence simultanée de plusieurs journaux dont personne ne sait lequel est actif.

Vérifier une trace contrôlée uniquement sur une copie

Sur une copie privée dont vous maîtrisez la configuration, un marqueur neutre peut distinguer une absence d’erreur d’une absence d’écriture. Cette étape facultative convient au mainteneur capable de modifier puis restaurer le fichier. Elle n’est pas nécessaire si une erreur récente apparaît déjà dans le journal, et elle ne doit pas être ajoutée durablement à la production.

Dans un wp-config.php classique, placez temporairement la ligne ci-dessous dans le code PHP, juste après l’instruction existante qui charge wp-settings.php, avant une éventuelle fermeture PHP. Ne dupliquez pas cette instruction de chargement. Le marqueur ne contient ni secret ni donnée de visiteur. Si votre architecture termine la requête avant cet emplacement, son absence ne permettra pas de conclure.

La présence du marqueur valide seulement cet appel manuel et sa destination pour la requête observée. Elle ne démontre pas que tous les niveaux d’erreur sont collectés automatiquement. Ne vous fiez pas non plus à la valeur de retour de error_log() : avec le type par défaut utilisé ici, PHP peut renvoyer true même si le message n’a pas été enregistré. C’est la ligne réellement retrouvée qu’il faut contrôler.

1. Sauvegardez le fichier de la copie et vérifiez que la destination privée est prête.
2. Ajoutez uniquement la ligne de marqueur à l’emplacement indiqué.
3. Chargez une page de la copie qui exécute effectivement WordPress, sans opération métier.
4. Cherchez le marqueur dans la destination et au créneau attendus, puis retirez immédiatement la ligne.
5. Sa présence confirme ce trajet d’écriture pour cette requête ; son absence impose de vérifier démarrage, cache et destination, sans provoquer volontairement une erreur fatale.

error_log( 'ATELIER-DIAG-JOURNAL' );

Consulter le journal serveur pour une erreur trop précoce

Une erreur de syntaxe dans la configuration peut empêcher PHP d’exécuter les lignes censées activer le journal WordPress. De même, une panne du moteur, une limite imposée au service ou un refus du serveur Web peut intervenir avant cette activation. Modifier encore WP_DEBUG_LOG ne permet pas de remonter dans le temps.

Ouvrez le journal PHP ou le journal d’erreurs du domaine fourni dans le panneau d’hébergement. Filtrez le créneau et le domaine exacts. Le journal d’accès décrit les requêtes reçues ; le journal d’erreurs décrit certains échecs. Les deux ne sont pas interchangeables, mais les rapprocher aide à voir si la demande a atteint le service attendu.

Si une erreur récente cite wp-config.php ou un fichier chargé avant le cœur, restaurez la dernière modification pertinente ou confiez sa correction ciblée au mainteneur. Ne modifiez pas les fichiers du cœur pour faire démarrer le débogage plus tôt. Le résultat attendu de cette voie est une trace serveur exploitable, même si aucun journal WordPress n’est créé. Son absence dans debug.log reste alors cohérente avec l’étape où la panne s’est produite.

Comparer le contexte Web et le contexte du terminal

Une commande en terminal peut utiliser un autre PHP, un autre fichier INI et un autre utilisateur que le site Web. Écrire un message depuis WP-CLI ou constater qu’un dossier est accessible avec votre compte ne vérifie donc pas, à lui seul, la journalisation d’une requête visiteur.

Pour le contexte Web, utilisez les informations privées de l’hébergement et, lorsque l’administration fonctionne, Outils > Santé du site > Informations > Serveur. Relevez la version PHP et les éléments de contexte disponibles, puis faites confirmer la destination effective des erreurs par le prestataire. Ne publiez pas une page phpinfo() pour comparer les réglages.

PHP possède ses propres paramètres log_errors et error_log. La destination peut être un fichier, le journal du service ou un collecteur système. Une configuration d’hébergement peut aussi imposer des valeurs qui empêchent une modification à l’exécution. Demandez quelle valeur est réellement appliquée aux requêtes du domaine, plutôt que d’ajouter plusieurs appels de configuration dans différents fichiers. Si le site et le terminal divergent, consignez les deux contextes et corrigez celui qui produit la panne.

Corriger un refus d’écriture sans ouvrir toutes les permissions

Si le journal serveur signale un accès refusé, faites vérifier le propriétaire du fichier, les droits du dossier parent et l’identité PHP du domaine. Si la destination n’existe pas, il faut pouvoir créer le fichier dans ce dossier ; si elle existe, il faut pouvoir y ajouter des données. Le même chiffre de permissions ne garantit pas ces conditions sur tous les hébergements.

Une restriction open_basedir peut également exclure le chemin privé choisi. Elle contrôle les chemins autorisés et ne se corrige pas en appliquant 777. Faites utiliser un emplacement privé déjà autorisé ou ajuster précisément le périmètre par son responsable. N’autorisez pas toute l’arborescence du serveur pour un seul journal.

Vérifiez aussi le quota d’espace et le quota de fichiers lorsque le service refuse de créer de nouveaux éléments. Conservez les journaux utiles avant toute rotation prévue et ne supprimez pas les sauvegardes au hasard pour dégager de la place. Après correction ciblée, reprenez une seule requête de contrôle et cherchez une nouvelle trace. Si elle apparaît, notez la cause concrète retenue et le réglage corrigé ; la création manuelle d’un fichier vide n’aurait pas démontré ce résultat.

Faire identifier un réglage remplacé pendant le chargement

La configuration initiale peut être correcte, puis un composant peut changer les paramètres PHP de journalisation ou installer son propre gestionnaire d’erreurs. Un environnement personnalisé peut aussi adapter les contrôles très tôt dans le démarrage. Ce sont des hypothèses à vérifier dans le code chargé, pas une raison de désactiver toutes les protections.

Si le problème suit une modification précise, comparez cette version à la précédente sur la copie. Demandez au mainteneur de rechercher les changements de destination error_log, de log_errors ou des gestionnaires d’erreurs dans le composant concerné. Pour une architecture qui personnalise le démarrage, faites aussi examiner le filtre enable_wp_debug_mode_checks ; il intervient avant les extensions ordinaires et ne doit pas être forcé sans comprendre son rôle.

Le test doit isoler le composant confirmé et conserver le fonctionnement prévu de la copie. Si une politique d’hébergement centralise volontairement les traces, utilisez son collecteur plutôt que d’ajouter un mécanisme concurrent. Documentez l’endroit où la décision est prise et le moyen de la vérifier. Une constante visible dans un fichier ne décrit pas nécessairement tous les réglages effectifs à la fin de la requête.

Observer les erreurs du chargement avec Query Monitor

Si l’administration fonctionne encore, Query Monitor peut compléter l’enquête sur une copie. Cette extension gratuite de John Blackbourn affiche notamment les erreurs PHP du chargement courant. La version vérifiée est 4.1.1, avec WordPress 6.3 et PHP 7.4 minimum et une compatibilité déclarée jusqu’à WordPress 7.1.4. Ces mentions ne constituent pas un test sur votre site.

Utilisez de préférence une installation déjà présente. Sinon, sur la copie autorisée, ouvrez Extensions > Ajouter, recherchez Query Monitor et vérifiez le nom ainsi que l’auteur avant installation et activation. N’ajoutez pas un second outil de collecte si un outil équivalent couvre déjà ce besoin.

1. Connectez-vous avec le compte de maintenance puis ouvrez la page qui reproduit le problème.
2. Dans la barre d’administration, ouvrez Query Monitor et son panneau PHP Errors lorsqu’il signale des erreurs.
3. Relevez le message, le niveau, l’appelant et le composant indiqués, avec le contexte de la page.
4. Comparez ce relevé avec le journal privé au même instant.
5. Désactivez l’outil après l’enquête si son installation était temporaire. Il ne répare pas l’écriture disque, ne reconstitue pas les événements passés et ne garantit pas la capture d’une panne survenue avant son chargement.

Valider le trajet de collecte avant d’exploiter l’erreur

Une fois la collecte retrouvée, vérifiez qu’elle décrit bien le problème initial. Un ancien avertissement sans rapport, un message d’un autre domaine ou un marqueur provenant du terminal ne suffit pas. Rapprochez l’heure, le chemin de la requête et le composant cité. Conservez quelques lignes de contexte sans exporter l’ensemble des traces de tous les utilisateurs.

Si seule une trace de contrôle apparaît mais pas la panne, le trajet du contrôle fonctionne ; le problème peut se produire ailleurs ou ne pas émettre d’erreur PHP. Examinez alors la réponse réseau ou le journal du service concerné. N’élargissez pas l’affichage public pour obtenir davantage d’informations.

1. Confirmez la présence d’un événement nouveau dans la destination identifiée.
2. Vérifiez que l’affichage public des erreurs reste désactivé et que le stockage est privé.
3. Reproduisez uniquement une action sans effet externe, ou utilisez la tentative métier déjà enregistrée.
4. Associez la trace utile à son contexte et transmettez un extrait expurgé au responsable de la réparation.
5. Séparez le résultat « collecte opérationnelle » du résultat « panne réparée » : le second exige ses propres contrôles fonctionnels.

Retirer le diagnostic temporaire et garder une procédure utilisable

Remettez les constantes et les réglages serveur dans l’état convenu après la collecte. Ne supprimez pas une configuration de journalisation permanente imposée par l’hébergement ; retirez seulement vos ajouts temporaires. Vérifiez les différences avant de restaurer un ancien fichier complet, car une autre intervention légitime a pu modifier sa configuration entre-temps.

Retirez le marqueur de la copie et toute page de diagnostic éventuelle créée hors de ce parcours. Rangez l’extrait utile dans un espace privé, avec sa date et une durée de conservation adaptée. Si une copie de journal a été exposée publiquement, faites évaluer ce qu’elle contenait plutôt que de supposer que changer son nom suffit à effacer l’exposition.

Contrôlez ensuite l’accueil, la connexion et l’action initialement affectée. Documentez le journal du domaine, sa destination, le contexte PHP concerné et la personne qui peut le consulter. La prochaine panne ne nécessitera ainsi pas de recréer un mécanisme de collecte dans l’urgence. Si aucun événement n’a pu être obtenu, transmettez précisément les chemins et contextes vérifiés ainsi que la limite rencontrée ; n’annoncez pas l’absence d’erreur sur la seule base d’un fichier vide.