Allow to enable/disable menu additions

Regarding SQL query optimization and possible caveats related to admin_menu, I'll wait for smk-ka's reply here.

Aside from that, setting to PNW because the configuration option would need to check whether Devel module exists (just like the running code that checks for the user permission). However, I'd recommend to wait for smk-ka's reply in front of posting follow-up patches.

Side-question: Is the "Enable/Disable developer modules" menu link in the icon menu not sufficient for you? From our experience, it became a best practice to disable all developer modules when there is no active development happening. When you need them again, just clicking on the same link will enable exactly the same modules again.

As long as the query can't be rewritten to make use of any index I suppose there isn't anything that we can do. Nevertheless, it seems like our sites are affected by this issue, too, so +1 from me.

Hm. Trying to think in use-cases and probability here - given the fact that we already have the "enable/disable developer modules" link, which completely avoids all development overhead in times it's not required - and - given the fact that the switch user list is only queried from the database if a user has sufficient privileges to actually switch to another user, which in turn limits those queries to a few users only - then my next best question is whether you really want to disable those switch user links for all developers at once, or just for yourself? (because you know that you don't need to switch users in the very next time)

So in short - are we sure that we want to disable those switch user links for all users at once? IMHO, it would lead to annoyance among developers (one does not need it currently, disables it, and another one will get upset about missing links).

Now call me crazy, but I always thought of this in the past: what if we loaded those (rarely used) links on demand only?

By hovering over the logout link, perform an AJAX request to retrieve a structured array or even already rendered markup of links, which are appended to the hovered item.

Rethinking based on #5 and #6: Only option 2 of your list, on-demand loading of switch user links, solves the original issue, because the links are only needed and used occasionally, but slow-down a site's performance on every page request for all developers.

Assigning to myself, and also adding the note that we were able to add a switch user autocomplete form field to those on-demand loaded menu items (hint, hint 8)

Refining and putting on the list of must-have features for 3.x. This is actually required for some other improvements for 3.x.

I think your issue is resolved in 3.x currently, because the entire menu output is cached now. I do not want to work further on workarounds, but instead work on the refined goal of this issue.

Reverting the scope of this issue. Moved the other proposal into #420816: On-demand loading of dynamic paths and local tasks #1.

admin_menu is available on drupal.org, but has been disabled, because of the user counter. With respect to aforementioned issue, we want to

- Allow users to enable/disable (toggle) certain menu additions, such as Devel's switch user links, admin_menu's user counter, flush cache links, and links to drupal.org.

- ... as well as toggle on-demand loadable sub-menus exposed by other modules.

Has any progress been made on enabling/disabling menu additions in general? Or customizing what items the menu displays? Contrib modules add a lot of clutter at the top level; ideally I'd like to move these things into a lower level as I might in the admin block via the menu system. Having the option to simply disable them would work as well, though.

+1 for being able to honor the menu.module settings for disabled/enabled menu items.

I am trying to turn off certain "create content" sub links for content that general users should NOT be allowed to create, but Admin Menu makes them visible even if the menu items are disabled.

I would really like to be able to disable the user count section of admin_menu; If this could be set as a configuration variable in settings.php (an array of items to disable), that would be even better than a checkbox in some administration section.

It would be nice to have more fine-grained control over other items as well...

+1 for the ability to disable time-intensive admin_menu features like switch users list and user counts. I don't care whether it's got a UI or just checks a variable.

Please give option to disable user-count. My sites using memcache-session, the user-counter has no meaning.

Thanks for great module.

My bug report about false user count was closed as a duplicate of this entry. If it is so, this entry should be a bug report, not feature request. False data shown to user shouldn't be treated in "it's not a bug, it's a feature" way.
Plus, if the session data exposed to user have no sense (sessions not in database), option to show them should be impossible to check, or at the very least guy turning it on should be warned.

There's a d.o project application that contains a pretty neat UI (see screenshot on project sandbox page) for this, and even allows to re-order the widgets/plugins:

#1735178: Administration Menu Elements
http://drupal.org/sandbox/fabioknoedt/1735066

Copying the implementation strategy/tasks from over there:

- the code in admin_menu_elements.admin.inc would be moved into admin_menu.inc.

- the main code in admin_menu_elements_admin_menu_output_alter() would be redone and applied to the respective output generating functions for the individual widgets throughout admin_menu instead. (This part might require some more thoughts, since admin_menu is actually prepared to allow for additional widgets/plugins being added by other modules, but doesn't expose a formal "registry" yet. Without a registry, we'd only ever know about admin_menu's own/built-in widgets and could only adjust those - so if another module adds something else, then that would probably appear at a seemingly random position... and could neither be enabled/disabled nor re-ordered. Adding a widget/plugin registry doesn't sound too hard to do though.)

- the OG group switcher widget would be contributed to OG instead. (admin_menu only contains Devel support built-in)

Attached patch for D8 implements

1) Configuration options on the settings page to toggle individual components of the menu.

2) A live preview. :)

Committed to 8.x-3.x.

For 7.x-3.x, I'm not sure whether it is safe to change the internal identifier for the 'user' links. There might be integration code somewhere that depends on the internal key (i.e., like the admin_menu_toolbar module). Chances for that are admittedly small, but I'm not sure.

It's nice to see this functionality incorporated in the admin_menu core. I'm testing already. Sorry that I didn't have time to make a patch, but I hope that my code in #1735178: Administration Menu Elements have helped in some way.

OK, I almost feared that the committed code was a tad too easy ;-)

Since #22 is a straight backport, and the follow-up fixes need to be forward-ported, attached patch is a patch-serial instead of a regular patch. Thus, the second contained patch is also the interdiff against #22. (In case anyone would care and actually review this... ;))

Does anyone know of an integration module that would break with the changed identifier of the user account links menu fragment?

Before: $content['user']

After: $content['account'] + $content['users']

Technically, we're still in RC-phase, so I'm not sure whether I should really care... :P

You know... we can still rename it back, if necessary.

Thanks for reporting, reviewing, and testing! Committed to 7.x-3.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Works awesome; just checked out the latest release, and with all the goodies included, admin_menu isn't really a performance concern for me anymore (was using rc3).

Was using 7.x-3.0-rc3+26-dev and after testing an upgrade to 7.x-3.0-rc4, the search box, user count, and shortcuts disappear until saving the admin_menu settings page. We need to deploy this out to 60+ sites running 7.x-3.0-rc3+26-dev which already have the search box, user count, and shortcuts available. How can I enforce these settings programmatically to get these options back so it isn't necessary to manually save the settings page on all sites? Thanks in advance.

Hm. I can see two options:

A) We add an explicit module update that enables all components on all existing sites that had admin_menu installed prior to RC4.

B) We just change the components that are enabled by default. Apparently, there's a mismatch between the default being used on the settings page and the default being used in admin_menu_output() anyway, which we should probably correct.

I'd probably lean towards B).

@sun: where should 'B' be set?

@sun: will this patch do it? Works for me on new installs and when I upgrade now. Patched against 7.x-3.x. Thanks.

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! :)