Block list block shows multiple core/navigation-link variations for WordPress 5.8 but not 5.7.2

[bobbingwide]

When analysing the block changes between Gutenberg 10.7.0 and the latest (11.6.0) I noted that the number of blocks and variations with WordPress 5.7.2 changed from 178 to 177 with Gutenberg 10.9.0, but with WordPress 5.8.0 there were many variations of the core/navigation-link block, giving 205 blocks and variations.

eg in blocks.wp.a2z the additional variations were:

1. Category Link - block_classification
2. Category Link - required_version
3. Category Link - compatible_up_to
4. Page Link - oik_file
5. Page Link - oik_class
6. Page Link - block
7. Post Link - wp_block
8. Post Link - product
9. Post Link - oik_shortcodes
10. Post Link - oik_sc_param
11. Post Link - shortcode_example
12. Post Link - oik_hook
13. Post Link - oik_api
14. Post Link - block_example
15. Post Link - oik-themes
16. Post Link - oik_themeversion
17. Post Link - oik_themiumversion
18. Post Link - oik-plugins
19. Post Link - oik_pluginversion
20. Post Link - oik_premiumversion
21. Post Link - download
22. Product Category Link - product_cat
23. Product Tag Link - product_tag
24. Tag Link - letters
25. Tag Link - block_category
26. Tag Link - block_keyword
27. Tag Link - oik_tags
28. Tag Link - oik_letters
29. Tag Link - block_letters

but the list didn't include Custom Link - core/navigation-link

[bobbingwide]

Here's a screenshot showing the Post link variations for the Navigation block

It also shows a subset of the Block list with Show batch commands toggled on.

[bobbingwide]

In #core-editor, in response to

I have a question regarding core/navigation-link blocks. With WordPress 5.8 and Gutenberg 10.9.2 I see many Category Link, Post Link, Page Link and Tag Link variations - one per CPT / taxonomy. What was the PR for this change?

I was pointed to WordPress/gutenberg#24814

which I'd commented on a long time ago, the most recent of which was WordPress/gutenberg#24814 (comment)
in which I wrote.

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.

[bobbingwide]

I was also advised what to do to control the display of and identify each variation.

1. If you don't want it to appear in navigation menus set show_in_nav_menus false. See https://developer.wordpress.org/reference/functions/register_post_type/#show_in_nav_menus
2. For those that do appear, override the default Post Link/Description text; add an item_link and item_link_description in the CPT registration.

This is what WooCommerce must have done for Product Category Link and Product Tag Link.

For the Block list block, when used in blocks.wp-a2z.org, it might make sense to shortcircuit these Link variations.
This could be achieved by removing the action hook which is used to register the variations.

add_action( 'init', 'gutenberg_register_block_core_navigation_link', 20 );

or we could filter the variations for the block registration

register_block_type_from_metadata(
		__DIR__ . '/navigation-link',
		array(
			'render_callback' => 'render_block_core_navigation_link',
			'variations'      => array_merge( $built_ins, $variations ),
		)
	);

by hooking into block_type_metadata

[bobbingwide]

OK, so I managed to prevent the variations from being registered in the server. But the defaults are still listed in the editor, so I assume these are still being registered in the JavaScript.

Now I want to see how to filter the variations to give them better names
or should I just change the registration of the CPTs and taxonomies and be done with it?

[variations] => Array
 (
 [0] => Array
 (
 [name] => post
 [title] => Post Link
 [description] => A link to a post.
 [attributes] => Array
 (
 [type] => post
 [kind] => post-type
 )
 )

[bobbingwide]

The 5 default's names are: post, page, category, tag and post_format

Other CPTs and taxonomies have different values for the name.
The value of attributes.type matches the name.

[bobbingwide]

or should I just change the registration of the CPTs and taxonomies and be done with it?

I changed bw_default_labels() but it didn't work until I deactivated oik-types.
This is because oik-types stores out of date information in the options table.
In this case it's the labels array not containing all the strings, eg item_link and item_link_description.

[bobbingwide]

With oik-types activated there are two scenarios that need addressing, both of which are for CPTs that were defined/updated in oik-types before the missing labels were added.

1. Updated post type - we can merge the labels arrays - change oikcpt_adjust_args()
2. Post type defined using oik-types, not programmatically ( eg for oik_todo ) - unset the labels before calling bw_register_post_type().

Check that this solution works for post types with different singular and plural names.