[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves
WordPress Trac
noreply at wordpress.org
Fri Apr 6 05:29:27 UTC 2018
#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]:
> > > 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.
One other question here: how does the autosave actually get applied to the
post?
From what I'm understanding here, it seems like it doesn't ever get
applied/committed. Rather, the editor just runs a real save with the full
content, which doesn't touch the autosave process at all. When the user
makes another change after that, the editor then starts autosaving stuff
again. Is that accurate?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:68>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list