[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves
WordPress Trac
noreply at wordpress.org
Tue Apr 24 12:00:36 UTC 2018
#43316: REST API: Support autosaves
-------------------------------------------------+-------------------------
Reporter: kraftbj | Owner: rmccue
Type: enhancement | Status: assigned
Priority: normal | Milestone: 5.0
Component: REST API | Version:
Severity: normal | Resolution:
Keywords: has-patch needs-testing needs-unit- | Focuses: rest-api
tests |
-------------------------------------------------+-------------------------
Comment (by danielbachhuber):
Replying to [comment:81 azaozz]:
> Hmm, possibly but the opposite is also true. An autosave revision is
always in a "post update" context and needs the same permissions. If we
are to copy/duplicate the functions we most likely will end up having to
update them in tandem with the same functions in the posts controller.
>
> Thinking that we can keep using the posts cap check for now. If it needs
changes and these changes are not needed for the autosaves, can copy the
functions then.
The current implementation is poorly coupled and confusing to follow. But,
given we can't use PHP traits, I don't have a reasonable alternative to
suggest at this point.
On a related note, if `WP_REST_Autosaves_Controller` subclasses
`WP_REST_Revisions_Controller`, is there a reason we're instantiating a
new object instead of calling the parent methods directly?
> Which `id` argument do you have in mind? The parent post ID in
`/wp/v2/posts/{id}/autosaves`? This seems to be the standard way of
creating a sub-item in REST. The same ID has to be set in the $request
(same as when updating a post). IMHO that makes sense when dealing with a
sub-item.
In a `POST wp/v2/posts/123/autosaves` request, the `123` value should be
referenced as `parent`, not `id`. The route is defined as
`/wp/v2/posts/{parent}/autosaves`.
Based on the current `test_update_item()`, it appears `id` is simply a
duplication of the `parent` value already present in the request.
Furthermore, the `id` returned is always different than the `id` passed.
This is incorrect from a technical perspective.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:82>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list