[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 azaozz):

 Replying to [comment:63 rmccue]:
 > Replying to [comment:62 azaozz]:
 > > Right. The current (non-API) logic is:
 > > Save:
 > > - User edits the post (a post is always edited as we start with an
 auto-draft).
 >
 > It doesn't seem like this is necessarily true; wp_create_post_autosave
 shortcircuits if the post is the exact same, so it seems like an autodraft
 can only be created once there is a change?

 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.)

 > We do already provide the functionality to delete revisions via the REST
 API, so they're not really usable for an audit trail, but rather as a sort
 of long-term undo.

 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...

 > Their (revisions) primary use is to see the evolution of a post over
 time.

 Perhaps we should look at removing the delete revision endpoint. It makes
 them "unreliable" and their purpose becomes "to maybe see the evolution of
 a post over time, or maybe see only some of it, or not see anything".

 If I understand the general logic behind a REST API correctly, it should
 care about the "client" and the "view", not overtake the server "business
 logic". The client is generally "untrusted" in handling low level logic,
 that should be handled by the server. There is a good reason why revisions
 cannot be deleted from the current (non-API) UI :)

 I'm aware that revisions can be limited or disabled altogether but that is
 a "server logic" decision on per site basis. Also note that this doesn't
 disable autosave revisions.

 > Right now, there's no way to say "update this post, but don't create a
 revision". The basic thing we want for autosaves is the ability to do
 this, but providing this functionality so allows any REST API client to do
 so, which I'm a little uncomfortable about (and which would totally
 destroy any concept of revisions being usable as an audit trail, since now
 changes can be made without being recorded anywhere).

 Right. Thinking more about this, it should stay this way (no way to save
 without a revision). Changing that would make revisions totally
 untrustworthy.

 > 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 now autosaves work at the moment for non-
 API. There are server autosaves and client (in browser) autosaves.

 Once the client decides to push a server auto-save, the logic for it
 should be on the server.

 > The main thing that seems strange is the special-casing of the post's
 author. If we can remove that special-casing, I think the rest is
 reasonably straightforward to model. Is there a reason for this special-
 casing?

 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 trial more consistent.

 > If clients don't want to use the autosave process, then they can keep
 using the existing process, they'll just potentially end up with lots of
 revisions. I see this autosave concept as similar to database
 transactions: you queue up and persist a bunch of changes, then commit
 them all in one revision at once. This preserves the process of always
 creating revisions, while reducing the amount of noise.

 Yes, this is a possible saving workflow. A client can decide to not use
 the server autosave process and instead store backups locally. Then "once
 in a while" sync these local backups with the server. Few years ago there
 was an idea to make the non-API autosave work this way too. It didn't
 materialize as browser storage was somewhat unreliable/limited back then.

 > > This will generally mean that a post will always have an autosaved
 revision. That revision will usually be more recent than the post content,
 and the user will have to manually "restore" that autosave revision before
 continuing to edit. That's not a good UX :) This can happen now too, but
 is relatively rare.
 >
 > The client can implement the functionality themselves to automatically
 "restore" the autosave. This is essentially what we're doing already with
 the special-case for the post author, but editors can do it in a more
 consistent way.

 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.

 > > Also, the part: "User hits save: `POST
 /wp/v2/posts/{id}/revisions/{rev_id}`" would be an actual save, i.e. `POST
 /wp/v2/posts/{id}`.
 >
 > I was thinking this would be a cleaner way of the client actually
 "committing" the autosaved changes. It avoids the problem where an update
 to a somewhat-unrelated resource (the post) affects a bunch of others (all
 the autosaves). This is the current behaviour though:
 `wp_save_post_revision()` is called by `wp_insert_post()`, and it wipes
 out all the autosaves.

 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.

 Also, the post is not an "unrelated resource" in this case. Generally we
 can view a WordPress post as consisting of several rows in the db: the
 actual post row plus all the revisions rows. They are the same "resource"
 from logical point of view. It doesn't matter how exactly the "post
 resource" is stored. As @schlessera mentions above, at some point the
 storage schema may change and perhaps post revisions may be stored as
 incremental diffs in the actual post row in the db. Well, at last in
 theory :)

 > > This is a "disaster recovery" for a rare edge case that was planned
 for the current (non-API) autosave too. We can remove it if need be.
 >
 > If it's a global change, that makes sense; I'd rather track and
 implement it separately I think :)

 Sure, lets separate that. But maybe first get the server autosaves
 logic/endpoint in.

 > (Sorry for the long post again; this is a complex topic.)

 Yeah, sorry for the long post too, very complex topic indeed :)

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