Wenn das WordPress-Update mal verstopft ist

So sieht es im Dashboard aus, wenn ein Upgrade fehlerfrei durchläuft. Im fünften Arbeitsschritt wird der Wartungsmodus eingeschaltet. Geht danach beim Kopieren aber etwas schief, wird er nicht wieder abgeschaltet. Zum Glück bleibt er nicht ewig an.

Zu den Annehmlichkeiten von WordPress zählen die automatischen Updates. Kleinere Versionssprünge (etwa 5.0.2 auf 5.0.3) werden normalerweise ganz ohne Zutun des Admins durchgeführt. Bei großen Versionssprüngen (etwa 4.9 auf 5.0) erscheint im Dashboard eine Aufforderung zum Upgrade (Aktualisierungen, die über Fehlerbeseitigung hinausgehen und neue Funktionen eröffnen, sind genau genommen keine Updates, sondern Upgrades), das sich mit einem Mausklick anstoßen lässt und dann ebenfalls automatisch durchläuft. Manchmal aber auch nicht.

Wenn das Upgrade einmal hängen bleiben sollte, dann ist Handarbeit angesagt. Im schlimmsten Fall verbleibt WordPress im sogenannten Wartungs-Modus, und statt des Blogs bekommen Besucher eine Fehlermeldung zu sehen.

Eine versteckte Datei namens .maintenance

Das ist peinlich, kann aber passieren. Im Zuge eines Upgrades legt WordPress nämlich eine versteckte Datei namens .maintenance im Wurzelverzeichnis des Blogs an. Damit befindet sich die Website im Wartungs-Modus, und zwar so lange, bis Dateien und Datenbank aktualisiert sind und WordPress die kleine Datei wieder löscht.

Nicht schön, wenn Besucher eine solche Fehlermeldung statt des Blogs zu sehen bekommen.

Läuft das Upgrade jedoch nicht bis zum Ende durch, wird die Datei nicht gelöscht und Besucher bekommen die Fehlermeldung zu sehen – bis ein Blog-Betreiber die Datei eigenhändig auf dem Webserver löscht, und zwar entweder per FTP oder SSH, oder bis die Datei, die einen Zeitstempel enthält, ignoriert wird. Das ist laut WordPress-Codex nach zehn Minuten der Fall. Die Peinlichkeit währt also nicht endlos.

Da es sich um eine versteckte Datei handelt (in Linux und anderen unixoiden Betriebssystemen beginnen die Namen versteckter Dateien mit einem Punkt), kann es sein, dass man sie in einem FTP-Programm gar nicht angezeigt bekommt. Ganz sicher lässt sich die Existenz der Wartungsdatei mit einem Fernzugriffs-Programm wie Putty oder in einer Konsole per ssh ermitteln:

ls -la /pfad/zu/wordpress/

listet alle Dateien, auch die versteckten, im WordPress-Wurzelvereichnis. Existiert die Datei (und das sollte sie, sonst würde der Hinweis auf den Wartungsmodus nicht erscheinen, es sei denn, es sind irgendwelche Plugins installiert, die den Wartungsmodus beeinflussen), kann sie wie folgt gelöscht werden:

rm /pfad/zu/wordpress/.maintenance

Klarer Fall: /pfad/zu/wordpress/ muss der tatsächlichen Verzeichnisstruktur entsprechend angepasst werden.

Zum Aktualisieren werden Schreibrechte benötigt, sonst bleibt das Upgrade hängen

Nicht immer muss ein gescheitertes Upgrade im Wartungs-Modus havarieren. Fast immer gibt es dafür laut den WordPress-Entwicklern jedoch denselben Grund: fehlende Schreibrechte.

One-click updates work on most servers. If you have any problems, it is probably related to permissions issues on the filesystem.WordPress Codex

Denn zum Aktualisieren ist der Zugriff auf alle Dateien einer WordPress-Installation notwendig – mit Ausnahme des Ordners wp-content und der Konfigurationsdatei wp-config.php, die sind natürlich tabu.

Wenn nun WordPress – genauer gesagt: dem Webserver, auf dem WordPress läuft -, verweigert wird, Dateien zu ändern, zu löschen oder neu zu schreiben, dann bleibt das Upgrade hängen. Abhilfe schafft hier nur, selbst Hand anzulegen und die Rechte entsprechend zu ändern.

Der Webserver muss für alle Dateien und Ordner im WordPress-Verzeichnis Schreibrechte erhalten (wie sicher das ist, soll an dieser Stelle nicht diskutiert werden; man kann die Automatik auch in der wp-config.php deaktivieren und manuell aktualisieren). In einer SSH-Konsole oder Putty sieht das etwa so aus wie der folgende Vierzeiler:

cd /pfad/zu/wordpress/
chown webserver-user -R .
chmod 600 -R .
find . -type d -exec chmod 700 {} \;

In diesem Beispiel erhält der Webserver als Eigentümer Schreib- und Leserechte auf alle Dateien (600) sowie Schreib-, Lese- und Ausführungsrechte auf alle Verzeichnisse (700). Gruppen und andere Benutzer dürfen nichts. Den Benutzernamen webserver-user muss man anpassen; auf einem typischen Debian-Linux wird der Webserver zum Beispiel als www-data ausgeführt, bei einem Shared-Hosting-Anbieter wird der Benutzername in der Regel mit Hilfe einer individuellen Kundenkennung gebildet.

Hat man die Rechte entsprechend geändert, kann die Aktualisierung im Dashboard erneut angestoßen werden. Der Vorteil gegenüber einem unbeaufsichtigten Upgrade besteht darin, dass man die Arbeitsschritte „live“ beobachten kann (siehe Screenshot oben).

Wenn das Upgrade schon am Anfang ohne Fehlermeldung hängenbleibt

Nun passiert es aber durchaus, dass der Upgrade-Vorgang bereits vor der eigentlich Aktualisierung, also beispielsweise beim zweiten Arbeitsschritt „Entpacken der aktualisierten Version …“ hängen bleibt. Auch das hat oft mit fehlenden Zugriffsrechten zu tun, oder es mangelt an Speicherplatz zum Entpacken.

Was genau die Fehler-Ursache ist, weiß man nicht genau. WordPress jedenfalls lässt den Admin in dieser Situation gerne mal im Unklaren: der Upgrade-Vorgang hält einfach an, im Dashboard tut sich nichts mehr, und ein Upgrade-Log gibt es auch nicht.

Immerhin – die Website funktioniert noch genauso wie zuvor, denn WordPress hat in diesem frühen Stadium des Upgrade-Prozesses noch nichts verändert und auch die .maintenance-Datei noch gar nicht geschrieben. Das geschieht ja erst beim fünften Arbeitsschritt.

„Momentan wird eine andere Aktualisierung durchgeführt“

Es gibt noch ein weiteres Upgrade-Phänomen bei WordPress: Man klickt im Dashboard auf den Button „Jetzt updaten“ -. doch die Anforderung wird mit der Fehlermeldung „Momentan wird eine andere Aktualisierung durchgeführt“ (englisch: „Another update is currently in progress“) schnöde verweigert. Das passiert immer dann, wenn nach einem fehlerhaften Upgrade-Vorgang ein erneutes Upgrade angestoßen wird.

Der Grund: WordPress setzt in der Datenbank ein Upgrade-Flag, und zwar den sogenannten „core_updater.lock“. Dieses Flag wird schon beim Herunterladen des Upgrade-Paketes gesetzt, also bevor der Wartungs-Modus ausgelöst wird. Deshalb wird man in diesem Fall noch keine .maintenance-Datei finden. Zur Löschung des Flags kommt es aber wegen des Abbruchs auch nicht mehr.

Die einfache Lösung ist, sich einen Kaffee zu kochen und abzuwarten – nach 15 Minuten entfernt WordPress nämlich den Lock wieder. Wer es eilig hat, entfernt den Eintrag für dem Lock eigenhändig aus der Tabelle wp_options der WordPress-Datenbank. Webhoster halten dafür eine Browser-Anwendung wie PHPMyAdmin bereit; wer auf der Kommandozeile heimisch ist, nutzt per SSH den mysql-Client:

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

Noch einfacher geht es, wenn auf dem Server die Kommandozeilen-Oberfläche von WordPress (WP-CLI) installiert ist, mit folgendem Einzeiler:

wp option delete core_updater.lock

Vermutlich hat jeder WordPress-Admin schon einmal seine persönliche Upgrade-Krise erlebt. Mit den Hinweisen in diesem Beitrag sollten sich typische Probleme bewältigen lassen. In allen anderen Fällen hilft statt aufwändiger Fehlersuche nur das Zurückspielen jenes Backups von WordPress-Verzeichnis und Datenbank, das umsichtige Menschen zumindest vor jedem Upgrade, besser noch täglich per Cron-Job oder Backup-Plugin, angelegt haben.

Schreibe einen Kommentar