[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves
WordPress Trac
noreply at wordpress.org
Fri Mar 30 12:56:24 UTC 2018
#43316: REST API: Support autosaves
-------------------------------------------------+-------------------------
Reporter: kraftbj | Owner:
Type: enhancement | Status: new
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):
@danielbachhuber thanks for the review! :)
Yes, as @adamsilverstein points out above the shape of the data is
identical - it is a post that is being saved (hence my idea to use the
same controller/endpoint). That includes all of the post "properties",
post_type, post_status, post_parent, etc.
If we are using `WP_REST_Posts_Controller::update_item()` to do both saves
and autosaves, we need some sort of a flag that is different than the post
properties, see 43316.1.patch that uses `is_autosave`.
> Generally, in thinking about this more, I'd be leaning closer to one
revisions endpoint that covers past and future revisions. We could handle
write operations through /wp/v2/posts with special status attribute
handling.
Right, thinking the same.
> Even taking a step back from this, it seems like it might make sense to
produce a design document capturing all of the detail on how the
endpoint(s) should behave, and write code once that's determined.
It's a bit too late for this :) The REST API is actively being used now,
and the lack of autosave support means it is creating tens or even
hundreds of revisions when it shouldn't. It's not uncommon to see 120-150
revisions for an average length post :(
Generally autosaves are "real" saves but the "business logic" on the
server is a bit different. It depends on post_status, post_author vs.
current_user, and post_lock (not implemented in the API yet!). It also
depends on decisions in some plugins.
> Has this idea (auto-creating a revision when an autosave is
significantly different) been validated as useful in the real world? Given
the tendency of revisions to bloat the database...
Yes, it has. It protects the users in a rare edge case when post_content
may "disappear" as a result of a user (or plugin/network?) error. Was
planning to add that to the non-API autosave too, have heard of many
disastrous cases over the years.
> > What if you want to save your work in progress when updating an
already published post?
> We need future revisions! But yeah, interesting question.
Perhaps we can even look at reducing the size diff that will trigger
creating a revision when autosaving a published post. But that is not
super urgent. We can adjust how this works when we have more "real life"
data.
@adamsilverstein @aduth @danielbachhuber @flixos90 @schlessera I'm going
to refresh 43316.1.patch over the weekend (yeah, I know it's a holiday,
but this cannot wait any longer) and then commit it, if no other
objections.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list