Add front-end revision browsing

[Shelob9]

This patch will add a live-updating revision browser to single post view when the current user can edit posts.

This feature requires the post and post revision routes of the WordPress REST API, as well as the JavaScript client for the REST API.

Here is demo of this patch:

Currently this is a functional prototype, as a plugin -- ​https://github.com/Shelob9/revisions-browser -- prepared by myself with guidance from @adamsilverstein and contributions from @mrahmadawais + @websupporter + @kadamwhite + @circlecube

[westonruter]

Actually, this wouldn't depend on the REST API. An alternate implementation can be powered by customizer (even on frontend) with changesets, selective refresh, and a WP_Customize_Post_Setting (from Customize Posts). See #31088 and ​https://github.com/xwp/wp-customize-posts/issues/17

[Shelob9]

Patch from ​https://github.com/WordPress/WordPress/pull/248

[Shelob9]

Some feedback on UI via twitter started by @markjaquith :

I agree with Mark that hiding previous and next is odd. I will refresh to make them unlcickable or something instead.

@mrahmadawais and I discussed arrows, but felt it didn't match core UI, but we could be wrong.

[westonruter]

I also want to mention that Selective Refresh in the customizer has JS hooks that themes and plugins can use for ensuring that any dynamic content elements will get set up properly when refreshed. Consider content that has emoji, media elements, and other elements that need JavaScript initialization. Selective Refresh also already has the construct for associating an a partial (e.g. title or content) with a given selector. Just want to avoid reinventing the wheel for something that already exists.

[westonruter]

Two more concerns:

• The logic in placeRevision doesn't account for themes that have more than the_content() in the .entry-content element. Twenty Sixteen also includes the author bio here.
• Using the content as rendered by the REST API will not account for shortcodes that contain content that is contextual based on where the post/page appears on the site. Since the REST API call is stateless, it won't render knowing if the content is to appear on the homepage, on an archive, or on a singular template. This may not be specifically a concern here if the intention is for the revisions to only be viewable on the singular template, but it seems ideal if the revisions could be viewed anywhere the post appears on a site.

Sorry to keep harping on this, but these are all challenges we've been working hard on in the customizer with changesets, selective refresh, and the Customize Posts feature plugin.

I think there definitely is a place for using the REST API here, and that is to get the raw data. The responsibility to render the data, however, I feel should be left to the customizer.

[mrahmadawais]

Following the conversation before jumping back into the code. @Shelob9 where do we stand with this now? I think not everyone needs this, so there should also be an option to enable it whereas it should come disabled by default.
Looking forward!

[karmatosed]

I can see some use cases for this, but tend to agree that I don't think everyone would need this functionality. If that's enough people, then it seems a good idea. Is there a plugin out there that does anything similar? I ask as that would be good as a use case to see the demand for this.

[flixos90]

Related: #40510