Make WordPress Core

Opened 8 years ago

Closed 8 years ago

#38494 closed enhancement (fixed)

WP REST API: Stale Post Status on DELETE of Post

Reported by: timmydcrawford's profile timmydcrawford Owned by: rmccue's profile rmccue
Milestone: 4.7 Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: has-unit-tests has-patch
Focuses: Cc:

Description

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.

Attachments (7)

DELETE-post.png (109.5 KB) - added by timmydcrawford 8 years ago.
return-updated-post-on-trash.diff (1.7 KB) - added by timmydcrawford 8 years ago.
38494.diff (9.3 KB) - added by rmccue 8 years ago.
Return { deleted: true, previous: { ... } } for permanent deletions
38494.2.diff (10.1 KB) - added by rmccue 8 years ago.
Consistently require force=true
38494.3.diff (10.2 KB) - added by rmccue 8 years ago.
Return current value for trashed comments
38494.4.diff (20.1 KB) - added by jnylen0 8 years ago.
Several fixes and improvements
38494.5.diff (22.3 KB) - added by jnylen0 8 years ago.
Missed a spot (/users/me)

Download all attachments as: .zip

Change History (20)

#1 follow-up: @rmccue
8 years ago

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.

#2 @timmydcrawford
8 years ago

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.

This ticket was mentioned in Slack in #core by jnylen. View the logs.


8 years ago

#4 in reply to: ↑ 1 @adamsilverstein
8 years ago

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.

#5 @jnylen0
8 years ago

+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)

This ticket was mentioned in Slack in #core-restapi by jnylen. View the logs.


8 years ago

#7 @timmydcrawford
8 years ago

  • Keywords has-patch has-unit-tests added

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 ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.


8 years ago

#9 @joehoyle
8 years ago

  • Milestone changed from Awaiting Review to 4.7

#10 @rmccue
8 years ago

  • Keywords needs-patch added; has-patch removed
  • Owner set to rmccue
  • Status changed from new to assigned

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.

@rmccue
8 years ago

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

#11 @rmccue
8 years ago

  • Keywords has-patch added; needs-patch removed
  • Type changed from defect (bug) to enhancement

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

@rmccue
8 years ago

Consistently require force=true

@rmccue
8 years ago

Return current value for trashed comments

@jnylen0
8 years ago

Several fixes and improvements

#12 @jnylen0
8 years ago

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.

@jnylen0
8 years ago

Missed a spot (/users/me)

#13 @rachelbaker
8 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.