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

 Replying to [comment:59 rmccue]:
 > I think the key thing we need to get at is defining what an "autosave"
 is.
 >
 > To me, the basic logic flow seems something like:
 >
 > 1. User starts editing: this creates a sort of "future revision" that
 they're working on, forked from the original post
 > 2. User makes some changes: this updates the "future revision" that
 they're working on
 > 3. User hits save: this "commits" the "future revision", and saves the
 original post
 > ...
 > IMO we need to get a concrete mental model of how this works,
 independent of the actual internal behaviour.

 Right. The current server logic is:
 Save:
 - User edits the post (a post is always edited as we start with an auto-
 draft).
 - User clicks Save.
 - The post is updated in the db.
 - At the same time a revision of the post is auto-created with identical
 content.

 When saving, the post is always updated and an identical revision is
 always created. Note that revisions (including autosave revisions) also
 provide an "audit trail". That's another reason revisions are not editable
 directly by the users.

 Auto-save:
 - User edits the post.
 - Periodically the client checks for changes. If there are any, the client
 saves the post.
 - The server has different logic for this save:
  - If the post is a draft, it is updated in the db without creating
 another revision.
  - If the post is a draft but the post author is different than the
 current user, the post is not updated and a revision is created.
  - If the post is published a revision is created without updating the
 post.
  - When creating a revision following the above logic, if an autosaved
 revision already exists, it is updated instead of creating another
 autosaved revision. Additionally if the post content is identical to the
 new content that is being auto-saved, the previous autosave revision is
 deleted to prevent having a redundant revision (i.e. if the update of the
 previous autosaved revision will make it identical to the current post,
 there is no need of it).

 When auto-saving the post may be updated (most common case), or a revision
 may be created, updated or deleted.

 > The flow I'm thinking would be something like:
 >
 > * User starts editing: `POST /wp/v2/posts/{id}/revisions` creates a new
 "future revision"
 > * User makes some changes: `PUT /wp/v2/posts/{id}/revisions/{rev_id}`
 updates this "future revision"
 > * User hits save: `POST /wp/v2/posts/{id}/revisions/{rev_id}` commits
 the "future revision"

 This differs a lot from the current workflow. Generally when auto-saving
 in any app (not WP), the actual item is being updated. In WP the logic is
 more complex as we have revisions and states, draft vs. published. If we
 create and update a revision directly instead of updating the current
 item, it will be unexpected.

 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.

 I don't mind changing how saving and auto-saving works in WP, but we'll
 need to come up with a nice workflow. Unsure if now is the best time as
 this ticket is urgent, but if you think we can manage it in the next 2-3
 days, I'm all for trying :)

 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'm not sure the current behaviour in [attachment:43316.12.diff] makes
 sense though; you POST to /autosaves, which updates the actual post?

 Yeah, the auto-saving logic is more complex. It may update a draft post
 without creating a revision. See the above description.

 > Also, I am -1 on this "detect how much has changed" idea; that seems
 like a pretty fundamental change, and not one that we should make in the
 context of this issue.

 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.

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