Integrate Navigation with Contextual editing

I forgot to add the Navigation stable blocker tag.

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

ckrina → credited lauriii → .

We discussed with @lauriii how to integrate the Contextual editing button into the Top Bar and we came up with this solution that will help unblock the Top Bar and the Navigation from becoming stable: move this Edit button (to show contextual areas) into the more actions dropdown.
The primary action would actually be the button to go to Edit the node if you're on a node, which actually has the same label: "Edit". Which makes it really complicated to understand what is this Edit button.

"Edit" label is problematic

Another problem the UI has is that the same label: "Edit" is used both to show the contextual actions and if you're in a node (the Edit option to go into the node). And it makes it really complicated to understand what is this Edit button and differentiate the 2 of them. So a follow-up would be to change the label for this contextual edit button. If it becomes complicated to find the right copy for this label the discussion should be moved to a follow-up so it doesn't block the Navigation from becoming stable.

Change the controller

Another conversation to have in the future is the UI pattern/controller this should be: it should be a toggle since it's showing and hiding the contextual areas that can be edited (I think for accessibility purposes). But please keep any change to this controller for a followup or we won't get this Stable blocker done.

As a final point, to keep in mind that this (almost not used) feature will progressively disappear with the new functionalities XB will provide.

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

Hi folks, follow the image below of the preview editable areas.

Even though this is categorized as a task think there is enough changes here to maybe warrant a simple test case. Least maybe an additional assertion in the module.

Thanks! Looks good I had nothing to add

Thank for commit.
I added few notes about js.

Good catch @finnsky. I forgot the once + context stuff, thanks.
Thanks.

Tested a confirmed the solution works as expected. once() is implemented correctly as well.

Code looks good and it has nice test coverage. Thanks!

However, it only adds the item to node pages.

We might need to discuss whether we need to extend it to other entity types, as the top bar does. Using NavigationRenderer::meetsContentEntityRoutesCondition() would help.

Besides the entity types, do we expect to have it in other pages to allow to modify header or footer blocks? That's the behavior we have now with the toolbar integration.

Adding the "Drupal CMS release target" to see if we could hopefully get to it.

Fixed merge conflicts.

@plopesc I've made the meetsContentEntityRoutesCondition method public, and used it to determine whether to add the links.

Hello! Thank you for work here.

Initially we managed that dropdown via common abstract script:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/navig...

And it worked before. We need to check git history here probably to avoid duplications in common things
This Dropdown should be universal(not related to contextual links) and reusable.

Are you saying that I should move the Javascript into that new file for managing toolbar-dropdown?

No, I mean we can search in the module history.
These links have already worked with the dropdown list. And there is already a script and styles for them.
The backend for this module has changed several times recently, so we should just re-apply it.
I think js is not needed here at all. Maybe only for optimisation.

Are you sure no javascript would be required to find and make visible all of the contextual links on the page when you click the "Preview editable areas" link in the contextual links menu?

I apologize.

I read the task description poorly.

As for MR
JavaScript looks acceptable to me.
+1 RTBC