7 deprecation issues, explained
Joomla! 3 and PHP 8: The Errors You Will Actually See
Joomla! 3's core code was written for PHP 5 and 7. PHP 8 tightened a number of interface and type rules that Joomla! 3 never anticipated, so hosts that force an upgrade to PHP 8.1 or later start throwing deprecation warnings from code that otherwise runs fine. None of these are security vulnerabilities. They are compatibility problems, and on some hosts they are noisy enough to fill error logs or even break admin screens depending on how strict the server's error reporting is configured.
Why this happens on a working site
PHP 8 deprecates several patterns that used to be normal: implementing certain SPL interfaces with a loosely typed method signature, declaring a parameter as nullable by giving it a default value of null without an explicit nullable type, and a few others. Joomla! 3's core, including files that get loaded on literally every request, uses these patterns throughout. The result is that upgrading PHP alone, without touching Joomla! itself, is often what triggers the flood of warnings.
The 7 specific issues
1 and 2. Input.php: Serializable and Countable interface compliance
PHP 8.1 deprecated the old style Serializable interface in favor of magic methods. Joomla! 3's Input class, loaded on every single request, still implements the old interface signature, which throws a deprecation notice on PHP 8.1 and later.
3. Application bootstrap files: implicit nullable parameters
PHP 8.4 deprecated implicitly nullable parameters, where a parameter is typed but given a default of null without an explicit ?Type declaration. Seven files in Joomla! 3's application bootstrap use this pattern, and because these files load on every front end and admin request, this is the highest reachability issue on the list.
4. Feed.php: SPL interface return type
Used by mod_feed and com_newsfeeds. Same class of SPL interface return type deprecation as the items below.
5. JDatabaseIterator and FOFDatabaseIterator: SPL interface return type
Optional APIs that some third party extensions call directly. If nothing in your stack calls them, this one is largely invisible, but it still shows up in a strict pre update check.
6. Joomla\Data\DataSet: SPL interface return type
Affects any extension that references this class directly.
What fixing these does and does not do
Fixing these 7 issues stops the Joomla! 3 core itself from throwing deprecation warnings under PHP 8.1 and later. It does not guarantee that every admin screen runs cleanly on PHP 8.1+, because your specific templates and third party extensions might use the same deprecated patterns independently, and those are outside what a core level fix can touch. It also is not a security fix: these are compatibility issues, not vulnerabilities. For the actual security side, see the full CVE list.
Our Joomla! 3 Security Patch includes all 7 of these fixes as a separate, optional toggle from the security fixes, so you can turn on PHP 8 compatibility exactly when your hosting forces the move, not before.