Improve UX for Local Tasks in Toolbar

Can you give us more details to reproduce it? Please.

The problem is resolved with this patch.

Sorry, when I went to the route /admin/config/user-interface/admin-toolbar-tools , I got this error and the patch is for this.

@alyaj2a , Does this patch #4 worked fine for you?

The patch is completely unrelated to this issue.

Thanks Norman (@norman.lol)!

What is expected in this ticket exactly?

Replacing the Local Tasks menu toolbar tab with a single Edit link?

I'm not clear exactly what this request is about, could somebody please clarify a bit ?

Thanks in advance!

Hey @dydave, I just took the time to quickly implement this request. The idea is to show an Edit button instead of Local Tasks if there is an entity edit form URL available. Like that editors could simply click that button to edit an entity which is a node in many cases.

A while ago it was possible to show the local tasks inside the vertical Gin toolbar ✨ Add option for node local tasks in toolbar Closed: won't fix . That issue was closed due to the functionality that Admin Toolbar Tools module provides. In order to make editor's life as easy as possible this is what I suggest:

Entity pages

In case that the local task links contain a route that has the pattern entity.TYPE.edit_form we use that URL for the button itself and also rewrite the label from Local Tasks to Edit so editing an entity is just one click away.

All other pages

If there is no entity edit form URL available we just take the current behavior which is showing Local Tasks.

Super nice! Thanks a lot Yannick (@yannickoo)!

Great description above at #12!
The MR looks great as well!
I haven't tested or reviewed in detail yet, but from a first look it should work very well.

One thing though: This is probably in conflict with another issue I answered yesterday, see: 🐛 "Local tasks" is hard to understand Active .

Any chance the two could be combined? Or should we drop the other one and keep this one?

Thanks in advance and again for the great work!

@dydave I think we can keep the other one open since we still need to figure out which labels could be a good replacement for Local Tasks 😇

Sounds good! 🙂
Thanks a lot Yannick (@yannickoo), once again!

OK, please give me a little bit of time: I'll checkout the changes locally later today, give this a round of testing and report back with my feedback on the MR.

Thanks again for the great help!

Thank Yannick (@yannickoo)!

OK, I've done a bit of testing locally and got a few issues:

Node page: /node/NID

(Note the Edit text is there, but just not visible since it's white on white)

Running D10.4.x with Claro/Olivero (standard fresh D10 install), it seems there is some kind of weird interaction with the Toolbar module:
It looks like there is some sort of JS that checks the DOM of the menu and applies styles based on the URL of the link.
Since the Edit links have the same URL, then the script seems to assign the same styles to the Edit link in the Tab and in the local tasks links.

I tried changing manually the link in the tab, for example forcing:
$local_tasks_default_url = Url::fromRoute('entity.node.edit_form', ['node' => 2]);
and it worked fine: Both links would be displayed as expected (Edit node 2 and Edit node 1)

Another "issue" I found is that the Edit link in the tab doesn't seem to trigger the URL when clicked: It just opens the tray and displays the local tasks underneath. In other words: It doesn't seem to make any difference from having no URL.
(Which seems to defeat a bit the purpose of this issue, if I understood well: Allowing users to click directly on Edit)
This is most likely related with the conflicting JS interactions mentioned above: The tabs in the toolbar probably have a specific JS processing.

Therefore, this doesn't seem as trivial as we may have thought and we might have to perhaps consider a different method, maybe with pure JS? Maybe adding a small JS behavior to add the URL after the page is loaded?
Maybe we would need to add a query string parameter in one of the URLs so they are different?
Maybe leaving the local tasks alone and creating another link in the menu toolbar? (with PHP and/or JS)

I spent 10 minutes, trying to change the code in here:
https://git.drupalcode.org/project/admin_toolbar/-/blob/3.x/admin_toolba...
I added something like this:

  $url = Url::fromRoute('entity.node.edit_form', array('node' => 2));
  $items['admin_toolbar_quick_link'] = [
    '#type' => 'toolbar_item',
    '#wrapper_attributes' => [
      'class' => ['local-edit-toolbar-tab'],
    ],
    '#weight' => 10,
    'tab' => [
      '#type' => 'link',
      '#title' => 'Edit',
      '#url' => $url,
    ],
  ];

copy/pasted from admin_toolbar_tools/src/AdminToolbarToolsHelper.php, just modified the values with a hard coded URL and obtained this:

The Edit link displays fine, no tray, the link URL works and opens correctly target page...
It's just not positioned at the "right"/same place mostly .... we might have to move it a bit to make it more visible?

It "might" be easier to go down this route? Maybe use the logic here:
https://git.drupalcode.org/project/admin_toolbar/-/merge_requests/127/di...
to get the entity from route, or the one you used with the regex to go through the links of $items['admin_toolbar_local_tasks'] in the module file and dynamically build the correct URL.
In other words, moving more or less your code from admin_toolbar_tools/src/AdminToolbarToolsHelper.php to web/modules/contrib/admin_toolbar/admin_toolbar_tools/admin_toolbar_tools.module.
Then fixing the CSS/position of the link in the toolbar.

I don't know exactly what would be the best option to fix this and where these styles/JS come from (I haven't looked further than that), but we might have to spend a bit more time to think this though 🙂

I would definitely be very happy to hear your ideas and opinion on this.
Thanks again for the great work and help on this issue!

Oh wow I didn't know that the toolbar looks so crazy without Gin theme 🤯

The big problem is that the regular toolbar does not open on hover, only when clicking. Having a simple Edit link could work but then we lose all the ability to choose one of the other local tasks.

Gin solves it in a really nice way: On wider viewports you expand the tray when hovering and on narrow screens you get the "click to open" behavior which simply shows all the other local tasks.

➡️ I have attached a patch → so you can quickly test that without polluting the MR

Regular toolbar with "Edit" link that has icon

Regular toolbar with hidden "Edit" link when on entity edit form

Gin toolbar (wide) with separated "Edit" link

Gin toolbar (narrow) with try that opens on click

I would love if we could somehow get the UX that Gin provides otherwise I find that standalone "Edit" button a bit tricky from UX perspective :/

Thanks a lot Yannick (@yannickoo), once again for your very helpful and clear reply, with screenshots and all 🙏
Sorry for the delay on this reply, but a few other tickets were raised recently and also needed to be answer 🙂

OK, I have done a bit of testing and think it's super impressive 🤩

I've tested the Admin Toolbar module with the Gin Admin Theme → and its Gin Toolbar → and it seems to work quite well overall and be pretty well integrated 👍

I've tested all 4 modes and they all seemed to integrate Admin Toolbar's main features quite well, with Admin Toolbar Tools and Admin Toolbar Search:
(Gin theme toolbar configured at: /admin/appearance/settings/gin)

• New Drupal Navigation, Test integration New (Experimental)
• Sidebar, Vertical Toolbar (Default)
• Horizontal, Modern Toolbar
• Legacy, Classic Drupal Toolbar

 
See the screenshot below, as an example, with Sidebar, Vertical Toolbar (Default):

I've checked the Gin Toolbar module code a bit and it seems there is some kind of integration with admin_toolbar, see for example:
https://git.drupalcode.org/project/gin_toolbar/-/blob/2.0.x/src/Render/E...
or
https://git.drupalcode.org/project/gin_toolbar/-/blob/2.0.x/gin_toolbar....

The big problem is that the regular toolbar does not open on hover, only when clicking. Having a simple Edit link could work but then we lose all the ability to choose one of the other local tasks.

Indeed, it seems the regular (legacy) toolbar and the new ones have very different user interactions 😅
Lots of different styles, JS and theme logic...

With the direction things are going and the popularity of the Gin theme (in particular with DrupalCMS), it could be worth adding special cases to the admin_toolbar module to better integrate with Gin, what do you think?!

For example, we could add a special case for Gin to implement the link logic you already added to the MR, adding an "Edit" link to the Local Tasks dropdown tab (GIN).
The module already has plenty of code checking for module integrations, with devel, devel_php, project_browser, etc... so adding more module specific logic shouldn't be a problem.

I have attached a patch so you can quickly test that without polluting the MR

Thanks a lot for the patch! 🙏
I've tested the patch locally and it works very well! The "Edit" link seems to display properly, see the screenshot below:

I don't really have any preference here Yannick:
We could keep this issue focused on adding this feature for Gin, with the current MR in this ticket.
And, in a different ticket handle a default case (Legacy) which implements the logic from the patch from #19, with a more generic approach... (?!)

Or, we could also, skip completely adding this feature for the regular (Legacy) toolbar and just add the feature for Gin... (?!)
 

In any case, I think you already laid out the different code implementations for both features, great job! 👍
I personally think we should keep this ticket focused on your initial vision of the implementation of this feature, with the Gin Toolbar/Theme, and maybe, if needed or requested, implement in another ticket the more generic approach (default/from the patch).

We would greatly appreciate to have your opinion on that, in particular if this answer could help clarifying the scope of this feature and help moving the merge request forward.
Thanks in advance! 🙂