Support for Joomla proxy configuration. Joomla allows you to configure the outbound proxy which needs to be used for your site to communicate to the outside world. We now automatically read and apply this proxy configuration in Akeeba Backup Professional, whenever we are sending your backup archives to remote storage. Due to PHP limitations this feature is not supported with FTP or SFTP (DirectFTP/DirectSFTP or Upload to Remote FTP/SFTP server) unless you use the cURL variants, i.e. "DirectFTP over cURL", "DirectSFTP over cURL", "Upload to Remote FTP server using cURL" or "Upload to Remote SFTP server using cURL".
Remove dash from automatically generated random values for archive naming. Some of our clients parse the filenames of generated backup archives for reporting or internal business reasons, on the assumption that dashes are used as information field separators in the filenames. Removing the dashes from the [RANDOM] field makes this process less complicated without affecting the security of the solution.
Increase the maximum Size Quota limit to 1Pb. The old limit of 4Gb dates back to 15 years ago. Back then sites and available server disk space were much smaller. 4Gb was a reasonable limit. Fast forward to 2021 and we see hosting accounts with 20Gb to 1Tb of disk space as the norm, big sites backing up to hundreds of Mb or a few Gb and this limit was just too low to be practical. This limit has been increased a few million times ensuring it will remain practical in the foreseeable future.
Could not restore on PHP 8 if Two Factor Authentication is enabled in any user account. This is actually a two–pronged issue stemming from a bug in Joomla itself. We have applied a workaround in our restoration script (ANGIE). Joomla will probably include a fix for it in Joomla 4.1 or 4.2, pending a decision from production leadership. Also note that Joomla 3.6.4 and later will fail logging in a user which has enabled Two Factor Authentication in their account using Joomla 3.2.0 to 3.6.3 inclusive and has not changed it using Joomla 3.6.4 or later if your server is upgraded to PHP 8 or later. This cannot be worked around in Joomla itself. The same problem that prevents you from logging in will also prevent you from editing the affected user account. However, if you backup up and restore your site with Akeeba Backup (using the Full Site backup mode!) you will be able to log in with or edit the affected user since the restoration will upgrade the way the Two Factor Authentication settings are stored to make them compatible with newer Joomla and PHP versions. We only ever found TWO (2) people who were affected by this bug but we decided to provide a solution anyway; debugging Joomla's code to understand why this happened was already doing 99% of the work to providing a workaround so what's the point of not spending the extra tiny amount of time to provide a workaround to a really weird if not extremely uncommon issue?
Backing up to Box, Dropbox, Google Drive or OneDrive was not possible if you are using an add-on Download ID. Add-on Download IDs use a colon (:) to separate the two parts of the identifier. This is not a valid character in a URL, it needs to be URL–encoded when it's sent to our server to retrieve a new access token for your remote storage provider. This was not a problem in the past since our hosting environment would silently accept this illegal character. During a recent security upgrade in our hosting environment this stopped working and requires a change in the backup engine to correctly encode the colon in the Add-on Download ID when sending it to our serer.
# [MEDIUM] Cannot restore on PHP 8 if Two Factor Authentication is enabled in any user account. This is actually a two–pronged issue stemming from a bug in Joomla itself. We have applied a workaround in our restoration script (ANGIE). Joomla will probably include a fix for it in Joomla 4.1 or 4.2, pending a decision from production leadership. Also note that Joomla up to and including 3.10 and 4.0 will fail logging in a user which has enabled Two Factor Authentication in their account using Joomla 3.2.0 to 3.6.3 inclusive and has not changed it using Joomla 3.6.4 or later if your server is upgraded to PHP 8 or later. This cannot be worked around in Joomla itself. The same problem that prevents you from logging in will also prevent you from editing the affected user account. However, if you backup up and restore your site with Akeeba Backup (using the Full Site backup mode!) you will be able to log in with or edit the affected user since the restoration will upgrade the way the Two Factor Authentication settings are stored to make them compatible with newer Joomla and PHP versions. We only ever found ONE (1) person who was affected by this bug but we decided to provide a solution anyway; debugging Joomla's code to understand why this happened was already doing 99% of the work to providing a workaround so what's the point of not spending the extra tiny amount of time to provide a workaround to a really weird if not extremely uncommon issue?
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
Please consult our Compatibility page. It explains our version support policy and lists which versions of our software are compatible with which versions of Joomla and PHP.