Requires Joomla 4.2 or later, PHP 7.4.0 or later. To best prepare for the upcoming versions of Joomla and PHP we had to make some changes to our software. These changes mean that we can no longer support Joomla 4.1 or earlier, or PHP 7.3 or earlier. These versions of Joomla and PHP are already End of Life (EOL) and are used by less than 2% of our clients.
No more messages about your PHP version. We will no longer show you messages about your PHP version having entered security maintenance mode (no bug fixes planned, one year or less before becoming End of Life) or about running End of Life versions of PHP. Joomla already does that in its main Control Panel page.
Changed all warnings to much more compact
elements. Most of the warnings printed by Akeeba Backup tend to be long and very descriptive. This can get in your way when you want to take an emergency backup without having to necessarily address all security best practices before doing so. Now we only display the header of the message. Clicking on it will show you the details on how to address it. Kindly note that the only reason to hide a warning or error message is to follow its instructions to rectify the very high priority security or functional issue it reports.
Access levels in backup profiles. In the past, all backup profiles were accessible to any user group which was allowed the Backup privilege. This may not be desirable. For example, you may have a quick backup you want your clients to be able to use on their site and a more complex, much heavier in resource usage full backup which only runs in the middle of the night. Up until now you couldn't give access to one backup profile but not the other. Now, you will be able to do that — assuming that your clients do not have a Super User account on the site (Super Users have unlimited access to everything, always).
Option about including the latest backup in remote quotas. In the past the backup in progress was always included in the quota management for both locally (web server) and remotely stored backup archive files. This could lead to a situation where you are left with no valid backups in remote storage if you have set up count or size quotas which result in just one backup being stored remotely, the latest backup is a multipart backup (it consists of multiple archive part files), and at least one of the parts failed to upload to the remote storage. In this situation only the partially uploaded archive would be in remote storage. If you didn't catch this problem, and you lost access to all files stored in your web server you would be left without a working site and without a valid backup. We changed this behavior in the previous version but this confused users who could no longer set up Akeeba Backup in the precarious configuration described. We are now making this an option. The default is to include the latest backup in progress in remote files quota management. However, if you do not want to risk ending up without a valid backup you can of course disable this option. Consider this a warning that you need to think about your backup strategy very hard. A bad backup strategy is effectively the same as no backup strategy.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.