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 | Owned by: | 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)
Change History (20)
#2
@
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
@
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
@
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 returntrue
) - Deleting a revision: does not require
force=true
; returnstrue
- Deleting a taxonomy term: requires
force=true
; returns the term object (by the logic above, this should returntrue
)
This ticket was mentioned in Slack in #core-restapi by jnylen. View the logs.
8 years ago
#7
@
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
#10
@
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.
#11
@
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.
#12
@
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 mentionforce=true
(this will save developers a Google search) - Add
'type' => 'boolean'
toforce
argument; this fixes passingforce=false
as a string - Fix the test suite and add more deletion tests
This is looking pretty good to me.
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.