Joomla! 3 y PHP 8: los errores que realmente verás

El código del núcleo de Joomla! 3 se escribió para PHP 5 y 7. PHP 8 endureció varias reglas de interfaces y tipado que Joomla! 3 nunca previó, así que los hostings que fuerzan una actualización a PHP 8.1 o posterior empiezan a lanzar avisos de obsolescencia desde código que por lo demás funciona bien. Ninguno de estos casos es una vulnerabilidad de seguridad. Son problemas de compatibilidad que, según lo estricta que sea la configuración de errores del servidor, pueden llenar los registros o incluso afectar a algunas pantallas de administración.

Por qué ocurre en un sitio que funciona

PHP 8 marca como obsoletos varios patrones que antes eran normales: implementar ciertas interfaces SPL con una firma de método débilmente tipada, declarar un parámetro como implícitamente nulable dándole un valor predeterminado de null sin una tipificación nulable explícita, y algunos más. El núcleo de Joomla! 3, incluidos archivos que se cargan literalmente en cada solicitud, usa estos patrones por todas partes. El resultado es que una simple actualización de PHP, sin tocar Joomla! en sí, suele ser lo que desencadena la avalancha de avisos.

Los 7 problemas concretos

1 y 2. Input.php: conformidad con las interfaces Serializable y Countable

PHP 8.1 marcó como obsoleta la antigua interfaz Serializable en favor de métodos mágicos. La clase Input de Joomla! 3, cargada en cada solicitud, sigue implementando la firma antigua de la interfaz, lo que genera un aviso de obsolescencia desde PHP 8.1 en adelante.

3. Archivos de arranque de la aplicación: parámetros implícitamente nulables

PHP 8.4 marcó como obsoletos los parámetros implícitamente nulables, donde un parámetro está tipado pero tiene un valor predeterminado de null sin una declaración explícita ?Tipo. Siete archivos del arranque de la aplicación de Joomla! 3 usan este patrón, y como estos archivos se cargan en cada solicitud de frontend y de administración, es la corrección con mayor alcance de esta lista.

4. Feed.php: tipo de retorno de interfaz SPL

Usado por mod_feed y com_newsfeeds. La misma categoría de obsolescencia de tipo de retorno de interfaz SPL que los puntos siguientes.

5. JDatabaseIterator y FOFDatabaseIterator: tipo de retorno de interfaz SPL

APIs opcionales que algunas extensiones de terceros llaman directamente. Si nada en tu instalación las llama, este punto permanece en gran medida invisible, pero aún así aparece en una comprobación previa estricta.

6. Joomla\Data\DataSet: tipo de retorno de interfaz SPL

Afecta a cualquier extensión que referencie directamente esta clase.

Qué hace y qué no hace corregir estos problemas

Corregir estos 7 problemas evita que el propio núcleo de Joomla! 3 genere avisos de obsolescencia en PHP 8.1 y versiones posteriores. No garantiza que cada pantalla de administración funcione limpiamente en PHP 8.1+, porque tus plantillas y extensiones de terceros específicas podrían usar de forma independiente los mismos patrones obsoletos, y eso queda fuera de lo que una corrección a nivel de núcleo puede alcanzar. Tampoco es una corrección de seguridad: son problemas de compatibilidad, no vulnerabilidades. Para el lado de seguridad propiamente dicho, consulta la lista completa de CVE.

Nuestro parche de seguridad para Joomla! 3 incluye estas 7 correcciones como un interruptor separado y opcional, distinto de las correcciones de seguridad, para que puedas activar la compatibilidad con PHP 8 exactamente cuando tu hosting fuerce el cambio, no antes.