Support for custom taxonomies

[afercia]

#1276 is going to add support for pages and custom post types.
Custom post types can use custom taxonomies (custom "categories" and "tags") and Gutenberg is already providing a UI to add hierarchical and non-hierarchical taxonomies.

In the case of custom post types, the UI should fetch, display, and allow to set the custom taxonomies.

For example, in the current WordPress implementation the tags suggestions correctly fetches custom post type non-hierarchical taxonomy. To see an example of how this works:

• enable Jetpack
• enable Jetpack custom post types
• create some "Portfolio" (Projects) CPTs
• create some Project Types and Project Tags
• edit a Project
• see how the metaboxes display the Project Types and Project Tags
• see how the Project tags suggestions list displays the Project Tags
• the "Choose from the most used tags" tag cloud works just when there are some Project Tags that are actually used, so first add some Project Tags to a Project, save, and then it works

[sbangnielsen]

The wording of this issue gives me the impression that Gutenberg will only support custom taxonomies for custom post types – not for regular posts.
If so, why?

[westonruter]

@sbangnielsen Custom taxonomies should also be recognized for builtin post types. I don't think @afercia intended to exclude them in his writeup.

[youknowriad]

API issue here. We need to access the custom taxonomies using the REST API even if they don't have the show_in_rest flag

[danielbachhuber]

We need to access the custom taxonomies using the REST API even if they don't have the show_in_rest flag

@youknowriad This is an interesting conundrum. Can you clarify your assumptions in greater detail? Presumably, this applies to custom post types as well.

[youknowriad]

If we want to retrieve the custom taxonomies and the custom post types to display a UI/manage them in WP-Admin, we'd have to retrieve all the entries even the ones that have "show_in_rest" to false.

How can we use Gutenberg for a CPT with "show_in_rest=false" right now? It can't work unless we remove this restriction.

The more we move things to client-side, the more we'd face this issue.

[danielbachhuber]

If we want to retrieve the custom taxonomies and the custom post types to display a UI/manage them in WP-Admin, we'd have to retrieve all the entries even the ones that have "show_in_rest" to false.

I understand your perspective, certainly. I think you've stumbled upon a significant conceptual issue worth significant discussion, not a mere technical implementation issue. I don't have any suggestions for resolution at this point, need to give the issue some thought.

cc @rmccue @rachelbaker @joehoyle for visibility

[joehoyle]

We need to access the custom taxonomies using the REST API even if they don't have the show_in_rest flag

I think this is a good case for defaulting show_in_rest to inherit from show_in_admin if it's not explicitly set. It's worth saying, though I image already assumed, that we absolutely should not ignore show_in_rest to privilege Gutenberg, but instead improve the defaults of the REST API. As fas as I see there's no special casing needed for Gutenberg, we should really just be looking at better defaults for the REST API as one, of many, potential editorial tools that can be built.

[youknowriad]

I don't think this is a special case for Gutenberg but I don't think this should be a choice (or maybe it should be always the same as show_in_admin) because even if we disable show_in_rest explicitly for a custom taxonomy but its show_in_admin is true, I still expect this taxonomy to show up in my editor and other WPAdmin UI pages (that retrieves the taxonomies using the REST API)

[nylen]

Can we get some examples of common taxonomies or post types that have show_in_rest => false but that we want to see in Gutenberg?

Do these common post types and taxonomies have show_in_admin => true? If so, defaulting the value of show_in_rest to show_in_admin may be a viable resolution.

Does exposing them via the REST API expose information that site owners wouldn't expect? If so, then this probably needs to be handled within the plugins that create the post types and taxonomies in question (this was the plan behind the current implementation of these API flags).

[danielbachhuber]

Does exposing them via the REST API expose information that site owners wouldn't expect?

Yes, we'd need some new permissions model for the REST API where custom post types and taxonomies (or endpoints generically) can define an authorization callback for their existence to be exposed. This way, we could respect the existing behavior in the admin where a custom taxonomy is only displayed upon an authorized request (e.g. editing a post) and not publicly accessible.

Put another way, to display a custom taxonomy if show_in_rest is unset but show_in_admin=>true would be a security issue.

[joehoyle]

Put another way, to display a custom taxonomy if show_in_rest is unset but show_in_admin=>true would be a security issue.

I'm not sure I agree with this. register_post_type / register_taxonomy already defaults to public, show in admin etc. The default of show_in_rest being the same I think would be fine.

I do think that the whole concept of show_in_admin is pretty archaic. Also, I think it's not really an issue to show the existence of a taxonomy in the rest api (but not allow actually fetching of the objects). object-permissions can already be done via public => false, or other capabilities check.

I'd see this as a chance to open up more data to the rest api, by changing the defaults, we can still do "public" and "private" content via the normal WP permissions model.

[nylen]

We need to see specific, commonly-used examples to inform any kind of decision here.

[nylen]

Props @danielbachhuber for this proposed solution, I think it's a good one:

Allow management of post types and taxonomies with show_in_rest => false but show_ui => true, if the user has the correct capabilities. (TBD exactly what those capabilities should be, but maybe there is an obvious answer.)

This will be the first time that the response structure of the API differs based on the user's authentication level - entirely new endpoints and links will appear. We'll want to take some care that things remain reasonably consistent.

Note the correct flag is (counterintuitively) called show_ui:

(boolean) (optional) Whether to generate a default UI for managing this post type in the admin.
Default: value of public argument

This should work from a technical perspective. However I want to emphasize again the value of looking at some examples from WooCommerce or another popular plugin, without seeing what people are actually using this for it's a bit hard to envision how it should behave.

[joehoyle]

I created https://core.trac.wordpress.org/ticket/42785 to get some progress on better defaults for content included in the REST API. This doesn't quite address all the cases here such as "private" post types, which I think we can also push ahead.