Add new hook to allow additional featured block

[Hug0-Drelon]

Fixes #39814

What?

Introduce a new filter to allow adding blocks in the navigation transform control panel.

Why?

This could be useful for third party plugins to feature their custom blocks and for the user to use it easily.

Testing Instructions

This PR can be manually tested after creating and registering a custom block and adding something like:

const featureNavigationCustomBlock = ( blockNames ) => {
    return blockNames.concat( [ 'my-plugin/my-custom-block' ] );
}

addFilter( 'allow_additional_featured_block_in_navigation', 'my-plugin/add_my_custom_block_to_featured_blocks', featureNavigationCustomBlock );

Your custom block feature should be displayed here:

[getdave]

Thank you for the PR. Code wise this looks good.

My only concern is how much this opens up the UI to being overwhelmed with multiple featured blocks.

Imagine if several Plugins you have installed insert blocks into this featured area. Suddenly it's going to become overwhelming very quickly.

In the linked Issue you say:

It's not possible for a third party plugin to feature a custom block for navigation. There is still a workaround by adding a random link and transforming it into another kind of block. But from a user point of view it is not convenient at all.

I wonder is there an alternative solution we could look at? Perhaps we need to look at opening up the Nav block to other types of blocks from the inserter?

I appreciate this probably seems like I'm blocking a perfectly reasonable filter, but it's really important that we keep the UIs streamlined.

Looking forward to hearing your thoughts.

[talldan]

Thanks for working on this. I agree with @getdave about opening it up to an arbitrary number of blocks. The design starts to look wrong with four. A filter could probably still support only three by disregarding anything after the third item as long as that's clearly documented.

Another option for deciding which three blocks to show could be to use the priority field that block transforms already have (https://developer.wordpress.org/block-editor/reference-guides/block-api/block-transforms/#block). The first three block with the highest priority could be shown. I don't know if that would be highjacking the priority system a bit. Any drawbacks anyone can think of?

Anyway, I think the core issue here is that it's still really quite hard to insert non-link blocks. I don't think #34041 was ever solved completely. It's now easy to insert a Link, not too difficult to insert a Search, Site Logo, or Social Icons, but very confusing to insert anything else.

[Mamaduka]

@talldan, I liked the idea of the variation approach you mentioned here - #36026 (comment). Maybe we can introduce a new variation scope (navigation) instead of a new filter.

I agreed that the design would need to adjust.

[Hug0-Drelon]

Thank you all for your feedback 😃

@getdave I understand your concerns about having too many blocks displayed in the transform control panel.
But I don't think that many plugins would insert blocks here, even less from a user point of view IMHO. Although I understand UI has to be controlled.
Maybe we could imagine a "show more" button like this:

(sorry for the bad design 🤣 )
Whit that, the number of displayed block is under control and we can still show more options (accepting that the panel would grow in space).

The idea of handling the displayed blocks through a priority seems to be easily implemented but everyone will require the first place in their code (that's what I'd do 😅 ). And the rendering won't be predictable by potentially hiding some custom blocks (which we want to avoid). But maybe I misunderstood your point.

As for the variation approach, I must say I'm not really qualified about this way of doing (newbie here ahah). So I won't dare to propose something.

[draganescu]

While the filter should be considered in the context of @talldan 's point that the design is not really "extensible" yet, I also don't think this particular solution solves #39814. The idea is for the user to be able to insert that language switcher. Should plugins be allowed to turn off the default behaviour of inserting links, and have the inserter open instead?

[Hug0-Drelon]

@draganescu You're right, the proposed solution is only a workaround. From a user point of view, the easiest way would be to insert the plugin's block directly (and not transform a link into something else).
So opening the inserter to plugins could be the best way to go.
I thought that the behavior of only being able to insert links was designed on purpose, that's why I proposed this filter.

[Hug0-Drelon]

Hi 👋
Any thought on how to handle this ? I'd be glad to make another PR if needed 😉

[draganescu]

@Hug0-Drelon I added design related labels, but what seems from reading above to be the blocker is to figure out how the UX for solving what @talldan described as

I think the core issue here is that it's still really quite hard to insert non-link blocks.

Bringing this PR and its associated issue up in design channels in core is also a good start. Briefly, it's not the code that is the major problem but the interaction.