[wp-trac] [WordPress Trac] #43316: REST API: Support autosaves
WordPress Trac
noreply at wordpress.org
Wed Mar 7 17:47:46 UTC 2018
#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 | Focuses: rest-api
-------------------------------------+-----------------------
Comment (by joehoyle):
From what I gather this means PUTing to `/wp/v2/posts` with `{
is_autosave: true }` will not necessarily update the item but could
instead actually create a new autosave revision for the user. I think this
is a very bad idea, because a PUT update to an object should update the
object. Breaking that fundamental assumption is creating inconsistent
design. If doing:
{{{
var post = new wp.api.models.Post();
post.set( 'title', 'autosave test' );
post.save();
post.set( 'status', 'publish' );
post.save();
post.set( 'title', 'updated autosave test' );
post.save( { is_autosave: true } );
}}}
actually creates a new post in the DB, and that can be fetched via
`/revisions` then it doesn't make sense (IMO). We should be creating a new
revision (with an autosave flag if needed) at `/revisions`. The Core
behaviour is kinda weird (updates unpublished posts, but creates auto
saves for published) which I think would be best left to client
implementation to handle, rather than baking this into the endpoint. It
breaks assumptions around PUT to `object` causes an update, POST to
`/posts` creates an object, etc.
I think the idea of using `autosave` for the post_type might be been
discarded, but if not I'd say similar things about that. No need to use an
existing field, I think it's likely to just increase complexity rather
than a dedicates field on `/revisions` for it.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43316#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list