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

Ein PHP-Update klingt in der Theorie einfach: Im Hosting-Panel die Version umschalten, kurz testen, fertig. In der Praxis sieht das oft ganz anders aus – besonders bei Websites, die jahrelang auf PHP 7.4 liefen und dann auf einen Schlag auf PHP 8.4 migriert werden müssen. Was als reine Wartungsaufgabe startet, entpuppt sich schnell als Tour durch veralteten Theme-Code, inkompatible Plugins und kaputte Umlaute in der Datenbank.

In diesem Beitrag zeige ich anhand eines kürzlich abgeschlossenen Projekts, welche Probleme bei einer WordPress PHP 8 Migration realistisch auftreten, wie ein sauberes Staging-Setup den Unterschied macht und warum das X Theme von Themeco zwar kein Schuldiger, aber oft der Auslöser der Fehlersuche ist.

Warum die WordPress PHP 8 Migration 2026 kein Aufschub-Thema mehr ist

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.

Der richtige Start: Staging statt Live-Server-Roulette

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.

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.

Die erste Überraschung: MySQLi-Charset-Fehler

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.

Der Fix: 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.

Der eigentliche PHP-Sprung: Von 7.4 auf 8.4

Fehler 1 – Child-Theme ruft veraltete API auf: 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.

Plugin „The Grid“ – wenn floor() zum Fatal Error wird

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. Fix:

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

WPML und UberMenu – wenn alte Versionen kollidieren

WPML meldete sich mit Fatal Errors. Die Ursache war 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.

UberMenu zeigte ein eigenes Problem: Hover-Events funktionierten nicht mehr. Fix: Auf Event-Delegation über $(document).on() umstellen.

Font Awesome und kleine Frontend-Reste

Nach Theme- und Plugin-Updates fehlte das Such-Icon. Fix per CSS im Child-Theme:

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

Der Endgegner: Kaputte Umlaute durch Charset-Chaos

Nach allen Updates 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 Encoding-Konvertierung (Mojibake).

Encoding-Cleanup – was funktioniert und was nicht

Der robuste Weg war eine Kombination:

• Für wp_posts, wp_terms und wp_comments: explizite REPLACE()-Ketten per SQL
• Für serialisierte Tabellen: ein eigenes PHP-Skript mit maybe_unserialize() / maybe_serialize()

Beispiel für eine REPLACE()-Kette:

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

Wichtig: wp_options und wp_postmeta dürfen niemals mit direkter String-Konvertierung angefasst werden.

Die unsichtbaren Gewinne nach der Migration

• Serverantwortzeit fiel deutlich
• Memory-Nutzung pro Request sank
• Core Web Vitals verbesserten sich
• Sicherheitsupdates kommen wieder regelmäßig an

Checkliste für deine eigene WordPress PHP 8 Migration

1. Bestandsaufnahme – Welche PHP-Version läuft? Welche Plugins und Themes sind installiert?
2. Staging einrichten – Saubere Kopie der Live-Seite mit identischer Server-Konfiguration
3. Datenbank und Charset überprüfen – utf8mb4 durchgängig sicherstellen
4. Backup einrichten – Vollständig, automatisiert, extern gespeichert
5. PHP-Version schrittweise hochziehen – Nicht von 7.4 direkt auf 8.4, sondern über 8.0, 8.1, 8.2 testen
6. Plugins und Theme aktualisieren – Zuerst kritische, dann den Rest; jedes Update einzeln testen
7. Encoding-Cleanup – Typische Mojibake-Muster mit REPLACE()-Statements bereinigen
8. Frontend-Durchklick – Jede wichtige Seite manuell prüfen
9. Performance- und Error-Monitoring aktivieren – Mindestens zwei Wochen die Logs im Auge behalten

Fazit

Eine WordPress PHP 8 Migration ist nur auf dem Papier ein technischer Versionswechsel. In der Praxis ist sie ein ehrlicher Blick auf den Zustand deiner WordPress-Installation. Mit der richtigen Reihenfolge – Staging vor Live, Datenbank vor PHP, PHP vor Theme, alles vor Encoding – kann auch eine jahrelang vernachlässigte WordPress-Seite sauber auf PHP 8.4 kommen.