Normalized the default backup description under all backup methods (backend, frontend, CLI, JSON API). We realised that each backup origin had a different default description, implemented with a different code path. This was both unreliable and confusing for the user. Now all default backup descriptions are set to "Backup taken on DATE-AND-TIME (METHOD)" which is far more reasonable. The date and time is expressed in the explicitly defined backup time zone if one has been selected. If you have not selected a backup time zone it will be expressed in the user's time zone specified in the currently logged in user's profile (backend backups only) or the site's server time zone specified in Joomla's Global Configuration. In the unlikely event that you have not selected either time zone it will be expressed in UTC. The abbreviated time zone name is printed next to the date and time for clarity.
Massive speedup in data replacement of heavily nested serialised tables with thousands of elements. We implemented a new data replacement algorithm which performs better when restoring WordPress sites having serialized arrays with thousands of elements only a few of which require data replacement. Furthermore, data replacement is now extremely fast when the original and the replacement data have equal lengths (think about moving a site from www.example.com to www.example.net).
You can select a faster algorithm for data replacement of really big serialised data during restoration. Even though we introduced major speed upgrades to the regular data replacement algorithm, there are still some cases where this wouldn't be enough, e.g. when there's a serialized array with hundreds or thousands of elements most of which include the string that needs to be replaced. We have an alternative, albeit more precarious, data replacement algorithm for these cases. It performs far faster but has a very, very small chance of causing data corruption. It is automatically applied on serialized data over a certain length (configurable). Adjusting the serialized data length over which it is applied lets you effectively select when to use it. The default is fine for most sites. On really slow servers you can set it to 0 to always use this super fast algorithm.
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.