[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves

[WordPress Trac]

#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 adamsilverstein):

 Hey @danielbachhuber thank you for your feedback! Mostly I think you are
 right on, and I appreciate the fresh perspective. Here are some responses
 to specific points you raise...

 > If we agree these are two distinct goals...

 Yes, I agree we need two distinct endpoints almost as you describe them,
 except I think the revisions endpoint can already delete revisions?

 > It seems magical to create a revision based on some algorithm applied to
 the saved data. I'd think this logic makes more sense client-side; let the
 client decide whether to perform a full save or an autosave.

 Yes, it is somewhat magical I agree :) In a good way. WordPress decides
 when you have made enough of a change that more than an autosave is
 warranted. this would happen if you were updating your post with any
 client and save you from disaster if you lost your single autosave. Also,
 this lets us save revisions for published posts without updating them,
 which currently is not possible.

 > Similarly, if revisions are only created when a post is fully saved,
 then I think it makes sense to keep that distinction in the client-side UX
 (i.e. you hit the "Save" button to create a revision).

 Here we are proposing that revisions are created whenever an autosave
 occurs and the content has changed not insignificantly. This expands the
 definition of autosaves and lets WordPress automatically track your
 changes over time versus keeping only a single backup (especially for
 published posts). This protects users by capturing a history of changes. A
 filter is provided to disable this behavior.

 Perhaps clicking 'update' or 'save' could remove all of the intermediate
 revisions so we can avoid clogging up the posts table with revisions. Is
 this part of your concern?

 What if you want to save your work in progress when updating an already
 published post?

 > `GET /wp/v2/posts/<post-id>/autosaves/<user-id>`

 Shouldn't this endpoint match revisions? `GET /wp/v2/posts/<post-
 id>/autosaves/<autosave-id>`

 > For a fun thought experiment, or dark rabbit hole, imagine revisions and
 autosaves for individual blocks :)

 Would you be surprised if I told you I've already been thinking about
 this?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform