Was du heute kannst besorgen, das verschiebe nicht auf morgen. Meistens lebe ich ganz gut nach diesem Prinzip. Bei meiner Website-Infrastruktur jedoch hatte ich mich in den vergangenen Monaten etwas gehenlassen. Meine WordPress-Installation war bei 5.2 stehengeblieben, mein Theme hatte ich zwei Jahre lang nicht erneuert und die PHP-Version war mit 7.2 am Ende ihres Lebenszyklus – ab Dezember wird die Version nicht mehr gewartet. Somit blieb mir nur noch eines: aktualisieren, aufmöbeln, auffrischen. Eine wahre Update-Schlacht wartete auf mich.

Weshalb ich der Schlacht so lange ausgewichen war, wurde mir alsbald klar. Nachdem ich meine Website auf die aktuelle WordPress-Version (5.5.1) angehoben hatte, luden meine Beiträge nicht mehr richtig und waren verschiedene Design-Elemente kaputt. Das wird sich geben, sobald die neueste Version meines Themes installiert ist, dachte ich mir. Denkste – das Gegenteil war der Fall.

White Screen of Death

Mich erwartete das, wovor sich jede Bloggerin und jeder Website-Betreiber fürchtet: der White Screen of Death. Meine Website war im Frontend nicht mehr erreichbar und starrte mich nur blank an. Google wusste vieles zu berichten über diesen eigenartigen weissen Tod, den anscheinend vor allem WordPress-Seiten sterben.

Ich schaute mir Dutzende von Hilfen, Tutorials und Checklisten an (einen guten 9-Punkte-Plan gegen den White Screen of Death hat die Hosting-Agentur Kinsta zusammengestellt). Mein Problem schien nicht zu den häufigsten Ursachen für den weissen Bildschirm zu gehören. Da ich aber immerhin herausfand, dass entweder eines meiner Plugins oder mein Theme der Grund für das Malaise waren, probierte ich intuitiv ein paar Dinge aus. Und tatsächlich: Auslöser für die Totenstarre meiner Website war der Pageloader des Themes. Ein kleines, animiertes Quadrat, das beim Wechsel von einer Seite zur nächsten erscheint. Ich deaktivierte den Pageloader – und voilà, meine Website wurde wieder angezeigt.

Totalabsturz

Mit dem aktuellen Theme und der neuesten WordPress-Version sah meine Seite nun ganz ordentlich aus. Es gab jedoch ein paar Veränderungen, die ich zurückanpassen wollte oder die ich als fehlerhaft identifizierte. Dumm nur: Auf die betroffenen Seiten konnte ich nicht zugreifen. WordPress meldete bei jedem Versuch einen «kritischen Fehler». Zwar hatte ich dem weissen Tod ein Schnippchen geschlagen und wieder eine öffentlich zugängliche Website. Diese wurde aber unsauber dargestellt und war nun im Backend nicht mehr erreichbar. Au Backe.

Ich hatte bei der Theme-Aktualisierung einen Trick angewandt, um die vorherige Version meines Themes im WordPress-Backend als Notnagel verfügbar zu haben. Nun war ich froh darum und wechselte guten Mutes zurück zur Vorgängerversion.

Es wurde aber nur schlimmer. Besagter Trick schien bei mir einen Konflikt zwischen den beiden Theme-Versionen zu provozieren. Die Website war plötzlich ein einziges Design-Chaos. Schriften, Schriftgrössen, Abstände, Formatierungen und Farben wurden irgendwie, nur nicht gestaltet ausgegeben. Andere Anpassungen waren ebenfalls verloren und auf die Werkseinstellungen des Themes zurückgesetzt. Ich textete per Whatsapp: «Habe soeben meine Website gecrasht.»

WordPress mit Backup wiederherstellen

Weshalb macht man wöchentlich ein Backup seiner WordPress-Datenbank und Website-Inhalte? Genau für solche Momente. Ich zückte das letzte Backup und fand bei meinem Plugin-Anbieter Backwpup und ebenso hier wertvolle Anleitungen für die Wiederherstellung von WordPress-Websites.

Nach 15 Minuten war meine Website wieder da, wahrhaftig in alter Frische. Ich war zwar keinen Schritt weiter als vor meinem Update-Run, dafür um eine Erkenntnis und eine Erfahrung reicher. Nämlich: Backups lohnen sich und Wiederherstellungen sind keine Hexerei.

Staging-Site einrichten

Bevor ich am nächsten Tag noch einmal von vorne loslegte, machte ich mich zum Thema Staging-Site schlau. Eine Staging-Seite ist eine Kopie der Live-Website und ermöglicht, Updates und Anpassungen der Live-Seite in einer geschützten Umgebung zu testen. Es gibt grob drei Möglichkeiten, ein Staging aufzusetzen: manuell (anspruchsvoll), über den Hosting-Anbieter (eher die Ausnahme als die Regel) oder mit einem Plugin (einfach). Ich entschied mich für letzteres und das Plugin «WP Staging». Das Aufsetzen klappte einwandfrei, im Handumdrehen hatte ich mein Staging eingerichtet.

Übrigens ist es mit WP Staging oder einem analogen Plugin auch möglich, PHP-Updates zu testen – zumindest bei Hostpoint, meinem Hosting-Anbieter. Das ist nicht selbstverständlich, da das Plugin in der Datenbank der Live-Website einen Unterordner für das Staging erstellt. Sowohl Live-Seite als auch Staging-Site basieren so auf der gleichen PHP-Version. Ein PHP-Update lässt sich damit nicht isoliert in der Staging-Umgebung ausprobieren.

Je nach Hosting lassen sich die Parameter der einzelnen Ordner in einer Datenbank aber individuell einstellen. Bei Hostpoint kann man den Staging-Ordner (dev) jedenfalls unabhängig vom übergeordneten Verzeichnis und den übrigen Ordnern ansteuern und über die «Web-Einstellungen» die PHP-Version proprietär anpassen:

Noch einmal von vorn

Nun war ich parat für den zweiten Update-Versuch – zunächst in meinem Staging-Labor. Alles lief wie am Schnürchen: WordPress-Aktualisierung, Theme-Update, PHP-Update, Feinschliff. Bei der Theme-Aktualisierung verzichtete ich indes auf oben erwähnten Trick und überschrieb die vorherige Version direkt im Backend, was WordPress nunmehr (ab Version 5.5.1) ermöglicht. Eine gute Übersicht darüber, welche vorgängigen Änderungen bei einem Theme-Update erhalten bleiben, gibt es übrigens hier.

Nun musste ich das ganze Prozedere nur noch in meiner Live-Umgebung durchexerzieren. Das tat ich. Post festum tippte ich in mein Handy: «Website läuft. :-)»