REST API: Expose theme_supports data through a minimal theme controller

[danielbachhuber]

In order to correctly render parts of its UI, Gutenberg needs access to the data from post-formats and post-thumbnails:

$formats = get_theme_support( 'post-formats' );
$formats = is_array( $formats ) ? array_values( $formats[0] ) : array();
$formats = array_merge( array( 'standard' ), $formats );
$site_info['theme_supports']['formats'] = $formats;

$post_thumbnails = get_theme_support( 'post-thumbnails' );
if ( $post_thumbnails ) {
	// $post_thumbnails can contain a nested array of post types.
	// e.g. array( array( 'post', 'page' ) ).
	$site_info['theme_supports']['post-thumbnails'] = is_array( $post_thumbnails ) ? $post_thumbnails[0] : true;
}

In ​wordpress/gutenberg#6318, this data landed on the REST API index.

As mentioned by @pento in https://core.trac.wordpress.org/ticket/43817#comment:4, the ideal location for this data would be a read-only Theme object. However, we may or may not have the time to accomplish this by our deadline.

[danielbachhuber]

#43817 was marked as a duplicate.

[kadamwhite]

I'd be very hesitant to add this to the index as a matter of expediency. If we need another endpoint for theme settings, let's absolutely do that mindfully. 5.0 and Gutenberg are meant to be the foundation for stable future iteration, we need to make that foundation solid.

[danielbachhuber]

Replying to kadamwhite:

I'd be very hesitant to add this to the index as a matter of expediency. If we need another endpoint for theme settings, let's absolutely do that mindfully. 5.0 and Gutenberg are meant to be the foundation for stable future iteration, we need to make that foundation solid.

What do you think is realistic to do in the next 4-6 weeks? We need something in core, as all PHP files will be removed from the Gutenberg plugin before this is finalized.

Personally, I would prefer a stripped-down, read-only Themes controller if we can track down engineering resources to put it together. Putting the data on the index would be the worst-case path of least resistance.

[kadamwhite]

Renamed based on discussion above & in slack clarifying the desired approach.

[danielbachhuber]

@desrosj said he'd pick this up today in Slack.

[danielbachhuber]

Worth noting too: we may be able to steal some code from ​https://github.com/WP-API/wp-api-plugins-themes-endpoints.

The ideal endpoint is something like /wp/v2/themes/current (I don't have a strong preference on the naming of 'current' or otherwise), and it would only expose the limited fields we need right now.

[kadamwhite]

Updates from discussion in Slack and on GitHub (​https://github.com/wordPress/gutenberg/pull/10518):

• For 5.0, the theme controller need not expose anything but the active theme, and whether that theme supports post formats and thumbnails.
• The only new endpoint will be /wp/v2/themes. We will query for active theme by passing a ?status=active query parameter. themes?status=active will return an array containing an object representing the active theme.
• For 5.0, we will not return any response on /wp/v2/themes if the ?status=active query is omitted, and no other themes than the active one will be represented in the endpoint.
• Endpoint access is limited to authenticated users with edit_posts.

The PR linked above implements this endpoint for Gutenberg; after merge, it can be moved here for core merge.

[desrosj]

The theme controller was merged in ​de2fab7. 45016.diff​ is a patch for moving the bare-bones theme endpoint into Core against the 5.0 branch. It should also apply to trunk cleanly.

I wasn't sure about including the tests/qunit/fixtures/wp-api-generated.js changes in the patch vs. those being made pre-commit. That file was automatically updated.

[adamsilverstein]

I wasn't sure about including the tests/qunit/fixtures/wp-api-generated.js changes in the patch vs. those being made pre-commit. That file was automatically updated.

The updates to this file look correct and can be included in the commit. These are generated during the phpunit run and later used by the REST API tests to provide mocked responses. Since you added an endpoint it is expected the fixture would be updated.

[desrosj]

Fix inline documentation description for WP_REST_Themes_Controller_Test::$themes_route

[desrosj]

Remove gutenberg text domain.

[kadamwhite]

In 43734:

REST API: Introduce themes endpoint to expose theme-supports values for the active theme.

In order to correctly render parts of its UI, the new editor needs to be aware of the active theme's post-formats and post-thumbnails support. This data is exposed by querying for the active theme on a new /wp/v2/themes endpoint for sufficiently privileged users.

props desrosj.
Fixes #45016.

[kadamwhite]

Reopening for trunk.

[kadamwhite]

In 43735:

REST API: Add new class file and tests missed in [43734].

See #45016.

[desrosj]

​https://github.com/WordPress/gutenberg/pull/10477 adds responsive-embeds to the theme_supports property of the themes endpoint. Incoming patch to add this to core.

Test build on Travis: ​https://travis-ci.org/desrosj/wordpress-develop/builds/443413062

[danielbachhuber]

Replying to desrosj:

​https://github.com/WordPress/gutenberg/pull/10477 adds responsive-embeds to the theme_supports property of the themes endpoint. Incoming patch to add this to core.

Related #45125

[desrosj]

Ignore 45016.4.diff​. I included it in the patch on #45125.

[jeremyfelt]

In 43985:

REST API: Introduce themes endpoint to expose theme-supports values for the active theme.

In order to correctly render parts of its UI, the new editor needs to be aware of the active theme's post-formats and post-thumbnails support. This data is exposed by querying for the active theme on a new /wp/v2/themes endpoint for sufficiently privileged users.

Merges [43734], [43735] to trunk.

props desrosj.
Fixes #45016.