Integrate Top Bar Navigation with Contextual editing

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

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.

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?

@finnsky I've created a new merge request against the 3465295-integrate-top-bar branch at if you could please review and advise. https://git.drupalcode.org/issue/drupal-3465295/-/merge_requests/1

I apologize.

I read the task description poorly.

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

Checked again the code after talking to @ckrina and we have a few notes about the current MR:

The "Preview Editable Areas" link should appear not only in the entity pages, but in any page, similar to the current "Edit" button added to the to the toolbar. We need to find a way to include it everywhere, disconnected from the entity local tasks.

The "Preview Editable Areas" link text might need to be updated to something like "Hide Editable Areas" while they're visible.

In the current implementation of the "Edit" toolbar button, the state of the contextual editing is stored in the local storage, so if the page is reloaded, o r the user navigates to a different page, the contextual links status persists. Not sure if we actually want to maintain this behavior, but I think it's worth at least to mention it.

Hey @plopesc, thanks for the review.
I'm having a look at the way that the Edit button appears. In the contextual module, they implement the hook toolbar. For the navigation we don't show that toolbar as the other modules do, so the only way that we currently display something similar to the toolbar hook is the top bar item, am I correct? please correct me if I'm wrong.
Since the PageActions plugin displays the Local tasks, how can we implement the edit button without using the local tasks? Should we create another plugin, for example: ToolbarActions, then we could add actions that are similar to the toolbar hook.
Thanks.

Hi, thank you for your interest on this one.

Given that this solution will be probably temporary, we could just provide this feature as part of the existing TopBarItem plugin.
You can just add an extra item to the Local Tasks list calculated using the logic you need, I guess it could be inspired in how contextual's hook_toolbar() works.

If there are no local tasks, you'll have only this new option will be displayed.

Thank you!

Hey @plopesc.

I was investigating how the contextual module adds the Edit button and the contextual link on the pages.
The Edit is added by the hook toolbar(ContextualHooks:19), by default this link is hidden, and then a javascript is responsible for showing or keeping it hidden. If I'm not wrong, the behavior checks if there is any contextual link on the page, and if the Edit is toggle to visible, otherwise keeps hidden. The contextual_preprocess function adds the contextual links if I'm not wrong.
Please, anyone, correct me if my understanding is wrong.

Based on that, for the entities we already have a solution, since the user is accessing an entity page the local tasks will appear and we add the Preview editable areas. Since this is a temporary solution, I don't think it's feasible to implement a "complexity" custom logic just to make this work for other pages. We probably need a javascript code to check if there are contextual links on the page and then control the top bar items. We probably will add a custom logic just for a temporary solution.

So, here is my suggestion. Based on the "complexity" that can be to adding the Preview editable area for non-entities pages, and this is a temporary solution. I would like to suggest that we could move forward with the current solution, displaying the feature only for entity pages.

What do you guys think?

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.

Thank you @ckrina.

Moving it outside of the dropdown will make things a bit easier. It could be implemented as a new TopBarItem plugin placed in the Top Bar's Tools region. Also it would allow to reuse, or at least take as inspiration, the JS implementation used for the Toolbar module.

Thank you for working on this new approach! Good progress here.

Left some comments in the MR.

Hi folks,

I’ve been working on this issue for a while, and it’s almost complete. However, I’m facing a challenge in the final stages and would appreciate any suggestions, ideas, or feedback to help resolve it.

We developed a new Top Bar plugin to display the Preview Editable Areas, which toggles the contextual links on the page if they exist.

The problem:

There is no straightforward way to determine on the backend whether contextual links are present on the page. That’s why we are handling this logic in JavaScript—the same approach used by the Contextual module to decide whether to display the Edit button in the toolbar.

Our current implementation adds the button to the Top Bar as hidden by default. Then, the navigationToggleContextualLinks behavior determines whether the button should be displayed based on the presence of contextual links on the page.

Additionally, there is a CSS rule that changes the display property of the Top Bar to block if the section is not empty. Since :empty considers spaces as valid content, I updated this rule to check for any actual elements instead.

Here’s the updated rule:

.top-bar:has(.top-bar__tools *),
.top-bar:has(.top-bar__context *),
.top-bar:has(.top-bar__actions *)

Everything works fine, but there’s a flickering issue on the screen.

The flickering occurs because the CSS rule initially displays the Top Bar as soon as there is content in the tools section—in this case, the Editable Areas button itself. However, when the JavaScript behavior runs and detects that there are no contextual links on the page, the button is removed. This results in a brief unintended appearance of the Top Bar before it disappears again.

Possible solutions:

I can think of two potential approaches:

1. Prevent the PagePreviewEditableAreas from rendering the button initially. Instead, only add the behavior that checks for contextual links, and then dynamically insert the button if needed. This approach eliminates flickering since the toolbar will only appear after the behavior adds the button.

2. Make the Top Bar “smart” enough to update its display to block only when there is visible content. However, I lack the CSS expertise to determine whether this is possible. Implementing this logic via JavaScript would likely result in the same flickering issue as the current approach.

Any insights or alternative suggestions would be greatly appreciated!

Pushed some css which make work done.

I would like to have some js optimisations here aswell

Tested manually and it looks very good after last changes.

We might need some test coverage to consider this one completed, though. This test could be inspired in Drupal\Tests\contextual\FunctionalJavascript\EditModeTest, where the toolbar integration was tested.

Besides that, we need to consider a couple of things:

• Eye icon is not being visible in latest chrome version. See #3505124: The icon for the more actions button is not visible
• Icons are being migrated to Icon API #3483209: Navigation leverage icon core API. Might need to take this into account and migrate the eye icons to this new approach if that issue lands first

Sounds good to me, no worries about the sunk cost, thanks for the explanation.