Navigation: Add variations for custom post types and taxonomies

[noisysocks]

#24670 added a Post, Page, Tag and Category variation to the Link block. We should extend this so that there is a Link variation for all post types and taxonomies that are registered using register_post_type() and register_taxonomy(). This will allow users to insert links to their third party post types and taxonomies.

This can probably be done by having packages/block-library/src/navigation-link/index.js fetch the post types and taxonomies from the REST API using @wordpress/core-data. It would then dynamically call registerBlockVariation() on core/navigation-link.

See discussion at #24670 (comment).

[ZebulanStanphill]

It's worth noting that it's already possible for plugins to register block variations for the block themselves.

[celloexpressions]

WordPress has a specific API for this already. Block-based menus need to observe the show_in_nav_menus argument for register_taxonomy and register_post_type. Plugins should not need to register blocks to maintain this core functionality.

https://developer.wordpress.org/reference/functions/register_taxonomy/
https://developer.wordpress.org/reference/functions/register_post_type/

[gwwar]

I can take a look at this one.

[gwwar]

Reserving this comment for some research notes:

Current data availability in blocks:

We already have reducers/selectors available in the core data store.

// https://developer.wordpress.org/rest-api/reference/post-types/
wp.data.select( 'core' ).getPostTypes( { per_page: -1 } )  
// https://developer.wordpress.org/rest-api/reference/taxonomies/
wp.data.select( 'core' ).getTaxonomies( { per_page: -1 } )  // -1 is handled in fetch api middleware, to fetch all entities.

Post Types	Taxonomies

Client filtering or core rest updates needed

The customizer currently filters for post types and taxonomies with:

$post_types = get_post_types( array( 'show_in_nav_menus' => true ), 'objects' );
$taxonomies = get_taxonomies( array( 'show_in_nav_menus' => true ), 'objects' );

Internally each post_type and taxonomy has a boolean value for controlling if these types are visible in navigation menus show_in_nav_menus.

We also cannot filter by show_in_nav_menus using the rest api on either end point. This is unfortunate since we'll need to rely on client filtering, without updating the endpoints. Client filtering means paging also becomes trickier, should we implement this on an as needed basis.

Post Types response doesn't expose show_in_nav_menus

The taxonomy rest response exposes show_in_nav_menus, but post_types does not. 😱

Unless I'm reading this incorrectly, if we try proxying this off another prop I think we'll implement this incorrectly. I don't think we can rely on viewable either, from this note:
https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-post-type.php#L57-L68

Next Steps

• I'll first play around with removing the hard coded variations in favor of that being powered with the rest api
• See if we can at least expose show_in_nav_menus for the post_type response, or find a different work around.

[gziolo]

I don't think you can register those block variations on the server because they wouldn't get propagated to the client as of today. See fields that are shared from the server to the client:
https://github.com/WordPress/wordpress-develop/blob/f9b901549b4bbed394d7b6a0df76672c4d68ef72/src/wp-admin/includes/post.php#L2242-L2256

In the future, we are going to migrate to using preloaded REST API response for registered block types:
https://developer.wordpress.org/rest-api/reference/block-types/

Now that I said that, I think that you might register those block variations by calling wp.block.registerBlockType in the <script> snippet printed on the server. It depends if the block needs to be registered earlier. It might be difficult to keep it like this in the long run, though. Well, you definitely should give it a try. 😄

[gwwar]

Thanks @gziolo, it sounds like I should try to experiment with some REST API updates in that case 👍

[bobbingwide]

I'd just like to add my comments on this. The code in #28892 assumes that $attributes['type'] is set.
In Gutenberg 10.0.2 it's not set when the Navigation Link is the default.

Variation	type attribute	id attribute is?
Link		probably a post
Post Link	post	post ID
Page Link	page	post ID
Category Link	category	term ID
Tag link	tag	term ID

This would lead to a Notice when WP_DEBUG is true.
It might make more sense if the type for Tag Link matched the taxonomy name ( post_tag ) rather than the default for the permalink base ( tag ).

See bobbingwide/fizzie#52 for the scenario I experienced.

[gwwar]

The code in #28892 assumes that $attributes['type'] is set.

Yes I missed an isset 😅 @bobbingwide That one was fixed in #28999 by @talldan. Are you still seeing the issue?

It might make more sense if the type for Tag Link matched the taxonomy name ( post_tag ) rather than the default for the permalink base ( tag ).

Since it's already set in data, I think the exception here is okay. It's also probably more familiar to folks if they are trying to edit markup by hand.

In my not yet merged PR, I try to clarify this further by providing taxonomy/post-type: https://github.com/WordPress/gutenberg/pull/29095/files#diff-96cfb99105116cdbf48eface8e7ac4dff062da11f291996bf5748d5a8b90f3e0R112

[bobbingwide]

Are you still seeing the issue?

I was using Gutenberg 10.0.2 and hadn't read further down the issues. I have a workaround until I upgrade.

Since it's already set in data, I think the exception here is okay. It's also probably more familiar to folks if they are trying to edit markup by hand.

That's assuming the user hasn't changed the permalink Tag base on Settings > Permalinks.

Re your PR:

It will be interesting to see how unwieldy the navigation blocks become with one variation per post type and taxonomy.

I'm using at least a dozen CPTs, some of which have 3 taxonomies, and some of these taxonomies are shared between post types.

Additionally, for my A to Z letter pagination menu(s) each link needs the post type as well as the taxonomy term.
eg. https://blocks.wp-a2z.org/letters/g/?post_type=oik-plugins shows Plugins with the first letter G.
Compare with https://blocks.wp-a2z.org/letters/f/?post_type=oik-themes which shows Themes with first letter F.

Not an immediate problem since these menus are generated programmatically.

[gwwar]

Should be fixed by #29095, WordPress/wordpress-develop#1015 https://core.trac.wordpress.org/ticket/52688