Framework: Improve how post revisions are handled

[gziolo]

Issue Overview

When fixing #3167 with #3233 we opened a discussion on how to handle post revisions in the long run:

While it doesn't appear that it will prevent content filtering from being run, an alternative solution to limiting the size of the version history payload in the upcoming 4.9 release is to specify only the necessary fields on the API request:
e.g. /wp/v2/posts/4462/revisions?_fields=id

See: https://core.trac.wordpress.org/ticket/38131

@aduth: Yes, that would be one of the possible ways of improving performance here. I think it would still need more work to make sure that REST API call is triggered every time new post's content is saved. At the moment information about revisions doesn't get updated whenever a post is saved. This PR addresses it, too.

Yes, I'm aware of that, I'm just saying we may want to load the "last_revision_id" and "revision_count" in a separate endpoint instead of adding these as extra fields to the default POST endpoint. Because this change will change the result for everything and not only Gutenberg.

@youknowriad: it is another solution that would work. Again, we would need to find a way to refresh data each time post is saved.

@pento post data structure contains a list of categories or tags, why this is not the case for revisions? I'm sure there are reasons like we don't want to fetch everything and ruin performance. According to the documentation, we can pass context argument where one of the values is edit. It seems like a perfect match to our use case. So I would be happy to explore adding revisions to the REST API and enable it by default only in edit context.

Let's discuss here how we can improve the current solution - https://github.com/WordPress/gutenberg/pull/3233/files#diff-9dfc2b70ad1c71918441461179054b0bR386. REST API endpoint for post data is extended to serve also information about revisions. The downside of this approach is that it is now added to every REST API call that fetches post data.

[mtias]

Marking this high priority for merge proposal.

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[danielbachhuber]

@gziolo Is this issue addressed by #6257, or are there other specific problems we need to address?

[gziolo]

@danielbachhuber, I don't think it #6257 is directly related to this issue.

We had this issue where all revisions were loaded and cached inside HTML output just to read the url of the last revision and the total count of revisions. I added a hook which adds those 2 values to the post object which didn't seem ideal, but solved all performance issues. See https://github.com/WordPress/gutenberg/pull/3233/files#diff-9dfc2b70ad1c71918441461179054b0b in particular. This issue exists to find an alternative solution which would be included also in WP Core.

[danielbachhuber]

I've opened a core ticket for this: https://core.trac.wordpress.org/ticket/44321

Whatever conclusion we identify there, we can apply here in the interim.