{"id":22443,"date":"2026-08-28T08:26:03","date_gmt":"2026-08-28T06:26:03","guid":{"rendered":"https:\/\/www.curiaweb.ch\/?post_type=docs&#038;p=22443"},"modified":"2026-08-28T08:26:04","modified_gmt":"2026-08-28T06:26:04","password":"","slug":"wordpress-debugging-fehlerprotokolle","status":"publish","type":"docs","link":"https:\/\/www.curiaweb.ch\/en\/hilfe\/wordpress\/wordpress-debugging-fehlerprotokolle\/","title":{"rendered":"Enable WordPress debugging and use error logs"},"content":{"rendered":"<p class=\"wp-block-paragraph\">Wenn WordPress einen kritischen Fehler, HTTP 500, eine weisse Seite oder ein anderes technisches Problem zeigt, reicht die sichtbare Fehlermeldung h\u00e4ufig nicht aus, um die tats\u00e4chliche Ursache zu erkennen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress und PHP k\u00f6nnen deshalb detailliertere Fehlerinformationen protokollieren. Diese Logs zeigen beispielsweise, welcher Fehlertyp aufgetreten ist, zu welchem Zeitpunkt der Fehler entstand und welche PHP-Datei beteiligt war.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress besitzt daf\u00fcr ein eigenes Debugging-System mit Einstellungen wie <code>WP_DEBUG<\/code>, <code>WP_DEBUG_LOG<\/code> and <code>WP_DEBUG_DISPLAY<\/code>. Zus\u00e4tzlich k\u00f6nnen serverseitige PHP Error Logs wichtige Informationen enthalten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Debugging bedeutet allerdings nicht, m\u00f6glichst viele Fehlermeldungen \u00f6ffentlich auf der Website anzuzeigen. Auf einer produktiven Website sollten technische Details m\u00f6glichst protokolliert und anschlie\u00dfend gezielt ausgewertet werden.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Briefly explained:<\/strong> Aktiviere Debugging nur gezielt zur Fehlersuche. Auf einer produktiven Website sollten Fehlermeldungen normalerweise nicht \u00f6ffentlich angezeigt werden. Verwende stattdessen ein Fehlerprotokoll, reproduziere den Fehler, notiere den Zeitpunkt und untersuche anschlie\u00dfend die dazu passenden Logeintr\u00e4ge.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">Was bedeutet Debugging in WordPress?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Debugging bezeichnet die systematische Suche nach Fehlern in einer Software oder Website.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei WordPress geht es beispielsweise darum herauszufinden, warum eine bestimmte Anfrage fehlschl\u00e4gt, ein Plugin einen Fehler verursacht oder PHP die Verarbeitung einer Seite abbricht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Statt lediglich verschiedene Einstellungen auszuprobieren, liefert Debugging technische Informationen \u00fcber den tats\u00e4chlichen Ablauf.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Damit l\u00e4sst sich eine Vermutung h\u00e4ufig in eine konkrete Diagnose verwandeln.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wann ist WordPress Debugging sinnvoll?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Debugging ist besonders hilfreich, wenn ein Problem reproduzierbar auftritt, die sichtbare Fehlermeldung aber keine ausreichende Erkl\u00e4rung liefert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das betrifft beispielsweise kritische WordPress-Fehler, HTTP-500-Fehler, Probleme nach einem Plugin- oder Theme-Update, Fehler nach einem PHP-Wechsel oder Funktionen, die pl\u00f6tzlich nicht mehr korrekt arbeiten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auch bei ungew\u00f6hnlichem Verhalten eines Plugins kann ein Log Hinweise liefern, selbst wenn die Website grunds\u00e4tzlich weiterhin erreichbar ist.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debugging ist nicht dasselbe wie Reparieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Fehlerprotokoll behebt das Problem nicht automatisch.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Debugging hilft zun\u00e4chst dabei, die Ursache zu identifizieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein Log beispielsweise zeigt, dass ein fataler PHP-Fehler innerhalb eines bestimmten Plugins auftritt, muss anschlie\u00dfend gepr\u00fcft werden, warum dieser Fehler entsteht und welche L\u00f6sung daf\u00fcr geeignet ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die St\u00e4rke des Debuggings liegt deshalb nicht in einer automatischen Reparatur, sondern in einer wesentlich pr\u00e4ziseren Diagnose.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Vor \u00c4nderungen ein Backup erstellen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bevor du Konfigurationsdateien wie <code>wp-config.php<\/code> bearbeitest, sollte eine aktuelle Sicherung vorhanden sein.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein kleiner Syntaxfehler in einer PHP-Konfigurationsdatei kann dazu f\u00fchren, dass WordPress nicht mehr korrekt geladen wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei komplexen oder gesch\u00e4ftskritischen Websites ist eine Staging-Umgebung f\u00fcr umfangreiche Debugging-Arbeiten grunds\u00e4tzlich vorzuziehen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Die Datei wp-config.php<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die wichtigsten WordPress-Debugging-Einstellungen werden normalerweise in:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-config.php<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">defined.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Datei befindet sich \u00fcblicherweise im Hauptverzeichnis der WordPress-Installation beziehungsweise eine Ebene dar\u00fcber, sofern die Installation entsprechend konfiguriert wurde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie enth\u00e4lt zentrale Einstellungen der WordPress-Installation und sollte deshalb nur kontrolliert bearbeitet werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WP_DEBUG<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die zentrale WordPress-Konstante f\u00fcr den Debug-Modus hei\u00dft:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_DEBUG<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In einer normalen produktiven WordPress-Installation ist Debugging \u00fcblicherweise deaktiviert:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', false );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr eine gezielte Diagnose kann es aktiviert werden:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', true );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mit aktiviertem <code>WP_DEBUG<\/code> erh\u00f6ht WordPress die PHP-Fehlerberichterstattung und erzeugt zus\u00e4tzlich WordPress-spezifische Hinweise, beispielsweise zu veralteten Funktionen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">true und false nicht in Anf\u00fchrungszeichen setzen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei den Debug-Konstanten sind <code>true<\/code> and <code>false<\/code> boolesche Werte.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Korrekt ist beispielsweise:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', false );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nicht verwendet werden sollte:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', 'false' );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die zweite Variante enth\u00e4lt eine Zeichenkette statt eines booleschen Werts und kann dadurch zu einem unerwarteten Ergebnis f\u00fchren.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Important:<\/strong> Bei WordPress-Konstanten sollte der Datentyp korrekt \u00fcbernommen werden. <code>false<\/code> and <code>'false'<\/code> sind in PHP nicht dasselbe.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">WP_DEBUG_LOG<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Mit:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_DEBUG_LOG<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">kann WordPress Debug-Meldungen in eine Datei schreiben.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine typische Konfiguration lautet:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG_LOG', true );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If <code>WP_DEBUG_LOG<\/code> on <code>true<\/code> gesetzt und <code>WP_DEBUG<\/code> aktiviert ist, verwendet WordPress standardm\u00e4\u00dfig:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/debug.log<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">als Debug-Logdatei.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WP_DEBUG_LOG ben\u00f6tigt WP_DEBUG<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein wichtiger Zusammenhang wird h\u00e4ufig \u00fcbersehen:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_DEBUG_LOG<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">arbeitet innerhalb des WordPress-Debug-Systems zusammen mit:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_DEBUG<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If <code>WP_DEBUG<\/code> nicht aktiviert ist, erzeugt das blo\u00dfe Setzen von <code>WP_DEBUG_LOG<\/code> nicht das erwartete WordPress-Debug-Logging.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Eigener Pfad f\u00fcr WP_DEBUG_LOG<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress kann f\u00fcr <code>WP_DEBUG_LOG<\/code> auch einen g\u00fcltigen Dateipfad verwenden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das kann sinnvoll sein, wenn das Fehlerprotokoll nicht direkt innerhalb des \u00f6ffentlich erreichbaren Website-Verzeichnisses gespeichert werden soll.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Welche Pfade in einer konkreten Hosting-Umgebung sinnvoll und beschreibbar sind, h\u00e4ngt von der Serverkonfiguration ab.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WP_DEBUG_DISPLAY<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Konstante:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>WP_DEBUG_DISPLAY<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">steuert, ob Debug-Meldungen innerhalb der Website ausgegeben werden sollen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr eine produktive Website ist w\u00e4hrend einer Diagnose h\u00e4ufig folgende Kombination sinnvoller als eine \u00f6ffentliche Fehlerausgabe:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>define( 'WP_DEBUG', true );\ndefine( 'WP_DEBUG_LOG', true );\ndefine( 'WP_DEBUG_DISPLAY', false );<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Damit kann WordPress Fehler protokollieren, ohne sie absichtlich f\u00fcr Besucher auf der Website darzustellen.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Attention:<\/strong> Detaillierte Fehlermeldungen k\u00f6nnen Dateipfade, technische Konfigurationen und andere interne Informationen enthalten. Sie sollten auf einer produktiven Website nicht dauerhaft \u00f6ffentlich angezeigt werden.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">display_errors zus\u00e4tzlich ber\u00fccksichtigen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die tats\u00e4chliche PHP-Fehlerausgabe kann zus\u00e4tzlich durch die PHP-Konfiguration beeinflusst werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr eine Diagnosekonfiguration kann deshalb erg\u00e4nzend verwendet werden:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>@ini_set( 'display_errors', 0 );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine m\u00f6gliche Kombination lautet damit:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>define( 'WP_DEBUG', true );\ndefine( 'WP_DEBUG_LOG', true );\ndefine( 'WP_DEBUG_DISPLAY', false );\n@ini_set( 'display_errors', 0 );<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Ob PHP-Einstellungen zur Laufzeit ver\u00e4ndert werden d\u00fcrfen, h\u00e4ngt allerdings von der Serverkonfiguration ab.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wo geh\u00f6rt der Debug-Code in wp-config.php hin?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Debug-Konstanten m\u00fcssen definiert werden, bevor WordPress vollst\u00e4ndig geladen wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In einer typischen <code>wp-config.php<\/code> befinden sie sich deshalb vor der bekannten Abschlusszeile beziehungsweise bevor <code>wp-settings.php<\/code> eingebunden wird.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn bereits eine Definition wie:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', false );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">vorhanden ist, solltest du nicht zus\u00e4tzlich an einer anderen Stelle eine zweite widerspr\u00fcchliche Definition anlegen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Die debug.log finden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei der Standardkonfiguration befindet sich die WordPress-Debugdatei unter:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/debug.log<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie kann beispielsweise \u00fcber den Dateimanager des Hostings oder einen geeigneten Datei\u00fcbertragungszugang eingesehen werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Datei muss nicht zwangsl\u00e4ufig bereits vorhanden sein. Sie wird ben\u00f6tigt beziehungsweise beschrieben, wenn entsprechende Meldungen protokolliert werden k\u00f6nnen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wenn keine debug.log erstellt wird<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn trotz aktiviertem Debugging keine Datei erscheint, solltest du zun\u00e4chst pr\u00fcfen, ob tats\u00e4chlich ein protokollierbarer Fehler erzeugt wurde und ob die Debug-Konstanten korrekt gesetzt sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Zus\u00e4tzlich k\u00f6nnen Dateirechte, der konfigurierte Log-Pfad und die Hosting- beziehungsweise PHP-Konfiguration eine Rolle spielen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein fehlendes <code>debug.log<\/code> beweist deshalb nicht automatisch, dass WordPress fehlerfrei arbeitet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Den Fehler gezielt reproduzieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine der effektivsten Methoden bei der Log-Analyse ist das kontrollierte Reproduzieren des Problems.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn beispielsweise der Klick auf \u201eAktualisieren\u201c bei einer bestimmten Seite einen Fehler verursacht, \u00f6ffne zun\u00e4chst das Log beziehungsweise notiere dessen aktuellen Stand. F\u00fchre anschlie\u00dfend genau diese Aktion erneut aus.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Danach untersuchst du die neu hinzugekommenen Eintr\u00e4ge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Damit reduzierst du das Risiko, einen alten und l\u00e4ngst nicht mehr relevanten Fehler mit dem aktuellen Problem zu verwechseln.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Zeitstempel sind entscheidend<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auf einer l\u00e4nger betriebenen Website kann ein Fehlerprotokoll Eintr\u00e4ge aus vielen unterschiedlichen Situationen enthalten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Fatal Error von gestern muss nichts mit dem Problem zu tun haben, das heute auftritt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Notiere deshalb m\u00f6glichst genau den Zeitpunkt, an dem du den Fehler reproduziert hast, und vergleiche diesen mit den Zeitstempeln im Log.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Practical Tip:<\/strong> Reproduziere einen Fehler einmal kontrolliert und notiere die Uhrzeit. Dadurch lassen sich relevante Logeintr\u00e4ge wesentlich schneller von altem Protokollrauschen unterscheiden.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">Wie liest man einen PHP-Fehler?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein PHP-Fehler enth\u00e4lt h\u00e4ufig mehrere n\u00fctzliche Bestandteile.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Besonders relevant sind Fehlertyp, Fehlermeldung, Dateipfad, Zeilennummer und Zeitstempel.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein vereinfachtes Beispiel k\u00f6nnte sinngem\u00e4\u00df so aussehen:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>PHP Fatal error: Uncaught Error ... in \/wp-content\/plugins\/beispiel-plugin\/datei.php on line 123<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Damit wei\u00dft du bereits, dass PHP die Ausf\u00fchrung wegen eines fatalen Fehlers beendet hat und in welchem Codebereich der Fehler sichtbar wurde.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">PHP Fatal error<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">One<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>PHP Fatal error<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ist ein schwerwiegender Fehler, bei dem PHP die betreffende Ausf\u00fchrung nicht normal fortsetzen kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Fehler k\u00f6nnen beispielsweise durch inkompatiblen Code, fehlende Funktionen oder Klassen, Speicherprobleme und andere schwerwiegende Programmfehler entstehen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Fatal Error ist deshalb bei einem HTTP-500-Fehler oder einer weissen Seite besonders relevant.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Uncaught Error und TypeError<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Messages such as:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Uncaught Error<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">or:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>TypeError<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">weisen auf Fehler w\u00e4hrend der PHP-Ausf\u00fchrung hin.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A <code>TypeError<\/code> kann beispielsweise entstehen, wenn Code einen Wert eines ungeeigneten Typs an eine Funktion \u00fcbergibt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Fehler treten h\u00e4ufig bei Inkompatibilit\u00e4ten oder fehlerhaftem Plugin-, Theme- oder individuellem Code auf.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Call to undefined function<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A message like:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Call to undefined function<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">bedeutet, dass PHP versucht hat, eine Funktion aufzurufen, die in diesem Ausf\u00fchrungskontext nicht verf\u00fcgbar ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">M\u00f6gliche Ursachen sind inkompatibler Code, eine fehlende Abh\u00e4ngigkeit oder eine nicht verf\u00fcgbare PHP-Erweiterung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Dateipfad und der Name der Funktion liefern wichtige Hinweise f\u00fcr die weitere Diagnose.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Class not found<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A message like:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Class ... not found<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">kann darauf hinweisen, dass erwarteter Programmcode nicht geladen wurde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das kann beispielsweise durch fehlende Dateien, Plugin-Abh\u00e4ngigkeiten, fehlerhafte Autoloading-Prozesse oder inkompatible Versionen entstehen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Cannot redeclare<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">At:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Cannot redeclare<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">wurde beispielsweise versucht, eine bereits vorhandene Funktion erneut zu deklarieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das kann bei doppelt geladenem oder sich \u00fcberschneidendem Code auftreten und ist deshalb auch bei Plugin- oder Theme-Konflikten interessant.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Allowed memory size exhausted<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Die Meldung:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Allowed memory size ... exhausted<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">zeigt, dass PHP w\u00e4hrend der Ausf\u00fchrung das erlaubte Speicherlimit erreicht hat.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das bedeutet nicht automatisch, dass lediglich ein h\u00f6heres Limit ben\u00f6tigt wird. Ein Plugin oder Prozess kann auch ungew\u00f6hnlich viel Speicher verbrauchen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We discuss the exact diagnosis under <a href=\"\/en\/help\/wordpress\/wordpress-php-memory-limit\/\">PHP Memory Limit in WordPress: Identify and fix errors<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Parse Error und Syntax Error<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Syntaxfehler entsteht, wenn PHP-Code nicht korrekt aufgebaut ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das kann beispielsweise nach einer manuellen \u00c4nderung an:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>functions.php<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">or:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-config.php<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">passieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Schon eine fehlende Klammer, ein falsches Zeichen oder ein fehlerhaftes Semikolon kann dazu f\u00fchren, dass PHP die Datei nicht korrekt interpretieren kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Warning ist nicht dasselbe wie Fatal Error<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">One<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>PHP Warning<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">ist normalerweise weniger schwerwiegend als ein Fatal Error.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">PHP kann die Ausf\u00fchrung je nach Situation trotz einer Warnung fortsetzen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Warnings sollten trotzdem untersucht werden, insbesondere wenn sie h\u00e4ufig auftreten oder mit einer konkreten Fehlfunktion zusammenh\u00e4ngen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nicht jede Warning erkl\u00e4rt jedoch automatisch den Fehler, wegen dem du das Log ge\u00f6ffnet hast.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Notice richtig einordnen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Notices weisen h\u00e4ufig auf problematischen oder unsauberen Code hin, ohne die Ausf\u00fchrung unmittelbar abzubrechen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei aktiviertem <code>WP_DEBUG<\/code> k\u00f6nnen deshalb viele Meldungen sichtbar werden, obwohl die Website auf den ersten Blick funktioniert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Menge der Meldungen darf nicht dazu verleiten, jeden Eintrag als gleich kritisch zu behandeln.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Deprecated-Meldungen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress und PHP k\u00f6nnen Hinweise zu veralteten Funktionen beziehungsweise Vorgehensweisen erzeugen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Meldungen enthalten h\u00e4ufig Begriffe wie:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>Deprecated<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine Deprecation bedeutet nicht zwangsl\u00e4ufig, dass die Funktion bereits nicht mehr funktioniert. Sie weist darauf hin, dass der betreffende Code veraltet ist und in zuk\u00fcnftigen Versionen problematisch werden kann.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei Plugins oder Themes sind viele neue Deprecated-Meldungen nach einem Versionswechsel deshalb ein Hinweis darauf, die betreffende Erweiterung auf Aktualit\u00e4t und Kompatibilit\u00e4t zu pr\u00fcfen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Die h\u00f6chste Meldungszahl ist nicht automatisch das gr\u00f6\u00dfte Problem<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Plugin kann hunderte Notices erzeugen, w\u00e4hrend ein einzelner Fatal Error einer anderen Komponente die Website tats\u00e4chlich zum Absturz bringt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Diagnose sollte deshalb nach Relevanz erfolgen und nicht lediglich danach, welche Meldung am h\u00e4ufigsten im Log erscheint.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Dateipfade richtig lesen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Dateipfad kann einen wichtigen Hinweis auf die beteiligte Komponente geben.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Pfad innerhalb von:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/plugins\/<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">f\u00fchrt zu einem Plugin.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Pfad innerhalb von:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/themes\/<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">f\u00fchrt zu einem Theme beziehungsweise Child-Theme.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Pfad innerhalb von:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-admin\/<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">or:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-includes\/<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">f\u00fchrt in den WordPress-Core.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Ein WordPress-Core-Pfad beweist keinen Core-Fehler<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn eine Fehlermeldung eine Datei unter <code>wp-includes<\/code> nennt, bedeutet das nicht automatisch, dass WordPress selbst fehlerhaft ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Plugin kann beispielsweise eine WordPress-Core-Funktion mit ung\u00fcltigen Daten aufrufen. Der Fehler wird dann m\u00f6glicherweise innerhalb der Core-Funktion sichtbar, obwohl die eigentliche Ursache au\u00dferhalb des WordPress-Cores liegt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der gesamte Fehlerkontext ist deshalb wichtiger als der letzte Dateipfad allein.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Stack Trace verstehen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei schwerwiegenden Fehlern kann ein sogenannter Stack Trace protokolliert werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Er zeigt vereinfacht, welche Funktionen beziehungsweise Methoden aufgerufen wurden, bevor der Fehler entstanden ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Dadurch l\u00e4sst sich nachvollziehen, wie PHP an die Stelle gelangt ist, an der die Ausf\u00fchrung abgebrochen wurde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Entwickler und technischen Support kann ein Stack Trace deshalb wesentlich aussagekr\u00e4ftiger sein als nur die letzte Fehlerzeile.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Plugin- oder Theme-Konflikte mit Logs untersuchen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein Log wiederholt auf ein bestimmtes Plugin oder Theme verweist, ist diese Komponente ein sinnvoller Ausgangspunkt f\u00fcr die weitere Diagnose.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie sollte trotzdem kontrolliert getestet und nicht einfach gel\u00f6scht werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Unsere Vorgehensweise findest du unter <a href=\"\/en\/help\/wordpress\/wordpress-plugin-theme-conflicts\/\">Identifying and Resolving Plugin or Theme Conflicts in WordPress<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Fehler nach einem PHP-Wechsel<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn unmittelbar nach dem Wechsel der PHP-Version neue Fatal Errors, TypeErrors oder Deprecated-Meldungen auftreten, sollte die Kompatibilit\u00e4t der beteiligten Komponenten gepr\u00fcft werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Dateipfad im Error Log kann dabei helfen, ein veraltetes Plugin, Theme oder individuelles Snippet zu identifizieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We explain more about this under <a href=\"\/en\/help\/wordpress\/change-wordpress-php-version\/\">Change PHP version for WordPress and check compatibility<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WordPress debug.log und PHP Error Log sind nicht dasselbe<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This difference is important.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Datei:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/debug.log<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">entsteht durch das WordPress-Debug-Logging, wenn es entsprechend aktiviert wurde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die Hosting- beziehungsweise PHP-Umgebung kann zus\u00e4tzlich eigene Error Logs f\u00fchren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Diese serverseitigen Logs k\u00f6nnen Fehler enthalten, die nicht oder nicht vollst\u00e4ndig im WordPress-Debug-Log erscheinen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Welches Log sollte zuerst gepr\u00fcft werden?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein PHP- beziehungsweise Server-Error-Log \u00fcber das Hosting verf\u00fcgbar ist, ist dieses bei schweren PHP-Problemen h\u00e4ufig ein sehr guter Ausgangspunkt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es erfordert keine dauerhafte \u00f6ffentliche Fehleranzeige und kann bereits den entscheidenden Fatal Error enthalten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn dort keine ausreichenden Informationen vorhanden sind, kann gezieltes WordPress-Debugging zus\u00e4tzliche Details liefern.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">HTTP 500 mit Logs diagnostizieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei einem HTTP-500-Fehler zeigt der Browser h\u00e4ufig nur eine allgemeine Serverfehlermeldung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Error Log kann dagegen den zugrunde liegenden PHP-Fatal-Error, einen Speicherfehler oder andere serverseitige Probleme enthalten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">You can find the complete procedure at <a href=\"\/en\/help\/wordpress\/how-to-fix-wordpress-error-500\/\">How to fix WordPress error 500<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Kritischen WordPress-Fehler untersuchen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress kann bei bestimmten fatalen PHP-Fehlern eine Meldung \u00fcber einen kritischen Fehler anzeigen und gegebenenfalls Recovery Mode anbieten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auch hier k\u00f6nnen Logs zus\u00e4tzliche Informationen dar\u00fcber liefern, welche Komponente den Fehler ausgel\u00f6st hat.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die entsprechenden Wiederherstellungsschritte erkl\u00e4ren wir unter <a href=\"\/en\/help\/wordpress\/wordpress-critical-error-white-screen\/\">WordPress shows a white screen or a critical error: What to do?<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">AJAX-Fehler protokollieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Vorteil von <code>WP_DEBUG_LOG<\/code> besteht darin, dass Fehler protokolliert werden k\u00f6nnen, die nicht auf einer normalen sichtbaren Seite erscheinen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das ist beispielsweise bei AJAX-Anfragen hilfreich.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein WordPress-Editor, Formular oder Plugin eine AJAX-Anfrage verwendet und diese serverseitig fehlschl\u00e4gt, kann ein Log Hinweise auf den PHP-Fehler liefern.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">WP-Cron und Hintergrundprozesse<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auch Fehler w\u00e4hrend geplanter WordPress-Aufgaben k\u00f6nnen schwierig zu erkennen sein, weil kein Besucher unmittelbar eine entsprechende Fehlermeldung sieht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Logging ist deshalb auch bei WP-Cron und anderen Hintergrundprozessen hilfreich.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein geplanter Prozess immer wieder fehlschl\u00e4gt, sollten Zeitstempel und wiederkehrende Fehlermuster untersucht werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">REST-API-Fehler<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Moderne WordPress-Funktionen und Plugins verwenden h\u00e4ufig die REST API.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein serverseitiger PHP-Fehler w\u00e4hrend einer REST-Anfrage erscheint m\u00f6glicherweise nicht als normale Fehlermeldung innerhalb einer sichtbaren WordPress-Seite.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auch hier k\u00f6nnen Logs wesentlich mehr Informationen liefern als die Benutzeroberfl\u00e4che.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">JavaScript-Fehler stehen nicht zwingend im PHP-Log<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress-Debugging und PHP Error Logs konzentrieren sich auf serverseitige Vorg\u00e4nge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn beispielsweise ein Men\u00fc, Slider oder Button im Browser nicht reagiert, kann die Ursache stattdessen in JavaScript liegen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Fehler werden h\u00e4ufig \u00fcber die Entwicklerwerkzeuge des Browsers untersucht.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein leeres PHP-Error-Log beweist deshalb nicht, dass auf einer Website keinerlei technischer Fehler existiert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">CSS-Probleme stehen normalerweise ebenfalls nicht im PHP-Log<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein falsch dargestelltes Element kann durch CSS verursacht werden, obwohl PHP vollst\u00e4ndig fehlerfrei arbeitet.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn eine Website technisch funktioniert, aber beispielsweise Abst\u00e4nde, Farben oder Layout falsch dargestellt werden, sind die Browser-Entwicklerwerkzeuge h\u00e4ufig das geeignetere Diagnosewerkzeug.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Datenbankfehler<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auch Datenbankprobleme k\u00f6nnen technische Fehler verursachen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bei aktiviertem WordPress-Debugging k\u00f6nnen zus\u00e4tzliche Informationen zu Datenbankfehlern sichtbar beziehungsweise protokolliert werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Fehler in einer SQL-Abfrage sollte allerdings nicht automatisch durch manuelle \u00c4nderungen an der Datenbank \u201erepariert\u201c werden. Zun\u00e4chst sollte festgestellt werden, welche Komponente die problematische Abfrage erzeugt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debugging kann die Website selbst beeinflussen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Umfangreiches Logging erzeugt zus\u00e4tzliche Dateioperationen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn eine Website pro Anfrage sehr viele Warnings oder Notices produziert, kann eine aktivierte Protokollierung eine gro\u00dfe Menge an Daten schreiben.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Debugging sollte deshalb als Diagnosewerkzeug und nicht als dauerhaft eingeschalteter Normalzustand einer produktiven Website betrachtet werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Eine debug.log kann sehr gro\u00df werden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn derselbe Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/debug.log<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">innerhalb kurzer Zeit stark anwachsen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das beansprucht Speicherplatz und erschwert zus\u00e4tzlich die Auswertung.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nach einer Diagnose solltest du deshalb pr\u00fcfen, ob das Debugging wieder deaktiviert wurde und ob eine nicht mehr ben\u00f6tigte Logdatei sicher entfernt werden kann.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Logs k\u00f6nnen sensible Informationen enthalten<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fehlerprotokolle k\u00f6nnen interne Dateipfade, technische Konfigurationen, Abfrageinformationen und je nach fehlerhafter Anwendung weitere Daten enthalten.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Behandle Logs deshalb nicht wie \u00f6ffentlich zug\u00e4ngliche Textdateien.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein Log an Support oder einen Entwickler weitergegeben wird, sollte nur der f\u00fcr die Diagnose erforderliche Ausschnitt \u00fcbermittelt und vorher gepr\u00fcft werden, ob darin sensible Daten enthalten sind.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Attention:<\/strong> Ver\u00f6ffentliche vollst\u00e4ndige Debug-Logs nicht ungepr\u00fcft in \u00f6ffentlichen Foren, Tickets oder sozialen Netzwerken. Kontrolliere zuerst, welche Informationen darin enthalten sind.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">debug.log im \u00f6ffentlich erreichbaren Verzeichnis<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Der Standardpfad:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>wp-content\/debug.log<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">liegt innerhalb der WordPress-Verzeichnisstruktur.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Abh\u00e4ngig von der Webserver-Konfiguration kann eine dort abgelegte Datei potenziell \u00fcber HTTP erreichbar sein. WordPress weist deshalb selbst darauf hin, dass \u00f6ffentlich erreichbare Fehlerprotokolle ein Sicherheitsrisiko darstellen k\u00f6nnen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auf produktiven Umgebungen sollte Logging daher kontrolliert eingesetzt und die Logdatei nach Abschluss der Diagnose nicht unn\u00f6tig bestehen gelassen werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debugging nach der Fehlersuche wieder deaktivieren<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Nach Abschluss der Diagnose sollte eine produktive Website wieder in eine normale Konfiguration versetzt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Eine einfache WordPress-Konfiguration kann beispielsweise wieder:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>define( 'WP_DEBUG', false );<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">use.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn zus\u00e4tzliche Debug-Konstanten nur f\u00fcr die Diagnose erg\u00e4nzt wurden, sollte gepr\u00fcft werden, ob sie weiterhin ben\u00f6tigt werden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debug-Log nach der Diagnose behandeln<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn die Logdatei nicht mehr ben\u00f6tigt wird, kann sie nach Sicherung eventuell relevanter Informationen entfernt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wird Debug-Logging sp\u00e4ter erneut aktiviert, kann WordPress beziehungsweise PHP wieder neue Meldungen protokollieren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Das Entfernen einer alten Logdatei behebt allerdings keine Ursache. Es dient lediglich dazu, nicht mehr ben\u00f6tigte Diagnoseinformationen zu entfernen.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Alte Fehler nicht mit aktuellen Problemen verwechseln<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Eine vorhandene <code>debug.log<\/code> kann Meldungen enthalten, die Wochen oder Monate alt sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn eine Website heute einen Fehler zeigt, sollte deshalb nicht automatisch der auff\u00e4lligste alte Fatal Error als Ursache angenommen werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Der Vergleich mit dem aktuellen Zeitpunkt ist entscheidend.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Wiederkehrende Fehlermuster erkennen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn derselbe Fehler immer wieder zu bestimmten Zeiten auftritt, kann das auf einen geplanten Prozess hinweisen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Beispielsweise k\u00f6nnen Cronjobs, Backups, Imports oder Sicherheits-Scans regelm\u00e4\u00dfig bestimmte Funktionen ausf\u00fchren.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein zeitliches Muster im Log kann deshalb einen wichtigen Hinweis liefern, auch wenn die Website zwischen diesen Ereignissen normal funktioniert.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Logs vor und nach einer \u00c4nderung vergleichen<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Bei einer kontrollierten Diagnose solltest du m\u00f6glichst nur eine relevante Variable gleichzeitig ver\u00e4ndern.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn beispielsweise ein Plugin deaktiviert wird, reproduziere anschlie\u00dfend den Fehler erneut und vergleiche die neuen Logeintr\u00e4ge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Verschwindet der Fehler, ist das eine wesentlich st\u00e4rkere Information als eine zuf\u00e4llige \u00c4nderung von f\u00fcnf verschiedenen Einstellungen gleichzeitig.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debugging bei einer langsamen WordPress-Website<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ein Error Log ist kein vollst\u00e4ndiges Performance-Analysewerkzeug.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Es kann jedoch Hinweise auf Prozesse liefern, die st\u00e4ndig Fehler oder Warnungen erzeugen und dadurch zus\u00e4tzliche Last verursachen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr eine vollst\u00e4ndige Performance-Diagnose m\u00fcssen zus\u00e4tzlich PHP-Verarbeitung, Datenbank, Plugins, Frontend-Ressourcen und Hosting-Ressourcen betrachtet werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">We explain the procedure under <a href=\"\/en\/help\/wordpress\/improve-wordpress-slow-loading-time\/\">WordPress is slow: Finding causes and improving loading time<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Query Monitor und \u00e4hnliche Diagnosewerkzeuge<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr weitergehende Analysen existieren WordPress-Plugins, die zus\u00e4tzliche technische Informationen darstellen k\u00f6nnen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein bekanntes Werkzeug ist beispielsweise Query Monitor. Damit k\u00f6nnen unter anderem Datenbankabfragen, PHP-Fehler, Hooks, HTTP-API-Aufrufe und weitere Informationen w\u00e4hrend einer Anfrage untersucht werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Solche Werkzeuge richten sich vor allem an Entwickler und technisch erfahrene Benutzer.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie sollten nicht dauerhaft nur deshalb installiert und aktiviert bleiben, weil eine Website irgendwann einmal einen Fehler hatte.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">SCRIPT_DEBUG ist nicht dasselbe wie WP_DEBUG<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress kennt zus\u00e4tzlich:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>SCRIPT_DEBUG<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Konstante ist nicht mit <code>WP_DEBUG<\/code> to equate.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Sie wird insbesondere bei der Entwicklung und Diagnose von WordPress-Core-JavaScript- beziehungsweise CSS-Dateien verwendet und ist f\u00fcr eine normale PHP-Fehlersuche in der Regel nicht erforderlich.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">SAVEQUERIES nur gezielt verwenden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr Datenbankdiagnosen existiert au\u00dferdem:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><code>SAVEQUERIES<\/code><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Damit k\u00f6nnen Informationen zu Datenbankabfragen gesammelt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Diese Funktion erzeugt zus\u00e4tzlichen Speicher- und Performance-Aufwand und sollte deshalb nur gezielt zur Diagnose eingesetzt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">F\u00fcr normale WordPress-Benutzer ist sie bei einer \u00fcblichen Fehlersuche normalerweise nicht der erste Schritt.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Debugging auf Staging und Produktion unterscheiden<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Auf einer Entwicklungs- oder Staging-Umgebung k\u00f6nnen ausf\u00fchrliche Diagnoseinformationen sinnvoll sein, weil dort keine normalen Besucher betroffen sind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auf einer produktiven Website muss dagegen st\u00e4rker darauf geachtet werden, dass technische Informationen nicht \u00f6ffentlich ausgegeben werden und das Logging nur so lange wie n\u00f6tig aktiv bleibt.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die gleiche Debug-Konfiguration ist deshalb nicht automatisch f\u00fcr jede Umgebung geeignet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Was du beim Debugging besser nicht tun solltest<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Aktiviere nicht einfach die \u00f6ffentliche Ausgabe s\u00e4mtlicher PHP-Fehler auf einer produktiven Website und lasse diese Einstellung anschlie\u00dfend dauerhaft bestehen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u00c4ndere au\u00dferdem nicht gleichzeitig mehrere Plugins, das Theme, PHP und die WordPress-Konfiguration. Dadurch wird schwer nachvollziehbar, welche \u00c4nderung den Fehler tats\u00e4chlich beeinflusst hat.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L\u00f6sche nicht sofort eine Komponente nur deshalb, weil ihr Dateipfad in einem Log erscheint. Pr\u00fcfe zun\u00e4chst den Zusammenhang und reproduziere den Fehler kontrolliert.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Und sende vollst\u00e4ndige Logdateien nicht ungepr\u00fcft an beliebige Dritte.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Basic rule:<\/strong> Fehler reproduzieren, Zeitpunkt notieren, relevante Logeintr\u00e4ge identifizieren und erst danach eine gezielte \u00c4nderung vornehmen. Anschlie\u00dfend denselben Fehler erneut testen. So wird aus Ausprobieren eine nachvollziehbare technische Diagnose.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">What information helps CURIAWEB support?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn du CURIAWEB wegen eines WordPress-Fehlers kontaktierst, beschreibe zun\u00e4chst, welche Aktion den Fehler ausl\u00f6st und wann er zuletzt aufgetreten ist.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Ein relevanter Logausschnitt mit Zeitstempel ist wesentlich hilfreicher als eine vollst\u00e4ndige Datei mit tausenden \u00e4lteren Meldungen.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Wenn ein Fatal Error vorhanden ist, sollte die vollst\u00e4ndige zugeh\u00f6rige Fehlermeldung einschlie\u00dflich Dateipfad und gegebenenfalls Stack Trace \u00fcbermittelt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Teile au\u00dferdem mit, ob unmittelbar zuvor WordPress, ein Plugin, das Theme, PHP oder individueller Code ver\u00e4ndert wurde.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Entferne beziehungsweise schw\u00e4rze sensible Informationen, falls sie f\u00fcr die Diagnose nicht ben\u00f6tigt werden. Passw\u00f6rter solltest du niemals unaufgefordert in einem Fehlerprotokoll oder Support-Ticket mitsenden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">WordPress Debugging und Fehlerprotokolle geh\u00f6ren zu den wichtigsten Werkzeugen f\u00fcr eine systematische technische Fehlersuche. Statt lediglich aufgrund einer sichtbaren Fehlermeldung zu raten, k\u00f6nnen Logs zeigen, welcher Fehler tats\u00e4chlich aufgetreten ist, wann er entstand und welcher Codebereich beteiligt war.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die zentrale Einstellung <code>WP_DEBUG<\/code> aktiviert den WordPress-Debug-Modus. Mit <code>WP_DEBUG_LOG<\/code> k\u00f6nnen Meldungen protokolliert werden, w\u00e4hrend <code>WP_DEBUG_DISPLAY<\/code> steuert, ob diese Informationen auf der Website angezeigt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Auf einer produktiven Website ist es normalerweise sinnvoller, Fehler kontrolliert zu protokollieren, statt technische Details \u00f6ffentlich auszugeben. Die standardm\u00e4\u00dfige WordPress-Debugdatei <code>wp-content\/debug.log<\/code> sollte au\u00dferdem als potenziell sensible Datei behandelt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Nach Abschluss der Diagnose sollte Debugging auf einer produktiven Website wieder passend deaktiviert und eine nicht mehr ben\u00f6tigte Logdatei entfernt beziehungsweise sicher behandelt werden.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Die wichtigste Methode bleibt dabei einfach: <strong>Fehler reproduzieren, Log pr\u00fcfen, Ursache eingrenzen, eine gezielte \u00c4nderung durchf\u00fchren und anschlie\u00dfend erneut testen.<\/strong><\/p>","protected":false},"excerpt":{"rendered":"<p>Wenn WordPress einen kritischen Fehler, HTTP 500, eine weisse Seite oder ein anderes technisches Problem zeigt, reicht die sichtbare Fehlermeldung h\u00e4ufig nicht aus, um die tats\u00e4chliche Ursache zu erkennen. WordPress und PHP k\u00f6nnen deshalb detailliertere Fehlerinformationen protokollieren. Diese Logs zeigen beispielsweise, welcher Fehlertyp aufgetreten ist, zu welchem Zeitpunkt der Fehler entstand und welche PHP-Datei beteiligt [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_joinchat":[],"footnotes":""},"doc_category":[80],"doc_tag":[],"class_list":["post-22443","docs","type-docs","status-publish","hentry","doc_category-wordpress"],"year_month":"2026-09","word_count":3951,"total_views":"6","reactions":{"happy":"0","normal":"0","sad":"0"},"author_info":{"name":"Silvio Mazenauer","author_nicename":"admin-curia","author_url":"https:\/\/www.curiaweb.ch\/en\/author\/admin-curia\/"},"doc_category_info":[{"term_name":"WordPress","term_url":"https:\/\/www.curiaweb.ch\/en\/hilfe-kategorie\/wordpress\/"}],"doc_tag_info":[],"knowledge_base_info":[],"knowledge_base_slug":[],"_links":{"self":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22443","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs"}],"about":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/types\/docs"}],"author":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/comments?post=22443"}],"version-history":[{"count":1,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22443\/revisions"}],"predecessor-version":[{"id":22445,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/docs\/22443\/revisions\/22445"}],"wp:attachment":[{"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/media?parent=22443"}],"wp:term":[{"taxonomy":"doc_category","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_category?post=22443"},{"taxonomy":"doc_tag","embeddable":true,"href":"https:\/\/www.curiaweb.ch\/en\/wp-json\/wp\/v2\/doc_tag?post=22443"}],"curies":[{"name":"WP","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}