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.
Replace zero datetime with nullable datetime. For historical reasons our software was following the old MySQL 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 both WordPress and Akeeba Solo do explicitly tell MySQL to allow zeroes in dates, this behavior is deprecated and might be removed in a future version. 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 PHP 7.1, 7.2, 7.3 or 7.4.
While our software still runs on PHP 7.1 we are no longer testing our software with this PHP version or consider it an actively supported environment for our software.
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.
At the time of this writing we have done extensive PHP 8 compatibility testing for the backup engine. However, PHP 8 is still in pre-release status as of this writing. We expect to be able to fully support PHP 8 around 2-4 weeks after WordPress 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 WordPress adds support for it by end December 2020.
Kindly note that our policy is to officially support only the PHP versions which are not yet End Of Life per the official PHP project with a voluntarily extension of support for 6 to 9 months after they become End of Life. After that time we stop providing any support for these obsolete versions of PHP without any further notice. New version branches of PHP will be supported experimentally starting sometime during their Release Candidate phase and fully about 4 to 8 weeks after the first stable version of that branch is released.
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 and do not consider them supported environments for our software.
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 are actively supporting Joomla 3.9 and 4.0. Joomla 4 support is considered experimental since it is still in beta.
Akeeba Solo should be able to back up and restore sites running on Joomla 1.5 or later. However, some of the restoration features in the Site Setup page may have no effect on sites older than Joomla 3.6. We recommend against using obsolete versions of Joomla. We do not test against them anymore and they include known security vulnerabilities which make them unsuitable for use on production sites.