Allow to enable/disable menu additions
| Project: | Administration menu |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
On our site we want the option to switch users so we grant the permission, but we dont want it on ALL admin page loads because we have the following issues:
- a high traffic site
- lots of authorised users
- lots of users in the user table - about 100,000
Upon enabling the query logging, I saw that the devel_switch_user_list function runs 2 queries - each was taking up to 1 second each. I dont know why - all the columns involved appears to be indexed, although there was a mention of 'Filesort'. There is also the issue in D5 that the user table has a few columns which get updated on EVERY authorised page access causing the MySQL QCache to get wiped on the user table.
The result was that an admin would have 2 seconds added to every page load (+ the implied server load) which slowed the website down.
This patch adds a checkbox to the admin menu settings page and does a check when the menu is built. It defaults to enabled so, if included, current users wont notice any missing feature unless they go in and disable the menu.
It'd be really useful for me (personally) if this patch was included in the module.
Cheers,
Nick
FYI: The patch's MD5 is 8563B1D00F3800D581D61D5E8582BDA9
| Attachment | Size |
|---|---|
| admin_menu_switch_users_disable.patch | 1.86 KB |
#1
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.
#2
Good point about checking for devel, however in terms of SQL optimization I dont think there is a lot Devel can do and its only really a problem on heavy/large sites like PPOnline (15k unique visitors a day).
#3
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.
#4
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.
#5
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.
#6
sun: I like the AJAX "on demand" idea as an alternative. Nice idea!
Saying that, personally I've always wondered why there hasn't been a callback page with a "type in the username or uid to switch to here" box with a submit button (or maybe even autocomplete). But that's a Devel Feature Request.
My issue here is that Admin Menu is using a feature of Devel and, as far as I knew at the time, had no way of disabling it.
I've just tried that "disable devel modules" and its a neat feature - a quick toggle for the devel module. Nice touch!
Thing is - I WANT the devel module. I regularly need to "Empty Cache" feature and there are many occasions when I DO want to change user - but the user I wanna change to is often not one of the top ten in the Log Off menu.
I perfectly understand what you're saying about Developer A wanting the menu and Developer B not wanting it... Maybe in this case the tickbox in site config could be a "default" setting and each user with a certain role should have access in their profile to have it (or not)... But this is getting quite complex for such a simple thing.
Personally I see 2 options and I "rank" them (IMHO) as this:
#7
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)
#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.
#9
Nice - I look foward to it! Please contact me if you need any testing done :)
#10
Fyi, If it's any help I've re-included my patch from my inital post for disabling the Switch Users drop down and I've included a "devel" check. Could this maybe be included until we get "on-demand" menu's working?
Fyi, this code is for DRUPAL-5--2, but should work fine for DRUPAL-6--x...
#11
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.
#12
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.
#13
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.
#14
+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.