Support

The API works just fine. We had another client claiming the same thing, we got access information to their site, and we proved that the API works using Akeeba Remote CLI.

Please read Information on failure to follow our instructions about Akeeba Backup for WordPress 8.1.0  under "The JSON API is NOT broken" and do tell me if you are using a third party service, and which one is it.

mySites has been falsely claiming the JSON API in Akeeba Backup for WordPress 8.1.0 is broken for the last three days. You're not the first person who was lied to and came here to file a false complaint. Something tells me you won't be the last one either.

The command you are running to test the connection is definitely wrong. Its --host argument is invalid for WordPress sites; it would only be valid if your site was running on Joomla, as you can see from the URL it is trying to access and which you posted here.

What you should have run instead is:

php remote.phar test --host https://xxxx.fr/wp-admin/admin-ajax.php?action=akeebabackup_api --secret XXXXXXXX --debug

Please remember that since Akeeba Backup for WordPress 7.7.0 which was released in August 2022 the endpoint URL for the Akeeba Backup Remote JSON API has changed from wp-content/plugins/akeebabackupwp/app/index.php to wp-admin/admin-ajax.php?action=akeebabackup_api. You can see that information in the Schedule Automatic Backups page, but do note that there is a simple visual bug which outputs the first part of the URL twice.

Further to that, I do not know which version of Remote CLI you are using. Versions before 3.0.0 would definitely not work correctly with Akeeba Backup 8.0.0 (actually, with the new endpoint URL introduced in 7.7.0). Just to be sure everyone's on the same page I released Remote CLI 3.1.0 today which has the same unified remote backup code which is already used in Akeeba UNiTE and Akeeba Panopticon, the Akeeba Backup JSON API Client Library which is open source and distributed under the GNU AGPL 3.0 or later license. That's what I have been testing with and it works perfectly fine with both the new and the old endpoint. I have also used 3.0.0 with the new endpoint without any problem whatsoever through Docker and only with the new endpoint (I honestly don't know if it will work with old endpoint; it's not something I was interested in, given that I deprecated more that a year prior), before releasing 8.1.0, for what it's worth. So, please, do try both versions. I want you to see that what I am saying is the truth, and nothing but the truth.

Please, let's test together.

First, with the new endpoint which you should all be using:

$ php remote.php test --host="https://XXXXX/wp-admin/admin-ajax.php?action=akeebabackup_api" --secret="XXXXXX"
Akeeba Remote Control CLI 3.1.0 (2023-11-13)
Copyright ©2006-2023 Nicholas K. Dionysopoulos / Akeeba Ltd.
--------------------------------------------------------------------------------
 This program comes with ABSOLUTELY NO WARRANTY. This is Free Software and you
 are welcome to redistribute it under certain conditions. Use command license
 for details.
--------------------------------------------------------------------------------
Successful connection to site
Akeeba Backup / Solo Professional 8.1.0 (API level 400)

Then, with the old endpoint which you should NOT be using as it's going to be removed at some point:

$ php remote.php test --host="https://XXXXX/wp-content/plugins/akeebabackupwp/app/index.php" --secret="XXXXXX"
Akeeba Remote Control CLI 3.1.0 (2023-11-13)
Copyright ©2006-2023 Nicholas K. Dionysopoulos / Akeeba Ltd.
--------------------------------------------------------------------------------
 This program comes with ABSOLUTELY NO WARRANTY. This is Free Software and you
 are welcome to redistribute it under certain conditions. Use command license
 for details.
--------------------------------------------------------------------------------
Successful connection to site
Akeeba Backup / Solo Professional 8.1.0 (API level 400)

So, you ask me, what do I think about it? I think that you did not come up with the idea to test with Remote CLI on your own, nor did you come up with the command to run yourself. Who told you to run this command that had absolutely no chance of working with any version of Akeeba Backup of WordPress?

Also, my offer to prove to you that the JSON API on your site is working fine still stands. I have no problem demonstrating to you that your problem is a third party service is broken, not a problem with Akeeba Backup.

Just FYI. I have figured out why mySites.guru does not work with Akeeba Backup 8.1.0 and without even having to look at Phil's code. It's so obvious.

There was one big change in Akeeba Backup 8.1.0 which we announced a month before releasing version 8.1.0. Here's the pertinent line:

The backup profile settings encryption key has been moved from wp-content/plugins/akeebabackupwp/app/Solo/secretkey.php (and its previous location wp-content/plugins/akeebabackupwp/app/Solo/engine/secretkey.php) to wp-content/akeebabackup_secretkey.php

Phil's code must still be looking at the old location of that file. Since the file is not there, he cannot decrypt the encrypted settings — the Secret Key is one of them. Therefore, his connector communicates the still encrypted Secret Key back to his service. As a result, when he tries to use it, he gets a message that the Secret Key is wrong because it is, in fact, wrong.

If he had let you, the user, provide the Secret Key he would not have had this self-inflicted problem. If had spent a few minutes reading my communication about the issue we had and how we addressed it, he would not have had this self-inflicted problem. If he had tried to debug his code he would have fixed his self-inflicted bug. Instead, he chose to do none of that and spent the last 4 days slandering us, and trying to use all of you to disrupt our services. What kind of person does that?!

Please forward him this entire message.