Die leere Seite gibt keinen Aufschluss darüber, ob ein Plugin, das WordPress-Theme oder PHP die Fehlerursache ist. Der WordPress-Debug-Modus hilft dabei, herauszufinden, wo Sie nach dem Problem suchen sollten, doch bei falscher Konfiguration können die technischen Details auch für Besucher sichtbar werden. Protokollieren Sie die Fehler daher und zeigen Sie sie nicht auf der Website an.

Es ist nicht immer klar, was in der Datei „wp-config.php“ geändert werden muss und wo sich das Protokoll befindet. In dieser Anleitung zeigen wir Ihnen Schritt für Schritt, wie Sie „WP_DEBUG“ und „WP_DEBUG_LOG“ sicher einrichten, die Datei „debug.log“ finden und die Einträge interpretieren. Außerdem zeigen wir Ihnen, wann es sinnvoll ist, das PHP-Fehlerprotokoll Ihres Webhostings zu überprüfen, beispielsweise wenn WordPress gar nicht erst startet. Abschließend gehen wir darauf ein, wie Sie den Debug-Modus deaktivieren und warum es wichtig ist, die Protokolldatei von der Live-Seite zu entfernen. Der Debug-Modus behebt den Fehler zwar nicht, hilft Ihnen jedoch dabei, dessen Ursache zu finden.

Was bedeutet die Fehlersuche in WordPress im Debug-Modus, und wann wird sie verwendet?

WP_DEBUG ist eine PHP-Konstante von WordPress. Wenn diese aktiviert wird, stehen Debugging-Informationen zur Verfügung, die Ihnen helfen zu verstehen, was während des Betriebs Ihrer Website geschieht. Der WordPress-Debugging-Modus ist ein nützlicher Ausgangspunkt, wenn nach dem Auftreten eines Fehlers unklar ist, ob WordPress, das WordPress-Theme oder eine der PHP-Erweiterungen betroffen ist.

Betrachten Sie die Log-Einträge als Anhaltspunkte und nicht als fertige Diagnose. Ein Dateiname oder eine Codezeile kann zwar aufzeigen, wo das Problem aufgetreten ist, aber nicht unbedingt, wodurch es ausgelöst wurde. Um die Meldung richtig zu interpretieren, sollten Sie berücksichtigen, welche Aktion dem Fehler vorausging, ob ein Update stattgefunden hat und ob sich das Phänomen wiederholen lässt.

Das Ziel der Fehlersuche ist die systematische Ermittlung der Fehlerquelle. Auch die Grundlagen der Fehlersuche befassen sich mit diesem diagnostischen Prozess. Dieser Leitfaden konzentriert sich auf die integrierten Fehlersuchfunktionen von WordPress. Die Analyse von Datenbankverbindungsfehlern und Webserver-Protokollen ist ein separates Thema. Das PHP-Fehlerprotokoll Ihres Webhostings kann nützlich sein, wenn WordPress noch nicht so weit ist, ein eigenes Protokoll zu erstellen.

Bei welchen Fehlern kann WP_DEBUG helfen?

WP_DEBUG kann dabei helfen, PHP-Fehler, Warnungen und Meldungen über veraltete Funktionen aufzudecken. Diese können nach einem Update oder bei der Nutzung einer bestimmten Seite, eines Formulars oder eines Verwaltungsvorgangs auftreten. Der im Protokoll angegebene Dateipfad kann auf eine PHP-Erweiterung, eine Vorlage oder eine WordPress-Datei verweisen.

• PHP-Fehler: Dies kann darauf hinweisen, dass die Ausführung des Codes unterbrochen wurde.
• Warnung: Hier wird auf einen Codeausschnitt hingewiesen, der später zu Problemen führen könnte.
• Meldung bezüglich einer veralteten Funktion: Dies kann darauf hindeuten, dass eine Komponente eine ältere Programmierlösung verwendet.

Die Meldung allein beweist nicht, dass die genannte Komponente den Fehler verursacht hat. Es kann vorkommen, dass der Code eines Plugins aufgrund eines Fehlers in einer anderen Komponente nicht ordnungsgemäß ausgeführt wird. Notieren Sie sich, wann die Meldung erschien, welche Aktion ihr vorausging und welche Datei genau darin genannt wird.

Was ist der Unterschied zwischen der Fehlersuche und der Fehlerbehebung?

WP_DEBUG macht Fehlerinformationen sichtbar, korrigiert den Code jedoch nicht. Die Fehlersuche dient der Ermittlung des Problems. Die Behebung ist ein separater Schritt, der die Änderung des betroffenen Codes oder der betreffenden Einstellung beinhaltet. Überprüfen Sie anschließend, ob die Änderung den Fehler behoben hat und keine neuen Funktionsstörungen verursacht hat.

1. Diagnose: Notieren Sie die Fehlermeldung und die Umstände, unter denen sie aufgetreten ist.
2. Änderung: Nehmen Sie die Änderung entsprechend der ermittelten Ursache vor, möglichst in einer Testumgebung.
3. Überprüfung: Wiederholen Sie den betreffenden Vorgang und prüfen Sie, ob der Fehler behoben wurde.

Erstellen Sie vor der Änderung von Dateien oder Einstellungen ein Backup, damit Sie im Falle eines Fehlers den vorherigen Zustand wiederherstellen können. Sofern die Verfügbarkeit einer Testumgebung besteht, testen Sie die Änderung dort und nicht direkt auf der von Besuchern genutzten Live-Website.

Wie aktivieren Sie den WordPress-Debug-Modus in der Datei „wp-config.php“?

Die Einstellungen müssen in der Datei „wp-config.php“ im Stammverzeichnis von WordPress vorgenommen werden. Erstellen Sie vor der Änderung ein Backup der Datei, damit Sie im Falle eines Tippfehlers oder einer fehlerhaften Einstellung die ursprüngliche Version wiederherstellen können.

1. Erstellen Sie eine Sicherungskopie. Laden Sie die aktuelle Datei „wp-config.php“ herunter oder kopieren Sie sie an einen sicheren Ort.
2. Öffnen Sie die Datei. Suchen Sie im Dateimanager Ihres Webhostings das Installationsverzeichnis von WordPress. Über den Dateimanager in der cPanel-Oberfläche können Sie die Datei öffnen und bearbeiten. Achten Sie bei der Verwaltung Ihres cPanel-Hostings darauf, dass Sie im Verzeichnis der richtigen Website arbeiten.
3. Überprüfen Sie die bestehenden Einstellungen. Suchen Sie nach den Bezeichnungen „WP_DEBUG“, „WP_DEBUG_LOG“ und „WP_DEBUG_DISPLAY“. Sollte eine dieser Definitionen bereits vorhanden sein, ändern Sie deren Wert, fügen Sie jedoch keine neue Definition hinzu.
4. Fügen Sie die Konfiguration ein. Die Zeilen sollten vor dem abschließenden Kommentar des WordPress-Editors eingefügt werden, der in der Regel den Text „That’s all, stop editing!“ enthält. Laden Sie die Seite nach dem Speichern neu und überprüfen Sie, ob alles ordnungsgemäß funktioniert.

Welche WP_DEBUG-Einstellungen sollten zusammen verwendet werden?

WP_DEBUG aktiviert den Debug-Modus von WordPress. WP_DEBUG_LOG ermöglicht das Schreiben von Debug-Meldungen in eine Datei, während WP_DEBUG_DISPLAY regelt, ob diese auf der Website angezeigt werden. Deaktivieren Sie die Anzeige auf der Live-Seite. Sie können dies auch über die PHP-Einstellung „display_errors“ deaktivieren.

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

@ini_set( 'display_errors', 0 );

Diese Konfiguration protokolliert Fehler, zeigt sie den Besuchern jedoch nicht an. Der offizielle WordPress-Leitfaden zur Fehlerbehebung enthält weitere Einzelheiten zur Funktionsweise von Konstanten und zur Protokollierung.

Wie bearbeiten Sie die Datei „wp-config.php“ auf sichere Weise?

Bitte überprüfen Sie vor dem Speichern die Semikolons und Anführungszeichen sowie, ob jede „define()“-Zeile eine eigene Konstante definiert. Definieren Sie dieselbe Konstante nicht zweimal, da dies zu einer Warnmeldung oder zu unvorhersehbarem Verhalten führen kann. Versuchen Sie nach der Änderung, sowohl die Website als auch das WordPress-Admin-Panel zu öffnen.

Bei der Fehlersuche in WordPress (Debug-Modus) ist die Protokollierung eine sicherere Lösung als die direkte Anzeige detaillierter PHP-Meldungen. Sollte die Seite nach dem Speichern der Konfigurationsdatei einen Fehler anzeigen, stellen Sie bitte die gespeicherte Version wieder her und überprüfen Sie die Änderungen anschließend erneut.

Wo finden Sie die Datei „debug.log“ und wie lesen Sie die Einträge darin?

Wenn Sie die Protokollierung über die Einstellung „WP_DEBUG_LOG“ aktiviert haben, erstellt WordPress standardmäßig die Datei „debug.log“ im Verzeichnis „wp-content“ Ihrer Installation. Öffnen Sie im Dateimanager Ihres WordPress-Hostings das Stammverzeichnis von WordPress und wechseln Sie anschließend in den Ordner „wp-content“. Suchen Sie die Datei und laden Sie sie herunter oder öffnen Sie sie im Textmodus. Bei einem benutzerdefinierten Protokollpfad suchen Sie die Datei an der entsprechenden Stelle.

Bevor Sie die Einträge durchsehen, notieren Sie sich bitte, wann der Fehler aufgetreten ist und während welcher Aktion. Notieren Sie beispielsweise, wenn nach der Aktualisierung eines Plugins beim Aufrufen der Seite dieses Plugins eine leere Seite angezeigt wird. Suchen Sie anschließend nach Log-Einträgen, die zeitlich nahe an diesem Zeitpunkt liegen. Sowohl Einträge vor als auch nach dem Fehler können wichtige Zusammenhänge aufzeigen.

Welche Fehlermeldung könnte der wichtigste Anhaltspunkt sein?

Prüfen Sie gemeinsam die Art des Fehlers, den Pfad der betroffenen Datei und die angegebene Zeilennummer. Im Dateinamen kann ein Plugin oder ein Vorlagenverzeichnis enthalten sein, und die Zeilennummer gibt an, an welcher Stelle in der jeweiligen Datei die Fehlermeldung aufgetreten ist. Der Zeitpunkt des Fehlers und der Dateipfad helfen dabei, die Untersuchung einzugrenzen. Dies beweist jedoch noch nicht, dass die betreffende Komponente fehlerhaft ist. Die Warnung oder der Eintrag, der auf eine veraltete Funktion hinweist, führt nicht zwangsläufig zu einem Ausfall der Seite.

Informationen zur allgemeinen Funktionsweise der Protokollierung von PHP-Meldungen finden Sie in der Dokumentation zur PHP-Fehlerprotokollierung. Das WordPress-Protokoll ist nicht mit den Protokollen des Webservers identisch. Dieser Abschnitt konzentriert sich auf die Interpretation der Datei „debug.log“; die detaillierte Analyse der Serverprotokolle ist Gegenstand einer gesonderten Untersuchung.

Wie lassen sich das Symptom und die mögliche Ursache voneinander unterscheiden?

Vergleichen Sie den Zeitpunkt des Fehlers mit kürzlich vorgenommenen Änderungen an Plugins oder Templates, Updates und Einstellungsänderungen. Falls im Protokoll der Pfad eines Plugins aufgeführt ist, notieren Sie bitte, ob der Fehler nach dessen Aktualisierung oder Verwendung aufgetreten ist. Die in der Datei genannte Komponente könnte betroffen sein, doch ein Protokolleintrag allein belegt noch keinen kausalen Zusammenhang.

Überprüfen Sie die Hypothese anhand eines kontrollierten Tests, möglichst in einer Testumgebung, und nehmen Sie jeweils nur eine Änderung vor. Auf diese Weise können Sie feststellen, ob das Symptom mit der jeweiligen Änderung zusammenhängt. Vergleichen Sie während der WordPress-Fehlersuche (Debug-Modus) die Log-Einträge mit dem wiederholbaren Verhalten und ziehen Sie keine sicheren Schlussfolgerungen aus einer einzelnen Zeile.

Wie können Sie den Fehler untersuchen, ohne Daten offenzulegen?

Das Protokoll kann nützliche technische Daten, Pfade sowie Details zur Serverumgebung enthalten. Zeigen Sie daher auf einer live geschalteten Website keine PHP-Meldungen für Besucher an. Der Wert von WP_DEBUG_DISPLAY sollte auf false gesetzt sein, und Fehler sollten in einer Datei protokolliert werden. Bei Verfügbarkeit einer Testumgebung lösen Sie den Fehler dort aus, damit die Nutzung der Website durch die Besucher möglichst wenig beeinträchtigt wird.

Befolgen Sie diese Reihenfolge und setzen Sie die Debugging-Einstellungen am Ende der Überprüfung wieder zurück:

1. Erstellen Sie ein Backup. Sichern Sie den aktuellen Zustand, bevor Sie Änderungen an der Konfiguration und den betroffenen Dateien vornehmen.
2. Aktivieren Sie die Protokollierung. Stellen Sie die Ausgabe von Fehlern in eine Datei ein und deaktivieren Sie die Anzeige auf dem Bildschirm.
3. Stellen Sie den Fehler nach. Führen Sie den Vorgang aus, bei dem der Fehler auftritt, und notieren Sie den Zeitpunkt.
4. Überprüfen Sie das Protokoll. Suchen Sie den Eintrag, der dem betreffenden Zeitpunkt am nächsten liegt, und notieren Sie sich die Meldung, den Dateipfad sowie die betroffene Komponente.
5. Beenden Sie die Untersuchung. Setzen Sie die Debugging-Einstellungen zurück und löschen Sie die Protokolldatei von der Live-Website, nachdem Sie die erforderlichen Informationen sicher gespeichert haben.

Was sollten Sie tun, wenn der Name eines Plugins oder einer Vorlage im Protokoll erscheint?

Notieren Sie sich den Namen des Moduls, die vollständige Fehlermeldung und die Umstände, unter denen der Fehler aufgetreten ist. Vergleichen Sie diese Angaben mit kürzlich vorgenommenen Änderungen, betrachten Sie den Dateinamen jedoch nicht als alleinigen Beweis. Sofern die Verfügbarkeit einer Testumgebung besteht, überprüfen Sie dort, ob das Deaktivieren oder Aktualisieren des betreffenden Plugins oder der Vorlage das Symptom verändert. Löschen oder überschreiben Sie keinen Code allein aufgrund einer einzigen Log-Zeile.

Wie können Sie Debugging-Informationen schützen?

Lassen Sie die Fehleranzeige auf dem Bildschirm auch während der Diagnose ausgeschaltet. Kopieren Sie den Inhalt des Protokolls nicht in ein öffentliches Forum oder auf eine Plattform, auf die jeder Zugriff hat. Sollten Sie einen Auszug weitergeben müssen, entfernen Sie zuvor alle personenbezogenen Daten oder Angaben, die Rückschlüsse auf die Umgebung zulassen, wie beispielsweise vollständige Pfadangaben. Prüfen Sie nach Abschluss der Untersuchung, ob Sie das Protokoll noch benötigen, und lassen Sie keine Einträge mehr auf der live geschalteten Website anfallen.

Überprüfen Sie nach dem Beenden des WordPress-Debug-Modus die Website und den Administrationsbereich und vergewissern Sie sich, dass der Debug-Modus deaktiviert ist. Für weitere Informationen zu den Hosting- und WordPress-Einstellungen ist die aWh-Wissensdatenbank ein nützlicher Ausgangspunkt.

Wie deaktivieren Sie den Debug-Modus und wann sollten Sie die Hosting-Umgebung überprüfen?

Überprüfen Sie nach Abschluss der Fehlerbehebung nicht nur, ob die Fehlermeldung verschwunden ist. Setzen Sie die temporären Einstellungen zurück, entfernen Sie die Protokolldatei von der Live-Website und testen Sie die betroffene Funktion anschließend erneut. Auf diese Weise bleiben die für die Diagnose verwendeten Daten nicht unnötig zugänglich, und Sie stellen zudem sicher, dass die Website wieder normal funktioniert.

1. Öffnen Sie die Datei „wp-config.php“. Erstellen Sie eine Sicherungskopie davon und suchen Sie anschließend nach den Konstanten, die zur Fehlerbehebung hinzugefügt wurden.
2. Deaktivieren Sie die Fehlerausgabe. Setzen Sie den Wert von „WP_DEBUG“ auf „false“. Überprüfen Sie außerdem die Einstellungen für „WP_DEBUG_LOG“ und „WP_DEBUG_DISPLAY“, um sicherzustellen, dass weder die Protokollierung noch die Anzeige auf dem Bildschirm aktiv bleibt.
3. Speichern Sie die Änderung und überprüfen Sie anschließend die Seite. Laden Sie die betroffene Seite sowie das Administrationsportal erneut. Wiederholen Sie zudem den Vorgang, der zuvor zu einem Fehler geführt hat.
4. Entfernen Sie die nicht mehr benötigte Protokolldatei. Sobald die Diagnose abgeschlossen ist, löschen Sie die Datei „debug.log“ von der Live-Website, damit deren Inhalt nicht unnötig dort verbleibt.

Welche Überprüfungen sollten Sie beim Abschluss der Fehlersuche durchführen?

Bitte überprüfen Sie, ob auf der Website ein PHP-Fehler oder eine technische Warnung angezeigt wird. Sehen Sie sich die geänderte Konfiguration noch einmal an, insbesondere die Werte der Konstanten und eventuelle doppelte Definitionen. Testen Sie anschließend die zuvor fehlerhafte Funktion, beispielsweise die Anmeldung oder das Laden der betroffenen Seite. WP_DEBUG unterstützt die Fehlerdiagnose, garantiert jedoch nicht allein die Behebung des Fehlers.

Wann sind WordPress-Hosting und die Wissensdatenbank relevant?

Sollten Sie im Protokoll eher Hinweise finden, die sich auf die Ausführungsumgebung beziehen, trennen Sie bitte die WordPress-Einstellungen von den Bedingungen auf der Hosting-Seite. In diesem Fall sollte die Überprüfung der Hosting-Umgebung der nächste Schritt sein, nicht das willkürliche Ändern von WordPress-Dateien. Eine detaillierte serverseitige Log-Analyse erfordert eine gesonderte Untersuchung. Auf den aWh-cPanel-Hosting-Paketen wird in einem Knowledge-Base-Artikel zum Debugging-Modus erläutert, wo sich das PHP-Fehlerprotokoll befindet und wie WordPress das Protokoll an einen Ort schreibt, der über das Web nicht zugänglich ist.

Im aWh WordPress-Hosting-Paket ist WordPress bereits vorinstalliert, und das WordPress Toolkit Deluxe unterstützt die Verwaltung von WordPress. Dabei handelt es sich um Tools zur Unterstützung des Betriebs, nicht um automatische Fehlerbehebungen. Für weitere Informationen zu den Einstellungen bieten die Artikel in der Wissensdatenbank einen praktischen Ausgangspunkt. Überprüfen Sie nach Abschluss der WordPress-Fehlersuche (Debug-Modus) die Funktionsweise der Seite auch anhand der tatsächlichen Nutzungsprozesse.

Sorgen Sie auch nach der Fehlerbehebung für einen sicheren Betrieb

Der WordPress-Debug-Modus ist ein nützliches Diagnosetool, doch lassen Sie ihn nur so lange aktiviert, wie Sie die Protokolleinträge benötigen. Überprüfen Sie nach dem Deaktivieren die Funktionsfähigkeit der Seite und überlegen Sie, wie Sie verhindern können, dass ein späteres Update oder eine Änderung zu unerwarteten Störungen führt. Konsequentes Testen kann Ihnen dabei helfen, im Falle eines erneuten Fehlers schneller die Richtung für die Fehlerbehebung festzulegen.

Die PHP-Version ist ebenfalls Teil der WordPress-Betriebsumgebung. Mit den in den Hosting-Paketen wählbaren PHP-Versionen können Sie die Umgebung an die Anforderungen Ihrer Website anpassen. Notieren Sie sich bei einer Änderung der Einstellungen die aktuelle Version sowie die betroffenen Komponenten. So lässt sich später leichter vergleichen, welche Konfiguration funktioniert und welche Fehler verursacht.

Es empfiehlt sich, das Ergebnis der Fehlersuche kurz zu dokumentieren. Halten Sie fest, welche Aktion den Fehler ausgelöst hat, unter welchen Umständen er aufgetreten ist und nach welcher Änderung sich das Verhalten geändert hat. Diese Notiz kann später dabei helfen, die Auswirkungen der WordPress-Einstellungen und der Hosting-Umgebung voneinander abzugrenzen.

Entdecken Sie die WordPress-Hosting-Lösungen von aWh und wählen Sie die Umgebung, die Ihren Anforderungen an den Betrieb Ihrer Website am besten entspricht. Sorgfältige Fehlerbehebung und sichere Absicherung bilden eine solide Grundlage für einen zuverlässigeren WordPress-Betrieb.

Häufig gestellte Fragen zur Fehlerbehebung bei WordPress

Lässt sich der WordPress-Debug-Modus über das Admin-Panel aktivieren?

In der standardmäßigen WordPress-Verwaltungsoberfläche gibt es keinen integrierten Schalter für den Debug-Modus. Die Einstellung muss in der Regel in der Datei „wp-config.php“ vorgenommen werden, sofern Sie über die entsprechenden Dateizugriffsrechte verfügen. Einige Plugins bieten möglicherweise eine eigene Benutzeroberfläche an, doch handelt es sich dabei um separate Tools und nicht um Standardfunktionen von WordPress. Sollten Sie die Konfigurationsdatei nicht bearbeiten können, bitten Sie den Administrator Ihrer Website um Unterstützung.

Zeigt WP_DEBUG automatisch an, welches Plugin den Fehler verursacht?

Nicht unbedingt. Der Name des Plugins in der Fehlermeldung kann zwar darauf hindeuten, dass der Fehler dort aufgetreten ist, beweist jedoch nicht, dass das Plugin allein dafür verantwortlich ist. Es kann beispielsweise vorkommen, dass ein Plugin fehlerhafte Daten verarbeitet, die von einem anderen Plugin übergeben wurden. Notieren Sie sich die betroffene Funktion und die im Protokoll angezeigte Datei und prüfen Sie anschließend in einer Testumgebung, ob sich das Symptom ändert, wenn Sie die Komponente deaktivieren.

Was bedeutet die PHP-Meldung „Notice“ oder „Deprecated“ im WordPress-Protokoll?

Eine „notice“ ist in der Regel eine informative Meldung zur Funktionsweise des Codes und führt für sich genommen nicht zwangsläufig zu einer Unterbrechung der Seite. Die Meldung „deprecated“ weist darauf hin, dass der Code eine als veraltet markierte PHP-Funktion oder -Lösung verwendet. Finden Sie heraus, auf welche Datei sich die Meldung bezieht, und überprüfen Sie, ob sie zeitgleich mit einem tatsächlichen Fehler der Website erscheint. Die Warnung allein bedeutet nicht, dass die Seite fehlerhaft funktioniert.

Kann der WP_DEBUG-Modus die Leistung einer WordPress-Website beeinträchtigen?

Ja, die Fehlersuche kann sich auf die Leistung auswirken, insbesondere wenn viele Meldungen generiert werden und diese kontinuierlich in eine Datei geschrieben werden müssen. Die Anzeige auf dem Bildschirm kann zudem das Besuchererlebnis beeinträchtigen, wenn technische Meldungen auf der Website erscheinen. Verwenden Sie die Fehlersuche auf einer live geschalteten Website daher nur für die Dauer der erforderlichen Überprüfung und deaktivieren Sie sie, sobald Sie sie nicht mehr benötigen.

Kann der WordPress-Debug-Modus auch bei einer Installation mit mehreren Websites verwendet werden?

Ja, aber bei einer WordPress-Installation mit mehreren Websites sollten Sie beachten, dass die Datei „wp-config.php“ die Konfiguration der gesamten Installation verwaltet. Die darin festgelegte Einstellung „WP_DEBUG“ gilt daher in der Regel für das gesamte Netzwerk und nicht nur für eine einzelne Subwebsite. Notieren Sie sich bei der Auswertung der Log-Einträge, auf welcher Unterseite und bei welchem Vorgang der Fehler aufgetreten ist. Die einzelnen Installationen verfügen über eigene Konfigurationsdateien.

Warum wird die Datei „debug.log“ nicht erstellt, nachdem „WP_DEBUG_LOG“ aktiviert wurde?

Die Datei kann aus verschiedenen Gründen fehlen. Überprüfen Sie, ob „WP_DEBUG“ aktiviert ist, und führen Sie anschließend einen Vorgang aus, der eine protokollierbare Meldung generiert. Ein fehlgeschlagenes Protokollieren kann auch dadurch verursacht werden, dass WordPress nicht in das Zielverzeichnis schreiben kann oder der Pfad zum Protokoll auf einen benutzerdefinierten Wert gesetzt ist. Wenn das System bereits vor dem Start von WordPress abstürzt, wird der Fehler nicht unbedingt in dieser Datei protokolliert.

Ist der WordPress-Debug-Modus dasselbe wie die Entwicklerkonsole des Browsers?

Nein. Die Fehleranalyse von WordPress liefert in erster Linie Informationen über die serverseitige PHP-Funktionalität. Mit der Entwicklerkonsole Ihres Browsers können Sie unter anderem JavaScript-Fehler, Netzwerkanfragen und die Darstellung der Seite im Browser untersuchen. Wenn beispielsweise eine Schaltfläche nicht reagiert, kann die Konsole Hinweise liefern; wenn beim Laden der Seite ein PHP-Prozess fehlschlägt, ist das WordPress-Protokoll möglicherweise hilfreicher.

• WordPress
• PHP
• Monitoring
• Anleitungen