Use post revisions as storage backend for post/postmeta changes

[westonruter]

There is currently a duplication of pending post data in the customizer vs the post editor. Pending changes made via the edit post screen get stored in a revision whereas the changes made via the customizer get embedded into a changeset. Ideally the pending changes in changesets should get exposed as autosave revisions post editor to continue editing. When editing a post in the customizer and you leave without publishing, those post changes are stored in a changeset. If you go to the editor, you will not see any reference to those changes. It would be helpful to users to list out the posts in pending changesets that they could “import” as an autosave revision to continue editing.

For that matter, should changesets not store the full post content in the changeset but always store it in such post revisions? The underlying setting value could be the ID of the revision, where the js_value then returns full hydrated content.

See https://wordpress.slack.com/archives/core-customize/p1484595235001026

[mohdsayed]

Lets do it along with #338 as its related.

[mohdsayed]

For that matter, should changesets not store the full post content in the changeset but always store it in such post revisions? The underlying setting value could be the ID of the revision, where the js_value then returns full hydrated content.

@westonruter Meaning a changeset would be created however would not contain the full post settings, but a revision would do? When would the revision be created, each time we click on the preview button? Can you elaborate little more please.

[westonruter]

@sayedtaqui what I mean is that every time that a change to a post is made in the customizer, and the changeset is updated… instead of putting the post data changes into the changeset itself, the changes could instead get routed to the post revision instead. So instead of a changeset containing data like this:

{
    "post[page][123]": { "value": { "post_title": "About", … } }
}

a post would look like:

{
    "post[page][123]": { "value": 987 }
}

Where 987 is the post ID for the revision that actually then stores the value in the DB.

However, the full post data object should still be sent back to the client for the setting's value and not just the post ID, and so that is where the WP_Customize_Post_Setting::js_value() comes in, to prepare the underlying data (the post revision ID) for JS by expanding it to the full object. When the post setting is changed on the client, it will send back the full object value which would then need to get ultimately turned back into a revision post ID by WP_Customize_Post_Setting::sanitize() for storage in the DB.

Maybe! 😄 All of this is experimental and I am not 100% confident it will work.