Files and Directories Exclusion: mark folder and file symlinks as such [gh-676]. In the past it was impossible to tell if a folder or file is real or a symlink. You had to know and remember, which is not ideal when you are trying to figure out what to exclude from a backup. Now symlinks will be marked with a chain link icon to make it easier to spot them. Please note that the symlink target is NOT displayed.
Automatically rewrite the Output Directory using site path variables such as [SITEROOT] for portability [gh-678]. This affects how the Output Directory field works in the Configuration page. In the past you would only get parent folder of the site substituted with [ROOTPARENT] and only when you used the GUI (directory browser) for selecting the output directory. The corollary to that is that if you selected a folder under your site's root or entered a path manually in the box it remained there as an absolute path. This would cause backups to fail after transferring your site to a different server or subdirectory. Starting with version 7.4.0 Akeeba Backup will try to rebase the path to the [DEFAULT_OUTPUT] or [SITEROOT] variable if possible, therefore making the Output Folder portable, i.e. it will continue working even after you restore your site to a different server or subdirectory. All you have to do is visit the Configuration page of each backup profile once and click on Save & Close. That's it!
Automatically rewrite the Off-site Folders Inclusion using site path variables for portability. Similar to the above but for Off-site Folders Inclusion. In the past the folders to include were only set up as absolute paths. Upon transferring your site to a different server you would have to reconfigure each of your backup profiles using Off-site Folders Inclusion or your backups would fail. Starting with Akeeba Backup 7.4.0 these will be automatically rebased to the [SITEROOT] or [ROOTPARENT] varaible, if possible, making them relative to your site therefore portable. You just need to edit the Off-site Folders Inclusion filters of each of your backup profiles once, just clicking on the save button, to have Akeeba Backup perform that conversion for you. That's it!
Remote backup JSON API version 2. We have introduced a new version of the remote backup JSON API which is less complex and more efficient. Both the old (v1) API and the new (v2) API will be available throughout Akeeba Backup 7 starting with version 7.4.0. The old v1 API will be removed in Akeeba Backup 8. Akeeba Backup Remote CLI and Akeeba UNiTE have also been updated to support the new API version.
ANGIE: Added feature to resume restoring the database if an error occurs. We have seen a few live servers and some local servers where the database restoration halts because the server experienced an error, e.g. reaching SQL query limits or an internal error in Apache itself. In the past that would make restoring your database impossible. We have now added a Resume feature, similar to the Resume feature in Akeeba Backup itself when taking a backup. If an error occurs ANGIE will wait for 30 seconds and resume the database restoration from roughly where it previously stopped. This should make it easier to work around most servers getting stuck during database restoration.
Deprecated Upload to pCloud. Unfortunately the OAuth2 authentication is broken on pCloud's side. Do note that pCloud was made aware of this issue months ago but does not seem interested in addressing it. We have to deprecate Upload to pCloud and will remove it in a future version as it's not something we can possibly work around ourselves.
Removed tooltips from Database Tables Exclusion and Files and Folders Exclusion pages to clean up the UI. These tooltips were repetitive and redundant. The explanation of each icon is already in the documentation.
Using nullable TIMESTAMP fields instead of zero dates. For historical reasons our software was following the Joomla convention of using the fake date “0000-00-00 00:00:00” as a placeholder meaning “no date”. MySQL 5.7 and later will, by default, not allow zeroes in the month or day part of the day unless explicitly told otherwise. While Joomla does explicitly tell MySQL to allow zeroes in dates, even in Joomla 4, this behavior is deprecated and might be removed in a future version of Joomla. We have now replaced these placeholder dates with a NULL value – a special value which MySQL and PHP understand to mean “a date has not been set yet”. All your database tables will be automatically converted upon upgrading our software or, if that fails, when you visit the Control Panel (main component) page. This means that the upgrade or first access to the Control Panel page may appear to take a bit longer than usual. That's normal and there's no reason to be alarmed. If you get a white page wait a minute and retry. On extremely big sites on very slow servers you may have to repeat that a few times. On the vast majority of sites you won't need to do that at all.
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.1, 7.2, 7.3 or 7.4. We strongly advise you to run the latest available version of PHP on a branch currently maintained by the PHP project for security 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.
At the time of this writing we have extensively tested our software with PHP 8 on both Joomla 3 and 4. However, PHP 8 is sill in a pre-release state and not officially supported by Joomla. As a result we consider PHP 8 support tentative. We expect to be able to officially support PHP 8 around 2-4 weeks after Joomla implements full PHP 8 compatibility. PHP 8 itself is scheduled for release on November 26th. Our prediction for full PHP 8 support is before the end of January 2021, as long as Joomla adds support for it by end December 2020.
Please note that earlier PHP versions including but not limited to PHP 5.3, 5.4, 5.5, 5.6 and 7.0 are no longer supported and our software no longer works on them.