Aktuelles

Wenn die Website ein Museum ist: Vom Abenteuer, alte WordPress-Seiten ins Heute zu holen

Es gibt diese Websites, die seit Jahren brav ihren Dienst tun. Niemand fasst sie an, weil sie ja laufen... sozusagen gewissermaßen quasi "Never touch a running system". Und genau das ist das Problem. Denn „läuft" heißt im Web nicht „ist gesund" – sondern es heißt nur „ist noch nicht abgekackt". Seit ein paar Monaten schalten Webhoster ihre alten PHP-Versionen aus, spätestens jetzt ziehen seeeeehr dunkle Wolken am digitalen Himmel auf.

In den letzten Tagen haben wir zwei solcher Patientinnen auf dem OP-Tisch liegen gehabt: einmal eine Seite, die wir relativ entspannt durch die Modernisierung gebracht haben, und einmal eine, die uns gezeigt hat, dass „kurzes Update, halbe Stunde" manchmal ein frommer Wunsch bleibt. Beide Fälle erzählen ziemlich gut, warum das Aktualisieren alter Websites ein eigenes Handwerk ist – und warum „einfach mal auf den Update-Button klicken" gelegentlich in einem weißen Bildschirm endet.

Warum überhaupt updaten, wenn doch alles funktioniert?

Die Frage hören wir oft, und sie ist völlig berechtigt. Die kurze Antwort: Sicherheit und Zukunftsfähigkeit.

Eine etwas längere: WordPress und PHP – die Programmiersprache, auf der WordPress läuft – bekommen regelmäßig Updates, die bekannte Sicherheitslücken schließen. Wer auf einer alten Version sitzen bleibt, lässt die Tür offen, von der inzwischen jeder weiß, wo sie ist und wie sie klemmt. Dazu kommt: Alte PHP-Versionen werden irgendwann gar nicht mehr gepflegt. PHP 7.4, das wir bei einem der beiden Projekte vorgefunden haben, bekommt schon seit Ende 2022 keine Sicherheitsupdates mehr. Das ist in Internet-Jahren ungefähr die Steinzeit.

Und schließlich gibt es noch den ganz praktischen Grund: Neue WordPress-Versionen setzen zunehmend aktuelle PHP-Versionen voraus, und neue Plugin-Versionen setzen aktuelle WordPress-Versionen voraus. Wer zu lange wartet, sitzt am Ende in einer Sackgasse, in der sich gegenseitig alles blockiert. Womit wir direkt beim ersten interessanten Phänomen wären.

Das Henne-Ei-Problem

Bei einer der Seiten wollte ich zuerst die Plugins aktualisieren, bevor ich an den großen WordPress-Sprung gehe. Klingt vernünftig. Nur: WordPress zeigte schlicht keine Plugin-Updates an. Stattdessen, in den Details, der freundliche Hinweis: „Dieses Plugin erfordert eine neuere WordPress-Version."

Man dreht sich also im Kreis. Das Plugin will ein neueres WordPress, das neuere WordPress wäre aber genau der Schritt, den man gerade machen will. Die Lösung ist unspektakulär, aber man muss sie kennen: zuerst der WordPress-Kern, dann die Plugins. WordPress versteckt die Plugin-Updates nämlich absichtlich, solange der Unterbau zu alt ist – damit man sich nicht eine Plugin-Version installiert, die mit der alten Basis ohnehin nicht laufen würde. Eine eingebaute Schutzfunktion, die sich im ersten Moment anfühlt wie ein Bug. Ist aber keiner.

Fall eins: Das Theme, dessen Hersteller es nicht mehr gibt

Die erste Seite lief auf einem Theme namens „Finale". Schönes Theme, durchaus. Kleines Detail: Der Hersteller existiert nicht mehr. Die Firma ist weg, die Website tot, Updates wird es nie wieder geben. Das Theme ist damit das digitale Äquivalent eines Oldtimers, für den niemand mehr Ersatzteile produziert – fahrbar, solange nichts kaputtgeht, aber bei jeder Reparatur ist Handarbeit angesagt.

Und genau die war nötig. Tief im Theme schlummerten Code-Bausteine aus einer Zeit, in der PHP noch ganz anders funktioniert hat. Funktionen, die in modernen PHP-Versionen schlicht ersatzlos gestrichen wurden. Schreibweisen, die vor zehn Jahren völlig normal waren und heute einen sofortigen Absturz auslösen. Ein eingebundenes Hilfsprogramm zur Theme-Konfiguration, das aus der digitalen Bronzezeit stammt und bei jedem Aufruf brav versucht hätte, Nutzungsdaten an einen Server zu schicken, den es längst nicht mehr gibt – "Es fährt ein Zug nach nirgendwo" um mal einen bekannten Schlager zu zitieren.

Das alles haben wir aufgespürt, ersetzt und sauber getestet, bevor überhaupt jemand etwas davon mitbekommen hat – und zwar auf einer Testkopie, nicht an der echten Seite. Das Erscheinungsbild blieb exakt gleich. Für die Besucher hat sich nichts verändert, außer dass im Maschinenraum jetzt kein Code mehr tickt, der bei der nächsten Server-Aktualisierung die ganze Seite hätte lahmlegen können. Sogar ein zweites Uralt-Plugin von 2006 (ja, Sie haben richtig gelesen, das Ding ist älter als das erste iPhone) ließ sich mit ein paar Handgriffen wiederbeleben.

Dieser Fall lief, wie man sich das wünscht: gründlich, planbar, am Ende ein zufriedener Haken auf der Liste. Was uns nahtlos zum zweiten Fall bringt, der sich nicht ganz an dieses Drehbuch gehalten hat.

Fall zwei: Wenn die Seite einfach „kritischer Fehler" sagt und sich wegduckt

Die zweite Seite war der deutlich größere Sprung. Über fünfzehn WordPress-Hauptversionen (!) lagen zwischen Start und Ziel – das ist, als würde man ein Auto von 2010 direkt zum aktuellen Modell umrüsten und dabei hoffen, dass die alten Teile mit der neuen Elektronik reden. Das WordPress-Update selbst lief erstaunlich glatt durch, bis zum letzten Schritt, dem Abschalten des Wartungsmodus. Und dann, genau in dem Moment, in dem die Seite wieder normal hätte laden sollen: Serverfehler 500. Schwarz auf weiß, oder genauer gesagt, weiß auf nichts.

Jetzt fängt die eigentliche Detektivarbeit an. Denn ein 500er sagt erstmal nur: „Irgendwas ist kaputt." Sehr informativ, nicht? Wo, warum, durch wen – Fehlanzeige. Das Fehlerprotokoll, das uns das eigentlich verraten sollte, blieb beharrlich leer. Wie sich herausstellte, war auf diesem Server die Fehlerprotokollierung schlicht abgeschaltet, und WordPress' eigener Schutzmechanismus fing den Absturz ab, bevor er sichtbar wurde – freundlich gemeint, aber für die Fehlersuche ungefähr so hilfreich wie ein Zeuge, der beteuert, er habe nichts gesehen.

Es brauchte also ein paar Schichten Überzeugungsarbeit und mehrere Hektoliter Kaffee, bis die Seite endlich verriet, was sie quält. Und die Antwort war keine, die man mit einer Zeile Code wegwischt: Der Speicher ging aus. Nicht ein bisschen knapp – komplett erschöpft, und das bei einem großzügig bemessenen halben Gigabyte. Irgendwo im Zusammenspiel der über Jahre angesammelten Inhalte, Plugins und Theme-Funktionen baute sich beim Aufruf ein Speicherberg auf, der das Limit sprengte. Das ist der Unterschied zwischen „eine kaputte Schraube" und „das Fundament ächzt": Es gibt nicht die eine Zeile, die schuld ist. Es ist das Gesamtgewicht.

Man könnte sich an dieser Stelle festbeißen. Stundenlang im uralten Theme-Code stochern, eine verdächtige Funktion nach der anderen freilegen, das digitale Äquivalent zu „dann bauen wir den Motor halt einmal komplett auseinander". Manchmal ist das der richtige Weg. Hier nicht. Denn anders als beim ersten Projekt gab es den Theme-Hersteller in diesem Fall noch – und der hatte längst eine aktuelle, für moderne Systeme generalüberholte Version im Regal liegen.

Also die pragmatische Lösung: aktuelle Theme-Version vom Hersteller geholt, sauber installiert, die zugehörigen Plugins nachgezogen. Und plötzlich lief die Seite wieder, als wäre nie etwas gewesen. Der Speicherberg? Verschwunden, weil der moderne Code schlicht nicht mehr so verschwenderisch mit Ressourcen umgeht wie sein betagter Vorgänger. Was eben noch nach einer langen Nacht aussah, war auf einmal eine ziemlich kurze Gerade.

Die Moral von der Geschichte ist fast schon poetisch, jedenfalls für jemanden, der Poesie in Servern sucht: Beim alten Oldtimer ist die beste Reparatur manchmal nicht, jede einzelne Schraube nachzudrehen, bis einem die Finger bluten – sondern den passenden neuen Motor einzubauen. Vorausgesetzt natürlich, es gibt überhaupt noch jemanden, der diesen Motor baut. Sonst sind wir wieder bei Fall eins und der liebevollen Handarbeit.

Was man daraus mitnimmt, neudeutsch "Learnings"

Ein paar Dinge zeigen sich bei solchen Aktionen immer wieder, fast wie Naturgesetze:

1. Ein Backup ist nicht optional, es ist die Lebensversicherung. Wer ohne aktuelles, vollständiges Backup an einer alten Live-Seite herumschraubt, hat entweder sehr viel Mut oder noch nie erlebt, wie es ist, wenn um 23 Uhr nichts mehr geht. Beides lässt sich kurieren – das eine durch Erfahrung, das andere durch ein Backup.Alter Code ist nicht automatisch schlechter Code. Vieles davon war zu seiner Zeit absolut sauber und korrekt. Es ist nur die Welt drumherum weitergezogen. Das ist kein Vorwurf an die ursprünglichen Entwickler, sondern einfach die Natur der Sache – Software altert, ob man will oder nicht.
2. Je länger man wartet, desto größer der Sprung. Die Seite, die nur ein paar Versionen zurücklag, war in einem Nachmittag erledigt. Die, die ein halbes Jahrzehnt liegengeblieben war, hat uns deutlich mehr Nerven gekostet – und am Ende den kompletten Theme-Austausch gebraucht, statt einer schnellen Politur. Regelmäßige kleine Updates sind unbequem, aber sie ersparen einem den großen, teuren Kraftakt.
3. Und schließlich: Es gibt einen Unterschied zwischen „die Seite ist online" und „die Seite ist in einem Zustand, in dem man nachts ruhig schläft". Genau dieser Unterschied ist unser Job.

Falls Sie jetzt mit leicht mulmigem Gefühl an Ihre eigene Website denken, die seit Bundeskanzler Adenauer kein Update mehr gesehen hat – das ist vermutlich ein guter Instinkt. Sprechen Sie uns gern an, bevor das der Server für Sie entscheidet.

24.06.2026