Wer heute noch WordPress-Plugins oder Themes nach alten Standards schreibt, wird auf modernen Servern im Jahr 2026 ein böses Erwachen erleben. Mit den jüngsten Releases von PHP 8.4 und den aktuellen Alpha-Builds von PHP 8.5 wurden etliche veraltete Funktionen endgültig entfernt und die Typensicherheit im Core drastisch verschärft. Was früher als harmlose «Notice» durchging, führt heute zu einem knallharten Fatal Error.
In diesem Artikel zeigen wir die kritischsten Bruchstellen bei der Migration auf die neuesten PHP-Versionen und wie du deinen Code zukunftssicher machst.
1. Die implizite Typkonvertierung wird bestraft
PHP war jahrelang dafür bekannt, bei Datentypen beide Augen zuzudrücken. Doch diese Zeiten sind vorbei. Besonders das automatische Umwandeln von unpassenden Typen in mathematischen Operationen oder String-Funktionen wirft nun Fehler.
Ein klassisches Beispiel, das man in hunderten älteren WordPress-Plugins findet:
PHP
// Alt & Fehlerhaft unter PHP 8.4+:
function berechne_rabatt($preis, $rabatt) {
// Wenn $rabatt aus einer unvalidierten Option als String "10%" oder null kommt:
return $preis - $rabatt;
}
Wenn $rabatt hier kein reiner numerischer Wert ist, bricht das Skript ab. Die Lösung ist eine strikte Typisierung (Strict Types) und sauberes Type-Casting:
PHP
// Zukunftssicher und sauber:
declare(strict_types=1);
function berechne_rabatt(float $preis, float $rabatt): float {
return $preis - $rabatt;
}
2. Deprecations im WordPress-Core vs. PHP-Realität
WordPress selbst hat in den letzten Versionen massiv an der PHP-Kompatibilität gearbeitet, doch viele Hooks und Filter übergeben historisch bedingt immer noch gemischte Datentypen (mixed). Wenn dein Plugin diese Daten ohne Prüfung verarbeitet, riskierst du weisse Seiten (White Screen of Death) beim Kunden.
Besonders kritisch sind:
- Veraltete Methodenaufrufe: Das dynamische Erstellen von Klasseneigenschaften (Dynamic Properties), die nicht explizit in der Klasse deklariert wurden, ist nun final gesperrt, sofern die Klasse nicht mit
#[AllowDynamicProperties]dekoriert ist. - Strengere Anforderungen bei OpenSSL: Wenn deine Plugins Daten verschlüsseln oder sichere API-Verbindungen aufbauen, verlangen die neuen PHP-Core-Bibliotheken zwingend modernere Chiffren und fehlerfreie Zertifikatsketten.
3. Praxis-Leitfaden: Code-Audit automatisieren
Niemand hat die Zeit, tausende Zeilen Code händisch zu durchforsten. Um deine PlugIns und Themes fit für die aktuellen Server-Umgebungen zu machen, solltest du den PHP Compatibility Standard für den PHP_CodeSniffer in deine Entwicklungsumgebung integrieren.
Mit folgendem Befehl in deiner CI/CD-Pipeline oder dem lokalen Terminal jagst du dein Plugin durch den Check:
Bash
phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4-8.5
Das Tool listet dir sofort jede Zeile auf, die unter den aktuellen PHP-Versionen zu Fehlern führt.
Fazit: Wer rastet, dessen Code rostet
Die Performance-Gewinne von PHP 8.4 und 8.5 sind gigantisch, doch sie erkaufen sich diese Geschwindigkeit durch kompromisslose Code-Qualität. Für Webentwickler bedeutet das: Wer seine Erweiterungen nicht kontinuierlich pflegt und testet, verliert Kunden an modernisierte Alternativen. Die Umstellung mag im ersten Moment mühsam sein, sorgt aber langfristig für stabilere, sicherere und schnellere Webseiten.
Hast du deine Plugins schon auf PHP 8.4 getestet? Welche Funktion hat bei dir den ersten Fatal Error ausgelöst? Schreib es in die Kommentare!
php 8.4, php 8.5, wordpress entwicklung, plugin programmierung, codequalitaet, webentwicklung, softwarearchitektur, refactoring, devops, phpcs
