Joomla! 3 e PHP 8: gli errori che vedrai davvero

Il codice core di Joomla! 3 è stato scritto per PHP 5 e 7. PHP 8 ha inasprito diverse regole su interfacce e tipizzazione che Joomla! 3 non aveva mai previsto, quindi gli hosting che impongono un aggiornamento a PHP 8.1 o successivo iniziano a generare avvisi di deprecazione da codice che altrimenti funziona bene. Nessuno di questi casi è una vulnerabilità di sicurezza. Sono problemi di compatibilità che, a seconda di quanto sia rigorosa la configurazione di reporting degli errori del server, possono riempire i log o persino disturbare alcune schermate di amministrazione.

Perché succede su un sito funzionante

PHP 8 segna come deprecati diversi schemi un tempo normali: implementare certe interfacce SPL con una firma di metodo tipizzata in modo debole, dichiarare un parametro come implicitamente nullable dandogli un valore predefinito null senza una tipizzazione nullable esplicita, e alcuni altri. Il core di Joomla! 3, inclusi file caricati letteralmente a ogni richiesta, utilizza questi schemi ovunque. Il risultato è che un semplice aggiornamento di PHP, senza toccare Joomla! stesso, è spesso ciò che scatena l'ondata di avvisi.

I 7 problemi specifici

1 e 2. Input.php: conformità alle interfacce Serializable e Countable

PHP 8.1 ha segnato come deprecata la vecchia interfaccia Serializable a favore dei metodi magici. La classe Input di Joomla! 3, caricata a ogni singola richiesta, implementa ancora la vecchia firma dell'interfaccia, il che genera un avviso di deprecazione da PHP 8.1 in poi.

3. File di bootstrap dell'applicazione: parametri implicitamente nullable

PHP 8.4 ha segnato come deprecati i parametri implicitamente nullable, dove un parametro è tipizzato ma dotato di un valore predefinito null senza una dichiarazione esplicita ?Tipo. Sette file nel bootstrap dell'applicazione di Joomla! 3 usano questo schema, e poiché questi file si caricano a ogni richiesta frontend e admin, questo è il correttivo con la portata più ampia in questo elenco.

4. Feed.php: tipo di ritorno di interfaccia SPL

Usato da mod_feed e com_newsfeeds. Stessa categoria di deprecazione del tipo di ritorno di interfaccia SPL dei punti seguenti.

5. JDatabaseIterator e FOFDatabaseIterator: tipo di ritorno di interfaccia SPL

API opzionali chiamate direttamente da alcune estensioni di terze parti. Se nulla nel tuo stack le chiama, questo punto resta in gran parte invisibile, ma compare comunque in un controllo preliminare rigoroso.

6. Joomla\Data\DataSet: tipo di ritorno di interfaccia SPL

Riguarda qualsiasi estensione che referenzi direttamente questa classe.

Cosa fa e cosa non fa la correzione di questi problemi

Correggere questi 7 problemi impedisce al core di Joomla! 3 di generare avvisi di deprecazione su PHP 8.1 e versioni successive. Non garantisce che ogni schermata di amministrazione funzioni correttamente su PHP 8.1+, perché i tuoi template ed estensioni di terze parti specifici potrebbero usare in modo indipendente gli stessi schemi deprecati, e questo va oltre ciò che una correzione a livello di core può raggiungere. Non è nemmeno una correzione di sicurezza: sono problemi di compatibilità, non vulnerabilità. Per il lato sicurezza vero e proprio, consulta l'elenco completo delle CVE.

La nostra patch di sicurezza per Joomla! 3 include tutte queste 7 correzioni come interruttore separato e opzionale rispetto alle correzioni di sicurezza, così puoi attivare la compatibilità PHP 8 esattamente quando il tuo hosting impone il passaggio, non prima.