Joomla! 5 support. We have addressed the backwards incompatible changes introduced in the week leading to the release of Joomla! 5.0-Beta1. Please note that Joomla! 5 is still in beta and should not be used on production sites.
Improve HSTS support. Now the HSTS feature in the .htaccess Maker etc has an additional option which lets you add `includeSubDomains; preload`. These flags are not necessary as per the specification, but the third party registry of sites with HSTS preloading run by Google requires them.
PHP File Change Scanner: options to scan double extensions and case-insensitive extensions. This option is enabled by default. This allows the scanner to scan files with multiple extensions where the executable extensions (e.g. .php) is in the middle of the name, for example example.php.png. These files are NOT executable on properly configured hosts. If your host has misconfigured their server in a way they have been warned not to for the past 20 years, allowing these files to be executable as PHP scripts, we recommend going to a decent host as fast as possible on the grounds that if the host cannot be bothered following a 20-year-old fundamental security advisory how can you possibly trust them to have thought of and addressed more tricky security issues.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
We have changed the PHP namespaces of our extensions to match the (as yet undocumented) intention of Joomla!'s core maintainers about third party extensions' PHP namespaces.
The namespaces in all of our extensions now start with our company name, i.e.
Akeeba\. In the past this was indeed the case for our components, but our plugins and modules had the generic prefix
Joomla\ due to an unfortunate misunderstanding of how the new at the time (and still officially undocumented) Joomla 4 MVC was meant to work back in late 2020, when we started migrating our extensions.
This one-time change has some implications on whether Joomla! will be able to find and load the code with the updated namespace. If it cannot, it will display (usually briefly) an error message stating “class not found”, “missing class”, or something similar to that. This is the result of how Joomla! works, and your server's configuration. Here are the two key points which can cause problems:
autoload_psr4.phpfile in its cache directory, generally a welcome performance-enhancing behaviour. Whenever you install an extension update, or a core Joomla! update, Joomla! tries to delete and create this file afresh.
.phpfiles have changed during the caching period set up in PHP's configuration. To work around that limitation, Joomla! asks PHP to clear the OPcache for each
.phpfile it writes to disk during the course of an extension or core Joomla! update.
While Joomla! generally works well, we observed a few issues which do get in the way:
autoload_psr4.phpis unwriteable Joomla fails to renew this file silently. As a result, it misleads the user into believing that an extension is misbehaving when, in fact, it's a Joomla! failure to check if this file is writeable (therefore can be updated, therefore can be trusted) before using it.
autoload_psr4.phpmay not be created afresh if an update fails, but has already written files on disk. This creates a discrepancy between the code available on your server and what Joomla! has cached about this code in that file, breaking your site.
provider.phpfile of every extension using the modern Joomla! 4 MVC. The undocumented workaround for this behaviour is to use PHP's
clearstatcache()to tell it to check the disk again before calling the code to reset the OPcache for a file.
Our extensions include post-installation code designed to mitigate these issues to the extent humanly possible:
autoload_psr4.phpfile and ask Joomla! to create it afresh. Then, we reset its PHP filesystem stats cache and the PHP OPcache on that file, just like what Joomla! does during a core Joomla! update.
.phpfiles in our extensions and resets PHP's OPcache for them, exactly like what Joomla! does during a core Joomla! update. This is more comprehensive that Joomla's code currently used in its
Despite our best efforts, we understand that some far less common server configurations may make it impossible for the mitigations to work. Namely, we have identified the following cases, mitigations, and expected impact:
autoload_psr4.phpfile and / or its containing folder is not writeable to PHP itself the file will be impossible to delete. As a result, Joomla! will keep using the old, out-of-date file, breaking your site. Note that most affected sites would already have issues installing or updating Joomla! and third party extensions. Mitigation: You will need to delete that file (
administrator/cache/autoload_psr4.php) yourself. Expected impact: rare; less than 0.1% of sites.
.phpfiles. Mitigation: You will have to either wait until the OPcache expires (usually between a few seconds to a few hours), or ask your host for help on resetting the OPcache. Expected impact: very rare; less than 0.01% of sites.
Despite us taking all reasonable precautions to refrain from inadvertently breaking your sites, some rather rare server configurations might get in the way of a stark minority of our clients. If your site stops responding, at all or intermittently, with an error indicating “class not found” please do the following:
administrator/cache/autoload_psr4.phpfile, and reload the page.
We would like to state that the likelihood of these issues occurring is vanishingly small. The vast majority of our clients will NOT experience any of that. We include this statement with our software because we believe in transparency, and are proponents of the “forewarned is forearmed” mantra.