Resolved WP Toolkit Delete Backup API Request not working

[Giu]

Username:

TITLE

WP Toolkit Delete Backup API Request not working

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

Debian 12.4, Plesk Obsidian
Version 18.0.58 Update #2
WP Toolkit: 6.2.14-7878

PROBLEM DESCRIPTION

WP Toolkit REST API Request: /api/modules/wp-toolkit/v1/installations/XX/backups
Delete Request

if you want to delete a WP Toolkit Backup with ?files%5B%5D=yourdomain.com__2024-02-01T12_37_48%2B0100.zip

the Backup will not get deleted.

STEPS TO REPRODUCE

curl --location --request DELETE 'yourserver.com:8443/api/modules/wp-toolkit/v1/installations/INSTALLATION_ID/backups?files=yourfilename.zip' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic BASICAUTH' \
--data '{
"delete": true
}'

ACTUAL RESULT

204 No Content
no backup deletion on the server

EXPECTED RESULT

some kind of response body and backup been removed from the server/wp installation

ANY ADDITIONAL INFORMATION

It's not an auth issue and it's not an issue with installation_id or filename

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Help with sorting out

 

[Giu]

Hello Plesk Team,

is there a chance this topic will be addressed and maybe fixed with an upcoming patch for the WP Toolkit extension?

 

[Peter Debik]

Could you please provide a link where you found a documentation on this function so that I can learn that "delete" is a defined transaction?

 

[Giu]

Hi Peter, thank you very much. the link to the documentation can't be directly accessed but its the wp-toolkit api documentation:

https://yourpleskserver.de/api/v2/?urls.primaryName=WP%20Toolkit%20REST%20API

navigate to "Installations.Backups"
There you find two endpoint descriptions:

Its the Delete Request in there:

 

[Peter Debik]

Thank you for your report. Forwarded to developers for further analysis as internal ID PPS-15562.

 

[Peter Debik]

Developers have checked this in Debian an Centos, but in both cases could use the API function. From the ticket:

curl -X 'DELETE' \
'https://<ip>:8443/api/modules/wp-toolkit/v1/installations/1/backups?files%5B%5D=<ip>.tld__2024-02-05T11_48_58%2B0000.zip' \
  -H 'accept: */*' \
  -H 'Authorization: Basic cm8avdDppZmdeZFM=' \
  -H 'Content-Type: application/json' \
  -d '{
  "delete": true
}'

I had to add the port 8443 because otherwise it would fail with:

Failed to fetch.
Possible Reasons:

CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.

I took the API request from:
https://<ip>:8443/api/v2/?urls.primaryName=WP%20Toolkit%20REST%20API#/Installations.Backups/removeInstallationBackups

Customer should replace with their own IP or hostname.

 

[Giu]

Developers have checked this in Debian an Centos, but in both cases could use the API function. From the ticket:

curl -X 'DELETE' \
'https://<ip>:8443/api/modules/wp-toolkit/v1/installations/1/backups?files%5B%5D=<ip>.tld__2024-02-05T11_48_58%2B0000.zip' \
  -H 'accept: */*' \
  -H 'Authorization: Basic cm8avdDppZmdeZFM=' \
  -H 'Content-Type: application/json' \
  -d '{
  "delete": true
}'

I had to add the port 8443 because otherwise it would fail with:

Failed to fetch.
Possible Reasons:

CORS
Network Failure
URL scheme must be "http" or "https" for CORS request.

I took the API request from:
https://<ip>:8443/api/v2/?urls.primaryName=WP%20Toolkit%20REST%20API#/Installations.Backups/removeInstallationBackups

Customer should replace with their own IP or hostname.

Dear Peter, thank you very much.

Please see the STEPS TO REPRODUCE: i use the right port of course since this is not the only endpoint im using (all others so far work perfectly)
Please also ignore the CORS Failure issue thats not the main issue i have.

My Problem is that the api request works in terms of the route is there and there is no 400 or unauthorized error but it does not actually delete the desired backup file on plesk server

i have a loom video to show you the process in Postman can i send it to you in private for you to forward to the devs?

 

[Giu]

Hi @Peter Debik,

the issue is not yet resolved. But our Hosting Support as well Plesk support found out it's because of an encoding issue with the "+" sign (%2B) in the filename.