Improve "Move local tasks to menu" or remove the feature

Re-purposing.

I, for one, use the "Move local tasks to menu" feature on every one of my sites, and my designers love it because they don't have to factor tabs into their designs. In #590760: Move local tasks into menu with PHP, not JS, which has been rolled into this issue, I suggested moving local tasks into admin menu at the server with PHP instead of on the client with JavaScript for at least three reasons which I'll repeat here:

1. It seems inefficient to create HTML on the server only to have the client remove and replace it.
2. The aforementioned process (#1) can result in an experience like a flash of unstyled content where there is an initial rendering of the page followed by a sudden change.
3. Finding the tabs with jQuery is too sloppy. It's looking for ul.tabs.primary li. If your theme uses any other HTML structure to display them, they won't be found. It seems more fool proof to override tab display with a Drupal hook.

I would also like to see local tasks (when moved into admin menu) all fly out to display their children, even if you aren't on their pages. What I mean by that is that if, for example, you're viewing a Webform node, you'll see View, Edit, and Results local tasks tabs. If you hover over them, you won't get any dropdowns. However, if you navigate to the Edit screen, then you'll get dropdown options (Configuration and Form Components). The reason for this, of course, is that when the tabs are displayed staticly, in the page, there's no need to display anything outside the active path. Thus only that is shown in the HTML. Thus only that exists in admin menu when it's moved up with jQuery. But the expected behavior in a dropdown menu is that everything that exists is shown. Of course the only way to accomplish that would be on the PHP level, which I think is another good reason to move the feature there (into the PHP rather than jQuery). (@sun, I'd like to offer you a proof of concept or upload a patch, but I'm just learning module development, and I'm probably not quite at that place yet. Thank you for your understanding.)

Those are my initial thoughts and concerns. Perhaps some other folks would like to comment on how they use the feature. I find it so useful I'd be surprised if nobody else did.

@sun: sorry for butting in, but...

Please don't remove this feature. It is already optional (enabled only through the checkbox in the module's settings) and I think a lot of people might be using it. The only reason I can think of that could make you remove it is for easier maintenance of the module. Fair enough, but instead of removing it, please consider making it a submodule and move related code there.

I propose changing the issue's title to:

Improve "Move local tasks to menu" or move the feature to a 'Administration menu Local tasks' submodule.

Thank you in advance for (re)considering this.

I agree with @TravisCarden. It's a very valuable feature to have.

Hey guys,

As a project manager, CMS trainer, I love this tool. It's very convenient and is easy to explain to my customers. It just seems to make sense to keep everything in one location, at the top of the page.

I hope you'll keep this tool in production mode.

Thanks for considering.

"Move local tasks to menu" the admin menu can become quite jumbled.

Yes, it would be great if for example we could put them in a submenu. (and NOT remove this feature..!)

Suggestion for a quick-fix, first-start, given this issue was filed 4 years ago:

I imagine that as a first functional step this could possibly be as simple as a one-line patch..:

Just make a "LT" (or "Tabs", but very short, please...) menu parent reside at the end of the Management menu. A very quick fix will not let users define the path of just that parent, but simply point it automatically to the same path as its first sub.

Context / perspective / use case:

The Local tasks / Menu issue has been a long standing problem for quite a few people, with related discussions in various module queues and contexts. (a quick google search reveals that...).

From my standpoint, I am (only) looking for a non-coding/non-css/non-theme solution, to provide any content manager with; just the option to move things around and out of sight on selected pages/contexts/roles, etc., without the need of coding/assistance.

Dman has a sandbox module called "Local tasks as menu" over at
http://cgit.drupalcode.org/sandbox-dman-2042705/tree/?id=4d6390585ff2d9c...
(attached it a zipped archive of that module, please have a look and give feedback both here and to dman)

Then we have:
- https://drupal.org/project/local_tasks
- https://drupal.org/project/tabtamer
- https://drupal.org/project/blockify
- https://drupal.org/project/menu_block
- https://drupal.org/project/admin_menu (this one, obviously)
- https://drupal.org/project/password_tab (tab example with a use case complication example)

Here is an example on the various incompatibilities related to my own use case(s):

E.g. nodes and user pages.

• want to lift the page content up by placing tabs in either a drop-down menu like in admin_menu, or optionally in a block "somewhere". This is extra useful and relevant for small screens like mobiles/tablets, which more and more people are using to access drupal sites with.
• want to move some tabs "here", and some "there", and have control on where they will be visible. Example is moving the password fields first out of the user edit page, and then its new tab out of sight and perpans into a submenu or a block below the content. Whatever.
• depending on which extra modules are being used, and the role/permissions of the actualy user, the user and node pages causes the admin_menu to very quickly get completely overwhelmed and ugly, if not using a drop-down menu parent for the local tasks

However, considering the current status of some of the most relevant alternatives..:

• neither Local_tasks module, Blockify module, menu_block module nor dman's sandbox module are removing the originals (AFAICS...?): even if they manage to place the Local Tasks in a block, the local task "tabs" are still occupying the original space on top of the content area. I thought part of the point was to move them away from there...
• furthermore; hiding tabs with tabtamer means that the menu blocks modules will not "see" there are local tasks on the current page, and thus they will not be possible to move away with menu_block module.
• dman's sandbox module only works on the user page in its current state (but it actually works), but then we cannot use the tabtamer module to hide the password fields that was moved out of the user edit page using password_tab module, as that password "tab" url (user/%/password, as that module is creating), will be made available in the user menu. Disabling a menu item in the menu system is not a solution as the Content Mangers have access to re-enable those menu items, which in this case is what we dont want. The "disable" variant of the Tabtamer module will prevent showing the tab, but it does not prevent itself form generating a new password link.
• using something like the menu_item_visibility module just to prevent access to one or a few menu items would be overkill that would hurt performance too much...
• ...

Therefore, given the current state of "things", the fact that very many people have been looking high and low for some practical non-coder solution to this for many years, I suggest considering the following features in admin_menu:

1. allow for Local_tasks to be placed in a submenu of the admin_menu, at the end (on the right side), with a very short Parent menu name (configurable name, configurable path target for it)
2. in case we assume that admin_menu is the "master" or "host" of this feature, also for other modules; admin_menu might help the lacking function of the other modules in hiding/not rendering the local_tasks area on top of the content area, as this module currently does well, still allowing other modules like tab tamer and the others to hook in and get hold of those local tasks and place them in blocks anyway, even if/when the are also in the admin_menu submenu.
3. support the 3 states of tab tamer for related items: visible, hidden, disabled, still without making the items unavailable for other local_tasks modules...

Alternatively:
- I wonder if not we could have this functionality moved into the https://www.drupal.org/project/admin_menu_source module (as a kind of "sub module feature"), and let THAT module take over control over the above proposed hooked-on submenu parent... In that case, site admins can choose by role to have this functionality available also for non-admins and roles that does not have access to the main admin_menu. (that would be a feature request for that module instead, perhaps)

Edit:
Corrected a typo: (..."From my standpoint, I am (only) looking for a "non-css/non-theme solution"...)

Btw., even if this module currently does free up the local tasks (content) area to allow for the real content to move up to the top of the content region, there are a couple of issues with that:

The local tasks are clearly first rendered in that location, and then "grabbed" and moved up in the admin_menu on page load (they are firstly rendered in their original location), which seems possibly unnecessarily late ("unnecessary" performance issue?) in the process, and yet still the other modules does not manage to get hold of those items before they are moved out of sight, rendering the other local tasks modules useless. (module weight issue, perhaps).

I would think that if technically possible, this should be done earlier, not rendering the local tasks in the original location at all, and yet still make those items available for the other local tasks modules even after the items are moved out of the content area.

(some of the considerations clearly demands adjustments also in some of the other mentioned modules, but I think that the admin_menu should help making it possible to cater for the mentioned flexibility)

@Leeteq - I think you nailed it for me. Trying to extend specific local menu without having to redesign another menu is very important for content authors/webmasters/etc. Will look at https://www.drupal.org/project/admin_menu_source as a temp solution, but integration with this module is very important.

I am sorry for no reply until now.

There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.

We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.

However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.

So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?

Thank you for understanding! :)

This issue has been automatically marked as closed because it has not had recent activity after the last post.

However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.

Again, thank you for your contributions! :)