WP REST API: Stale Post Status on DELETE of Post

[timmydcrawford]

When issuing a DELETE against a post or page in the WP REST API, the response sends the original post object, which includes the post.status prior to the DELETE operation being completed.

The returned object, since the context is edit, shows the post.status, and it does not show the post with a status=trash, which is what I would expect after the DELETE operation completes. Instead, the status of the post prior to the DELETE operation is shown.

Additionally, when DELETE'ing a revision on a post or a page, the response sent back after the request simply says "true". Seems like the DELETE operations should return a similar response for all operations across the API.

This was intentional, as it allows you to restore the post to its previous state by sending that data back as a PUT. It is a tad confusing though.

The other response is when something cannot be trashed, and hence cannot be restored.

I'm not sure this is the best behaviour.

I can see the reasoning there, though yes it is a tad confusing. I suppose I just assumed that the object returned would always represent the current state in the database.

The return of "true" makes sense now that you have explained it. Perhaps we can wait and see what other feedback comes in around the topic to see if there is further confusion at all.

Replying to rmccue:

This was intentional, as it allows you to restore the post to its previous state by sending that data back as a PUT. It is a tad confusing though.

This doesn't make sense to me. The return should reflect the new state of the object. If I want to change the status back to published, I would set that before issuing a new PUT.

+1 we should send status: 'trash' when trashing a post/page.

There is also some inconsistency around how other DELETE requests behave and what they return:

• Deleting a post with force=true: returns the post object (by the logic above, this should return true)
• Deleting a revision: does not require force=true; returns true
• Deleting a taxonomy term: requires force=true; returns the term object (by the logic above, this should return true)

Based on the feedback left above, I have added a diff that changes the following responses from delete_item :

• Returns latest post object when DELETE is issued without force=true
• Returns true on force=true

This was previously discussed in ​https://github.com/WP-API/WP-API/issues/1260

We chatted in ​Slack briefly about this; true is too "bare" of a response, and doesn't give you any recourse for undoing. Returning an object instead is a little nicer, and what we originally discussed on the above ticket before we (likely, me) changed our minds.

Let's switch it back, and make it nice and extensible for forwards-compatibility.

Return { deleted: true, previous: { ... } } for permanent deletions

Added patch that does just that, and updates the tests appropriately.

Consistently require force=true

Return current value for trashed comments

Several fixes and improvements

Changes from 38494.3.diff to 38494.4.diff:

• Only call prepare_item_for_response on previous comment when it is needed
• Improve rest_trash_not_supported error messages with specific resource type and mention force=true (this will save developers a Google search)
• Add 'type' => 'boolean' to force argument; this fixes passing force=false as a string
• Fix the test suite and add more deletion tests

This is looking pretty good to me.

Missed a spot (/users/me)

In 39126:

REST API: Modify the structure of our DELETE responses to be more explicit.

Add the deleted property to the root of the Response object to communicate if the delete action was successful. Move the state of the resource prior to the delete request under a new previous property. As a result DELETE responses are now structured like so:

{ deleted: true, previous: { ... } }

Also includes helpful information to DELETE requests for resources that are not trashable.

Props timmydcrawford, rmccue, jnylen0.
Fixes #38494.