Icon in navigation top bar cannot be customized

@anjali rathod Thank you for joining Navigation!

You don't need to assign tasks to yourself. Usually it's enough to write that you're working on it.

https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...

Sure!
I will be working on this.

Should we have separate icon set for different entity types? This would mean to have another field added to each entity type and user if has set the logo for the entity then it would appear otherwise fallback to database icon. Or should we have another field for icon in the module configuration form that would replace the default icon and would be same across all the entities.

I am thinking of doing something like this. Any suggestions or if there is any better way to implement it?

Agree that adding a new UI to handle this could be complex and not easy to maintain, since new modules can add new content entity types.

Besides Gàbor's approach, another possibility could be to use create a theme wrapper for the PageContext render array. That theme wrapper would expose a preprocess hook, from where XB or other modules could alter the PageContext content. That would allow to customize quickly not only the icon, but also the badge text or status.

we're trying to remove preprocesses so let's find another way, title and icon callback somehow, like how breadcrumbs are manage maybe?

we're trying to remove preprocesses so let's find another way, title and icon callback somehow, like how breadcrumbs are manage maybe?

It looks like Breadcrumb (at least via the \Drupal\system\PathBasedBreadcrumbBuilder) leverages the title_resolver services to get the title for a breadcrumb. title_resolver in turn relies on a _title_callback defined on the current route to pull the title. For nodes this ends up being \Drupal\node\Controller\NodeViewController::title. It will fall back to _title param on the route.

All that is to say, I take your suggestion to mean that we'd have a similar icon_resolver service, which would in turn rely on a _icon_callback param, which for nodes could be implemented in \Drupal\node\Controller\NodeViewController::icon, and consult the entity definition for the icon set in the ContentEntityType Attribute. Probably it could be more generic and live in \Drupal\Core\Entity\Controller\EntityViewController since consulting the entity definition would be common for all entity types.

That could be super interesting and provide a nice generic way of associating an icon with any given route, which is something we're missing at the minute if I'm not mistaken.

I'm happy with that

All that is to say, I take your suggestion to mean that we'd have a similar icon_resolver service, which would in turn rely on a _icon_callback param, which for nodes could be implemented in \Drupal\node\Controller\NodeViewController::icon, and consult the entity definition for the icon set in the ContentEntityType Attribute. Probably it could be more generic and live in

If we can detect that we're on the canonical route for the node, then could we not directly get the icon from the ContentEntityType attribute? I'm not sure where the _icon_callback part is entirely necessary.

Created MR based on a ChainPageContextBuilderInterface that allows for now to define the page context in content entity pages, but opens the door to extend it to other routes.

XB could implement its own PageContextBuilderInterface service and define its own page context SDC component for the top bar.

Since navigation is still experimental do the new services or interfaces need a CR?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. 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.

Re: #18 Given that this is quite a clever/novel approach I do not see any reason not to create a CR. If CR's are to publicise new opportunities for development that didn't exist prior to the change it would make sense. Not sure that developers wanting to change the icon would easily stumble on this unless it is officially announced.

Could close this issue since a duplicate of https://www.drupal.org/project/experience_builder/issues/3523007 which is now fixed.