Joomla! 3 et PHP 8 : les erreurs que vous verrez réellement

Le code du noyau de Joomla! 3 a été écrit pour PHP 5 et 7. PHP 8 a durci plusieurs règles d'interfaces et de typage que Joomla! 3 n'avait jamais anticipées. Les hébergements qui imposent une mise à niveau vers PHP 8.1 ou plus récent commencent donc à générer des avertissements de dépréciation depuis du code qui fonctionne par ailleurs normalement. Aucun de ces cas n'est une vulnérabilité de sécurité. Ce sont des problèmes de compatibilité qui, selon la rigueur de la configuration de rapport d'erreurs du serveur, peuvent remplir les journaux, voire perturber certains écrans d'administration.

Pourquoi cela arrive sur un site qui fonctionne

PHP 8 marque comme dépréciés plusieurs schémas auparavant normaux : implémenter certaines interfaces SPL avec une signature de méthode faiblement typée, déclarer un paramètre comme implicitement nullable en lui donnant une valeur par défaut de null sans typage nullable explicite, et quelques autres. Le noyau de Joomla! 3, y compris des fichiers chargés à littéralement chaque requête, utilise ces schémas partout. Résultat : une simple mise à niveau de PHP, sans toucher à Joomla! lui-même, suffit souvent à déclencher le flot d'avertissements.

Les 7 problèmes concrets

1 et 2. Input.php : conformité aux interfaces Serializable et Countable

PHP 8.1 a marqué l'ancienne interface Serializable comme dépréciée au profit des méthodes magiques. La classe Input de Joomla! 3, chargée à chaque requête, implémente encore l'ancienne signature d'interface, ce qui déclenche un avis de dépréciation dès PHP 8.1.

3. Fichiers bootstrap de l'application : paramètres implicitement nullable

PHP 8.4 a marqué comme dépréciés les paramètres implicitement nullable, où un paramètre est typé mais doté d'une valeur par défaut de null sans déclaration explicite ?Type. Sept fichiers du bootstrap de l'application Joomla! 3 utilisent ce schéma, et comme ces fichiers se chargent à chaque requête front-end et admin, c'est le correctif à la plus haute portée de cette liste.

4. Feed.php : type de retour d'interface SPL

Utilisé par mod_feed et com_newsfeeds. Même catégorie de dépréciation de type de retour d'interface SPL que les points suivants.

5. JDatabaseIterator et FOFDatabaseIterator : type de retour d'interface SPL

API optionnelles appelées directement par certaines extensions tierces. Si rien dans votre installation ne les appelle, ce point reste largement invisible, mais il apparaît tout de même lors d'un contrôle préalable strict.

6. Joomla\Data\DataSet : type de retour d'interface SPL

Concerne toute extension qui référence directement cette classe.

Ce que corriger ces problèmes fait, et ne fait pas

Corriger ces 7 problèmes empêche le noyau Joomla! 3 lui-même de générer des avertissements de dépréciation sous PHP 8.1 et plus récent. Cela ne garantit pas que chaque écran d'administration fonctionne proprement sous PHP 8.1+, car vos templates et extensions tierces spécifiques peuvent utiliser indépendamment les mêmes schémas dépréciés, ce qui échappe à ce qu'un correctif au niveau du noyau peut atteindre. Ce n'est pas non plus un correctif de sécurité : ce sont des problèmes de compatibilité, pas des vulnérabilités. Pour le volet sécurité proprement dit, consultez la liste complète des CVE.

Notre correctif de sécurité Joomla! 3 inclut ces 7 correctifs sous forme d'un interrupteur séparé et optionnel, distinct des correctifs de sécurité, afin que vous puissiez activer la compatibilité PHP 8 exactement quand votre hébergement impose le passage, pas avant.