Lorsque WordPress affiche une erreur critique, une erreur HTTP 500, une page blanche ou un autre problème technique, le message d'erreur visible ne suffit souvent pas à identifier la cause réelle.
WordPress et PHP peuvent par conséquent consigner des informations d'erreur plus détaillées. Ces journaux indiquent par exemple quel type d'erreur s'est produit, à quel moment elle est intervenue et quel fichier PHP était impliqué.
WordPress dispose pour cela de son propre système de débogage avec des paramètres tels que WP_DEBUG, WP_DEBUG_LOG et WP_DEBUG_DISPLAY. De plus, les journaux d'erreurs PHP côté serveur peuvent contenir des informations importantes.
Cependant, le débogage ne consiste pas à afficher publiquement autant de messages d'erreur que possible sur le site web. Sur un site web de production, les détails techniques doivent être consignés dans des journaux si possible, puis analysés de manière ciblée.
En bref : N'activez le débogage que de manière ciblée pour la recherche d'erreurs. Sur un site web en production, les messages d'erreur ne doivent normalement pas être affichés publiquement. Utilisez plutôt un journal des erreurs, reproduisez l'erreur, notez l'heure et examinez ensuite les entrées de journal correspondantes.
Que signifie le débogage dans WordPress ? #
Le débogage désigne la recherche systématique d'erreurs dans un logiciel ou un site web.
Dans le cas de WordPress, il s'agit par exemple de découvrir pourquoi une requête spécifique échoue, pourquoi un plugin provoque une erreur ou pourquoi PHP interrompt le traitement d'une page.
Plutôt que de simplement tester différents paramètres, le débogage fournit des informations techniques sur le déroulement réel.
Cela permet souvent de transformer une supposition en un diagnostic concret.
Quand le débogage WordPress est-il utile ? #
Le débogage est particulièrement utile lorsqu'un problème se produit de manière reproductible, mais que le message d'erreur visible ne fournit pas d'explication suffisante.
Cela concerne par exemple les erreurs WordPress critiques, les erreurs HTTP 500, les problèmes suite à une mise à jour de plugin ou de thème, les erreurs après un changement de version PHP ou des fonctionnalités qui ne fonctionnent soudainement plus correctement.
Même en cas de comportement inhabituel d'un plugin, un journal peut fournir des indices, même si le site Web reste fondamentalement accessible.
Le débogage n'est pas la même chose que la réparation #
Un journal d'erreurs ne résout pas automatiquement le problème.
Le débogage aide d'abord à identifier la cause.
Si un journal, par exemple, montre qu'une erreur fatale PHP se produit dans un plugin spécifique, il faut ensuite vérifier pourquoi cette erreur se produit et quelle solution y est adaptée.
La force du débogage ne réside donc pas dans une réparation automatique, mais dans un diagnostic nettement plus précis.
Créer une sauvegarde avant d'apporter des modifications #
Avant de modifier des fichiers de configuration tels que wp-config.php tu le modifies, une sauvegarde récente doit être présente.
Une petite erreur de syntaxe dans un fichier de configuration PHP peut empêcher le chargement correct de WordPress.
Pour les sites Web complexes ou critiques pour l'activité, un environnement de staging est fondamentalement préférable pour des travaux de débogage approfondis.
Le fichier wp-config.php #
Les principaux paramètres de débogage de WordPress se trouvent généralement dans :
wp-config.php
défini.
Ce fichier se trouve généralement dans le répertoire principal de l'installation WordPress ou un niveau au-dessus, si l'installation a été configurée en conséquence.
Elle contient les paramètres centraux de l'installation WordPress et ne doit par conséquent être modifiée qu'avec précaution.
WP_DEBUG #
La constante WordPress principale pour le mode de débogage s'appelle :
WP_DEBUG
Dans une installation WordPress de production normale, le débogage est généralement désactivé :
define( 'WP_DEBUG', false );
Il peut être activé pour un diagnostic ciblé :
define( 'WP_DEBUG', true );
Activé WP_DEBUG WordPress augmente le rapport d'erreurs PHP et génère en outre des avis spécifiques à WordPress, par exemple concernant des fonctions obsolètes.
ne pas mettre true et false entre guillemets #
En ce qui concerne les constantes de débogage vrai et faux valeurs booléennes.
Correct is, for example:
define( 'WP_DEBUG', false );
Ne doit pas être utilisé :
define( 'WP_DEBUG', 'false' );
La deuxième variante contient une chaîne de caractères au lieu d'une valeur booléenne et peut ainsi conduire à un résultat inattendu.
Important : Pour les constantes WordPress, le type de données doit être correctement repris.
fauxet'faux'ne sont pas la même chose en PHP.
WP_DEBUG_LOG #
Avec :
WP_DEBUG_LOG
WordPress peut écrire les messages de débogage dans un fichier.
Une configuration typique est :
define( 'WP_DEBUG_LOG', true );
Si WP_DEBUG_LOG sur vrai et WP_DEBUG est activé, WordPress utilise par défaut :
wp-content/debug.log
comme fichier journal de débogage.
WP_DEBUG_LOG nécessite WP_DEBUG #
Un lien important est souvent négligé :
WP_DEBUG_LOG
fonctionne au sein du système de débogage de WordPress avec :
WP_DEBUG
Si WP_DEBUG n'est pas activé, le simple fait de définir WP_DEBUG_LOG le journal de débogage WordPress attendu.
Chemin personnalisé pour WP_DEBUG_LOG #
WordPress peut être WP_DEBUG_LOG utiliser également un chemin de fichier valide.
Cela peut être utile si le journal des erreurs ne doit pas être stocké directement dans le répertoire du site web accessible au public.
Quels chemins sont utiles et descriptibles dans un environnement d'hébergement concret dépend de la configuration du serveur.
WP_DEBUG_DISPLAY #
La constante :
WP_DEBUG_DISPLAY
détermine si les messages de débogage doivent être affichés sur le site web.
Pour un site web productif, la combinaison suivante est souvent plus judicieuse lors d'un diagnostic qu'un affichage public des erreurs :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Cela permet à WordPress de consigner les erreurs sans les afficher intentionnellement aux visiteurs sur le site web.
Attention : Les messages d'erreur détaillés peuvent contenir des chemins de fichiers, des configurations techniques et d'autres informations internes. Ils ne doivent pas être affichés publiquement de manière permanente sur un site web de production.
prendre également en compte display_errors #
L'affichage réel des erreurs PHP peut également être influencé par la configuration de PHP.
Il peut donc être utilisé en complément pour une configuration de diagnostic :
@ini_set( 'display_errors', 0 );
Une combinaison possible est donc la suivante :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );La possibilité de modifier les paramètres PHP pendant l'exécution dépend toutefois de la configuration du serveur.
Où faut-il placer le code de débogage dans wp-config.php ? #
Les constantes de débogage doivent être définies avant que WordPress ne soit entièrement chargé.
Dans un typique wp-config.php se trouvent-ils pour cette raison devant la ligne de conclusion connue ou avant wp-settings.php est intégré.
Si une définition telle que :
define( 'WP_DEBUG', false );
existant, tu ne devrais pas en créer une seconde définition contradictoire ailleurs.
Trouver le fichier debug.log #
Dans la configuration par défaut, le fichier de débogage WordPress se trouve à l'adresse suivante :
wp-content/debug.log
Elle peut par exemple être consultée via le gestionnaire de fichiers de l'hébergement ou un accès de transfert de fichiers approprié.
Le fichier ne doit pas nécessairement déjà exister. Il sera créé ou écrit lorsque les messages correspondants pourront être enregistrés dans le journal.
Si aucun fichier debug.log n'est créé #
Si, malgré l'activation du débogage, aucun fichier n'apparaît, vous devez d'abord vérifier si une erreur enregistrable a réellement été générée et si les constantes de débogage sont définies correctement.
De plus, les droits des fichiers, le chemin des journaux configuré et la configuration de l'hébergement ou de PHP peuvent jouer un rôle.
Un manquant journal de débogage ne prouve donc pas automatiquement que WordPress fonctionne sans erreur.
Reproduire l'erreur de manière ciblée #
L'une des méthodes les plus efficaces pour l'analyse des journaux est la reproduction contrôlée du problème.
Si, par exemple, un clic sur „ Mettre à jour “ sur une page spécifique provoque une erreur, ouvrez d'abord le journal ou notez son état actuel. Effectuez ensuite exactement cette même action à nouveau.
Ensuite, tu examines les nouvelles entrées.
Cela te permet de réduire le risque de confondre une ancienne erreur qui n'est plus pertinente depuis longtemps avec le problème actuel.
Les horodatages sont cruciaux #
Sur un site web exploité de longue date, un journal d'erreurs peut contenir des entrées provenant de situations très diverses.
Une erreur fatale d'hier n'a pas nécessairement de rapport avec le problème qui survient aujourd'hui.
Note par conséquent le plus précisément possible le moment où tu as reproduit l'erreur et compare-le avec les horodatages dans le journal.
Conseil pratique : Reproduisez une erreur de manière contrôlée et notez l'heure. Cela permet de distinguer beaucoup plus rapidement les entrées de journal pertinentes du bruit des anciens protocoles.
Comment lit-on une erreur PHP ? #
Une erreur PHP contient souvent plusieurs éléments utiles.
Le type d'erreur, le message d'erreur, le chemin du fichier, le numéro de ligne et l'horodatage sont particulièrement pertinents.
Un exemple simplifié pourrait ressembler à ceci :
Erreur fatale PHP : Erreur non interceptée ... dans /wp-content/plugins/beispiel-plugin/datei.php à la ligne 123
Cela vous permet déjà de savoir que PHP a interrompu l'exécution en raison d'une erreur fatale et dans quelle zone de code l'erreur est apparue.
Erreur fatale PHP #
Un
Erreur fatale PHP
est une erreur fatale qui empêche PHP de poursuivre l'exécution normale.
De telles erreurs peuvent par exemple être causées par du code incompatible, des fonctions ou des classes manquantes, des problèmes de mémoire et d'autres bugs graves.
Une erreur fatale est donc particulièrement pertinente en cas d'erreur HTTP 500 ou de page blanche.
Erreur non interceptée et TypeError #
Des messages tels que :
Erreur non interceptée
ou
TypeError
signalent des erreurs lors de l'exécution de PHP.
Un TypeError peut survenir, par exemple, lorsqu'un code transmet une valeur d'un type inapproprié à une fonction.
Ce type d'erreur se produit souvent en cas d'incompatibilités ou de code défectueux de plugin, de thème ou de code personnalisé.
Appel à une fonction non définie #
Un message tel que :
Appel à une fonction non définie
signifie que PHP a tenté d'appeler une fonction qui n'est pas disponible dans ce contexte d'exécution.
Les causes possibles sont un code incompatible, une dépendance manquante ou une extension PHP non disponible.
Le chemin du fichier et le nom de la fonction fournissent des indications importantes pour la suite du diagnostic.
Classe introuvable #
Un message tel que :
Classe ... introuvable
peut indiquer que le code de programme attendu n'a pas été chargé.
Cela peut être causé par exemple par des fichiers manquants, des dépendances de plugins, des processus de chargement automatique défectueux ou des versions incompatibles.
Impossible de redeclarer #
Chez :
Impossible de redeclarer
par exemple, on a essayé de redeclarer une fonction déjà existante.
Cela peut se produire en cas de code doublement chargé ou qui se chevauche, et c'est donc également intéressant en cas de conflits de plugins ou de thèmes.
Taille de mémoire autorisée épuisée #
Le message :
Taille de mémoire autorisée ... épuisée
indique que PHP a atteint la limite de mémoire autorisée lors de son exécution.
Cela ne signifie pas automatiquement qu'uniquement une limite plus élevée est nécessaire. Un plugin ou un processus peut également consommer une quantité inhabituelle de mémoire.
Nous traitons le diagnostic exact sous Limite de mémoire PHP dans WordPress : identifier et corriger l'erreur.
Erreur d'analyse syntaxique et erreur de syntaxe #
Une erreur de syntaxe se produit lorsque le code PHP n'est pas correctement structuré.
Cela peut se produire, par exemple, après une modification manuelle sur :
fonctions.php
ou
wp-config.php
arriver.
Une simple parenthèse manquante, un caractère erroné ou un point-virgule défectueux peuvent amener PHP à ne pas interpréter correctement le fichier.
Un avertissement n'est pas la même chose qu'une erreur fatale #
Un
Avertissement PHP
est généralement moins grave qu'une erreur fatale.
PHP peut poursuivre son exécution selon la situation malgré un avertissement.
Les avertissements doivent quand même être examinés, en particulier s'ils se produisent fréquemment ou s'ils sont liés à un dysfonctionnement concret.
Cependant, chaque avertissement n'explique pas automatiquement l'erreur pour laquelle vous avez ouvert le journal.
Bien replacer la notice dans son contexte #
Les notices signalent souvent un code problématique ou malpropre sans interrompre immédiatement l'exécution.
Une fois activé WP_DEBUG plusieurs messages peuvent donc apparaître, même si le site Web fonctionne au premier abord.
Le volume des messages ne doit pas inciter à traiter chaque entrée avec le même niveau de criticité.
Messages obsolètes #
WordPress et PHP peuvent générer des avis concernant des fonctionnalités ou des pratiques obsolètes.
De tels messages contiennent souvent des termes tels que :
Obsolète
Une dépréciation ne signifie pas nécessairement que la fonction ne fonctionne déjà plus. Elle indique que le code concerné est obsolète et peut devenir problématique dans les versions futures.
Dans le cas des plugins ou des thèmes, de nombreux nouveaux messages de dépréciation après un changement de version indiquent donc qu'il convient de vérifier l'actualité et la compatibilité de l'extension concernée.
Le nombre de signalements le plus élevé ne constitue pas automatiquement le problème le plus important #
Un plugin peut générer des centaines d'avis, tandis qu'une seule erreur fatale d'un autre composant fait réellement planter le site Web.
Le diagnostic devrait donc être effectué en fonction de la pertinence et non pas simplement selon le message qui apparaît le plus souvent dans le journal.
Lire correctement les chemins de fichiers #
Un chemin de fichier peut donner un indice important sur le composant concerné.
Un chemin au sein de :
wp-content/plugins/
mène à un plugin.
Un chemin au sein de :
wp-content/themes/
conduit à un thème ou un thème enfant.
Un chemin au sein de :
wp-admin/
ou
wp-includes/
mène au cœur de WordPress.
Un chemin de cœur WordPress ne prouve pas un bug du cœur #
Si un message d'erreur indique un fichier sous wp-includes mentionne, cela ne signifie pas automatiquement que WordPress lui-même comporte des erreurs.
Par exemple, un plugin peut appeler une fonction du cœur de WordPress avec des données non valides. L'erreur peut alors apparaître au sein de la fonction du cœur, bien que la cause réelle se situe en dehors du cœur de WordPress.
Par conséquent, l'ensemble du contexte de l'erreur est plus important que le seul dernier chemin de fichier.
Comprendre la trace de la pile #
En cas d'erreurs graves, une trace de la pile (stack trace) peut être enregistrée.
Il montre, de manière simplifiée, quelles fonctions ou méthodes ont été appelées avant que l'erreur ne se produise.
Cela permet de comprendre comment PHP est parvenu à l'endroit où l'exécution a été interrompue.
Pour les développeurs et le support technique, une trace de pile peut donc être beaucoup plus éloquente que la simple dernière ligne d'erreur.
Analyser les conflits de plugins ou de thèmes à l'aide des journaux #
Si un journal renvoie de manière répétée à un plugin ou un thème particulier, ce composant constitue un point de départ logique pour un diagnostic approfondi.
Elle devrait néanmoins faire l'objet de tests contrôlés et ne pas être simplement supprimée.
Vous trouverez notre démarche sous Détecter et résoudre les conflits de plugins ou de thèmes dans WordPress.
Erreur après un changement de PHP #
Si, immédiatement après le changement de version de PHP, de nouvelles erreurs fatales, des erreurs de type ou des messages d'obsolescence apparaissent, la compatibilité des composants concernés doit être vérifiée.
Le chemin d'accès au fichier dans le journal des erreurs peut aider à identifier une extension, un thème ou un extrait de code personnalisé obsolète.
Nous expliquons cela plus en détail sous Modifier la version PHP pour WordPress et vérifier la compatibilité.
Le journal de débogage WordPress et le journal d'erreurs PHP ne sont pas la même chose #
Cette différence est importante.
Le fichier :
wp-content/debug.log
est généré par la journalisation de débogage WordPress, si elle a été activée en conséquence.
L'environnement d'hébergement ou PHP peut également conserver ses propres journaux d'erreurs.
Ces journaux côté serveur peuvent contenir des erreurs qui n'apparaissent pas, ou pas complètement, dans le journal de débogage de WordPress.
Quel journal doit-il être vérifié en premier ? #
Si un journal des erreurs PHP ou du serveur est disponible via l'hébergement, il constitue souvent un très bon point de départ en cas de problèmes PHP graves.
Il ne nécessite pas d'affichage public permanent des erreurs et peut déjà contenir l'erreur fatale décisive.
S'il n'y a pas suffisamment d'informations, un débogage WordPress ciblé peut fournir des détails supplémentaires.
Diagnostiquer une erreur HTTP 500 à l'aide des journaux #
Lors d'une erreur HTTP 500, le navigateur affiche souvent seulement un message d'erreur de serveur général.
Le journal des erreurs peut en revanche contenir l'erreur fatale PHP sous-jacente, une erreur de mémoire ou d'autres problèmes côté serveur.
Tu trouveras la procédure complète sur Corriger l'erreur 500 dans WordPress.
Enquêter sur une erreur critique de WordPress #
WordPress peut afficher un message d'erreur critique en cas de certaines erreurs PHP fatales et, le cas échéant, proposer un mode de récupération.
Ici aussi, les journaux peuvent fournir des informations supplémentaires sur le composant qui a déclenché l'erreur.
Nous expliquons les étapes de restauration correspondantes sous WordPress affiche une page blanche ou une erreur critique : que faire ?.
Enregistrer les erreurs AJAX #
Un avantage de WP_DEBUG_LOG consiste à permettre l'enregistrement d'erreurs qui n'apparaissent pas sur une page visible normale.
C'est par exemple utile pour les requêtes AJAX.
Si un éditeur WordPress, un formulaire ou un plugin utilise une requête AJAX et que celle-ci échoue côté serveur, un journal peut fournir des indications sur l'erreur PHP.
WP-Cron et processus d'arrière-plan #
Les erreurs survenant lors des tâches WordPress planifiées peuvent également être difficiles à repérer, car aucun visiteur ne voit directement de message d'erreur correspondant.
La journalisation est donc également utile pour WP-Cron et d'autres processus d'arrière-plan.
Si un processus planifié échoue à répétition, il convient d'analyser les horodatages et les schémas d'erreur récurrents.
Erreur d'API REST #
Les fonctions et extensions WordPress modernes utilisent souvent l'API REST.
Une erreur PHP côté serveur lors d'une requête REST peut ne pas apparaître comme un message d'erreur normal dans une page WordPress visible.
Ici aussi, les journaux peuvent fournir beaucoup plus d'informations que l'interface utilisateur.
Les erreurs JavaScript ne figurent pas nécessairement dans le journal PHP #
Le débogage WordPress et les journaux d'erreurs PHP se concentrent sur les opérations côté serveur.
Par exemple, si un menu, un curseur ou un bouton ne réagit pas dans le navigateur, la cause peut plutôt provenir de JavaScript.
De telles erreurs sont souvent étudiées à l'aide des outils de développement du navigateur.
Un journal d'erreurs PHP vide ne prouve donc pas qu'il n'existe aucun dysfonctionnement technique sur un site web.
Les problèmes CSS ne figurent généralement pas non plus dans le journal PHP. #
Un élément mal affiché peut être causé par le CSS, même si le PHP fonctionne de manière totalement irréprochable.
Si un site Web fonctionne techniquement, mais que, par exemple, les espacements, les couleurs ou la mise en page sont mal affichés, les outils de développement du navigateur sont souvent l'outil de diagnostic le plus approprié.
Erreur de base de données #
Des problèmes de base de données peuvent également provoquer des erreurs techniques.
Lorsque le mode de débogage de WordPress est activé, des informations supplémentaires concernant les erreurs de base de données peuvent être visibles ou enregistrées dans les journaux.
Cependant, une erreur dans une requête SQL ne doit pas être „ réparée “ automatiquement par des modifications manuelles de la base de données. Il convient d'abord de déterminer quelle composant génère la requête problématique.
Le débogage peut lui-même affecter le site web #
Un journalisation extensive génère des opérations de fichiers supplémentaires.
Si un site Web génère un très grand nombre d'avertissements ou de notices par requête, une journalisation activée peut écrire une quantité considérable de données.
Le débogage devrait donc être considéré comme un outil de diagnostic et non comme l'état normal permanent d'un site Web de production.
Un fichier debug.log peut devenir très volumineux #
Si la même erreur est enregistrée plusieurs fois à chaque chargement de page, cela peut :
wp-content/debug.log
connaître une forte croissance en peu de temps.
Cela prend de l'espace de stockage et rend en outre l'analyse plus difficile.
Par conséquent, après un diagnostic, vous devez vérifier si le débogage a été désactivé et si un fichier journal dont vous n'avez plus besoin peut être supprimé en toute sécurité.
Les journaux peuvent contenir des informations sensibles #
Les journaux d'erreurs peuvent contenir des chemins de fichiers internes, des configurations techniques, des informations sur les requêtes et, selon l'application défectueuse, d'autres données.
Ne traitez donc pas les journaux comme des fichiers texte accessibles au public.
Lorsqu'un journal est transmis au support ou à un développeur, seul l'extrait nécessaire au diagnostic doit être envoyé, après avoir vérifié qu'il ne contient pas de données sensibles.
Attention : Ne publiez pas de journaux de débogage complets sans vérification préalable sur les forums publics, dans les tickets ou sur les réseaux sociaux. Vérifiez d'abord quelles informations ils contiennent.
debug.log dans le répertoire accessible au public #
Le chemin par défaut :
wp-content/debug.log
se trouve dans la structure des répertoires de WordPress.
Selon la configuration du serveur Web, un fichier qui y est stocké peut potentiellement être accessible via HTTP. WordPress signale donc lui-même que des journaux d'erreurs accessibles au public peuvent constituer un risque pour la sécurité.
Par conséquent, sur les environnements de production, la journalisation doit être utilisée de manière contrôlée et le fichier journal ne doit pas être conservé inutilement après la fin du diagnostic.
Désactiver le débogage après la recherche d'erreurs #
Une fois le diagnostic terminé, un site web productif doit être remis dans une configuration normale.
Une configuration WordPress simple peut par exemple à nouveau :
define( 'WP_DEBUG', false );
utiliser.
Si des constantes de débogage supplémentaires ont été ajoutées uniquement pour le diagnostic, il convient de vérifier si elles sont toujours nécessaires.
Traiter le journal de débogage après le diagnostic #
Lorsque le fichier journal n'est plus nécessaire, il peut être supprimé après la sauvegarde des informations éventuellement pertinentes.
Si la journalisation du débogage est activée ultérieurement, WordPress ou PHP pourra de nouveau enregistrer de nouveaux messages.
Cependant, la suppression d'un ancien fichier journal ne résout aucune cause. Elle sert uniquement à supprimer des informations de diagnostic qui ne sont plus nécessaires.
Ne pas confondre les erreurs du passé avec les problèmes actuels #
Une existante journal de débogage peut contenir des messages vieux de plusieurs semaines ou mois.
Lorsqu'un site web affiche une erreur aujourd'hui, il ne faut donc pas automatiquement supposer que la vieille erreur fatale la plus visible en est la cause.
La comparaison avec le moment présent est cruciale.
Identifier les schémas d'erreurs récurrents #
Si la même erreur se produit à répétition à des moments précis, cela peut indiquer un processus planifié.
Par exemple, des tâches cron, des sauvegardes, des importations ou des analyses de sécurité peuvent exécuter régulièrement certaines fonctions.
Un motif temporel dans le journal des événements peut donc fournir un indice important, même si le site Web fonctionne normalement entre ces événements.
Comparer les journaux avant et après une modification #
Lors d'un diagnostic contrôlé, vous ne devriez idéalement modifier qu'une seule variable pertinente à la fois.
Par exemple, si un plugin est désactivé, reproduisez ensuite à nouveau l'erreur et comparez les nouveaux journaux.
Si l'erreur disparaît, c'est une information nettement plus forte qu'une modification aléatoire de cinq réglages différents en même temps.
Débogage d'un site WordPress lent #
Un journal d'erreurs n'est pas un outil d'analyse des performances complet.
Cependant, cela peut fournir des indications sur des processus qui génèrent constamment des erreurs ou des avertissements et provoquent ainsi une charge supplémentaire.
Pour un diagnostic de performance complet, il faut également examiner le traitement PHP, la base de données, les plugins, les ressources frontend et les ressources d'hébergement.
Nous expliquons la procédure sous WordPress est lent : trouver les causes et améliorer le temps de chargement.
Query Monitor et des outils de diagnostic similaires #
Pour des analyses plus approfondies, il existe des plugins WordPress capables d'afficher des informations techniques supplémentaires.
Un outil bien connu est par exemple Query Monitor. Il permet notamment d'analyser les requêtes de base de données, les erreurs PHP, les hooks, les appels d'API HTTP et d'autres informations lors d'une requête.
De tels outils s'adressent principalement aux développeurs et aux utilisateurs expérimentés sur le plan technique.
Ils ne devraient pas rester installés et activés en permanence simplement parce qu'un site Web a eu un problème à un moment donné.
SCRIPT_DEBUG n'est pas la même chose que WP_DEBUG #
WordPress connaît en outre :
DÉBOGAGE_DE_SCRIPT
Cette constante n'est pas avec WP_DEBUG assimiler.
Elle est particulièrement utilisée pour le développement et le diagnostic des fichiers JavaScript ou CSS du noyau de WordPress et n'est généralement pas nécessaire pour un débogage PHP normal.
N'utiliser SAVEQUERIES que de manière ciblée #
Il existe également pour les diagnostics de base de données :
SAVEQUERIES
Cela permet de collecter des informations sur les requêtes de base de données.
Cette fonction génère une charge mémoire et de performance supplémentaire et ne doit donc être utilisée qu'à des fins de diagnostic ciblées.
Pour les utilisateurs de WordPress habituels, ce n'est généralement pas la première étape lors d'un dépannage courant.
Différencier le débogage en staging et en production #
Sur un environnement de développement ou de staging, des informations de diagnostic détaillées peuvent être utiles car aucun visiteur normal n'y est affecté.
Sur un site Web de production, il faut en revanche veiller davantage à ce que les informations techniques ne soient pas rendues publiques et que la journalisation ne reste active que le temps nécessaire.
La même configuration de débogage n'est par conséquent pas automatiquement adaptée à chaque environnement.
Ce que vous feriez mieux de ne pas faire lors du débogage #
N'activez pas simplement l'affichage public de toutes les erreurs PHP sur un site web de production pour ensuite laisser ce paramètre activé en permanence.
Ne modifiez pas non plus simultanément plusieurs extensions, le thème, PHP et la configuration de WordPress. Cela rendrait difficile de déterminer quelle modification a réellement causé l'erreur.
Ne supprimez pas immédiatement un composant simplement parce que son chemin de fichier apparaît dans un journal. Vérifiez d'abord le contexte et reproduisez l'erreur de manière contrôlée.
Et n'envoyez pas de fichiers journaux complets sans les avoir vérifiés à des tiers quelconques.
Règle de base : Reproduire l'erreur, noter l'heure, identifier les entrées de journal pertinentes et seulement ensuite apporter une modification ciblée. Tester ensuite à nouveau la même erreur. C'est ainsi que les essais et erreurs se transforment en un diagnostic technique traçable.
Quelles informations aident le support de CURIAWEB ? #
Si vous contactez CURIAWEB au sujet d'une erreur WordPress, décrivez d'abord quelle action déclenche l'erreur et quand elle s'est produite pour la dernière fois.
Un extrait de journal pertinent avec un horodatage est beaucoup plus utile qu'un fichier complet contenant des milliers de messages plus anciens.
S'il y a une erreur fatale, le message d'erreur complet correspondant, y compris le chemin du fichier et éventuellement la trace de la pile, doit être transmis.
Précisez également si WordPress, une extension, le thème, PHP ou du code personnalisé a été modifié immédiatement avant.
Supprimez ou masquez les informations sensibles si elles ne sont pas nécessaires au diagnostic. Vous ne devez jamais envoyer de mots de passe de manière non sollicitée dans un journal d'erreurs ou un ticket de support.
Résumé #
Le débogage WordPress et les journaux d'erreurs comptent parmi les outils les plus importants pour le dépannage technique systématique. Au lieu de se contenter de deviner sur la base d'un message d'erreur visible, les journaux peuvent montrer quelle erreur s'est réellement produite, quand elle est apparue et quelle zone de code était concernée.
Le réglage central WP_DEBUG active le mode de débogage WordPress. Avec WP_DEBUG_LOG les messages peuvent être consignés pendant que WP_DEBUG_DISPLAY détermine si ces informations sont affichées sur le site Web.
Sur un site web en production, il est généralement plus judicieux de consigner les erreurs de manière contrôlée plutôt que d'afficher publiquement des détails techniques. Le fichier de débogage WordPress par défaut wp-content/debug.log devrait également être considéré comme un fichier potentiellement sensible.
Lors de l'évaluation, le type d'erreur, l'horodatage, le chemin du fichier et, le cas échéant, la trace de la pile sont particulièrement importants. Un chemin de fichier fournit un indice, mais ne prouve pas toujours à lui seul quelle composante est la cause réelle.
Une fois le diagnostic terminé, le débogage doit être désactivé de manière appropriée sur un site Web de production, et un fichier journal qui n'est plus nécessaire doit être supprimé ou traité en toute sécurité.
La méthode la plus importante reste simple : Reproduire l'erreur, vérifier les journaux, identifier la cause, effectuer une modification ciblée, puis tester à nouveau.
