Verschiedene WordPress-Probleme und wie diese behoben werden können
Was tun wenn man sich nach einem Update nicht mehr in WordPress einloggen kann? Website mit WPML ist plötzlich nicht mehr erreichbar? In diesem Beitrag erklären wir typische Probleme, die immer wieder auftauchen, wenn man eine Website mit WordPress erstellt oder eine WordPress-Website betreut, und zeigen, wie diese Probleme gelöst werden können.
Inhalt
- Subseiten liefern beim Aufruf im Frontend einen Error 500 (Internal Server Error)
- Vorsicht beim Deaktivieren der XML-RPC-Schnittstelle
- Wie man in WordPress den Debugmodus aktiviert damit PHP-Fehlermeldungen im Frontend angezeigt werden
- Was tun wenn nach einem Plugin-Update die Website crasht und man sich auch nicht mehr in das Backend einloggen kann?
- Gutenberg-Blöcke können nicht bearbeitet werden
- Website nicht erreichbar und Fehlermeldung ab WordPress 6.1 + WPML
Subseiten liefern beim Aufruf im Frontend einen Error 500 (Internal Server Error)
Manchmal, zum Beispiel nach dem Einspielen von Updates für WordPress und bestimmte Plugins, kann es vorkommen, dass nur noch die Startseite im Frontend aufgerufen werden kann. Jede Subseite liefert einen Error 500 (Internal Server Error), kann also nicht mehr angezeigt werden. Im WordPress-Backend können diese Seiten aber bearbeitet werden.
In so einem Fall liegt häufig ein Problem mit den Permalinks vor. Denn es gibt Situationen bei Updates, bei denen Einträge in der .htaccess-Datei geändert werden. Das zerstört manchmal bzw. beschädigt die Permalink-Struktur, die Urls können dann von WordPress keiner Seite mehr zugeordnet werden, oder es kommt zu endlosen Redirects, sodass der Browser irgendwann abbricht.
Testen kann man das ganz einfach, indem man im Backend unter Einstellungen->Permalinks auf die Standardeinstellungen umstellt und dann speichert. Wenn dann im Frontend die Subseiten wieder aufgerufen werden können war das die Ursache.
Auch die Fehlerbehebung ist schnell erledigt: Einfach die gewünschte Permalink-Struktur einstellen und nochmals neu speichern, dann sollte wieder alles korrekt funktionieren und die Subseiten über die richtigen Urls erreichbar sein.
Vorsicht beim Deaktivieren der XML-RPC-Schnittstelle
Die XML-RPC-Schnittstelle ist dazu da, um von außen auf WordPress, genauer gesagt auf Funktionen von WordPress zugreifen zu können. Es lassen sich damit Beiträge oder Seiten erstellen und bearbeiten, ohne sich in das WordPress-Backend im Browser einloggen zu müssen.
Auch die diverse Apps wie z.B. die Smartphoneapp von WordPress benutzt die XML-RPC-Schnittstelle.
Der Zugriff von außen auf eine WordPress-Website stellt aber auch eine potentielle Gefahr dar. Denn um Beiträge erstellen zu können muss sich eine App ja in WordPress authentifizieren, es werden also die Userdaten (Username + Passwort) übertragen. Auch sind über diese Schnittstelle auch generell Zugriffe von anderen Apps oder Webseiten möglich. Gefährlich wird es aber (wie überhaupt bei Webseiten) immer dann, wenn die Passwörter bekannt sind.
Oftmals wird aufgrund dieser Gefahren aber empfohlen, die XML-RPC-Schnittstelle zu deaktivieren (dafür gibt es verschiedene Plugins), oder den Zugriff darauf per WordPress-Firewall (z.B. Ninja Firewall) zu blockieren. Das kann man machen um die Sicherheit zu erhöhen – Sicherheit ist immer gut – allerdings ist hier auch etwas Vorsicht geboten. Denn einerseits ist dann eine Wartung der Website von außen über die Smartphoneapp nicht mehr möglich, andererseits benutzen aber auch viele WordPress-Plugins selbst die Schnittstelle.
Kontaktformularplugins wie z.B. Contact Form 7 können dann keine Formulare mehr verschicken, auch der Zugriff von anderen externen Diensten oder Pingbacks sind dann nicht mehr möglich. Es ist daher wichtig, nach Deaktivierung der XML-RPC-Schnittstelle die WordPress-Website auf korrekte Funktion zu überprüfen.
Wie man in WordPress den Debugmodus aktiviert damit PHP-Fehlermeldungen im Frontend angezeigt werden
Manchmal kommt es vor dass eine WordPress-Website crasht. Sie kann also nicht aufgerufen werden, im Frontend erscheint nur eine Fehlermeldung „Es gab einen kritischen Fehler auf deiner Website“.
Das kann aufgrund eines Fehlers in einem Plugin, in einem Theme, oder im WordPress-Core selbst sein. Um den Fehler zu finden und die Website zu reparieren muss man wissen, wo der Fehler auftritt. Man muss also wissen, welcher PHP-Fehler erzeugt wird.
Da ja standardmäßig in WordPress die Anzeige von PHP-Fehlern im Frontend deaktiviert ist muss man diese manuell aktivieren. Das geht aber ganz einfach über FTP.
Loggen Sie sich per FTP auf Ihren Webhost ein und laden Sie aus dem WordPress-Hauptverzeichnis die Datei „wp-config.php“ herunter. Öffnen Sie die Datei und suchen Sie nach dem Eintrag
define( 'WP_DEBUG', 'false');
Setzen Sie den Wert dieser Variabe auf „true“ damit das Debugging aktiviert ist und Fehlermeldungen im Frontend angezeigt werden:
define( 'WP_DEBUG', 'true');
Falls Sie diese Zeile in der Datei „wp-config.php“ nicht finden muss Sie neu angelegt werden. Fügen Sie dazu am Ende der Datei einfach folgenden Eintrag ein:
define( 'WP_DEBUG', 'true');
Speichern Sie danach die Datei und laden Sie sie auf den Webspace hoch. Danach können Sie Ihre WordPress-Website im Frontend aufrufen, anstatt der kryptischen Meldung „Es gab einen Fehler auf deiner Website“ werden nun die genauen PHP-Fehlermeldungen angezeigt.
Was tun wenn nach einem Plugin-Update die Website crasht und man sich auch nicht mehr in das Backend einloggen kann?
Manchmal kommt es vor, dass unmittelbar nach dem Update eines WordPress-Plugins die Website crasht, also nicht mehr aufgerufen werden kann. Auch ein Einloggen in das Backend ist dann nicht mehr möglich.
Gründe dafür kann es mehrere geben: es kann sein dass beim Update des Plugins einfach ein Fehler aufgetreten ist, dass das Pluginupdate (bzw. diese Version des Plugins) fehlerhaft ist oder sich mit der aktuell installierten Version von WordPress nicht verträgt, oder dass es einen Konflikt mit einem anderen Plugin gibt.
Um die Website wieder funktionsfähig zu machen muss man nun das Plugin deaktivieren. Normalerweise macht man das im Backend, das funktioniert hier aber nicht weil ja auch das Backend nicht mehr aufgerufen werden kann.
Es gibt aber noch eine andere Möglichkeit um ein WordPress-Plugin zu deaktivieren, und zwar über FTP. Loggen Sie sich dazu per FTP auf Ihren Webspace ein und wechseln Sie in das WordPress-Verzeichnis. Dort wechseln Sie in das Verzeichnig „wp-content“ und dort dann in das Verzeichnis „plugins“.
Hier sehen Sie nun verschiedene Verzeichnise, jedes Verzeichnis gehört zu einem Plugin, darin befinden sich die Dateien des jeweiligen Plugins. Suchen Sie sich nun das fehlerhafte Plugin (die Verzeichnisnamen entsprechen mehr oder weniger den Namen der Plugins) und nennen Sie dieses Verzeichnis um. Welchen Namen Sie hier neu setzen ist es egal, er darf nur keinen der anderen Plugins entsprechen.
Durch das Umbenennen wird das Plugin automatisch deaktiviert, der Aufruf der Website und des Backends sollte wieder ganz normal möglich sein. Sie können sich nun wieder in das Backend einloggen und mit der Fehlersuche beginnen. Wenn Sie das Plugin wieder aktivieren möchten, um etwa Konflikt mit anderen Plugins auszutesten, müssen Sie den Verzeichnisnamen aber vorher wieder auf den ursprünglichen zurücksetzen. Keine Angst, nach dem Deaktivieren kann hier erstmal nichts passieren.
Meistens werden Sie das Plugin aber löschen und neu installieren müssen. Es kann auch sinnvoll sein nochmal genau die Anforderungen des Plugins an WordPress und den Webspace zu überprüfen. Eventuell benötigt es ja in der aktuellsten Version Einstellungen, die Ihr Webhoster nicht mehr unterstützt.
Gutenberg-Blöcke können nicht bearbeitet werden
Wenn man im WordPress-Backend Inhalte bearbeitet kann es vorkommen, dass z.B. auf Seiten, Blogbeiträgen oder in Widgets einzelne oder alle Blöcke des Gutenberg-Editors nicht mehr bearbeitet werden können. Der jeweilige Block lässt sich nicht mehr anklicken, stattdessen wird folgende Fehlermeldung angezeigt: „In diesem Block ist ein Fehler aufgetreten und eine Vorschau ist nicht möglich.“
Meistens liegt die Ursache darin, dass eines oder mehrere installierte Plugins nicht mit der installierten WordPress-Version kompatibel sind. Daher tritt dieses Problem meistens auch nach Updates auf, insbesondere dann, wenn automatische Updates von WordPress oder Plugins aktiviert wurden.
Um Fehler zu beseitigen sollten Sie WordPress und alle Plugins auf den aktuellen Stand bringen. Sollte das nicht helfen kann es sein, dass es für ein einzelnes Plugin, das den Fehler verursacht, noch kein passendes Update gibt. Dann müsse Sie dieses Plugin deaktivieren und ein Alternativplugin installieren, bis ein passendes Update verfügbar ist. Als Alternative können Sie natürlich auch einfach auf das Bearbeiten der Gutenberg-Blöcke vorübergehend verzichten bis ein passendes Update installiert werden kann.
Website nicht erreichbar und Fehlermeldung ab WordPress 6.1 + WPML
Das Problem:
Bei Webseiten, auf denen das Mehrsprachenplugin WPML im Einsatz ist, kommt es in letzter Zeit häufig zu Fehlermeldungen. Die Website kann dann im Frontend nicht mehr aufgerufen werden, WordPress gibt die Meldung „Es gab einen kritischen Fehler auf deiner Website“ aus.
Wenn man das Debugging aktiviert erhält man eine Fehlermeldung in der Form „Uncaught Error: Call to undefined method WP_Textdomain_Registry::reset() in /kunden/XXXXXX/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LanguageSwitch.php“.
Die Lösung:
In WordPress Version 6.1 wurden gröbere Änderungen im Code eingebaut, die nicht mit älteren Version von WPML, genauer gesagt mit dem Plugin „WPML Multilingual CMS“ und „WPML String Translation“ kompatibel sind. Mehr Informationen dazu hier.
Wird nun WordPress auf die Version 6.1 oder aktueller upgedated, dann crasht WPML und die Website, im Frontend wird die angeführte Fehlermeldung angezeigt.
Um das zu beheben muss WPML auf die aktuellste Version upgedated werden. Dazu wurden aktuelle Versionen von WPML Multilingual CMS (4.5.13) sowie WPML String Translation (3.2.3) veröffentlicht. Die Updates können (wenn man eine aktuelle Lizenz besitzt) einfach im WordPress-Backend installiert werden.
Wichtig: um Fehler im Vorhinein zu vermeiden müssen diese Updates eingespielt werden, bevor WordPress selbst auf eine Version ab 6.1 upgedated wird. Das wird auch von WPML selbst so empfohlen.
