Add contextual link for the whole Navigation bar to link to the Navigation Admin UI

If we just want to make one link that always takes the user or admin to the configuration page "/admin/config/user-interface/navigation-section" I don't think it's needed. The admin can already go to this page using the module's configure link or by going to "/admin/config" For me, having this link doesn't make sense. I'd like to hear what others think about it.

Thank you.

We do want a quick way to get to this admin screen from the toolbar/navigation bar itself for usability reasons: it'll make it easier to find the place where it's managed, and it'll mean less clicks. So if a user has the permission to manage the toolbar, the contextual link should be available.

What I would suggest is that the contextual region is around of the content area only, and not the footer or the top header. It's the only region we'll let people customize for now.

Hi folks,

Started to work on this issue and was able to add the necessary HTML markup to the navigation bar to show the contextual link, as you can see in the image or in the Tugboat environment.

However, I have been unable to make it visible due to the complexity of the navigation styles and my limited frontend skills. It seems like there are styles that hides it. @m4olivei mentioned that individual block contextual links were hidden to avoid UX issues, so the issues I'm having could be related to those modifications.

Would be great if someone with better FE skills could take a look and confirm whether it works or not.

Regarding the implementation itself, contextual module "automates" the process of adding the contextual links, assuming a generic twig template structure. Given that navigation bar has a more complex structure, I ended up doing it in a manual way. Once we have the link visible, we could try to improve it if necessary.

Thank you!

Fixed template a bit. Now you can see contextual links. However it requires design.
Current behavior is:

1. Contextual links are sticky on scroll - not sure if we need it

2. Contextual links can overlap "close" icon for

3. Contextual links in collapsed variant can overlap logotype

Nice, this is looking good as a starting point to review and get some design input. Thanks for putting together all those screenshots @kostyashupenko. Perfect way to review.

@plopesc found one issue with the contextual links definition. See MR thread.

As mentioned in the call today, the contextual link doesn't have to be sticky. The menu itself is more important than accessing the admin page to manage the menus. Adding/rearranging menus might happen 2-3 time per project, using the menu continuously. So the priority is that the menu can be easily used regardless of the contextual link: meaning contextual links shouldn't get in the way.

That said, and since I can't access this Tugboat environment and judging from the screenshots: the icon should land on the margin on top of the first menu link, but not on top of the logo. It should actually wrap the menus, not the whole area. Quick idea of what I'm trying to explain:

Just figured out new problems. Regarding position on expanded navigation - clear. We also can make it non-sticky on scroll. Works fine locally (but i didn't push anything for now).

However here is the issue in collapsed state.
Here is default position i tried to implement (equal spaces above contextual circle and below):

But when i'm hovering first menu link - it's a bit overlapped by contextual link:

But when i'm trying to browse contextual menu, a big part of contextual menu goes out of viewport:

Obviously i tried to display contextual menu bar in collapsed navigation from left side till right (by default it grows from the right side to the left, that's why it's trimmed on my previous screenshot). However it didn't help:

Because parent divs has overflow: auto; - which is totally fine, navigation menu is vertical scrollable.
So all these attempts are really noising to me and i wasn't able to come up with something better. I also was thinking with `position: fixed` for contextual links in collapsed variant -> but in that case it will be kind of "sticky" on scroll, because position fixed will overlap everything. So not sure where exactly i have to put contextual links in collapsed variant.

Also no issues at all in expanded variant.

Maybe i will say dumb thing, but what if we will not use UI provided by contextual core module, and instead we will have "Edit Navigation Bar" just regular link (same link as menu links in our navigation), with icon. Like this:

I'm suggesting it because:
1. It can be a static link which is always visible / pretty clear to the user. It's in the style of navigation design. Shown no matter if navigation block is hovered or not.
2. Works perfect already (thx to already written js) in collapsed state
3. Initial behavior of contextual links is to show circle with pencil icon only when container is hovered. Which points me to the though - we will need to rewrite javascript of contextual module to adapt our needs for collapsed navigation behavior.

ckrina → changed the visibility of the branch 3412116-add-contextual-link to hidden.

ckrina → changed the visibility of the branch 3412116-add-contextual-link to active.

ckrina → closed merge request !162

ckrina → reopened merge request !162

With @ckrina: The admin navigation is not as likely to be edited consistently after the site is built, so we feel this can be downgraded to minor.

I'm not sure I agree we should show contextual link for the navigation. The feature to customize the navigation is great for power users, but it seems unlikely that most users would customize the menu. Basically as @KeyboardCowboy is saying, even for power users it's something you'd once and then never do it again. Because of this, I think the contextual link is adding extra noise that is not warranted. We already hide contextual links elsewhere in the admin UI for similar reasons.