Welcome to the first stable version of Akeeba Backup 7! There are many, exciting changes for you to explore.
Remove TABLESPACE and DATA|INDEX DIRECTORY table options during backup. These are very rarely used options in the context of web applications. In either case they are absolutely specific to the database server since they define paths on the disk where individual table data is going to be stored. These options don't make sense when transferring a site, or restoring it after a complete disaster, therefore they were dropped.
Obsolete backup quotas would fail to run on some sites. Newer versions of MySQL and MariaDB treat NULL and empty strings differently. The end result was that obsolete backup quotas would stop working without an error for no immediately obvious reason.
FTP and SFTP connection tests were always failing. There was a typo in our updated JavaScript in Release Candidate 1.
Fetching update information on WordPress could result in a PHP exception. This happened when the latest available release on our site is less stable than your preferred update stability target. The latter being “Stable” by default, most users experienced this issue when we published an Alpha, Beta or Release Candidate version on our site. In most reported cases the experienced problem is that WordFence's site scan would fail. In very few cases you might experience the Plugins page not loading fully until you try reloading it. This issue does not affect Akeeba Solo, only Akeeba Backup for WordPress.
Removed obsolete “Use IFRAMEs instead of AJAX” option. This switch actually didn't do anything for a very long time now.
Upload to OVH now supports Keystone v3. This will be mandatory starting mid-January 2020.
An error in an early backup domain could result in a forever-running backup. This seems to have been an issue since at least 2015 but would manifest itself very rarely. We finally got enough information to reproduce and fix this.
DB connection errors wouldn't result in the backup failing, as it should be doing. This was due to an error propagation issue introduced on Beta 1.
Manage remotely stored files: Fetch to server would fail after the first batch of downloads. A typo led to failure to download any backups which required more time than that afforded by a single page load.
Common PHP version warning scripts. All of our software will now include unified messaging about versions of PHP that have entered their Security Support stage of life, have recently gone End of Life, have gone End of Life a long while ago or are not supported at all by our software. This will help you better plan your PHP updates.
Reinstated pCloud support. We gave pCloud access to a dev site of ours and they were able to find and fix the bug in their OAuth2 server which prevented our clients from using the pCloud integration.
Improved Dark Mode. We reworked the entire Dark Mode CSS and added the necessary tweaks to make it look even better. Do note that we treat Dark Mode as an accessibility feature, not a design trend.
Improved PHP 7.4 compatibility. PHP 7.4 went stable around the time we released beta 1. We are now using it as our default development version of PHP which let us identify and resolve numerous compatibility issues with it. None of them was causing functional issues but we fixed them nonetheless since we consider full support for modern PHP a very important feature.
Improved integration with the WordPress plugins update system. We fixed misleading messages about PHP and WordPress version support when an update is available but it's less stable than your preferred minimum stability setting. All warning messages are now displayed correctly, not just when WordPress happens to reload the update information. Moreover, they now use translated strings instead of being hardcoded in English.
Clearer message when setting decryption fails in CLI backup script. Previously we stated that your PHP CLI didn't support encryption even when it was not the case (e.g. the decryption key had changed since you last saved the backup profile). The new messages convey the actual failure reason.
Removed all Javascript eval calls with calls to the JSON library. These were leftovers from a bygone era and triggering false positives in some malware scanners.
The database dump was broken with some versions of PCRE. Newer versions of PCRE, like the one used in Ubuntu 18.04 and later or most PHP 7.4 builds, silenty dropped support of a feature we were using in the new backup engine, causing database dumps to fail. We are now automatically detecting this and applying a workaround without any perceptible performance impact.
The integrated restoration was broken since beta 1. We identified the problem and fixed it.
ANGIE: Options to remove AddHandler lines on restoration. Have you ever restored a site on a different server only to find that it either not loads or downloads the .php file as text? That's because your site was using an AddHandler line to tell your old server which PHP version to use. These are server-specific and the new server did not understand it. Now you can remove these lines on restoration to prevent this kind of issue. You may still have to go to your hosting control panel and select the PHP version depending on your host and whether its default PHP version is simply too old to be usable.
Fixed OAuth authentication flow. A bug prevented authentication with some remote storage providers such as Google Drive.
You would always be asked to run the Configuration Wizard, even if you had done so already. This was both annoying and would override some of your backup settings if you had customized your backup profile.
New major version 7. Please consult our announcement for an overview of the new features and changes. It's just too much to include in these release notes!
We only officially support using our software with PHP 5.6, 7.1, 7.2, 7.3 or 7.4.
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.
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.
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).
We do not recommend using our software with WordPress versions earlier than 4.6 as some WordPress features we rely on for our software to function properly did not exist in these vintage versions. We generally strongly advise against running old, no longer maintained versions of WordPress for security and performance reasons.