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.
Auch hier können Logs zusätzliche Informationen darüber liefern, welche Komponente den Fehler ausgelöst hat.
Die entsprechenden Wiederherstellungsschritte erklären wir unter WordPress affiche une page blanche ou une erreur critique : que faire ?.
AJAX-Fehler protokollieren #
Ein Vorteil von WP_DEBUG_LOG besteht darin, dass Fehler protokolliert werden können, die nicht auf einer normalen sichtbaren Seite erscheinen.
Das ist beispielsweise bei AJAX-Anfragen hilfreich.
Wenn ein WordPress-Editor, Formular oder Plugin eine AJAX-Anfrage verwendet und diese serverseitig fehlschlägt, kann ein Log Hinweise auf den PHP-Fehler liefern.
WP-Cron und Hintergrundprozesse #
Auch Fehler während geplanter WordPress-Aufgaben können schwierig zu erkennen sein, weil kein Besucher unmittelbar eine entsprechende Fehlermeldung sieht.
Logging ist deshalb auch bei WP-Cron und anderen Hintergrundprozessen hilfreich.
Wenn ein geplanter Prozess immer wieder fehlschlägt, sollten Zeitstempel und wiederkehrende Fehlermuster untersucht werden.
REST-API-Fehler #
Moderne WordPress-Funktionen und Plugins verwenden häufig die REST API.
Ein serverseitiger PHP-Fehler während einer REST-Anfrage erscheint möglicherweise nicht als normale Fehlermeldung innerhalb einer sichtbaren WordPress-Seite.
Auch hier können Logs wesentlich mehr Informationen liefern als die Benutzeroberfläche.
JavaScript-Fehler stehen nicht zwingend im PHP-Log #
WordPress-Debugging und PHP Error Logs konzentrieren sich auf serverseitige Vorgänge.
Wenn beispielsweise ein Menü, Slider oder Button im Browser nicht reagiert, kann die Ursache stattdessen in JavaScript liegen.
Solche Fehler werden häufig über die Entwicklerwerkzeuge des Browsers untersucht.
Ein leeres PHP-Error-Log beweist deshalb nicht, dass auf einer Website keinerlei technischer Fehler existiert.
CSS-Probleme stehen normalerweise ebenfalls nicht im PHP-Log #
Ein falsch dargestelltes Element kann durch CSS verursacht werden, obwohl PHP vollständig fehlerfrei arbeitet.
Wenn eine Website technisch funktioniert, aber beispielsweise Abstände, Farben oder Layout falsch dargestellt werden, sind die Browser-Entwicklerwerkzeuge häufig das geeignetere Diagnosewerkzeug.
Datenbankfehler #
Auch Datenbankprobleme können technische Fehler verursachen.
Bei aktiviertem WordPress-Debugging können zusätzliche Informationen zu Datenbankfehlern sichtbar beziehungsweise protokolliert werden.
Ein Fehler in einer SQL-Abfrage sollte allerdings nicht automatisch durch manuelle Änderungen an der Datenbank „repariert“ werden. Zunächst sollte festgestellt werden, welche Komponente die problematische Abfrage erzeugt.
Debugging kann die Website selbst beeinflussen #
Umfangreiches Logging erzeugt zusätzliche Dateioperationen.
Wenn eine Website pro Anfrage sehr viele Warnings oder Notices produziert, kann eine aktivierte Protokollierung eine große Menge an Daten schreiben.
Debugging sollte deshalb als Diagnosewerkzeug und nicht als dauerhaft eingeschalteter Normalzustand einer produktiven Website betrachtet werden.
Eine debug.log kann sehr groß werden #
Wenn derselbe Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann:
wp-content/debug.log
innerhalb kurzer Zeit stark anwachsen.
Das beansprucht Speicherplatz und erschwert zusätzlich die Auswertung.
Nach einer Diagnose solltest du deshalb prüfen, ob das Debugging wieder deaktiviert wurde und ob eine nicht mehr benötigte Logdatei sicher entfernt werden kann.
Logs können sensible Informationen enthalten #
Fehlerprotokolle können interne Dateipfade, technische Konfigurationen, Abfrageinformationen und je nach fehlerhafter Anwendung weitere Daten enthalten.
Behandle Logs deshalb nicht wie öffentlich zugängliche Textdateien.
Wenn ein Log an Support oder einen Entwickler weitergegeben wird, sollte nur der für die Diagnose erforderliche Ausschnitt übermittelt und vorher geprüft werden, ob darin sensible Daten enthalten sind.
Attention : Veröffentliche vollständige Debug-Logs nicht ungeprüft in öffentlichen Foren, Tickets oder sozialen Netzwerken. Kontrolliere zuerst, welche Informationen darin enthalten sind.
debug.log im öffentlich erreichbaren Verzeichnis #
Der Standardpfad:
wp-content/debug.log
liegt innerhalb der WordPress-Verzeichnisstruktur.
Abhängig von der Webserver-Konfiguration kann eine dort abgelegte Datei potenziell über HTTP erreichbar sein. WordPress weist deshalb selbst darauf hin, dass öffentlich erreichbare Fehlerprotokolle ein Sicherheitsrisiko darstellen können.
Auf produktiven Umgebungen sollte Logging daher kontrolliert eingesetzt und die Logdatei nach Abschluss der Diagnose nicht unnötig bestehen gelassen werden.
Debugging nach der Fehlersuche wieder deaktivieren #
Nach Abschluss der Diagnose sollte eine produktive Website wieder in eine normale Konfiguration versetzt werden.
Eine einfache WordPress-Konfiguration kann beispielsweise wieder:
define( 'WP_DEBUG', false );
utiliser.
Wenn zusätzliche Debug-Konstanten nur für die Diagnose ergänzt wurden, sollte geprüft werden, ob sie weiterhin benötigt werden.
Debug-Log nach der Diagnose behandeln #
Wenn die Logdatei nicht mehr benötigt wird, kann sie nach Sicherung eventuell relevanter Informationen entfernt werden.
Wird Debug-Logging später erneut aktiviert, kann WordPress beziehungsweise PHP wieder neue Meldungen protokollieren.
Das Entfernen einer alten Logdatei behebt allerdings keine Ursache. Es dient lediglich dazu, nicht mehr benötigte Diagnoseinformationen zu entfernen.
Alte Fehler nicht mit aktuellen Problemen verwechseln #
Eine vorhandene journal de débogage kann Meldungen enthalten, die Wochen oder Monate alt sind.
Wenn eine Website heute einen Fehler zeigt, sollte deshalb nicht automatisch der auffälligste alte Fatal Error als Ursache angenommen werden.
Der Vergleich mit dem aktuellen Zeitpunkt ist entscheidend.
Wiederkehrende Fehlermuster erkennen #
Wenn derselbe Fehler immer wieder zu bestimmten Zeiten auftritt, kann das auf einen geplanten Prozess hinweisen.
Beispielsweise können Cronjobs, Backups, Imports oder Sicherheits-Scans regelmäßig bestimmte Funktionen ausführen.
Ein zeitliches Muster im Log kann deshalb einen wichtigen Hinweis liefern, auch wenn die Website zwischen diesen Ereignissen normal funktioniert.
Logs vor und nach einer Änderung vergleichen #
Bei einer kontrollierten Diagnose solltest du möglichst nur eine relevante Variable gleichzeitig verändern.
Wenn beispielsweise ein Plugin deaktiviert wird, reproduziere anschließend den Fehler erneut und vergleiche die neuen Logeinträge.
Verschwindet der Fehler, ist das eine wesentlich stärkere Information als eine zufällige Änderung von fünf verschiedenen Einstellungen gleichzeitig.
Debugging bei einer langsamen WordPress-Website #
Ein Error Log ist kein vollständiges Performance-Analysewerkzeug.
Es kann jedoch Hinweise auf Prozesse liefern, die ständig Fehler oder Warnungen erzeugen und dadurch zusätzliche Last verursachen.
Für eine vollständige Performance-Diagnose müssen zusätzlich PHP-Verarbeitung, Datenbank, Plugins, Frontend-Ressourcen und Hosting-Ressourcen betrachtet werden.
Nous expliquons la procédure sous WordPress est lent : trouver les causes et améliorer le temps de chargement.
Query Monitor und ähnliche Diagnosewerkzeuge #
Für weitergehende Analysen existieren WordPress-Plugins, die zusätzliche technische Informationen darstellen können.
Ein bekanntes Werkzeug ist beispielsweise Query Monitor. Damit können unter anderem Datenbankabfragen, PHP-Fehler, Hooks, HTTP-API-Aufrufe und weitere Informationen während einer Anfrage untersucht werden.
Solche Werkzeuge richten sich vor allem an Entwickler und technisch erfahrene Benutzer.
Sie sollten nicht dauerhaft nur deshalb installiert und aktiviert bleiben, weil eine Website irgendwann einmal einen Fehler hatte.
SCRIPT_DEBUG ist nicht dasselbe wie WP_DEBUG #
WordPress kennt zusätzlich:
SCRIPT_DEBUG
Diese Konstante ist nicht mit WP_DEBUG gleichzusetzen.
Sie wird insbesondere bei der Entwicklung und Diagnose von WordPress-Core-JavaScript- beziehungsweise CSS-Dateien verwendet und ist für eine normale PHP-Fehlersuche in der Regel nicht erforderlich.
SAVEQUERIES nur gezielt verwenden #
Für Datenbankdiagnosen existiert außerdem:
SAVEQUERIES
Damit können Informationen zu Datenbankabfragen gesammelt werden.
Diese Funktion erzeugt zusätzlichen Speicher- und Performance-Aufwand und sollte deshalb nur gezielt zur Diagnose eingesetzt werden.
Für normale WordPress-Benutzer ist sie bei einer üblichen Fehlersuche normalerweise nicht der erste Schritt.
Debugging auf Staging und Produktion unterscheiden #
Auf einer Entwicklungs- oder Staging-Umgebung können ausführliche Diagnoseinformationen sinnvoll sein, weil dort keine normalen Besucher betroffen sind.
Auf einer produktiven Website muss dagegen stärker darauf geachtet werden, dass technische Informationen nicht öffentlich ausgegeben werden und das Logging nur so lange wie nötig aktiv bleibt.
Die gleiche Debug-Konfiguration ist deshalb nicht automatisch für jede Umgebung geeignet.
Was du beim Debugging besser nicht tun solltest #
Aktiviere nicht einfach die öffentliche Ausgabe sämtlicher PHP-Fehler auf einer produktiven Website und lasse diese Einstellung anschließend dauerhaft bestehen.
Ändere außerdem nicht gleichzeitig mehrere Plugins, das Theme, PHP und die WordPress-Konfiguration. Dadurch wird schwer nachvollziehbar, welche Änderung den Fehler tatsächlich beeinflusst hat.
Lösche nicht sofort eine Komponente nur deshalb, weil ihr Dateipfad in einem Log erscheint. Prüfe zunächst den Zusammenhang und reproduziere den Fehler kontrolliert.
Und sende vollständige Logdateien nicht ungeprüft an beliebige Dritte.
Règle de base : Fehler reproduzieren, Zeitpunkt notieren, relevante Logeinträge identifizieren und erst danach eine gezielte Änderung vornehmen. Anschließend denselben Fehler erneut testen. So wird aus Ausprobieren eine nachvollziehbare technische Diagnose.
Quelles informations aident le support de CURIAWEB ? #
Wenn du CURIAWEB wegen eines WordPress-Fehlers kontaktierst, beschreibe zunächst, welche Aktion den Fehler auslöst und wann er zuletzt aufgetreten ist.
Ein relevanter Logausschnitt mit Zeitstempel ist wesentlich hilfreicher als eine vollständige Datei mit tausenden älteren Meldungen.
Wenn ein Fatal Error vorhanden ist, sollte die vollständige zugehörige Fehlermeldung einschließlich Dateipfad und gegebenenfalls Stack Trace übermittelt werden.
Teile außerdem mit, ob unmittelbar zuvor WordPress, ein Plugin, das Theme, PHP oder individueller Code verändert wurde.
Entferne beziehungsweise schwärze sensible Informationen, falls sie für die Diagnose nicht benötigt werden. Passwörter solltest du niemals unaufgefordert in einem Fehlerprotokoll oder Support-Ticket mitsenden.
Résumé #
WordPress Debugging und Fehlerprotokolle gehören zu den wichtigsten Werkzeugen für eine systematische technische Fehlersuche. Statt lediglich aufgrund einer sichtbaren Fehlermeldung zu raten, können Logs zeigen, welcher Fehler tatsächlich aufgetreten ist, wann er entstand und welcher Codebereich beteiligt war.
Die zentrale Einstellung WP_DEBUG aktiviert den WordPress-Debug-Modus. Mit WP_DEBUG_LOG können Meldungen protokolliert werden, während WP_DEBUG_DISPLAY steuert, ob diese Informationen auf der Website angezeigt werden.
Auf einer produktiven Website ist es normalerweise sinnvoller, Fehler kontrolliert zu protokollieren, statt technische Details öffentlich auszugeben. Die standardmäßige WordPress-Debugdatei wp-content/debug.log sollte außerdem als potenziell sensible Datei behandelt werden.
Bei der Auswertung sind Fehlertyp, Zeitstempel, Dateipfad und gegebenenfalls Stack Trace besonders wichtig. Ein Dateipfad liefert einen Hinweis, beweist aber nicht immer allein, welche Komponente die eigentliche Ursache ist.
Nach Abschluss der Diagnose sollte Debugging auf einer produktiven Website wieder passend deaktiviert und eine nicht mehr benötigte Logdatei entfernt beziehungsweise sicher behandelt werden.
Die wichtigste Methode bleibt dabei einfach: Fehler reproduzieren, Log prüfen, Ursache eingrenzen, eine gezielte Änderung durchführen und anschließend erneut testen.
