Add option for node local tasks in toolbar

Cool idea, maybe we can make this a setting?

@breidert can you provide a patch for this?

How's it coming @breidert? We'd love to have this too and I'm willing to help. I was just about to re-invent this wheel.

Here is the patch, that adds the local tasks to gin_toolbar. The only thing left so far is the icon. It should be added to gin, I guess.

Patch in #9 appears to work perfectly (except no icon for the local task toolbar item, of course).

Re-rolled patch

Just a note that the patch in #12 is no longer working on dev. I'm getting:

Drupal\Core\Security\UntrustedCallbackException: Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was gin_toolbar_add_local_tasks_bar. See https://www.drupal.org/node/2966725 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 96 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).

the patch in #9 #12 is no longer working on latest betas.

I am late to this discussion, but I want to chip in the module Moderation Sidebar which works great on core's toolbar and basically puts all the local tasks into a sidebar already (hence the name).

However, it's not working with Gin Toolbar. Maybe you could join forces and support each other?

Setting status back to Needs Work according to #14.

Any update on this? I think the placement should be different, but that's something I can work on afterwards.

I will try to work on this this week, maybe even today.

I created the merge request with the updated functionality. Now pre_render uses class that implemets TrustedCallbackInterface.

Applied #21:

TypeError: Argument 1 passed to Drupal\Core\Render\Renderer::doTrustedCallback() must be callable, array given, called in /docroot/core/lib/Drupal/Core/Render/Renderer.php on line 781 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 51 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php).

Have you cleaned the cache after you applied the patch? According to PHP documentation array could be passed as callable if there is static method of class in array https://www.php.net/manual/en/language.types.callable.php .

Attached is a reroll, plus I changed/fixed the things noted below.

1. +++ b/gin_toolbar.module
   @@ -327,3 +331,73 @@ function _gin_toolbar_user__classic_toolbar() {
   +    $items['administration']['tray']['toolbar_administration']['#pre_render'][] = 'gin_toolbar_add_local_tasks_bar';
   

   Think we now need this to be a TrustedCallback.

2. +++ b/gin_toolbar.module
   @@ -327,3 +331,73 @@ function _gin_toolbar_user__classic_toolbar() {
   +  if (!empty($local_tasks['tabs'])) {
   

   This seems to always render all local tasks in the admin menu (even for admin pages not related to entities). I found that a bit confusing. Maybe only add local tasks if the URL contains a content entity?

3. +++ b/gin_toolbar.module
   @@ -327,3 +331,73 @@ function _gin_toolbar_user__classic_toolbar() {
   +        $items[] = $local_task['#link'];
   

   The link is missing some classes so the styling doesn't show up as expected.

4. +++ b/gin_toolbar.module
   @@ -327,3 +331,73 @@ function _gin_toolbar_user__classic_toolbar() {
   +        if (strpos($key, 'edit_form') !== FALSE) {
   

   Since view is mostly the first tab, shouldn't this also be the main link?

5. +++ b/gin_toolbar.module
   @@ -327,3 +331,73 @@ function _gin_toolbar_user__classic_toolbar() {
   +    // Add local tasks cacheable metadata to result build.
   

   This now only add the cache metadata on pages that have local tasks. That could mean another page could set the cache for the admin menu without local tasks, and after that the local task never show up. I think we should always apply the local task cache metadata since even when local tasks are empty, we did use them to build our output.

One other minor thing, the icon for the local tasks was already in the code, but it looks a little off. That might be a separate issue, but we could maybe fix it here. I think it is because the lines are a different width from the other icons.

Just found that when using the "admin_toolbar_links_access_filter" module you also need #3209342: Links without "original_link" are filtered by admin_toolbar_links_access_filter.

Actually needed a few more changes to make it work with "admin_toolbar_links_access_filter".

Looks good to me!
Thanks seanB.

Looks great for me!

Reroll MR2. Works now with beta17.

Noticed a few oddities here. Screenshots attached.

1. It looks like some classes are missing in Local Tasks, as menu items appear to be missing some styling (notably font styling and padding)
2. The order of these Local Tasks is a bit wonky. Noticing this on all routes that have local tasks (both front-end with toolbar and actual "/admin" routes. The order of the Local Tasks never seems to match what's outputted normally through Drupal. Not sure if there's a pattern, but consistently the last item seems to be outputted first, at least

Adjusted this, resolved the two issues I reported above. Modified existing patch with some additional attributes and respecting ordering.
Patch attached.

Tested path #34, works like a charm! Thanks!

Patch #34 is working perfectly for me as well. ​Thanks for the implementation! :)

I second the question from #3: shouldn't this feature have an opt-out setting for site builders who prefer to use the local task tabs and avoid duplication?

After using this for a while one of our clients found it confusing to have the local tasks and primary tabs so asked us to take this out again. I think it would be nice to have a setting to enable/disable this.

Hey all, I made a new related issue to this to add some more toolbar items my team needed.
I used the base of this new system from this current issue to extend to some other options, including Shortcuts and User Actions.

Depending on how this current issue moves forward, I'll watch to consolidate some stuff! Mostly didn't want to add to this issue as it's changed scope a bit for my need!

I hope to address some of the feedback here in that new issue as well, including the desire to make these a setting rather than just a default.

https://www.drupal.org/project/gin_toolbar/issues/3244394

Was using Better Local Tasks before but this is even better.
Patch #34 works great on beta20.
No visual clutter in the frontend anymore! Thanks!

I'm not convinced about this approach to add the local tasks to the toolbar. I think it's confusing since the admin toolbar links are global and the local tasks are, well, local. I don't think they should be mixed.

I'm personally more fan of the Better Local Tasks approach, I have been doing the same thing for my own projects in custom code: rendering the local tasks block as usual and apply custom css to it. Here's what that looks like, floating to the bottom right of the screen:

Another option is integrating it with the new meta region since there's already an entity edit link anyway, but the problem(?) there is that that region is not sticky, it disappears when you scroll down the page.

For those interested in testing the current implementation, here's a version of the patch re-rolled against the dev branch.

#41 Local tasks are working back for me with the 3.0.0-beta1 of gin and beta-21 of gin_toolbar. Thank you @DieterHolvoet.

I can confirm that https://www.drupal.org/project/gin_toolbar/issues/3244394 current implementation is outdated as @Nuuou said (I understood you were waiting on this issue to adapt your work).

Would be nice if it highlighted the active tab.

Just noticed that admin_toolbar has an option within admin_toolbar_tools that adds the local tasks to the secondary toolbar

@svdhout Thanks for letting us know! Looks pretty good to me.

Closing this in favor of the admin_toolbar solution mentioned in #44

I liked the way the feature was implemented here better, so I've rebased the code to get a new patch that would apply.

Re-rolled for rc4

Maybe move this to a separate module instead of re-rolling? The issue is marked as Closed (won't fix).

Can confirm thatt patch #49 works with rc4.
I understand DieterHolvoet. But we have several projects at our company that are using gin + gin toolbar + local tasks at this moment, and we need to be able to update them. Changing the patch to a rc4 compatible patch in composer is the easiest way to do that for us at the moment, until a tried and tested separate module for this actually exists.