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

[WordPress Trac]

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

 Replying to [comment:65 azaozz]:
 > No, currently the auto-draft is created right before the user loads the
 Add New (post) screen. This is done so we have a post_ID for the brand new
 post and covers cases where the user may upload files or add tags,
 categories, post meta, etc. before they actually start writing the post
 (we need a post_ID to "attach" the meta). I'm not sure how that works
 through the API at the moment, or if it is possible at all. (That has
 nothing to do with auto-saving as there is nothing in the post to save
 yet.)

 OK, so I guess the first logical step in the workflow is:
 * User starts editing post, editor creates an autosave: `POST
 /wp/v2/posts/{id}/autosaves`

 > Yeah, I'm not sure why this was added to the API. IMHO we shouldn't be
 removing the functionality of the audit trail. This changes the purpose
 and functionality of revisions quite a bit...

 This was way back in https://github.com/WP-API/WP-API/pull/1110

 It does check the delete cap on revisions, so I'd make the argument this
 should be handled in the capability system instead. This is a conversation
 for another day though :)

 > > The proposed autosave process I'm talking about here would allow this,
 but in a very controlled way. Each change would still get a revision, but
 clients would now have the ability to temporarily persist changes while
 the user is still working on them.
 >
 > So basically you want to move the server auto-saving logic to the
 client. Not sure this is a good idea. The client can store "persistent
 backup data" by itself, for example in browser storage. This has nothing
 to do with server auto-saving. This is how autosaves work at the moment
 for non-API. There are server autosaves and client (in browser storage)
 autosaves.
 >
 > Once the client decides to push a server auto-save, the logic for it
 should be on the server.

 The reason we want the server involved is for cross-client purposes
 though: switching from web to mobile, restoring autosaves by others, etc.
 The only thing that really requires is storing the content of the autosave
 on the server.

 Now that I'm more familiar with the code, it doesn't seem like there's a
 huge amount of special casing anyway, so there's not really any complex
 logic that needs implementing on the client. Basically, just "if this post
 is a draft and I'm the post author, save directly, otherwise use
 autosaves".

 > This is mainly needed for post locking (not implemented through the API
 yet). It prevents data loss when more than one client tries to edit the
 same post. It also keeps the audit trail more consistent.
 >
 > [...]
 >
 > Perhaps but there are some edge cases like when there are several
 autosaves authored by different users that have edited the post at
 different times. Then it can get really messy :) Thinking that
 restoring/overwriting a post from a revision should always be user-
 controlled.
 >
 > The current logic is that the post author is "the boss" and other users
 that edit the post leave audit trail with their changes. This is essential
 for larger sites that have many authors and many editors.

 Right, my proposal is that we treat the post author the same in this
 sense, which would improve the audit trail I think. The question I don't
 have an answer for is whether this makes the UX or data harder to deal
 with.


 > Hm, `wp_save_post_revision()` doesn't wipe autosave revisions. It has
 some logic to keep a max number of revisions if they are limited by a
 plugin. The default is `-1` (unlimited). Also note that this logic
 specifically bypasses (keeps) autosave revisions, even when they are over
 the max.

 Ah, you're right, I'd misread the code there.

 > Also, the post is not an "unrelated resource" in this case.

 "Unrelated resource" in the sense of REST resources, not in the sense of
 WordPress resources; that is, one URL affects another.

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