This version addresses known issues which could affect usability, site transfers and restoring backups taken on
sites running a. Joomla 3.6.3 or later; b. WordPress 4.6 or later with UTF8MB4 database collation
Updating Akeeba Backup for WordPress to version 2.0.x
Due to changes in the packaging format and / or issues in the updater, you cannot update automatically from Akeeba
Backup for WordPress versions 1.0 through 1.8.2 (inclusive) to version 1.9.0 and beyond. You will have to do that
Heads up! You must NOT uninstall or deactivate the plugin before the update. Doing so may result in
loss of your backup settings and / or your backup archives. Instead, here's what to do:
Download the ZIP file for Akeeba Backup for WordPress 2.0 and extract it locally. You will see an extracted
Upload the files from the extracted
akeebabackupwp folder into your site's
folder, overwriting your existing files, using FTP or SFTP.
Please note that the name of the folder on your site may be different than
akeebabackupwp (1) or something similar. It depends on how
you installed the plugin.
Log in to WordPress' wp-admin and access Akeeba Backup for WordPress to automatically complete the update
process. There is no message when the process completes. You just see the main page of Akeeba Backup for
WordPress (this means the update succeeded).
You will only need to do this once, upgrading to version 1.9 or later for the first time.
PHP 5.3.3 or later or PHP 7 is required
Akeeba Solo and Akeeba Backup for WordPress 1.9 are compatible with PHP 5.3.04 and later versions, including 5.4,
5.5, 5.6 and the newest version of PHP, 7.0.
We'd like to remind you that most third party software which can be backed up by our software do not support
PHP 7 yet. As a result we can't guarantee a trouble-free restoration or tha the restored site will work on
PHP 7 as this depends entirely on the software powering your site.
- [HIGH] Joomla restoration: changes in Joomla 3.6.3 and 3.6.4 regarding Two Factor Authentication setup handling could lead to disabling TFA when restoring a site
- [HIGH] Site Transfer Wizard fails on sites with too much memory or very fast connection speeds to the target site
- [HIGH] Site Transfer Wizard is missing a file required to transfer very large files to the remote server
- [LOW] ANGIE: Restoring WordPress 4.2+ from MySQL 5.6 to MySQL 5.5 or earlier fails due to WP using the utf8mb4_unicode_520_ci collation which is not available on older MySQL versions
- [LOW] The changelog was not displayed when clicking on the "Changelog" button
- [MEDIUM] Fixed typo in Site Transfer Wizard page, preventing the actual transfer
- [MEDIUM] In several instances there was a typo declaring 1Mb = 1048756 bytes instead of the correct 1048576 bytes (1024 tiems 1024). This threw off some size calculations which, in extreme cases, could lead to backup failure.
- [MEDIUM] Infinite loop creating part size in rare cases where the space left in the part is one byte or less
- [MEDIUM] Obsolete records quota did not delete the associated log file when removing an obsolete backup record
- [MEDIUM] Obsolete records quota was applied to all backup records, not just the ones from the currently active backup profile
- JSON API: export and import a profile's configuration