Only display featured image UI when theme supports it too

[danielbachhuber]

Description

Ensures the "Featured Image" UI only displays when the theme supports post-thumbnails too.

Fixes #2523

How has this been tested?

Using Twenty Seventeen, here's the UI that normally displays:

Then, add the following code snippet to a wp-content/mu-plugins/local.php file:

add_action( 'after_setup_theme', function(){
	remove_theme_support( 'post-thumbnails' );
}, 100 );

The "Featured Image" will no longer display:

Types of changes

My code ensures PostTypeSupportCheck also respects the theme's post-thumbnails setting. It introduces post-thumbnails=>true on the site index for exposure through the REST API.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[gziolo]

Can we use more targeted expectation in here to ensure it properly renders foobar text? One of the ways of doing it is to use toHaveText matcher.

[gziolo]

I haven't tested but the code looks good 👍

[aduth]

This must be updated to pass the second argument as an array, or will fail master build. (#6247)

[aduth]

Why does PostTypeSupportCheck need to be handling this exception? If they're truly intentionally different, why lump them to be considered together? Should it be up to the consuming component to check for both the post type and theme supports? Notably, I see this as being part of the reason PostFeaturedImageCheck exists as a standalone component, so it can become:

function PostFeaturedImageCheck( props ) {
	return (
		<ThemeSupportCheck supportKeys="post-thumbnails">
			<PostTypeSupportCheck { ...props } supportKeys="thumbnail" />
		</ThemeSupportCheck>
	);
}

[danielbachhuber]

ThemeSupportCheck is a good suggestion. I'll open a new PR with a different implementation.

[danielbachhuber]

Closing in favor of #6541