Tracking: Core data revisions follow ups

[ramonjd]

A list of tasks/bugs to address related to the following PR:

• Revisions: add new selectors to fetch entity revisions #54046

Tasks/Bugs

• Bug: calling getRevisions() then getRevision replaces current items state. Core data: harmonize getRevision selector and resolver function signatures #56416
• Bug: calling getRevisions() then getRevision() doesn't return cached store item (makes an unnecessary API call) Core data: harmonize getRevision selector and resolver function signatures #56416
• A follow up PR can use getRevisions for global styles revisions as per the above diff and potentially deprecate getCurrentThemeGlobalStylesRevisions Global styles revisions: migrate API call to getRevisions()  #56349
• Extend WP_REST_Global_Styles_Revisions_Controller REST API class to handle fetching individual revisions: Global styles revisions: add route for single styles revisions #55827
• Add support for other post types Core data revisions: extend support to other post types #56353
• Remove hard-coded constants for revisions supports Core data revisions: remove hardcoded supports constant #56701
• Core data: selectors return stale data despite different query parameters #56355

Related

• Tracking: Style Revision UX Improvements #55776

[ramonjd]

Add "supports" information to the view context for /types or at least get it from the backend somehow

Dumping some research here.

Adding revisions support info to the /wp/v2/types?context=view response is trivial via a rest_prepare_post_type filter hook.

/**
 * Returns post type supports data in the request's view context.
 *
 * @since 6.5.0
 *
 * @param WP_REST_Response $response  The response object.
 * @param WP_Post_Type     $post_type The original post type object.
 * @param WP_REST_Request  $request   Request used to generate the response.
 */
function gutenberg_rest_prepare_post_type_add_support( $response, $post_type, $request ) {
	if ( 'view' === $request['context'] ) {
		$supports = get_all_post_type_supports( $post_type->name );
		if ( isset( $supports['revisions'] ) && true === $supports['revisions'] ) {
			$response->data['supports']['revisions'] = true;
		}
	}
	return $response;
}

add_filter( 'rest_prepare_post_type', 'gutenberg_rest_prepare_post_type_add_support', 10, 3 );

The question is: what's the best path to Core migration? 🤔

Do we want to return revision supports info for all /wp/v2/types?context=view get requests?

If yes...

...then we could modify get_item_schema() and allow supports.revisions in view context always.

The next question is, is this okay out of the edit context? I'm not sure but I can't see why not.

And do we have to worry about returning data that folks don't expect? We're not removing data, and the structure would mirror the supports structure in the edit context.

If no...

We could ask for supports information via a request parameter or something? E.g., /wp/v2/types?context=view&include_supports=revisions

We'd need to modify WP_REST_Post_Types_Controller to add this data to the response based on the request parameter.

It seems undesirable to add a non-standard parameter in this way. And not great for maintenance.

Edit: #56701 addresses this issue by letting the server decide :)

[ramonjd]

Closing this issue now, since all directly related issues are resolved.

#56355 was an existing core data issue and not related to revisions.