Joomla! 3 und PHP 8: Diese Fehler tauchen tatsächlich auf

Der Core-Code von Joomla! 3 wurde für PHP 5 und 7 geschrieben. PHP 8 hat eine Reihe von Interface- und Typregeln verschärft, die Joomla! 3 nie vorhergesehen hat. Deshalb werfen Hostings, die ein Upgrade auf PHP 8.1 oder neuer erzwingen, Deprecation-Warnungen aus Code, der ansonsten einwandfrei läuft. Keiner dieser Fälle ist eine Sicherheitslücke. Es sind Kompatibilitätsprobleme, die je nach Strenge der Fehlerausgabe-Konfiguration des Servers Logs füllen oder sogar Adminbildschirme stören können.

Warum das auf einer funktionierenden Website passiert

PHP 8 markiert mehrere früher normale Muster als veraltet: die Implementierung bestimmter SPL-Interfaces mit einer lose typisierten Methodensignatur, die Deklaration eines Parameters als implizit nullable durch einen Standardwert von null ohne explizite Nullable-Typisierung, und einige weitere. Der Core von Joomla! 3, einschliesslich Dateien, die bei buchstäblich jedem Request geladen werden, verwendet diese Muster durchgehend. Das Ergebnis: Ein reines PHP-Upgrade, ohne Joomla! selbst anzufassen, löst oft die Flut an Warnungen aus.

Die 7 konkreten Probleme

1 und 2. Input.php: Serializable- und Countable-Interface-Konformität

PHP 8.1 hat das alte Serializable-Interface zugunsten von Magic Methods als veraltet markiert. Die Input-Klasse von Joomla! 3, die bei jedem einzelnen Request geladen wird, implementiert noch die alte Interface-Signatur, was ab PHP 8.1 eine Deprecation-Meldung auslöst.

3. Application-Bootstrap-Dateien: implizit nullable Parameter

PHP 8.4 hat implizit nullable Parameter als veraltet markiert, bei denen ein Parameter typisiert, aber mit einem Standardwert von null ohne explizite ?Typ-Deklaration versehen ist. Sieben Dateien im Application-Bootstrap von Joomla! 3 verwenden dieses Muster, und weil diese Dateien bei jedem Frontend- und Admin-Request geladen werden, ist das der Fix mit der höchsten Erreichbarkeit auf dieser Liste.

4. Feed.php: SPL-Interface-Rückgabetyp

Genutzt von mod_feed und com_newsfeeds. Die gleiche Klasse von SPL-Interface-Rückgabetyp-Deprecation wie die folgenden Punkte.

5. JDatabaseIterator und FOFDatabaseIterator: SPL-Interface-Rückgabetyp

Optionale APIs, die manche Drittanbieter-Erweiterungen direkt aufrufen. Wenn nichts in deinem Stack sie aufruft, bleibt das weitgehend unsichtbar, taucht aber trotzdem bei einem strengen Pre-Update-Check auf.

6. Joomla\Data\DataSet: SPL-Interface-Rückgabetyp

Betrifft jede Erweiterung, die diese Klasse direkt referenziert.

Was das Beheben dieser Probleme bewirkt und was nicht

Das Beheben dieser 7 Probleme verhindert, dass der Joomla! 3 Core selbst unter PHP 8.1 und neuer Deprecation-Warnungen wirft. Es garantiert nicht, dass jeder Adminbildschirm sauber auf PHP 8.1+ läuft, weil deine spezifischen Templates und Drittanbieter-Erweiterungen unabhängig davon dieselben veralteten Muster verwenden könnten, und die liegen ausserhalb dessen, was ein Fix auf Core-Ebene erreichen kann. Es ist auch kein Sicherheitsfix: Das sind Kompatibilitätsprobleme, keine Sicherheitslücken. Für die tatsächliche Sicherheitsseite siehe die vollständige CVE-Liste.

Unser Joomla! 3 Security Patch enthält alle 7 dieser Fixes als separaten, optionalen Schalter getrennt von den Sicherheitsfixes, sodass du die PHP-8-Kompatibilität genau dann aktivieren kannst, wenn dein Hosting den Umstieg erzwingt, nicht früher.