WordPress ist seit vielen Jahren das populärste Content-Management-System (CMS) und befindet sich momentan auf mehr als 41 Prozent aller Websites im Einsatz. Wenn wir uns zu diesen Millionen von Websites auch noch die mehr als 58.000 Plugins, die knapp 4.000 Themes und die sehr verschiedenen Konfigurationen bei den Webhostern in Erinnerung rufen, dann kann sich so ziemlich jeder gut vorstellen, welche ungewöhnlichen und exotischen Kombinationen möglich sind.
Wie äußern sich WordPress-Fehler, und warum treten sie auf?
Darum ist es nicht verwunderlich, dass es bei manchen Kombinationen gehäuft zu Fehlern kommt, die durch Inkompatibilitäten entstehen. Diese WordPress-Fehler können sich mannigfaltig äußern: Mal funktioniert die Permalink-Struktur nicht, mal gibt es Layout-Probleme, und recht häufig – und von allen Websitebetreibern gefürchtet – gibt es den Totalausfall im Frontend: den sogenannten „White Screen of Death“.
White Screen of Death: kein schöner Anblick und kein gutes Gefühl, wenn die Website nicht mehr zu sehen ist, aber kein Grund zur Panik. Es gibt mehrere Lösungen, um das Problem zu beheben.
Oft treten die Fehler im Zusammenhang mit Updates auf, also wenn Nutzer WordPress, Plugins, Themes oder die PHP-Version aktualisieren. Die große Frage lautet dann: Wie können solche Fehler behoben werden? Die Antwort darauf ist nicht immer einfach. Zunächst einmal hängt es von der Schwere des Fehlers ab. Gibt es lediglich einzelne Fehler auf der Seite, d. h. Darstellungsfehler oder einzelne Funktionalitäten, die nicht mehr funktionieren? Oder ist die Seite für Besucher nicht mehr erreichbar (Stichwort: “White Screen of Death”)? Können Sie sich als Betreiber der Website noch ins Backend einloggen, oder geht auch das nicht mehr?
“Einfache Fehler” beheben
Je nach Schwere des Problems gibt es also unterschiedliche Herangehensweisen, um dieses zu beheben. Sollte es sich nur um ein kleineres Problem handeln, also Sie können das Backend der Website aufrufen, und die Inhalte erscheinen auch im Frontend, allerdings gibt es punktuelle Probleme mit dem Layout und/oder der Funktionalität, dann können Sie mithilfe des Debug-Modus oder der Developer-Toolbar schauen, ob Sie herausfinden, wer der Übeltäter ist.
Debug-Modus
Debug-Modus aktivieren
Mithilfe des Debug-Modus können Sie sich Fehlermeldungen anzeigen lassen und so analysieren, warum es zu Fehlern auf Ihrer Website kommt. Die Steuerung bzw. Aktivierung des Debug-Modus funktioniert über die wp-config.php, die im Hauptverzeichnis Ihrer WordPress-Installation liegt.
Hier findet man die Zeile
define( 'WP_DEBUG', false );
Wie man sieht, ist der Debug-Modus standardmäßig deaktiviert. Um ihn zu aktivieren, ändert man den Wert false zu true:
define( 'WP_DEBUG', true );
Zum Bearbeiten der Datei muss man sich die wp-config.php mit einem FTP-Programm herunterladen, mit einem Text- oder besser noch mit einem Code-Bearbeitungsprogramm öffnen, die entsprechende Zeile ändern und anschließend speichern und wieder auf den Server hochladen. Am besten legen Sie sich vorher noch eine Sicherungskopie der Datei an, die Sie im Zweifelsfall als Backup wieder hochladen können.
Wenn die wp-config.php nun mit aktiviertem Debug-Modus wieder auf dem Server hochgeladen ist, werden Fehler im Frontend angezeigt. Für eine kurze Weile und für eine Testseite oder eine Seite, die sich noch im Aufbau befindet, also nicht öffentlich zugänglich ist, ist dies sicherlich eine Möglichkeit. Besser ist es jedoch, den Code in der wp-config.php noch zu erweitern.
Dies geht zum einen mit der Zeile
define( 'WP_DEBUG_LOG', true );
Hiermit wird die Fehlermeldung nämlich in einer Log-Datei gespeichert, sodass man sich die Datei herunterladen und in Ruhe analysieren kann. Standardmäßig befindet sich die Log-Datei im Ordner wp-content und heißt debug.log.
Wer es individueller mag, kann das gerne anpassen, z. B. so:
define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );
Da der Code aber immer noch im Frontend ausgegeben wird, ist u. U. folgende Ergänzung sinnvoll:
define( 'WP_DEBUG_DISPLAY', false );
Hiermit wird die HTML-Anzeige gesteuert. Ist sie deaktiviert, erfolgt keine Ausgabe im Frontend bzw. HTML der Website. Standardmäßig ist diese Anzeige aktiviert.
Sowohl WP_DEBUG_LOG wie auch WP_DEBUG_DISPLAY funktionieren nur bei aktiviertem Debug-Modus!
Debug-Meldung im Fußbereich einer Website mit Hinweis auf Fehler.
Die Meldungen des Debug-Modus sind für Laien manchmal nicht ganz einfach zu verstehen, aber meist geben Sie doch einen Hinweis auf den Verursacher. Und so kann man sich das mühsame Nacheinander aktivieren, deaktivieren, aktivieren, deaktivieren von sämtlichen installierten und aktivierten Plugins ersparen und direkt das betroffene Plugin deaktivieren.
Debug-Modus deaktivieren
Wichtig ist es aber, nach Abschluss der Debugging-Arbeiten den Debug-Modus wieder zu deaktivieren.
Durch einen aktivierten Debug-Modus werden zum einen unnötige Performance-Einbußen verursacht, und zum anderen wird die Seite angreifbar, da so auch Außenstehende mögliche Fehler sehen und somit eventuelle Sicherheitslücken sichtbar sein könnten.
Also, immer daran denken, den Code in der wp-config.php wieder zu deaktivieren:
define( 'WP_DEBUG', false );
Developer-Toolbar
Wenn Sie Erfahrung mit der Developer-Toolbar haben, kann es ebenfalls sinnvoll sein, direkt in der Konsole nachzuschauen, welche Fehlermeldung auftaucht. Oft kann man auch hier erkennen, wo die Ursache des Problems liegt.
Wiederherstellungsmodus
Wenn es sich um ein schwerwiegendes Problem handelt, werden Sie höchstwahrscheinlich eine E-Mail von WordPress erhalten, die Sie darüber informiert. Auch hier erhalten Sie einen wertvollen Hinweis darauf, wo die Ursache des Problems liegt.
E-Mail von WordPress mit der Fehlerbeschreibung.
Hinweis: Eine E-Mail von WordPress über Fehler erhalten Sie nur, wenn Sie WordPress 5.2 oder höher installiert haben, da erst ab dieser Version diese Funktion eingebaut wurde.
Neben dem Hinweis darauf, welches Plugin zum Fehler geführt hat, enthält die E-Mail auch einen Link zum “Wiederherstellungsmodus”, d. h. das Plugin wird deaktiviert, und Sie können Ihre Website wieder erreichen.
Fehlerursache beheben
Nun geht es daran, den Fehler zu beheben. Unabhängig davon, ob Sie das Plugin, das den Fehler verursacht hat, selbst über die Developer-Toolbar aufgespürt und deaktiviert haben oder ob dies automatisiert durch WordPress selber stattgefunden hat, sollten Sie im nächsten Schritt überlegen, ob das betroffene Plugin wirklich notwendig ist, denn die Devise bei jeder WordPress-Installation lautet: Weniger ist mehr!
Falls Sie diese Frage jedoch eindeutig mit “ja” beantworten können, dann gibt es mehrere Möglichkeiten:
- Schauen Sie im Entwickler-Forum, ob andere Nutzer ein ähnliches Problem haben und ob es evtl. schon eine Lösung oder einen Fix, bestenfalls in Form eines Updates, gibt.
- Suchen Sie nach Alternativen. Evtl. wird ihr jetziges Plugin gar nicht mehr vom Entwickler weiterentwickelt. In so einem Fall sollten sie den Wechsel zu einem anderen Plugin vornehmen.
- Es gibt noch keinen Fix, aber in naher Zukunft. Dann kann es sinnvoll sein, eine ältere Version des Plugins zu installieren. Wie das geht, wird im Abschnitt “Das Release-Archive” beschrieben. Dies sollte jedoch immer nur eine temporäre Lösung sein.
“Schwere Fehler” beheben
Backup einspielen
Handelt es sich bei dem aufgetretenen Fehler jedoch um einen “Komplettausfall”, so kann es sinnvoll und auch Zeit-schonend sein, ein Backup einzuspielen und dann Schritt für Schritt Updates vorzunehmen, um so den Update-Schritt, der die Probleme verursacht, eindeutig zu identifizieren.
Darum ist es sinnvoll, in regelmäßigen und zeitlich sinnvollen Abständen Komplettbackups durchzuführen.
Mit “zeitlich sinnvollen Abständen” meine ich, dass die Abstände der Backups auch mit der Größe und vor allem der Häufigkeit der Änderungen auf der Website korrelieren.
Während wöchentliche Backups bei Websites sinnvoll sind, an denen es lediglich drei- bis viermal im Monat Änderungen gibt, sind die wöchentlichen Backups keine sinnvolle Maßnahme bei Webprojekten, bei denen täglich gebloggt wird.
Darüber hinaus ist es, meiner langjährigen WordPress-Erfahrung nach, bei bestimmten Konstellationen ratsam, eine Klon-Installation zu pflegen und dort umfangreichere Updates vorab zu testen. Das ist vor allem bei größeren, bei stark angepassten und bei Projekten angeraten, die große und leistungsstarke Plugins wie zum Beispiel WooCommerce im Einsatz haben.
In solchen Szenarien kommt es häufiger zu Problemen bei Updates. Auch wenn es einige Lösungen gibt, um WordPress relativ schnell wieder einzuspielen – sogar manche Hoster bieten solch eine Funktion an – so gilt auch in diesem Fall die Devise:
„Vorbeugen ist besser als Heilen!“
Christoph Wilhelm Hufeland (1762-1836)
Nutzen Sie also nur Plugins, die Sie wirklich benötigen, und testen Sie Updates vorher in einer Klon-Installation.
Kein Backup, das Backup ist fehlerhaft oder unvollständig. Was nun?
Haben Sie nun Updates eingespielt, die Probleme verursachen, also kein (funktionierendes) Backup, dann gilt es, Ruhe zu bewahren. Auch und vor allem bei großen Problemen wie dem sogenannten „White Screen of Death“. Sich zu ärgern, bringt Sie nicht weiter. Es geht darum, das Problem zu lösen, und trotz einer anscheinend ausweglosen Lage stehen Ihnen einige Lösungen zur Verfügung.
Zwei Methoden, um im Notfall alle Plugins in WordPress zu deaktivieren
Bei der Fehlersuche und vor allem in Notfällen (zum Beispiel, wenn statt der eigentlichen Website nur ein weißer Bildschirm zu sehen ist) ist eine gängige und erprobte Methode, alle Plugins gleichzeitig zu deaktivieren. In den meisten Fällen liegt der Fehler bei einem Plugin bzw. dem nicht funktionierenden Zusammenspiel von einigen Plugins.
Da man in so einem Notfall sehr häufig auch nicht den Zugriff auf das Backend hat, kann man logischerweise auch nicht die Pluginverwaltung bemühen und einzelne Plugins gezielt deaktivieren. In einem solchen Fall stehen uns dennoch zwei Methoden zur Verfügung, mit denen wir alle oder zumindest einige Plugins deaktivieren können.
Die elegantere Methode: alle Plugins über die Datenbank deaktivieren
Sofern man den Zugriff auf die Datenbank oder auf die Datenbankverwaltung hat (in vielen Fällen handelt es sich dabei um phpMyAdmin), kann man das Problem sehr elegant lösen, indem man in der Datenbanktabelle wp_options den Namen active_plugins sucht und dort auf Bearbeiten geht. Je nachdem, wie viele Plugins aktiv sind, finden Sie dort eine recht kurze oder sehr lange Zeichenkette. Diese Zeichenkette kopiert man sicherheitshalber als Backup in einen Texteditor und ersetzt sie in der Datenbank durch den Wert a:0:{}:
Hinweis: Haben Sie sich bei der WordPress-Installation für ein anderes Datenbankpräfix entschieden, dann steht in der Datenbank nicht wp_options, sondern ein entsprechend anderer Wert.
Sollte der Fehler nicht an den Plugins liegen, dann können Sie ganz einfach den zwischengespeicherten Code aus dem Texteditor zurück einfügen und abspeichern – alle Plugins sind dann wieder zurück und aktiv.
Der Nothammer: alle Plugins per FTP deaktivieren
Haben Sie jedoch keinen Zugriff auf die Datenbank, und es muss schnell gehen, dann kann man die Plugins auch über FTP deaktivieren. Hier können Sie entweder den ganzen Plugins-Ordner umbenennen, einfach von plugins zu irgendetwas oder einzelne Plugins aus dem Plugin-Ordner umbenennen, verschieben oder sogar löschen.
Der Nachteil dieser Methode ist, dass die Plugins, wenn man den Ordner zurück umbenennt oder die einzelnen Plugins wieder hochlädt bzw. zurückschiebt, nicht mehr aktiv sind. Bei einigen Plugins kann das problematisch oder zumindest zeitraubend werden, wenn dann die Einstellungen verloren gegangen sind.
Zurück in die Zukunft
Manchmal führt allerdings nur der Weg zurück in eine fehlerfreie WordPress-Zukunft, und glücklicherweise kann man sowohl auf ältere WordPress- wie aber auch Plugin- und Theme-Versionen zugreifen.
Das Release-Archiv: ältere und weiter gepflegte Versionen von WordPress
Auf der offiziellen Website von WordPress gibt es im Download-Bereich auch einen Unterbereich mit dem Namen Release Archive. Dieses Archiv ist nicht nur für Web-Archäologen interessant, sondern auch bei bestimmten Szenarien hilfreich.
Dort findet man neben alten Versionen wie der Version 0.71-gold aus dem Jahr 2003 ebenso Versionen, die mit aktuellen Sicherheitsupdates versorgt werden (und zwar alle Hauptversionen bis runter zu WordPress 3.7.x).
Infos in der Dokumentation zu der jeweiligen Version.
Zu den jeweiligen Versionen, die im Release-Archiv gelistet werden, kann man sich im Codex über die Veröffentlichungsdaten und die Änderungen informieren. Einfach zum Beispiel codex.wordpress.org/Version_4.1.15 im Browser aufrufen, um sich über WordPress 4.1.15 zu informieren. Für die Version 3.7.18 wäre der Pfad codex.wordpress.org/Version_3.7.18.
Diese noch weiter gepflegten Versionen sind bei einer Reihe von Szenarien interessant, zumindest übergangsweise. Es kann passieren, dass Plugins oder Anpassungen am Theme nicht mit der neuesten Version kompatibel sind. Bis man eine endgültige Lösung oder Ersatz gefunden hat, kann man sich hier eine ältere WordPress-Version herunterladen und installieren. Dabei ist es wichtig, dass man eine Installation wählt, die mit aktuellen Sicherheitsupdates versorgt wird.
Ein weiteres Szenario ist, dass auf dem Server neue PHP- und MySQL-Versionen eingespielt wurden und man die Benachrichtigung darüber entweder nicht bekam oder übersah. Nun ist dort eine alte WP-Version vorhanden, die nicht mit den neueren PHP- und MySQL-Versionen kompatibel ist. Auch in solchen Fällen ist es gut zu wissen, dass es das Release-Archiv gibt.
Grundsätzlich empfiehlt es sich, bei betagten WP-Projekten das Update in mehreren kleinen, vorsichtigen Schritten vorzunehmen. Aktualisiert man beispielsweise in einem großen Schritt von WP 3.8 auf WP 5.8, sind Schwierigkeiten vorprogrammiert. Durch den großen Sprung lassen sich Fehlerquellen auch nicht lokalisieren: Tauchte das Problem schon in der Version 4.9 oder erst in 5.1 auf?
Kurz und knapp: Das Release-Archiv ist nicht nur ein Museum, sondern auch ein Retter in der Not und ein Lieferant für sichere Übergangslösungen.
Die Betonung liegt hierbei auf dem Wort „Übergangslösung“. Ich persönlich halte es – von einigen Ausnahmefällen abgesehen – für keine nachhaltige Lösung, bei älteren WordPress-Zweigen zu bleiben.
Rollback-Plugins
Hinweis: Die im Folgenden beschriebene Methode geht von Plugins und Themes aus, die im offiziellen Verzeichnis verfügbar sind. Bei Premium-Plugins und Themes müssen Sie die Autoren bzw. Entwickler wegen der Verfügbarkeit älterer Versionen kontaktieren.
Wenn Sie Zugriff auf das Backend von WordPress haben und der begründete Verdacht besteht, dass das Update eines Plugins oder Themes den Fehler verursacht, dann können Sie mit Hilfe von Plugins sogenannte Rollbacks vornehmen, also eine ältere Version installieren.
Für das Rollback von Plugins und Themes gibt es z. B. das Plugin WP Rollback. Nach der Installation können Sie gezielt Versionen eines bestimmten Plugins installieren.
Analog gibt es das Plugin WP Downgrade. Entgegen seinem Namen kann man damit eine WordPress-Installation gezielt down- aber auch upgraden. Bitte nicht vergessen: Vorher ein Backup machen!
Achtung: Wenn Sie das Plugin WP Downgrade nutzen und eine Zielversion festgelegt und installiert haben, werden Ihnen im Backend keine aktuellen Updates angezeigt. Das Plugin sollte also nur gezielt und zeitlich begrenzt genutzt werden.
Typische WordPress-Fehler | Effektive Methoden für die Analyse & Behebung – Fazit
Die oberste Regel bei der Fehlerbehebung ist: Ruhe bewahren. Versuchen Sie möglichst strukturiert und analytisch an die Sache heranzugehen. Zwei Fragen helfen meist schon, um die Ursache zu finden:
- Seit wann tritt der Fehler auf?
- Welche Änderungen wurden unmittelbar vor dem Auftreten des Fehlers gemacht?
Und wenn die Ursache ausgemacht ist, ist auch meist eine Lösung möglich.
In jedem Fall sollten Sie die Sache positiv sehen: Nun sind Sie um eine Erfahrung reicher, wissen, warum funktionierende und aktuelle Backups wichtig sind, und haben für sich selber ein zusätzliches Argument, warum eine Klon-Installation sinnvoll sein könnte.
- Web3 – ein besseres Web oder doch nur leere Versprechen? - 12. Mai 2022
- WordPress Performance Optimierung: Die besten praxiserprobten Methoden - 22. April 2022
- WordPress Performance Optimierung: Die wichtigsten Tools - 13. April 2022
