WordPress PHP 8 Migration: Warum ein Update von PHP 7.4 auf 8.4 mehr ist als nur ein Versionssprung

PHP 7.4 hat bereits im November 2022 das offizielle End-of-Life erreicht – seitdem gibt es keine Sicherheitsupdates mehr. Viele Websites laufen trotzdem noch darauf, weil das Update „mal kaputtgegangen ist" oder weil niemand sich rantraut. Das Problem: Jeder Monat auf einer veralteten PHP-Version ist ein Monat mit offenen Sicherheitslücken und immer weiter wachsender technischer Schuld.

Dazu kommt die Performance. PHP 8.x ist je nach Anwendungsfall bis zu dreimal schneller als PHP 7.4. Bei einer typischen WordPress-Seite mit vielen Plugins merkst du das sofort an der Time-to-First-Byte und den Core Web Vitals. Und seit PHP 8.0 hat sich in der Typenprüfung einiges getan: 8.0 führte strikte Type-Checks für interne Funktionen ein, 8.1 deprecated viele Nullable-Parameter-Muster, 8.2 verbot dynamische Properties, 8.4 verschärft nochmal bei Null-Handling. Jeder dieser Schritte bringt Bruchstellen in alten Plugin- und Theme-Code.

Genau das war die Ausgangslage im Projekt: Eine gewachsene WordPress-Seite auf PHP 7.4, Theme X in einer mehrere Versionen zurückliegenden Installation, ein bunter Mix aus Plugins – und der dringende Wunsch des Kunden, endlich sauber auf PHP 8.4 zu kommen.

Die erste Regel bei jeder WordPress PHP 8 Migration lautet: Niemals direkt auf Produktion. Das klingt trivial, wird aber trotzdem häufig missachtet – oft mit dem Argument, „ich hab ja ein Backup". Ein Backup rettet dich, wenn die Seite weiß wird. Es rettet dich nicht vor kumulativen Problemen, die du erst nach Stunden Klickarbeit bemerkst.

Staging-Lizenz beim X Theme sauber klären: Beim X Theme von Themeco ist das Staging-Setup lizenztechnisch sauber gelöst. Jede Single-Use-Lizenz erlaubt eine zusätzliche Staging-Domain ohne Mehrkosten – vorausgesetzt, es handelt sich um dieselbe Website, also zum Beispiel staging.domain.com für domain.com. Die Staging-Domain muss im Themeco-Account-Dashboard über den Button „Add Staging" validiert werden, sonst bekommt die Staging-Seite keinen Zugriff auf Updates und gebündelte Extensions.

Wichtig dabei: Subdomain-basierte Staging-Installationen gelten aus Sicht der Lizenz als eigene Installation und müssen explizit registriert werden. Betreibst du dein Staging stattdessen als Unterordner (domain.com/staging), greift der API-Key der Hauptdomain automatisch. Diese Unterscheidung wird gerne übersehen und führt dann auf dem Staging zu „License not validated"-Meldungen.

Staging-Klon aufsetzen: Das Staging selbst ist ein vollwertiger Klon der Live-Seite – Dateien per SFTP oder SSH gespiegelt, Datenbank per mysqldump übernommen, URLs per wp search-replace oder einem sauberen SQL-Query angepasst. Wichtig ist, dass die Staging-Umgebung auch technisch der Produktion ähnelt: gleicher PHP-Modus, gleiche Extensions, gleiche MySQL-Version. Sonst findest du Fehler, die live nicht auftreten, und übersiehst welche, die live ganz sicher passieren werden.

Nach dem Klonen auf die Staging-Umgebung kam direkt der erste Fehler – noch vor dem eigentlichen PHP-Update. Ein mysqli_sql_exception in Kombination mit einem Charset-Problem. Ursache: Der neue Server nutzte utf8mb4 als Standard, während die Datenbank aus der alten Umgebung an vielen Stellen noch utf8mb3 im Hintergrund hatte. Das merkst du nicht im Backend, aber überall dort, wo Sonderzeichen in alten Inhalten stehen.

Der Fix war an dieser Stelle noch überschaubar: In der wp-config.php wurde DB_CHARSET von utf8mb3 auf utf8mb4 umgestellt, und der Hosting-Support hat MySQL serverseitig auf utf8mb4_unicode_ci gezogen. Das war der Auftakt, aber nicht das Ende der Encoding-Geschichte. Dazu später mehr.

Mit sauberem Staging und funktionierender Datenbank konnte der PHP-Wechsel los. Und hier kommt die Wahrheit, die dir niemand gerne sagt: Je älter der Plugin- und Theme-Stack, desto mehr Fehler fallen dir gleichzeitig entgegen.

Fehler 1 – Child-Theme ruft veraltete API auf: Der erste Fehler kam aus dem Child-Theme des X Themes. Eine alte Anpassung nutzte den veralteten clean_url-Filter, der unter PHP 8.4 nicht mehr sauber durchläuft. Zusätzlich war das Skript-Laden so verbogen, dass die WordPress-Core-Reihenfolge zerschossen wurde.

Der Fix: Den veralteten clean_url-Filter durch den modernen script_loader_tag-Filter ersetzt – und dabei bewusst auf eine Whitelist statt einer Blacklist gesetzt. Nur explizit definierte Skript-Handles werden mit defer geladen, alles andere bleibt unangetastet. Das ist robuster als das alte „alles defern außer X"-Muster, weil neue Skripte aus Plugins automatisch korrekt geladen werden, ohne dass jemand die Blacklist pflegen muss.

Zusätzlich war eine custom.js im Child-Theme gar nicht enqueued – sie funktionierte vorher zufällig, weil sie aus einem Plugin-Kontext geladen wurde. Sauber eingebunden mit jQuery als Dependency und im Footer geladen, lief sie unter PHP 8.4 wieder normal.

Der nächste Fehler war heftiger. Das Plugin „The Grid" produzierte einen Fatal Error in the-grid-base.class.php, Zeile 603:

$whole = floor($n_format);

Seit PHP 8.0 erwartet floor() zwingend einen numerischen Wert. Das Plugin übergab an dieser Stelle einen String, der in früheren PHP-Versionen implizit konvertiert wurde. Unter PHP 8.4 ist damit Schluss.

Schnell-Fix direkt im Plugin-Code:

$whole = floor((float) $n_format);

Das Problem: Ein Plugin-Fix per Hand wird beim nächsten Update wieder überschrieben. Bei „The Grid" kam erschwerend hinzu, dass es schon länger keine aktiven Updates mehr erhalten hat. Langfristige Empfehlung an den Kunden: Plugin ersetzen oder das Patch-Szenario über ein Must-Use-Plugin absichern.

WPML meldete sich mit Fatal Errors, die zunächst rätselhaft wirkten. Die Ursache war kein typisches PHP-8-Problem, sondern eine alte WPML-Version mit -old-Suffix, die im Plugin-Verzeichnis liegen geblieben war und parallel zur aktuellen aktiv geladen wurde. Zwei Versionen desselben Plugins gleichzeitig aktiv: Garantiertes Chaos.

Lösung: Die alte Version entfernt, die aktuelle WPML-Version installiert, Lizenz auf die Staging-Domain registriert. Die aktuelle WPML-Version ist PHP-8-kompatibel und hat viele alte Probleme inzwischen behoben.

UberMenu zeigte ein eigenes Problem, das erst im Frontend sichtbar wurde: Hover-Events funktionierten nicht mehr. Die alte Implementierung nutzte direkte .on()-Bindings auf den Menü-Elementen. UberMenu rendert seine Strukturen aber dynamisch nach DOM-Ready, sodass die Bindings auf nicht-existente Elemente liefen. Fix: Auf Event-Delegation über $(document).on() umstellen. Damit fangen die Events korrekt, auch wenn das Ziel-Element erst später erzeugt wird.

Was alle diese Fälle zeigen: Eine PHP-Migration offenbart, welche Teile deines WordPress-Stacks aktiv gepflegt werden und welche nicht. Plugins und Themes mit regelmäßigen Updates laufen nach dem Update einfach weiter. Alles, was seit zwei oder drei Jahren nicht mehr angefasst wurde, wird zum Wartungsfall.

Eine häufig diskutierte Frage: Update ich das Theme vor oder nach dem PHP-Sprung? Im konkreten Fall lief das X Theme mehrere Major-Versionen hinter dem aktuellen Stand. Die Empfehlung lautete: zuerst PHP stabilisieren, dann Theme updaten.

Der Grund ist simpel: Das aktuelle X Theme unterstützt PHP 8.x explizit. Würdest du das Theme auf einer PHP-7.4-Installation updaten, könnte es selbst schon Features nutzen, die auf der alten PHP-Version nicht mehr sauber laufen. Umgekehrt läuft das alte Theme zwar nicht perfekt, aber stabil genug auf PHP 8.x, um das Update durchzuziehen und danach das Theme nachzuziehen.

Theme.co pflegt das X Theme aktiv weiter – aktuelle Versionen erscheinen regelmäßig über ThemeForest und den Themeco-eigenen Update-Kanal. Nach dem Theme-Update verschwanden mehrere Legacy-Warnings, die vorher noch nebenher mitliefen, weil das Theme intern alte PHP-Muster modernisiert hatte.

Ein Sonderfall war Yoast SEO: Nach dem PHP-Update fehlten plötzlich interne Datenbanktabellen, das Plugin produzierte Fehler beim Aufruf. Lösung war hier denkbar einfach – Yoast einmal deaktivieren und wieder aktivieren. Beim Aktivieren legt Yoast die nötigen Tabellen sauber neu an. Ein Klick, Problem gelöst.

Nach Theme- und Plugin-Updates lief die Seite – fast. Im Header fehlte das Such-Icon: Statt der Lupe erschien ein leerer Kasten. Ursache: Das Theme nutzte intern eine andere Font-Awesome-Klassen-Variante als die aktuell ausgelieferte Version.

Fix per CSS im Child-Theme:

.x-btn-navbar-search .x-icon-search:before { font-family: "Font Awesome 5 Free"; content: "\f002"; }

Drei Zeilen CSS, das Icon ist zurück. Genau die Art von Detail, die du nur findest, wenn du nach allen Updates noch einmal sauber durch die Seite klickst.

Nach PHP-Update, Theme-Update und Plugin-Patches lief die Seite – technisch. Optisch lief sie weniger rund. Im gesamten Backend und Frontend tauchten Einträge auf wie:

• Ãœber uns statt Über uns
• Bluetooth® Lautsprecher statt Bluetooth® Lautsprecher
• Fläche statt Fläche

Das ist das klassische Symptom einer doppelten oder falschen Encoding-Konvertierung. Irgendwo im Lebenszyklus der Datenbank wurden UTF-8-Zeichen als Latin-1 interpretiert und neu als UTF-8 gespeichert – das Ergebnis sind die sogenannten „Mojibake". Sie sehen harmlos aus, sind aber echte Daten, keine Darstellungsfehler. Der Browser macht alles richtig, die Datenbank enthält schlicht den falschen Inhalt.

Der erste, naheliegende Ansatz war eine SQL-Konvertierung über phpMyAdmin mit CONVERT(CAST(CONVERT(...))). Klingt sauber, ist aber riskant: Für serialisierte Daten in wp_options oder wp_postmeta ist das Gift. Die Byte-Längen in serialisierten PHP-Arrays stimmen nach der Konvertierung nicht mehr, und das Plugin oder Theme bekommt beim nächsten Aufruf nur noch Fragmente zurück. Im Projekt ist genau das einmal passiert – Rettung kam aus dem UpdraftPlus-Backup, das vorher angelegt war.

Die Lehre: wp_options und wp_postmeta dürfen niemals mit direkter String-Konvertierung angefasst werden. Für diese Tabellen braucht es entweder WP-CLI oder ein Skript, das mit maybe_unserialize() und maybe_serialize() korrekt arbeitet.

Der robuste Weg war am Ende eine Kombination:

• Für wp_posts, wp_terms und wp_comments: explizite REPLACE()-Ketten per SQL, Zeichen für Zeichen (ü → ü, ö → ö, Ãœ → Ü, ® → ® und so weiter)
• Für serialisierte Tabellen: ein eigenes PHP-Skript, das die WordPress-Funktionen für Deserialisierung nutzt

Beispiel für eine REPLACE()-Kette:

UPDATE wp_posts SET post_title = REPLACE(REPLACE(REPLACE(post_title, 'ü', 'ü'), 'ö', 'ö'), 'Ãœ', 'Ü');

WP-CLI wäre der schnellste Weg gewesen – auf dem betroffenen Hosting stand es nicht zur Verfügung. Deshalb landete die Logik in einem PHP-Skript, das einmalig im Webroot abgelegt, ausgeführt und danach wieder gelöscht wurde. Klassischer Wartungs-Workflow auf Shared-Hostings ohne Shell-Tools.

Wenn die sichtbaren Fehler gefixt sind, folgt der angenehme Teil: die unsichtbaren Verbesserungen. Nach der PHP-8.4-Migration zeigten sich folgende Effekte:

Die Serverantwortzeit fiel deutlich. Besonders spürbar bei Admin-Seiten mit vielen Plugins, die vorher sekundenlang zum Laden brauchten. PHP 8 ist durch JIT-Kompilierung und interne Optimierungen einfach schneller – das merkst du vor allem bei komplexen Abfragen.

Die Memory-Nutzung pro Request sank, weil neuere PHP-Versionen effizienter mit Opcodes umgehen. Das Hosting hatte plötzlich Luft, die vorher nicht da war.

Die Core Web Vitals verbesserten sich – nicht weil die Frontend-Assets geändert wurden, sondern weil das Backend schneller HTML lieferte. Das wirkt sich direkt auf LCP und INP aus.

Und nicht zuletzt: Sicherheitsupdates kommen wieder regelmäßig an. PHP 8.3 und 8.4 werden aktiv gepflegt, während 7.4 seit Jahren tot ist.

Wenn du vor einem ähnlichen Projekt stehst, arbeite dich an dieser Reihenfolge entlang:

1. Bestandsaufnahme. Welche PHP-Version läuft aktuell? Welche Plugins und Themes sind installiert? Wann wurde jedes davon zuletzt aktualisiert? Alles, was älter als zwei Jahre ist, markiere als Risikokandidat.

2. Staging einrichten. Saubere Kopie der Live-Seite auf einer Subdomain oder einem Unterordner, mit identischer Server-Konfiguration. Bei lizenzpflichtigen Themes wie dem X Theme die Staging-Domain über den Account-Dashboard registrieren.

3. Datenbank und Charset überprüfen. Stimmen DB_CHARSET und DB_COLLATE in der wp-config.php? Ist die Datenbank durchgängig auf utf8mb4? Encoding-Probleme rechtzeitig identifizieren spart später Stunden.

4. Backup einrichten. UpdraftPlus oder eine vergleichbare Lösung – vollständig, automatisiert, extern gespeichert. Vor jeder größeren Änderung manuelles Backup auslösen.

5. PHP-Version schrittweise hochziehen. Nicht von 7.4 direkt auf 8.4, sondern über 8.0, 8.1, 8.2 testen. So siehst du, in welchem Sprung welche Fehler auftauchen.

6. Plugins und Theme aktualisieren. Zuerst die kritischen (Theme, Sicherheits-Plugins), dann den Rest. Jedes Update einzeln testen, nicht alle auf einmal – sonst weißt du bei Problemen nicht, welches Update schuld ist.

7. Encoding-Cleanup. Nach allen Updates einmal durch die Datenbank gehen und typische Mojibake-Muster mit gezielten REPLACE()-Statements oder einem sauberen Skript entfernen. wp_options und wp_postmeta ausschließlich serialisierungssicher anfassen.

8. Frontend-Durchklick. Nach allen Updates jede wichtige Seite manuell prüfen – Header, Footer, Menüs, Formulare, Such-Icons. Kleinkram fällt oft nur beim aktiven Klicken auf.

9. Performance- und Error-Monitoring aktivieren. Nach der Live-Migration mindestens zwei Wochen die Logs im Auge behalten. Viele PHP-8-Probleme tauchen erst auf, wenn bestimmte Funktionen aufgerufen werden – zum Beispiel im Checkout oder im Benutzerprofil.