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.
Joomla 4 CLI (joomla.php) support – full CLI client to Akeeba Backup. This feature is currently in BETA. It also only works with Joomla 4 which is itself in beta. This allows you to manage most aspects of the Akeeba Backup component including taking and managing backups, configuring backup profiles, exporting/importing backup profiles and changing the component's options using the command line interface. The command line interface is scriptable and can be used for automating tasks on your sites, including setting up new sites.
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 Joomla 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 extensions, including your templates, 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.
Joomla 4 beta 6 (pre-release) changes how the session works, breaking everything.. This is apparently a bug introduced after the Joomla 4 beta 5, breaking the way the Joomla session works. We had not reported it because it appeared to be an intentional, but undocumented, change. The Joomla 3 release lead noticed our workaround and had the Joomla 4 team address the underlying bug since it breaks the stated backwards compatibility goal with the upcoming Joomla 3.10. However, given the severity of this issue and the fact that it did appear to be an intentional change (the code commit was unambiguous about the underlying change that triggered this issue being intentional) we decided to keep our workaround in case the Joomla project changes its mind or makes another change which accidentally breaks the way sessions work. Better be safe than sorry.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
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.
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.