#53826 register variations in a later init hook#54434
#53826 register variations in a later init hook#54434gaambo wants to merge 2 commits intoWordPress:trunkfrom
Conversation
|
I've reached out to some Core folks for advice on altering the priority here. |
|
I feel that we should probably add a PHPUnit test for this as well. Register some CPTs and Taxonomies and then see if the Nav block variations get registered. |
Would that be just PHPUnit tests which check the existence of the variations (e.g. shortly before loading the editor), or should they be e2e tests? I've searched in the repo and found that for example in |
| $navigation_block_type->variations = array_merge( $navigation_block_type->variations, $built_ins, $variations ); | ||
| } | ||
| add_action( 'init', 'register_block_core_navigation_link' ); | ||
| add_action( 'init', 'register_block_core_navigation_link_variations', 1000 ); |
There was a problem hiding this comment.
Speaking away from Github with @ironprogrammer we discussed avoiding using 1000 here. This is because - as you noted - we cannot assume extenders will have done their work by this point.
Another option might be moving this to a later action hook?
@ironprogrammer may be able to advise on a suitable candidate but you could experiment in the meantime to see what works 🙏
There was a problem hiding this comment.
I was thinking, that maybe we could run the initial registration on 10 like it is in core atm but additionally add an action hook to registered_post_type and then add custom variations in that callback. This way we can be sure, to catch all post types that will be registered.
I would opt for PHPUNit tests which live in the Then for the test itself I'm thinking something like:
$registry = WP_Block_Type_Registry::get_instance();
$nav_link_block = $registry->get_registered( 'core/navigation-link` );
To run the unit tests from the Gutenberg repo you can use |
|
#54801 seems to be a better approach, therefore closing this PR. |
What?
This is a first try at fixing #53826.
I try to create the variations of the navigation link block for all taxonomies and post types in a seperate function hooked to init on priority 1000.
Why?
See #53826 - server side function runs too early to make sure it gets all custom taxonomies/post types by plugins, themes etc..
How?
I just chose 1000 because I'd assume then most other plugins have registered their post types. I've seen plugins use 99, 100 etc - but I guess 1000 should be save.
I'm using a seperate function and directly modify the registered
WP_Block_Typeinstance. I'm not sure if that is really an intended way, but the properties of the class are public - so I guessed "yes".Alternative solutions are described in the issue.
Testing Instructions
Custom Post Type
Important: Set the item_link label or the block variation is called Post Link.
Important: change add_action priority to something lower than 10 (eg 9)
2. Go into site-editor and add a navigation block
3. try to search for a block named like the custom taxonomy (eg "Product Link").
4. Block is available
Testing Instructions for Keyboard
Screenshots or screencast