PHP 5.6 läuft noch, und niemand traut sich an das Upgrade
Die Ausgangslage
Ein Berufsverband mit rund 6.000 Mitgliedern betreibt eine Website mit drei Komponenten: ein klassisches WordPress als Außenauftritt, ein selbstgeschriebenes Mitglieder-Portal in reinem PHP (Sessions, MySQL, Templates ohne Framework), und eine PDF-Generierung für Beitragsbescheinigungen über mPDF 5. Alles läuft auf einem gemeinsamen Webserver mit PHP 5.6.
PHP 5.6 ist seit Anfang 2019 End-of-Life. Keine Sicherheitsupdates, keine offiziellen Patches, keine Kompatibilität mehr mit aktuellen Bibliotheken. Der Hoster hatte mehrfach angekündigt, PHP 5.6 abzuschalten, und genauso oft die Frist verlängert. Beim Verband wusste man, dass es ein Problem ist. Man hatte sich nicht getraut, weil:
- Das WordPress lief mit fünf veralteten Plugins, von denen zwei seit Jahren nicht mehr im Repository sind.
- Das Mitglieder-Portal nutzte
mysql_*-Funktionen, kurze PHP-Tags,ereg()und magische Quotes. - Niemand wusste, ob die Beitragsbescheinigungen unter neuerem PHP noch korrekt erzeugt würden.
- Der ursprüngliche Dienstleister hatte den Betrieb eingestellt.
Ein Angebot, „mal eben alles neu zu machen", lag bei knapp 80.000 Euro vor. Der Vorstand suchte eine kleinere, realistische Lösung.
Was wir gemacht haben
Wir haben den Ist-Stand erfasst und einen Tilgungsplan in vier Etappen aufgestellt. Vor jeder Etappe ein Backup, nach jeder Etappe ein Regressionstest mit echten Mitgliederdaten in einer Staging-Umgebung.
Etappe 1, Bestandsaufnahme und Staging. Wir haben das System 1:1 auf einem Staging-Server gespiegelt. Dort konnten wir gefahrlos testen. Parallel haben wir alle Deprecation-Warnings unter PHP 7.4 dokumentiert: 312 Stellen im Mitglieder-Portal, davon 47 mit echtem Refactoring-Bedarf.
Etappe 2, PHP 7.4. Wir haben das Portal Schritt für Schritt PHP-7.4-kompatibel gemacht: mysql_* durch PDO ersetzt, ereg() durch preg_*, kurze Tags ausgeschrieben. WordPress wurde aktualisiert, zwei verwaiste Plugins durch gepflegte Alternativen ersetzt, ein drittes nach Code-Review weiter verwendet. Deployment via Rsync auf Produktion am Sonntagmorgen, Rollback-Plan bereit, keine Downtime.
Etappe 3, PHP 8.0 und 8.1. Hauptthema: strikte Typen, geänderte Fehler bei Strings/Numbers, neue Behandlung von null. Hier waren die Beitragsbescheinigungen kritisch, denn die mPDF-Version war nicht 8er-kompatibel. Wir haben auf mPDF 8.2 aktualisiert, die Templates angepasst und mit 30 echten Bescheinigungen aus dem Vorjahr verglichen, byteweise.
Etappe 4, PHP 8.2. Hier waren die Änderungen klein: ein paar dynamische Properties, ein utf8_encode. Schnell erledigt.
Das Ergebnis
Sechs Monate von Bestandsaufnahme bis PHP 8.2. Keine Downtime, keine verlorenen Daten, keine fehlerhaften Bescheinigungen. Kosten lagen bei knapp einem Fünftel des Neuangebots. Die Website läuft schneller, der Server-RAM-Verbrauch ist gesunken, der Hoster ist zufrieden.
Wichtiger: Der Verband hat jetzt eine dokumentierte Codebasis und einen Wartungsvertrag. Die nächste PHP-Version wird kein Drama mehr sein, sondern eine kalkulierbare Etappe.