Information on failure to follow our instructions about Akeeba Backup for WordPress 8.1.0

13 November 2023 Last updated on 15 November 2023

This is further information to Akeeba Backup for WordPress 8.1.0 and how failing to follow our instructions will lead to failure, as already discussed. Moreover, we would like to explicitly state that despite mySites.guru proclaiming that the JSON API in Akeeba Backup for WordPress 8.1.0 is broken they are merely wrong, as they usually are every single time they proclaim such a thing.

The only supported update method is what we emailed you

As we already told you, and emailed all of our Akeeba Backup for WordPress subscribers, the only supported method for updating Akeeba Backup 8.0.0.2 or earlier to Akeeba Backup 8.1.0 or later is the following:

  • Download the latest version from our site.
  • Download the latest version from our site.
  • Upload the contents of the extracted akeebabackupwp folder into your site's wp-content/plugins/akeebabackupwp folder.
  • Visit your site's wp-admin and click on Akeeba Backup in the sidebar.

There is no other method that is supported.

Using any other method will break your installation

The whole point of requiring this manual upload is that WordPress 6.3 introduced a backwards incompatible feature. Whenever you use WordPress' code to update a plugin, it will delete the installed plugin files before it installs the new version. This causes two problems:

  1. It deletes any backup archives stored inside the plugin's folder. This is especially important if you were using the default backup output directory, or if you had created a backup output directory under the plugin's folder (by default: wp-content/plugins/akeebabackupwp).
  2. It deletes the encrypted settings key file, breaking all encrypted settings. This means you will lose all your backup profile settings, and your front-end backup / remote JSON API backup Secret Key will become corrupt.

The problem, as we have already explained, happens whenever you use WordPress' code to update the plugin. Indicatively:

  • Using automatic plugin updates (WordPress detects and installs the plugins without any user interaction).
  • Using the web UI to install a plugin update found by WordPress.
  • Using the web UI to upload the new version of the plugin i.e. using WordPress' Plugins, Add New feature.
  • Using WP-CLI to install an update that WordPress has found.
  • Using WP-CLI to tell WordPress to install the new version of the plugin.
  • Using third party tools or services to update plugins, either using the update information gathered by WordPress, or by using the ZIP file of a new version of the plugin.

Using any of these methods will break your Akeeba Backup installation, for reasons outside our control.

Please keep in mind that we gave you explicit instructions on how to install this update. We did that so there is absolutely no room of misinterpretation as to what "manual update" means in this context. Doing anything different is at your own risk and peril. We, objectively, cannot be held accountable for anyone's choice not to follow our instructions.

Do not mix Akeeba Backup Core and Professional

If you have Akeeba Backup Core already installed on your site you must update it to Akeeba Backup Core.

If you have Akeeba Backup Professional already installed on your site you must update it to Akeeba Backup Professional.

We did not explicitly state that on account of this having been self-understood over the last 16 years we have provided different editions of our software.

Some of you either didn't get that, or were not careful when not downloading the newest version, downloading Akeeba Backup Core instead of Akeeba Backup Professional. If you tried installing Akeeba Backup Core over Akeeba Backup Professional you may have ended up with a broken installation. However, this is a recoverable problem. Here's what to do in this case:

  • Download the latest Professional version from our site. The name of the file you download is something like akeebabackupwp-8.1.0-pro.zip. Note that it ends in pro.zip not core.zip.
  • Extract the downloaded ZIP file on your computer.
  • Upload the contents of the extracted akeebabackupwp folder into your site's wp-content/plugins/akeebabackupwp folder.
  • Visit your site's wp-admin and click on Akeeba Backup in the sidebar.

The JSON API is NOT broken

The third party site monitoring service mySites.guru is telling you that allegedly Akeeba Backup for WordPress 8.1.0 has a "MAJOR BUG" in that our JSON API is broken. This is not the case. 

We now know for a fact that their problem is that they are using the wrong endpoint URL (wp-content/plugins/akeebabackupwp/app/index.php) which is no longer valid for Akeeba Backup 8. The correct endpoint since Akeeba Backup 7.7.0, released in August 2022 – well over a year ago – is wp-admin/admin-ajax.php?action=akeebabackup_api as you can clearly see in the Schedule Automatic Backups page of our plugin.

The old endpoint was retired and became unsupported in Akeeba Backup 8, but not completely disabled. Not disabling it completely was an oversight which is addressed in version 8.1.1, to be released on November 15th, 2023.

Instead of mySites.guru fixing their bug, they are asking you to run Remote CLI with an incorrect command line which would never work to begin with to “prove” our software is broken. The command line has this form:

php remote.phar --host="https://www.example.com" --secret="YOUR_SECRET_KEY"

This command line will not work with any version of Akeeba Backup for WordPress published the last two years. This command line, as it is constructed, will only work with Joomla! sites. Since you are trying to use it with WordPress it fails, as expected.

When using Remote CLI with Akeeba Backup for WordPress you have to pass the complete endpoint as detailed in our documentation for Akeeba Remote CLI. As noted in the documentation, the endpoint you need to use for Akeeba Backup for WordPress 7.7.1 or later is in this form:

https://www.example.com/wp-admin/admin-ajax.php?action=akeebabackup_api&option=com_akeeba&view=api&format=raw

Therefore, the correct command line to use is:

php remote.phar --host="https://www.example.com/wp-admin/admin-ajax.php?action=akeebabackup_api&option=com_akeeba&view=api&format=raw" --secret="YOUR_SECRET_KEY"

If you are using Akeeba Remote CLI version 3.0.0 or later this can be written in a slightly more compact manner (we rewrote part of our code to recognise the endpoint that is specific to WordPress and our API v2 so that you no longer need to provide the option, view, and format parameters):

php remote.phar --host="https://www.example.com/wp-admin/admin-ajax.php?action=akeebabackup_api" --secret="YOUR_SECRET_KEY"

If you use that, you will see that it works with all Akeeba Backup for WordPress versions from 7.7.1 (released September 2022) all the way to the latest 8.1.x versions.

Moreover, mySites.guru tells you to contact us with the output of their rigged command line and the equally false claim that you were using that command line up with to and including Akeeba Backup for WordPress 8.0.0.2. As noted, that command line does not work, making this claim ridiculously easy to spot as a fake. Please, do not reproduce their lies in your tickets. It only makes you look like you are deliberately lying to us which leads to a rather awkward interaction.

Again, the problem is that this third party service is using the wrong endpoint URL, something they should have addressed since at least September 2022 when Akeeba Backup 7.7.1 was released and the new endpoint URL became fully operational. They had 14 months to address this change, but they failed to do so.

We understand that third parties may fail to keep up with the changes we make to the API, even though we always make the old API available for at least one year after we introduce a change. It can happen, and we won't hold it against anyone.

What we absolutely do not accept is having a third party using strong, belittling, and unprofessional language for what is ultimately their fault when communicating to our mutual clients, all the while refusing to address the problem in their service. This is unprofessional, and unproductive.

Unfortunately, this kind of unprofessional language has been a consistent pattern in all communications coming from mySites.guru we received or were made aware of the past four years. As a result, we decided to discontinue any and all support for using our software with mySites.guru effective Monday, November 13th, 2023.

We strongly recommend using that you use a service which is run in a professional manner. While we don't use any third party services —we are actually building our own free-of-charge site monitoring software; WordPress support to come in 2024— we can tell you that we never had this kind of problematic behaviour coming from the folks at Watchful and YourSites. We ask you to draw your own conclusions.

Do not downgrade from Akeeba Backup 8.1.0 or later

Downgrading from Akeeba Backup 8.1.0 or later to Akeeba Backup 8.0.0.2 or earlier is not supported.

As we have previously explained, we had to change the update channel and format in Akeeba Backup 8.1.0 since using the old update channel would have resulted in automatic updates using WordPress code which would have broken your Akeeba Backup installation. A side-effect of changing the update format is that the update information is stored in the database in a different way which is incompatible with previous versions of the software (8.0.0.2 and earlier versions).

If you downgrade from Akeeba Backup 8.1.0 to one of these older versions, the update code in these older versions will break with a PHP error as it cannot ingest the update information already stored in the database. Since the update code is called by WordPress very early when loading the backend interface, this might cause complete inability to access your site's wp-admin. This is why we would never ask you to downgrade, and we would tell you not to do so if we were asked.

If this happened to you, you will need to use your host's database management interface (usually phpMyAdmin or Adminer) to remove two rows in the wp_options table with the option_name values of update_plugins and akeebabackupwp_pluginupdate_frozenstate. Please note that the wp_options table may have a different table name prefix, e.g. foo_options, on your site.

Removing these two transient options has no operational impact on your site other than telling WordPress to look for plugin updates anew, and Akeeba Backup to reload its update information (since we deleted its updates cache).

A final note on civility in communication

Last month, we gave a free pass to unprofessional conduct in communication towards us for the very simple reason that neither us, nor you, could have expected a major backwards incompatible change in WordPress 6.3 not being communicated, or documented by WordPress itself, and causing such a major problem.

In the 40 days since we have published four articles, this included, as well as 3 beta versions and a stable version. We even emailed you explicit instructions for the update. There is no longer any reasonable doubt as to what has happened and what you need to do about it. Therefore, we can no longer justify any kind of unprofessional communication.

Thank you for keeping discourse civil and reasonable.