Decide strategy to customize or provide 1st level menu items' icons

I like idea with yaml config field like:

navigation_nodule_icon: `icon-name`

grouping with some popular and documented icons library like:
https://fonts.google.com/icons?selected=Material+Symbols+Outlined:add:FILL@0;wght@400;GRAD@0;opsz@24

That one looks pretty similar to our styles.

I was thinking how to bring minimal effort for solving this idea and here it is:
1. We have to redo CSS logic, we need to get rid of ".toolbar-button::before" selector with mask-image and replace it by embedded svg image in twig template with source(), like:

// toolbar-button.html.twig

<button { ...props }>
  <span class="toolbar-button__icon">
    {{ source('path/to/root/assets/icons/folder/' ~ iconname, true) }} 
  </span>
</button>

btw, second param in source() twig function true required to prevent WSOD if template defined in first param is not found.

2. We put all the icons we have currently in assets/icons folder where filename of svg file = twig's iconname. So this is a strict rule, filename of icon matters.

3. In admin back office for admin menu links we can put some select field (or fieldset with the group of radio inputs). Each element = 1 icon. Preview of the icon + its label (based on icon filename). So user can browse all available icons at once and choose any icon he want.

4. Now how to use external icons? I'm not backender, but seems like we can create some folder in modules or themes, named "navigation-icons" where all custom svg icons can be stored. And then Drupal can scan all of the icons from specific folders and grab them and merge with the default icons stored in navigation module, so user in step 3 can browse all available icons at once.

Any opinions?

This is interesting, because as a site builder you might want to provide an icon for a custom menu link that you happen to place on the navigation.

Similarly, providing icons for menu links could be seen as a common requirement for websites in general.

So one thing to also consider (maybe this is a separate issue though), could Core also provide a "icon" field on custom menu links, which would then be used by the navigation module, but could also be used by the frontend theme for menu links which appear in the main navigation.

FWIW, a similar problem was recently solved in the Field UI redesign ( 🌱 [Plan] Improve field creation experience Active ), and the final solution there was implemented in 📌 Consider replacing hook_field_type_category_info with YML based plugin discovery Fixed and 📌 Allow field_type_categories.yml entries to define asset libraries Fixed .

@AaronMcHale thanks for the ideas! We've discussed it several times and providing a library in core is out of scope, but we all agree it'd be a great addition for a contrib module. That's why we came up with ✨ On collapsed sidebars, if no icon for a top-level item is provided, use the first two letters Active as an easy solution for core.

could Core also provide a "icon" field on custom menu links

And this is the reason why. I'd love it and seems logical, but opening that Pandora box is way beyond this Navigation module if we want to get it done. :)

Re #3: the design team chose go with the library Phosphor. ;)

Re #4: Same, option 3 is out of scope if we want to get this done :)

I'm leaning towards the yml, specially because it'd be able to work with config changes provided by git. That's why yml sound good: we can add icon X name in yml and add the route for it on the yml, and the file itself in the same commit.

A hypothetical contrib that will provide icons sounds great, but I'd try to not account for that for now. Let's focus here in something we can archive for now :)

Have you considered allowing users to just set a path to an svg similar to theme favicon/logo fields? The current icons are set in CSS via mask-image: var(--icon); and --icon is set to url("data:image/svg+xml, <some svg code>").

If custom menu items are added and have a field that takes a path to an icon, we could use file_get_contents() to get the SVG code and then urlencode() to convert it to the format CSS expects. Then setting style="--icon: ..." on the custom menu item allows no custom CSS to be written.

ideas:
https://atendesigngroup.com/articles/add-svg-icons-drupal-menus
https://www.drupal.org/project/simple_menu_icons → is an interesting idea to add file to menu item and how to render CSS.

#7 from @amateescu is worth exploring I think, the field UI approach would work for a couple of use cases:

For modules that provide top level menu links, e.g. announcements in core, groups and commerce in contrib, they can define their own icons in YAML to be consistent with the other top level links (most of which are provided by system module, but navigation could provide those on system module's behalf in the same YAML format).

With a build or alter hook, that then would let a contrib module provide a config entity (or static config maybe) to override what's in the YAML and allow arbitary images to be used.

The icon on custom menu links approach is tricky because most of the admin links in core aren't content menu links - they're either YAML defined or from views, and then don't have fields at all - so even for custom admin pages, if someone's made a view, it would require separate creating a content menu link to point to it instead of the menu settings on the view.

I've added quick POC with usage of `Phosphor` icons and core config via options property in Yaml.

Can be any stable and popular open-source library. Used id as recommended in #8

It needs backender review. Since as far as i understand can be more that only yaml option to define menu items.

All works fine:

Library https://phosphoricons.com/

I realize this issue is currently more geared around the basic design guide of the overall project.

@finnsky - what you are showing with adding into announcements_feed.links.menu.yml* is a great insight into how others can use this.
*needs developer/conrib demo doc.

Maybe another ticket is needed:
#10 -- I've continued some local POC to be able to 'select a file' from the block config. This would open in Settings Tray while editing menu levels and use the current 1st to add an 'naviagation_icon_fid' as as menu 'optional data' through the context link of the layout navigation builder.

Similarly if using an icon library, then this could let users select from a UI .
- add a settings for the library prefix? if site has other libraries
- also render . would allow more to be done by theming/contrib.

maybe an addition question is users add a file or selects an icon from UI is
- how can user user other icon libraries? this is singular to one design library (long term?) and run puts
- imagecache use consideration (same as logo).

I don't think we should give people a Swiss army knife. In this task we need to provide a simple and predictable way to set a suitable icon. And this is the Yaml config and library.

This is possible in the case of a large and well-documented library. This way, the developer can easily choose a suitable icon from a large set.

I don't see much point in giving the opportunity to specify a new library. Because in this case, two or more different sets in one menu will look obviously ugly from an aesthetic point of view.

For the same reason, I don’t see any point in giving the opportunity to download a file. In the case when a developer really needs a custom icon (for example, some branded item), you can always use a css like

.ph.ph-custom-name-from-yaml {
  background-image: url(custom.svg);
}

I am for simplicity in everything.

I really like the approach proposed in #7 or a similar one.

However, I don't see where we can connect the Icon plugins with the menu items.

Menu item class for menu items created through yml files are like toolbar-button--icon--system-admin-structure that can be inferred from the menu definition. It would require some Drupal knowledge to discover the specific class. These menu items cannot be modified from the UI though

However, if editors want to add menu items through the UI, icon class is like toolbar-button--icon--menu-link-contenta614ff3e-4306-4830-933c-f152268ea849 which is not friendly and also can differ between the different environments.
.
At this point 2 possible approaches come to my mind:

• Add an extra config property in NavigationMenuBlock where editors can define the menu item - icon relationship manually. Values for core menu items would be shipped by default. For other NavigationBlocks like Shortcut or User, the icon could be chosen from the list of available plugins and stored as part of the block config.
• Modify the menu item form UI to add a field from where each menu item could relate to an icon to be used just in case the menu item is used for navigation. These relationships could be stored as third party settings in the menu config entity. hook_install() would take care of setting the default values when installing navigation. For other NavigationBlocks like Shortcut or User, the icon could be chosen from the list of available plugins and stored as part of the block config.

Would be great to have some other ideas brought to the table and reach some kind of agreement before starting to work on this.

Thank you

Perhaps SDC will be useful here

I've added an icon component and now using SDC I replaced the icon to umami. We need to decide how this yaml config also can be overriden. But globally i prefer this obvious and simplest way.

Hi everyone,

I have been thinking on this from the DrupalCon Portland after the conversation with @ckrina and lauriii, this is my proposal:

• Create a module called Icon Library:
• Detects svg sprites or single icons from any module or theme.
• Provides field, widget and formatter.
• The widget should be a button to open the icon library.
• The icons should use a naming convention to provide context that can be used as filters, that will avoid storing metadata for the icons in database or config, the pattern could be: solid-megaphone, outline-megaphone, duotone-megaphone
• A filter for the Icon library by Provider - The module or theme that provides the icons - FontAwesome, Claro or any other module or theme.
• A filter for the Icon library by Style - Solid, Outline, Duotone or any other word extracted from the first part of the name of the icon.
• The icon library should provide searchbox to find icons by name.
• The value for configuration or content entities should be the icon id

Let me know what do you think?

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Gauravvvv → made their first commit to this issue’s fork.

Mithun S → made their first commit to this issue’s fork.

I don't think proof of concept should be rebased. But thank you anyway.