WordPress.org

Make WordPress Core

Opened 2 months ago

Last modified 8 weeks ago

#43817 assigned enhancement

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

Reported by: pento Owned by: flixos90
Milestone: 5.0 Priority: normal
Severity: normal Version:
Component: Post Formats Keywords: has-patch has-unit-tests
Focuses: rest-api Cc:

Description (last modified by 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

Attachments (1)

43817.diff (4.7 KB) - added by flixos90 2 months ago.

Download all attachments as: .zip

Change History (5)

#1 @pento
2 months ago

  • Description modified (diff)

#2 @flixos90
2 months ago

  • Owner set to flixos90
  • Status changed from new to assigned

I‘ll tackle this today.

@flixos90
2 months ago

#3 @flixos90
2 months ago

  • Keywords has-patch has-unit-tests added; needs-patch needs-unit-tests removed

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.

#4 @pento
8 weeks ago

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.

Note: See TracTickets for help on using tickets.