REST API: Include 'formats' attribute on Post Type resource

[pento]

We need to know which post formats we can display when editing a post in Gutenberg.

While supported post formats are technically a theme setting, not a post type setting, post type is the closest matching resource that we make available.

See: ​https://github.com/WordPress/gutenberg/pull/6301

[flixos90]

I‘ll tackle this today.

[flixos90]

43817.diff​ adds a formats field to post type objects.

@pento I mostly followed your approach from the GitHub PR, with a few adjustments:

• When fetching the post formats, I added support for the case where someone does add_theme_support( 'post-formats ). In that case, all post formats are supported.
• When fetching all post formats, I added a whitelist check against the available post formats, so that random strings defined as post formats are stripped from the list.
• In the schema description, I added a note that these post formats depend on the post type and the current theme.
• In the schema, I added definition for the items in the post formats array.
• I added three tests: One for add_theme_support() being called without extra parameters, one for add_theme_support() being called with a subset of post formats, and one for a post type that doesn't support post formats.

A few additional thoughts from my end:

• I don't really like that we put theme-specific data into a post type controller, but we don't have a themes controller, and even if we did, it would be inconvenient to make two database requests for this matter. Since one can still check for only the post type support for post formats as necessary (via the supports field), I can accept this as a necessary evil. :)
• I'm not sure about how the standard post format. I went with the same approach like your PR for now, but I'd prefer if we never included it in that list or alternatively also include this when the post type doesn't support formats (as sole value in the array). Because that format is always supported. The UI could still make a check like "only show post formats UI component if more than 1 format are supported), so it would still be feasible from a usage standpoint, but more logical from a data standpoint.

[pento]

Thanks for this, @flixos90.

@danielbachhuber has done some more thinking/work on this idea (​PR), and I think we may move towards a more general data source for grouping all of the "theme supports" data together.

Gutenberg's implementation will probably just expose the necessary data somewhere, but I quite like the idea of using this as the first stage of a themes controller. I really, really wouldn't want this to get bogged down in trying to implement every conceivable part of a themes controller, particularly as Core has no use for a fully featured themes controller at this stage. I think a reasonable first step is to expose information about the current theme, in the vein of WPCOM's ​themes/mine endpoint.

If this single read-only endpoint is implemented with forward compatibility in mind (for example, future requirements may include listing all themes installed, searching w.org themes, changing themes, and maybe even editing theme files 😉), I have no problem with that landing in 5.0, and iterating on it as we need to expend it.

[danielbachhuber]

Closing in favor of #45016