[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves
WordPress Trac
noreply at wordpress.org
Tue Apr 24 12:31:08 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 azaozz):
Replying to [comment:82 danielbachhuber]:
> 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?
Think this has been there since the first patch, perhaps @adamsilverstein
would know more. I have no preference either way.
> 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.
Right. The problem here is that `(post_)parent` is a property of WP_Post
and the API shouldn't be overwriting it, especially for `pages`. Taht's a
UI setting for them. It seems this is another bug in the API. How would
that work when a draft page with a (real) post_parent is autosaved and the
actual page row is updated in the db? Would the page's parent be
overwritten?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:83>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list