Navigation: allow plugins to register icons for custom post type and taxonomy variants

[Aljullu]

Navigation inner blocks are automatically available for Custom Post Types and taxonomies. That was introduced in #29095 and works great, making plugin authors life much easier. However, it doesn't allow setting a custom icon for those inner blocks.

In the screenshot below, you can see the Product Link, Product Category Link and Product Tag Link blocks added by WooCommerce using the generic icon:

I anticipate this will be an issue for sites with several plugins installed.

@gwwar do you have any thoughts about whether an interface could be added so plugins can register custom icons for the Navigation inner blocks which are generated automatically?

Step-by-step reproduction instructions

The testing steps from https://github.com/WordPress/gutenberg/pull/29095 showcase the issue.

Expected behaviour

As a plugin author, I would like to be able to set custom icons for the custom post types and taxonomies registered in my plugin.

Actual behaviour

AFAIK, currently there is no API do register icons for CPT and taxonomy link blocks.

[getdave]

@Aljullu I agree we should enable the ability to register custom icons for the core/navigation-link variations (which is what you are referring to as the innerBlocks.

You will also notice that once you insert one of the block variations for a custom post type the name of the block in the block sidebar still reads Post link. That should also be fixed.

I'm currently working on https://github.com/WordPress/gutenberg/pull/31004 which standardizes the serialization of blocks to nav menu items (and vica versa) so that existing menus will translate perfectly over to the new Nav editor screen. I'd love some more 👀 on that if possible.

[gwwar]

@gwwar do you have any thoughts about whether an interface could be added so plugins can register custom icons for the Navigation inner blocks which are generated automatically?

Yes, I hope we'll have this in the future. The current variations API only allows icons to be set with a JS function. We need to explore if we can set icons as a react component function OR svg string (and still have this work for React Native). Once an icon is serializable, it'll be possible then to update the server API.

The workaround for right now is adding a block filter, which even the core/navigation-link needs to do:

addFilter(
    'blocks.registerBlockType',
    'core/navigation-link',
        ( settings, name ) => {
             if ( settings.variations ) {
        const variations = settings.variations.map( ( variation ) => {
            return {
                ...variation,
                ...( ! variation.icon && {
                    icon: getIcon( variation.name ), //add your custom icon here
                } ),
            };
        } );
        return {
            ...settings,
            variations,
        };
    }
    return settings;
);

[gwwar]

You will also notice that once you insert one of the block variations for a custom post type the name of the block in the block sidebar still reads Post link.

To fix that, when registering the custom post type, add two new labels item_link and item_link_description. New post type labels were added to avoid joining two translated strings.

[Aljullu]

@getdave

@Aljullu I agree we should enable the ability to register custom icons for the core/navigation-link variations (which is what you are referring to as the innerBlocks.

Thanks for clarifying those concepts to me, I'm still new to all the Gutenberg nomenclature. :slightly_smiling_face:

I'm currently working on https://github.com/WordPress/gutenberg/pull/31004 which standardizes the serialization of blocks to nav menu items (and vica versa) so that existing menus will translate perfectly over to the new Nav editor screen. I'd love some more 👀 on that if possible.

Will do. Adding this to my todo list for this week. :+1:

[Aljullu]

@gwwar

The workaround for right now is adding a block filter, which even the core/navigation-link needs to do:

That worked great, thanks for pointing me in the right direction! I needed to tweak the code a bit because when calling it from a plugin, variation.icon is already set. Sharing the code here in case it's helpful for other plugin authors:

function replaceIcon( variation ) {
    switch ( variation.name ) {
        case 'my-variation':
            return {
                ...variation,
                icon: <MyIcon />,
            };
        default:
            return variation;
    }
}

addFilter( 'blocks.registerBlockType', 'my-plugin/navigation-link-icons', ( settings ) => {
    if ( settings.variations ) {
        const variations = settings.variations.map( replaceIcon );
        return {
            ...settings,
            variations,
        };
    }
    return settings;
} );

[jordesign]

Hey @getdave - just triaging older issues - and wanted to see if we had inadvertently solved this one in the last 2 years? Or if it still needs working on.

[getdave]

I don't think this has been resolved no.