Post-backup emails can now display the total backup size and the approximate size of each part file We added two variables for the body of emails to be sent after the backup is complete, configurable in the System Configuration page. One will report the total size of the backup, the other will list all backup part files with their approximate file sizes. Please read the documentation for more detailed information
Backup failure to S3 with a PHP Type Error when the Dual Stack option has no value. This is an extremely rare situation. Akeeba Backup normally detects when the Dual Stack option has not been set yet and defaults it to Yes. In case the configuration was saved automatically before a backup ran or the configuration page opened (an extremely rare occurence) an invalid value would be stored causing a PHP error. We now detect the invalid value and convert it to the default value.
Uploading to Dropbox would fail if you linked your Dropbox account after December 2020. Startring December 2020 Akeeba Backup is using scoped access with short-lived Dropbox tokens to authenticate itself to Dropbox. Due to a Dropbox documentation error at the time of implementation and a missing line in our code you were unable to use Dropbox if you linked your Dropbox account to Akeeba Backup after we aplied this change in December 2020. If you had linked your account before that you had a never-expiring access token which wasn't affected. We have identiifed and resolved both problems now.
WordPress: Better media version instead of using the plugin's version directly. We are now using a long hash as the version query for static media files instead of the actual version number of the plugin. This seems to work better with browsers, preventing them from caching JavaScript and CSS when we release a new version.
WordPress: Backup on Update was always taking place in Akeeba Backup Core even though it's meant to be a Pro-only feature. The backup on update feature was always being triggered in the Core version. There was no user interface to disable this feature since this is only provided in the Professional version. We have now disabled this feature in the Core version to prevent a long backup always being triggered every time you are working on your site and WordPress decides to install an update to itself. Pro version users can choose whther to enable this feature or not just like before.
Dropbox is now using the scoped API access. Dropbox changed their OAuth2 API from long-lived, cross-site tokens to short-lived, per-site tokens just like those used by Microsoft OneDrive or Google Drive. Dropbox emailed us that they would stop issuing old-style tokens on September 30th, 2021. While old-style tokens may work after that date, Dropbox does not make any commitments as to for how long that will be the case. We strongly recommend reconnecting each and every one of your backup profiles, on each and every one of your sites, to Dropbox to avoid any upload disruptions in the future. This release note entry was added for version 7.4.1 of our software and will be repeated on every release we make until at least December 2021. This information will also appear in our documentation.
Amazon S3: Added support for Dual Stack option (use of IPv6 when available). The implementation of Amazon S3 was using the traditional API endpoints which only resolved to an IPv4 address. Starting with this version we are now using Amazon S3 dual-stack endpoints which resolve to both IPv4 and IPv6 addresses. If your server has an IPv6 connection this can speed up the file transfer somewhat. You can always opt-out of this behaviour by disabling the relevant option in the backup profile's Configuration page. Do note that even if your server only supports IPv4 you will NOT notice any adverse effects; you will STILL be able to upload your backups to Amazon S3 since the dual-stack endpoint does resolve to an IPv4 address just fine.
Dropped PHP 7.1 support. PHP 7.1 became End of Life on December 1st, 2019. Over the last year we saw its relative use among our clients drop from 11% of all sites in January 2020 to just under 3.8% in November 2020. According to our experience this is a good point in time to remove support for it. This allows us to introduce PHP 7.2 features in our code which will improve the type consistency of internal data. This will let us catch type consistency bugs in development, a class of bugs that has caused weird issues that were very hard to debug in the past.
PHP 8.0 support. PHP 8 was released just two weeks ago but we had already started working on supporting it months ago, since it was still in development. Now that WordPress itself supports PHP 8 we can finally validate our work, fix the remaining issues and confirm that PHP 8 can be officially supported. Please bear in mind that PHP 8 brings major changes to the PHP language and not all third party extensions support it yet. Before venturing into it please do make sure that all of your third party plugins, including your themes, are up to the task.
Remove the JPS and ANGIE password fields from the Backup Now page.. You can still configure these features in the backup profile's Configuration page. The reason for this change is that browsers saw the two password fields and incorrectly concluded that this is a login page, trying to auto-fill these passwords with your Joomla super user login password. In many cases this ended up with the restoration script being inadvertently password-protected. TO make matters worse, modern browser IGNORE autocomplete="off" attributes in HTML form inputs, essentially making it impossible for us to tell them that no, it is not a login form. We had JavaScript in place to work around that behavior but it would sometimes get blocked by third party browser extensions. The best we can do is remove these fields from the Backup Now page and relocate them to the Configuration page. The latter is generated by JavaScript and gives us more flexibility in applying workarounds against browsers auto-filling passwords.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
We only officially support using our software with PHP 7.2, 7.3, 7.4 or 8.0.
While our software still runs on PHP 7.2, this versions of PHP is declared End of Life by the PHP project and no longer receives any security updates. We are no longer testing our software with these PHP versions and we strongly advise you to not use them on production sites.
We strongly advise you to run either of the two latest available version branches of PHP on a branch currently maintained by the PHP project for security and performance reasons. Older versions of PHP have known major security issues which are being actively exploited to hack sites and they have stopped receiving security updates, leaving you exposed to these issues. Moreover, they are slower, therefore consuming more server resources to perform the same tasks.
Please note that PHP 8.0 is, at the time of this writing, a very new PHP version which brings major changes to the PHP language. We strongly recommend holding off updating into it until April 2021 and only doing so after confirming that all of your extensions have been updated to support it. Do note that by “all extensions” we mean components, plugins, modules and templates.
Finally, please bear in mind that earlier PHP versions including but not limited to all PHP 4.x and 5.x versions, as well as PHP 7.0 are no longer supported. Our software no longer works on these old, unsupported versions of PHP. All of these versions of PHP have been end of life for several years. We VERY STRONGLY recommend upgrading to a version of PHP that's currently supported by the PHP project.
Our policy with regards to PHP version support is to officially support the PHP versions that the PHP project itself considers a Currently Supported version, i.e. all versions of PHP in the Active Support and Security Support phase. We will show you a warning when we detect a PHP version that has entered Security Support so you have the chance to plan and implement a PHP version update. After a PHP versions becomes End of Life (EOL) we will only support it for a further 6 to 9 months. If we detect such a version we will show you a message so you can urgently plan and implement a PHP version update. After 6 to 9 months after a PHP version becomes EOL we may stop providing support for it without any prior notice. We also track the development of new versions of PHP. New versions of PHP will be unofficially supported sometime during their Release Candidate phase and fully supported about 4 to 8 weeks after the first stable version of that branch is officially released by the PHP project. Your site's participation in the opt-out usage statistics helps us collect anonymous information about the use of PHP versions on your sites and decide when to withdraw support for EOL versions of PHP.
We officially only support the latest WordPress 5.x release.
Our software should also work on WordPress 4.9 and ClassicPress 1.x since we do not rely on any features added in later WordPress versions. However, we no longer test against these versions of WordPress / ClassicPress.
We fully support single site and multi-site installations of WordPress. Multi-site installations can be converted on restoration from directory-based to subdomain-based or vice versa. You cannot restore a single site backup into a multi-site installation. You cannot restore / convert a blog of a multi-site network installation into a single site WordPress installation (in fact, there is no official WordPress method to do that safely).
Using our software with versions of WordPress earlier than 4.9 may be possible but we cannot provide any support for them. Furthermore, we very strongly discourage using our software with WordPress versions earlier than 4.6 because some WordPress features we rely on for our software to function properly did not exist in these very old, End of Life versions. We generally strongly advise against running old, no longer maintained versions of WordPress for security and performance reasons.
We only officially support using our software with the latest Joomla! release branch, 3.9. We strongly advise you to run the latest available version of Joomla! for security reasons. Older versions of Joomla! have known major security issues which are being actively exploited to hack sites.
We offer limited support for Joomla 4.0 which is currently in Beta. Akeeba Ticket System will work on it but there may be some minor or bigger issues. We try to discover and address them. The biggest challenge is that Joomla 4 is still undergoing changes, despite being labeled Beta, which may introduce new issues on each release. We do not plan on offering full support for Joomla 4 until it reaches at least the Release Candidate 1 stage.
Support for Joomla 3.10 is currently considered experimental. At the time of this writing Joomla 3.10 is in a pre-production, alpha state. We strongly advise you to NOT use Joomla 3.10. Like all new Joomla 3 version families we plan on supporting it as soon as it reaches stable status.