[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