Kurzzeitig nicht verfügbar für geplante Wartung
WordPress schreibt eine .maintenance Datei vor einem Update und entfernt sie danach. Das Update wurde nicht beendet, also ist die Datei immer noch da.
Briefly unavailable for scheduled maintenance. Check back in a minute.
Löschen Sie die .maintenance-Datei im Web-Root und die Website kehrt sofort zurück. Das ist die gesamte Korrektur - aber ein Update, das auf halbem Weg gestorben ist, hat möglicherweise Dateien teilweise ersetzt, also überprüfen Sie den Kern danach.
Die wahrscheinlichsten Ursachen zuerst.
Gehen Sie die Liste der Reihe nach durch. Prüfen Sie jede Ursache, bevor Sie etwas ändern, da die Lösungen unterschiedlich sind und eine Vermutung mehr Zeit kostet als ein Befehl.
| Ursache | So prüfen Sie es | Lösung |
|---|---|---|
| Ein Update, das Mitte des Laufs ausgefallen ist | Der Zeitstempel der Datei stimmt mit dem Start des Updates überein, und das Update hat nie einen Erfolg gemeldet. | Löschen Sie die Datei und führen Sie das Update dann irgendwo ohne Timeout aus. |
| Der Browser-Tab wurde während eines Updates geschlossen | Sie navigierten weg oder die verbindung fiel, während der fortschrittsbildschirm angezeigt wurde. | Löschen Sie die Datei und wiederholen Sie sie erneut. Nichts wird dadurch von selbst beschädigt - die Flagge hat den Prozess, der sie festgelegt hat, einfach überlebt. |
| Bulk Updates liefen aus dem Speicher | Mehrere Plugins wurden auf einmal aktualisiert und das Fehlerprotokoll zeigt einen Out-of-Memory-Faltic zu diesem Zeitpunkt. | Löschen Sie die Datei und aktualisieren Sie sie in kleineren Batches oder aus der Befehlszeile. |
| Ein halber ersetzter Kern | Die Website kehrt nach dem Löschen der Datei zurück, verhält sich aber seltsam - fehlende Administratorbildschirme oder Versionsnummern, die nicht übereinstimmen. | Überprüfen Sie die Prüfsummen des Kerns und installieren Sie dieselbe Version erneut. |
| Die Datei kann nicht gelöscht werden | Der Webbenutzer besitzt es nicht, daher konnte das Update es auch nicht entfernen. | Beheben Sie das Eigentum im Web-Root. Gemischtes Eigentum ist der Grund, warum dieser Fehler eher dauerhaft als momentan wird. |
Schritt für Schritt zur Lösung.
Die Befehle setzen WP-CLI und Shell-Zugriff voraus. Jeder Schritt erklärt, was er tut, damit Sie ihn bei Bedarf im Dashboard oder per SFTP ausführen können.
Bestätigen Sie, dass die Datei vorhanden ist
Es ist eine Dotfile im Web-Root, so dass es nicht in einer gewöhnlichen Auflistung angezeigt wird.
ls -la .maintenance
Löschen Sie es
Die Seite ist zurück, sobald sie weg ist. Kein Neustart, kein Cache Flush.
rm .maintenance
Prüfen Sie, ob der Kern intakt ist
Ein unterbrochenes Update kann einige Dateien ersetzen lassen und andere nicht.
wp core verify-checksums
Beenden Sie das Update, das fehlgeschlagen ist
Von der Befehlszeile, wo ein Browser-Tab ihn nicht vorzeitig beenden kann.
wp core update && wp plugin update --all
Stellen Sie sicher, dass die Dateien im Besitz des Web-Benutzers sind
Wenn dies nicht der Fall ist, schlägt das nächste Update auf die gleiche Weise fehl.
ls -la wp-content | head -n 5
Darum kümmert sich die Plattform.
Updates laufen über die Plattform und nicht über eine Browser-Registerkarte, so dass ein geschlossenes Fenster das Flag nicht zurücklassen kann, und der Administratorkontext hat Ausführungslimits, die für die Arbeit statt der dreißig Sekunden, die eine Web-Anfrage erhält, festgelegt sind. Das Eigentum über den Web-Root ist auf Deployment festgelegt und bleibt konsistent, was die Version von diesem entfernt, wo die Datei überhaupt nicht gelöscht werden kann.
Häufige Fragen.
Ist es sicher, die Datei einfach zu löschen?
Ich kann die Datei nicht über SFTP sehen.
Es kam zurück, nachdem ich es gelöscht hatte.
Werden meine Besucher das gesehen haben?
War es keiner davon?
Diese Fehler können im Browser ähnlich aussehen.