You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Akeeba Backup Pro for J!4 9.9.10
No permission to download
- Author Dano627775
- Creation date
- Automatically downgrade utf8mb4_900_* collations to utf8mb4_unicode_520_ci on MariaDB
- Updated environment stats collection code
- [LOW] Cannot delete backup archive from CLI
- [LOW] PHP 8.3 deprecated notice in ComponentParameters service (no functional issue)
- [MEDIUM] PHP error trying to use WebPush for the first time
Released on: 2023-10-15 22:53 CDT
Improved Joomla! 5 support. We now support Joomla 5's custom public folder feature, and we have improved the display in Joomla 5's all-new built-in administrator Dark Mode!
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
- Restoration: Support Joomla 5 custom public folder
- Restoration: Use transactions to speed up large table restoration
- Support for Joomla 5 custom public folder
- [HIGH] The (deprecated) JSON API command to export the configuration fails when the configuration is encrypted
- [HIGH] The Quick Icon plugin does not show anything in the Joomla! control panel
- [HIGH] The akeeba:backup:delete CLI command threw an error due to a typo
- Joomla 5 Dark Mode workarounds
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.
Workaround for Wasabi S3v4 signatures. Wasabi is a low-cost storage service with an Amazon S3–compatible API. However, they have misinterpreted a part of the Amazon signature version 4 specification which made it impossible to use it with Akeeba Backup (unless you downgraded to the older, v2 signature method). We have added a workaround for that, so you can now use Wasabi with v4 signatures with Akeeba Backup. Our documentation has been updated with instructions since this is a very popular alternative to S3.
Support for uploading to Shared With Me folders in Google Drive. Unlike shared drives and regular folder, folders your clients have shared with you (and appear in Google Drive under Shared With Me) are not treated as any other folder / drive, and cannot be listed using the documented Google Drive API. We started making wild guesses, found out what looks like to be an undocumented way to list them, and we now allow you to use them as if they were any regular folder. That was… a weird experience, frankly.
Improved error reporting. We removed the unhelpful "(HTML containing script tags)" message, instead replacing by the text representation of the message received by the server.
Improved mixed– and upper–case database prefix support at backup time. Akeeba Backup can now detect if you have a database table name prefix with uppercase characters (e.g. something like FOO_ or fOO_) and whether this would cause a problem backing up your site's tables, applying automatic mitigations whenever possible. This will solve most problems when backing up this kind of tables on Windows and macOS hosts. While a rare issue, when it happened it was very difficult to work around at restoration time. Based on our tests on both test and production sites, across our own sites and client sites, this workaround seems to address the majority of practical problems our users faced in those rare cases.
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:
While Joomla! generally works well, we observed a few issues which do get in the way:
- Joomla! caches the namespaces of core and third party extensions in the autoload_psr4.php file 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.
- Servers with PHP OPcache enabled will not “see” that .php files 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 .php file it writes to disk during the course of an extension or core Joomla! update.
Our extensions include post-installation code designed to mitigate these issues to the extent humanly possible:
- If the autoload_psr4.php is 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.
- The autoload_psr4.php may 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.
- The code which resets the OPcache is incomplete due to an esoteric quirk of PHP. PHP will only reset the OPcache for a file if it can detect that the file has changed. However, PHP caches the filesystem information of files it has already loaded which, in Joomla's case, includes the all-important provider.php file 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.
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:
- We delete the autoload_psr4.php file 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.
- We have included code which goes through all the .php files 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 Joomla\Filesystem\File::write() method.
- If the autoload_psr4.php file 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.
- Some servers may have disabled the PHP features necessary to reset the OPcache on specific .php files. 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.
- Some web hosts may be using a server cluster, i.e. multiple servers which handle requests in a round-robin, or availability basis. As a result, the OPcache will not be reset across all servers in the cluster, causing intermittent errors on your site. Affected sites will already have problems installing or updating Joomla! and third party extensions. It is furthermore extremely unlikely that someone is hosted on a server cluster without being acutely aware of the fact, and what is necessary. Mitigation: ask your host to reset OPcache across all servers in the cluster. Expected impact: infinitesimal; less than 0.001% of sites.
TL;DR: What to do if something breaks
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:
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.
- Wait a minute, then reload the page. More often than not, that's all that's needed.
- Delete the administrator/cache/autoload_psr4.php file, and reload the page.
- Ask your host to reset the OPcache, or similar code cache, on your site's server(s).
- [LOW] Possible PHP error when updating this along other extensions using the same post-installation script
- [LOW] Backup On Update: Inversion of logic of the switches in its options page
- [LOW] Backup On Update: Would always use profile 1
- [LOW] CLI backups no longer record an end date and time due to a change in Joomla's behavior
- Block uninstallation of child extensions
- New JSON API endpoint, using the Joomla API Application
- Support for files and archives over 2GiB (JPA file format 1.3)
- [MEDIUM] JSON API: deleteFiles method throws an exception due to a typo
- Disabled deprecated API methods
- Improve the Schedule Automatic Backups page