This is a bugfix release, addressing a major issue affecting a very limited number of hosts. We strongly recommend all Professional version subscribers to update to it immediately.
Fixed “forever” running backups on a very small number of hosts. A change introduced in version 7.3.1 could inadvertently cause a non-backend (CLI, frontend backup OR or remote JSON API) backup run forever. This would only happen if the database server dropped the connection during the finalization stage. This is an uncommon issue and only really happens on hosts with a database server set up to automatically close the connection after a very short period (less than 2 seconds) of inactivity. Because of the timing-sensitive nature of this issue we could not test against it before the release of 7.3.1. In fact, debugging and fixing this issue required access to an affected server. A big thank you is in order to everybody who gave us access to their affected sites so we could resolve this issue.
Fixed compatibility with WP Engine. WP Engine runs a modified PHP which prevents the creation of .php files if there is no user logged into WordPress. We have switched our backup log files and the backup engine's temporary (“memory”) files to .php files with a die() statement on top for security reasons: even if your backup output directory is we accessible an attacker cannot access these files over the web. This clashes with WP Engine's platform protection feature we described above. If you have a site on WP Engine and are taking a backup through any method other than Akeeba Backup's interface in wp-admin we will now detect the inability to create .php files and will try to revert to using plain old .log files for logs and .dat files for the "memory" files. This will NOT affect the security of your backups on WP Engine. Access to the backup output directory will be limited by the .htaccess file Akeeba Backup forcibly places in that directory. Kindly note that we very strongly recommend moving your backup output directory outside your site's web root for optimal security of your backup archives.
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 only done some preliminary PHP 8 compatibility testing for the backup engine, PHP 8 being in alpha. 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.