Letzten Samstag bekam ich einen Schreck. Als ich mich als Admin ins WordPress-Backend meines Blogs einloggen wollte, ging nichts mehr. Der vermeintliche Login-Prozess dauerte ewig, am Ende wurde lediglich eine Fehlermeldung eingeblendet: »502 Proxy Error – The proxy server received an invalid response from an upstream server. The proxy server could not handle the request. Reason: Error reading from remote server«. Uff.
Die gute Nachricht: Das Blog war abseits des Login-Fehlers im Netz fehlerfrei aufrufbar. Die schlechte Nachricht: Das letzte Backup war einige Monate her (KEIN MITLEID!). Also suchte ich nach Berichten und Tipps in Foren, Blogs und auf Hilfeseiten, was die Ursache sein könnte. Am Abend zuvor hatte ich noch vor dem Einschlafen mit dem mobilen WordPress-Client vom Bett aus einen Beitragskommentar freigegeben und beantwortet, doch auch dieser App war nun jeder Login-Zugriff verwehrt. Über Nacht hatten keine protokollierten Updates von Plugins, der PHP-Version oder WordPress selbst stattgefunden. Es blieb ein Rätsel. Die Recherche ergab, dass oftmals Plugins für diese Fehlermeldung verantwortlich sind und es gab auch Tipps, wie ich alle oder einzelne Plugins mittels eines FTP-Clients – der glücklicherweise eingerichtet vorhanden war und auch funktionierte – deaktivieren und so systematisch prüfen konnte, wo der Übeltäter zu vermuten war. Inzwischen war auch eine E-Mail aus dem Backend eingetroffen, die zwar nochmals für Herzklopfen sorgte mit Betreff und Einleitung (»Deine Website hat ein technisches Problem« / »ein Plugin oder ein Theme hat einen fatalen Fehler auf deiner Website verursacht«) , aber auch zwei wichtige Hinweise zur Fehlerbehebung enthielt, nämlich den Namen des Plugins sowie einen Login-Link, der Zugriff auf das WordPress-Backup im »Wiederherstellungsmodus« ermöglichen sollte. Und das klappte!
Ich beschloss daraufhin, nicht nur das vermeintlich fehlerhafte Plugin zu deaktivieren bzw. zu ersetzen, sondern das Blog insgesamt einer Generalüberholung zu unterziehen: alle Plugins auf Kompatibilität prüfen, nicht (mehr) benötigte abzuschalten und zu entfernen bzw. durch neue oder besser bewertete zu ersetzen, die PHP-Version zu aktualisieren und das jüngste Update des WordPress-Core selbst zu installieren. Doch auch mein Backup-Plugin »BackWPup« wies nun Fehlfunktionen auf. Trotz der bis zum Ende durchgeführten Backup-Prozedur wurden bei mehreren Durchgängen und mit unterschiedlichen Backup-Konfigurationen zwischen 9.000 und 20.000 »Warnungen« ausgegeben: »Trying to access array offset on value of type bool«. Also auch dieses Plugin ausgetauscht. Das neue, »UpdraftPlus« lief anstandslos, na also. Nach dem Schreck erschien es mir sinnvoll, ein Backup-Schema mit regelmäßigen Sicherungsintervallen einzurichten und schließlich funktionierte alles wieder fehlerfrei. Hurra!
Dennoch wollte ich es dabei nicht bewenden lassen. Die Anzahl der Plugins könnte noch weiter verringert werden, mein schon etwas betagtes Theme »Treville« auf eine neuere, komfortabler zu handhabende Generation umgestellt werden und das Design einem behutsamen »Facelift« unterzogen werden. Also, auf ans Werk!
Als ich den »Look« des Blogs kritisch betrachtete, war ich damit insgesamt immer noch recht zufrieden. Mein Farbschema, die gewählten Schriften, die vom »EXPO2000«-Logo inspirierte Headergrafik, das Seitenlayout – eigentlich war das immer noch »ich«, obwohl dieser Look bereits seit November 2012 im Einsatz ist. Ein gutes Zeichen, also beschloss ich, das Design nur minimal zu aktualisieren und ansonsten dabei zu bleiben.
Da die Arbeit mit HTML und CSS nicht mein täglich Brot ist und meine Kenntnisse darin begrenzt sind, suche ich beim »Blogbasteln« recht oft Unterstützung auf Seiten wie mdn web docs‘ CSS reference oder W3Schools, bislang auch stets mit Erfolg. Diesmal beschloss ich, versuchsweise zusätzlich ChatGPT zur Prüfung und Optimierung meiner selbstgebastelten Codeschnipsel hinzuzuziehen. Das klappte im Prinzip auch sehr gut, lediglich bei der Schlussprüfung der lokalen Schrifteinbindung baute mir die K.I. einen ziemlich groben Fehler bei der Auszeichnung der »Fallback-Schriften« in den CSS-Code ein, der zwar anfangs plausibel aussah, aber bei der Anwendung zum kompletten Versagen des Stylesheets führte. Erst mithilfe menschlicher Ratgeber via Mastodon konnte ich den Lapsus wieder ausmerzen.
Jetzt sieht alles so aus, wie es aussehen soll, funktioniert (der ersten Prüfung nach) fehlerfrei, auf dem neuesten Stand mit einem neuen WordPress-Theme und gut gesichert mit einem periodischem Backup-Plan. Ich hoffe, meinen Besuchern und Lesern gefällt’s.
Ein kleiner Tipp, auf den andere sicher rufen werden: „Mach das bloß nicht!!!“ Ich betreibe schon längere Zeit auch mehrere Blogs, die ich neulich (hier dann mit fachkundiger Hilfe und Aufsicht) zu einer Multi-Wordpress-Seite (oder wie das heißt) zusammengefasst habe. 5 WordPress habe ich jetzt auf einer Installation laufen, die vorher alle ihre eigene hatten. Und es läuft gut. Worauf ich hinaus will: Ich habe alles, was auch nur ein automatisches Update als Funktion anbot, auf Automatik gestellt: Plugins, Themes und natürlich auch WordPress selbst. Und es läuft fehlerfrei, seit Jahren schon (einzeln und als Sammel-WP). Natürlich wird ab und an kontrolliert, ob alles wirklich aktuell ist, aber die E-Mails, die Bescheid geben, wenn mal wieder wo eine Versionsnummer gestiegen ist und was aktualisiert wurde, beruhigen das Gewissen. Nur bei der PHP-Version muss ich direkt auf der Providerseite die Einstellung vornehmen, bin aber auch hier am oben Ende. Und läuft.
Also: Mut zur Automatik. 😉
Die Plugin-Aktualisierungen habe ich schon länger automatisiert, nur bei PHP und WordPress-Core scheue ich mich noch etwas. Liegt aber vor allem daran, weil ich die periodischen Backups nicht täglich machen will, andererseits aber direkt vor einem Core-Update eins fällig wäre. Mal sehen …
Tja, der Gedanke hat was. Andererseits muss man ja nicht nur Backup und Update unter einen Hut bringen sondern auch die inhaltlichen Ergänzungen. Bei nicht so hohem Contentausstoß kann man die Backups ja eher daran orientieren und die sonstigen Updates automatisieren (bis hin zu WP). Also Backup nach einem neuen Artikel und dann Augen zu und durch. 😉