#76 admin_menu-overflow-height-687750-76.patch1.88 KBrobertgarrigos
#71 admin_menu-overflow-height-687750-71.patch1.88 KBrobertgarrigos
#69 admin_menu-overflow-height-687750-69.patch1.75 KBrobertgarrigos
#65 admin_menu-overflow-height-687750-65.patch1.65 KBsplatio
#64 admin_menu-overflow-height-687750-64.patch1.8 KBa.hover
#63 admin_menu-overflow-height-687750-63.patch1.79 KBa.hover
#43 screenshot3.png23.59 KBTravisCarden
#43 screenshot4.png22.89 KBTravisCarden
#40 screenshot1.png27.81 KBTravisCarden
#40 screenshot2.png26.13 KBTravisCarden
#31 admin_menu.long_.31.patch4.7 KBsun
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View
#24 admin_menu.long_.24.patch2.68 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.24.patch. Unable to apply patch. See the log in the details link for more information. View
#23 admin_menu.long_.22.patch2.52 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.22.patch. Unable to apply patch. See the log in the details link for more information. View
#21 admin_menu.long_.21.patch2.94 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.21.patch. Unable to apply patch. See the log in the details link for more information. View
#20 admin_menu.long_.20.patch2.41 KBsun
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.20.patch. Unable to apply patch. See the log in the details link for more information. View
#17 admin_menu-unfix_when_in_use-687750.patch1.03 KBdarktygur
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu-unfix_when_in_use-687750.patch. Unable to apply patch. See the log in the details link for more information. View
Members fund testing for the Drupal project. Drupal Association Learn more


donquixote’s picture

Menus below the fold is only one half of the story.
The other is, menus that push the body height, and cause a jumping scrollbar issue. This is especially relevant on pages with a small or fixed height.

For long pages, I don't mind to scroll the entire page, if my mouse does have a scroll wheel. And hey, admin menu is for admins, and admins have scroll wheels.

For shorter pages I see two solutions to avoid the jumping page height:
1. A scrollbar (overflow-y:auto) in the menu itself. I think I have seen this somewhere, and didn't find a problem with it.
2. Let the menus disappear to the left (left:-10000px) instead of "display:none;". This will push the bottom of the page down, even when the menu is not visible. However, this will make the entire page as high as the longest submenu - which is usually the list of modules on This might be unintended.
3. Make sure that the page does always show a vertical scrollbar. There is a documented solution for this, but I don't remember it atm.


One more problem I found: If the windows has no focus, the scroll wheel has no effect - but hovering does have an effect. You are stuck in the menu tree, because you would need to click somewhere to give the window focus - and this means, you need to leave the menu tree.

verta’s picture

I too, have reached the point where I have too many modules installed and admin_menu is too long for the screen. Frustrating.

sun’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
klonos’s picture

same here sun...

[copy-paste from #425832: admin_menu: implement mega-menus]:

@sun: please keep in mind that A LOT of people still use the D6 version and we surely want this. I mean, there is only 40-60 people trying the D7 while more than 110,000 use D6. Besides, if you implement this in D6 branch you'll have more people to beta test ;)


sun’s picture

Aren Cambre’s picture

subscribing from #425832: admin_menu: implement mega-menus

My opinion: scrolling menus will hurt usability badly because they potentially insert a "mess with a scrolling interface and things that are flying all over the place" step to find any menu item. Mega drop downs are superior to scrolling menus.

donquixote’s picture

Mega drop downs are cool, but:
- The information stored with the current Drupal menu system does not tell us how to arrange things in a mega dropdown.
- To solve the vertical space problem, we would have to use multi-column mega dropdowns, and these are not designed to have drop/fly-out submenus themselves.

I use a program called True Launch Bar on my desktop, and it has long scrollable menus with fly-out submenus. My entire filesystem structure is accessible through these menu. I did not have problems yet.

One trick why this works is that the scrollbar is on the left. But even when the menus fly out to the left (which happens after I reach level 4), the scrollbar is not in the way.

That said, I can well imagine how nested scroll boxes (especially with javascript effects) will be clunky and horrible on the web.

Aren Cambre’s picture

Well-implemented mega-dropdowns + good information architecture = no flyouts.

donquixote’s picture

Did you ever try ubercart, and count the menu items you get?
And do you honestly consider to arrange all CCK types and field instances in a mega dropdown, for a site with 20 types and each having 7 field instances? Even if you would manage to do this, the user experience would be horrible.

The benefit of flyouts/dropdowns is to have menu items out of the way if you don't want to see them. The admin menu typically contains a lot of things that you only want to see if you are explicitly looking for them.

Mega dropdowns are made for situations where you always want to show all possibilities (of one section of your site). This is a very different situation than what we have with admin menu.

good information architecture

Information architecture requires that you know the information. A generic tool like admin_menu knows nothing about the site you want to build.

What I propose is that you produce a nice editorial menu for your client, with the nicest information architecture that you can imagine. This is actually the same that i do - my clients will never see the admin menu (unless they want to do the admin stuff themselves). This menu will be special for every site I make, and I could imagine that in some situations I would make this a mega dropdown.

donquixote’s picture

I would suggest to solve this in separate modules.

admin_menu_scroll could define a js and a css file that would make the existing admin_menu scrollable.

editorial_megadropdown would be a customizable dashboard menu, with little in common with the existing admin_menu.

Aren Cambre’s picture

#10 (separate module) makes sense. I am sure this isn't the only module that could benefit from mega dropdowns.

TravisCarden’s picture

Title: Scrolling Dropdowns a Solution for Too Long Menus? » Seeking a Solution for Too Long Menus

I think @donquixote is correct in his assertion that mega dropdowns probably don't scale well enough to handle a dynamic (theoretically infinite) link set, and so is probably best suited to particular uses where it can be crafted to specific requirements. Scrolling menus scale much better, so they make a very good generic solution. Of course there are various styles of implementation. I personally would like one that let me use my scroll wheel—I think we definitely shouldn't require the user to click on a down arrow or anything like that. Then again, maybe we could let the user choose in the configuration.

donquixote’s picture

I played a bit with Firebug + admin_menu + overflow-y:auto.

Some problems I run into immediately:
- I get vertical and horizontal scrollbars. I guess I need to refresh my CSS skills?
- The scrollbars cut off the submenus that fly out to the right. Even worse, the flyouts make the horizontal scrollbar grow and shrink.
- If I scroll down and hit the end of a menu, the next scroll step will scroll the page instead. Trying to go back (scroll up one step) will not undo the page scroll, but instead scroll the menu up. This is a huge pain, and would require some evil javascript to fix.

Possible things to try:
- Wrap the ul elements in div containers (with javascript), if this proves useful.
- Try different CSS implementations: Don't make the li elements float, don't define a fixed width, etc. If it proves useful.
- Somewhere I read that direction:rtl would put the scrollbar on the left. No success with that so far.
- Higher z-index for deeper nested submenus.
- javascript to fight the vertical page scroll when you hit the end of the submenu scrollbar.

All of this appears hacky and ugly and unreliable to me, so I don't want this in the default admin_menu. For my projects I'm happy with admin_menu as it is now. Very happy. (I just like to write stuff in issues..)

donquixote’s picture

I had another look at the example

The submenu on the left ("Really Tall Menu") has 39 items, says my notepad.
None of them has a child fly-out menu.

The "Site configuration" submenu of one of my projects has 45 items, with submenus.
The "" probably has around 100.

A decent size for a submenu would be around 300px. With 100 items you would see a new item every 3 pixels of mouse movement.
The bigger problem is the sub-submenus, and how they will follow the scroll movement.

Now, whatever, let's just wait for some other contrib person to implement this.

sun’s picture

Please note that parts of the most recent discussion here are intermixing a unrelated feature request: #336611: Allow to configure different menu to use for certain roles -- Regardless of the administrative menu that is rendered, the menu can still be too long.

sun’s picture

FYI: I've re-opened #425832: admin_menu: implement mega-menus, because I now understood how mega dropdowns are supposed to work + look, which is entirely different from admin_menu's default styling.

darktygur’s picture

1.03 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu-unfix_when_in_use-687750.patch. Unable to apply patch. See the log in the details link for more information. View

We've been having the same problem, so I just created a patch that simply unfixes the menu while it's in use (so that when it goes off the bottom, you can just scroll down). When you're done, it fixes it back again.

I can expand the patch to make the new behavior optional if that's desired. If people like this solution, maybe this issue status can move to "needs review"?

I didn't even know about this issue until just now when I came around to gauge interest in the patch.

By the way, the patch was generated against version 6.x-1.5, because that's the version I use. I don't know if admin_menu.js has changed at all in more recent versions. I can make new patches against other versions too, if it is necessary. I would really like to see the problem go away.

sun’s picture


Doesn't solve the cause, but super-definitely solves the trigger.

sun’s picture

Status: Active » Needs work

wow, and @donquixote - sorry, I didn't really recognize your link to - that's actually exactly what I had in mind! We should definitely try to turn this into a patch, make it optional, and crowd-source feedback on it.

sun’s picture

2.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.20.patch. Unable to apply patch. See the log in the details link for more information. View

wow, just wow... on it.

sun’s picture

2.94 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.21.patch. Unable to apply patch. See the log in the details link for more information. View
CrashTest_’s picture


sun’s picture

Status: Needs work » Needs review
2.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.22.patch. Unable to apply patch. See the log in the details link for more information. View


All open todos are documented in-code.

sun’s picture

2.68 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch admin_menu.long_.24.patch. Unable to apply patch. See the log in the details link for more information. View

Resolves some further @todos, introduced new ones :P

sun’s picture

Version: 7.x-3.x-dev » 6.x-3.x-dev

At this point, this patch is against D6.

donquixote’s picture

Status: Needs work » Needs review

wow, and @donquixote - sorry, I didn't really recognize your link to - that's actually exactly what I had in mind! We should definitely try to turn this into a patch, make it optional, and crowd-source feedback on it.

This wasn't me, it was a quote from the topic starter. You need to read better :)
My own post was rather a critical reflection of that idea. The solution as advertised does not have sub-submenus, and I'm not sure how well they would work.
If this is going to make it into admin_menu, I would very much appreciate if it was optional. .. EDIT: and I also need to read better.

klonos’s picture

Status: Needs review » Needs work

First tests show that it seems to be working just fine. Even submenus. Even sub-submenus. Even sub-sub-submenus ;)

For example, tested in the ImageAPI menu:

Site configuration -> ImageAPI -> Configuration -> ImageAPI GD2

I didn't just hover to see the menu children open or simply look at the URL in the browser's status bar on hover. Everything really works!

The only (trivial) issue I came across was that it reaches almost at the end of the menu. It leaves two or three menu items off the bottom end of the browser and you need to scroll a bit. Minor thing as I said.

Now, all that remains to be done is (perhaps) some way to control the speed it scrolls + the @todos.

Thanx people for making a great module even greater! Keep it up.

sun’s picture

Priority: Normal » Critical

@TravisCarden & everyone: Sorry for not properly reading this thread. I already lost hope when I first saw it, as we had another (duplicate) issue languishing around for 2 years until I finally won't fix'ed it... ;)

@donquixote: Although we can make it optional... heheh - did you try the patch? It's an entire rewrite of that script/plugin, which works smoothly with expandable sub-menu-trees. ;)

@klonos: Thanks for testing! A couple of questions on your feedback:

1) Which browser/platform did you test on?

It leaves two or three menu items off the bottom end of the browser and you need to scroll a bit.

2) Does this happen on all levels or only on the third-level and below (i.e. below expandable items)? I'm asking because it didn't happen for me, and my "test" was to open Firebug (docked) and make the Firebug console almost as large as the window, so I was able to test various menu lengths.

(perhaps) some way to control the speed it scrolls

3) Is it too fast or too slow? Originally, that script was convoluted with some accelerated animation depending on the menu length. I found it totally wonky and unusable that some menus scrolled faster and some slower. On my client/browser (which is not really representative), the speed is just right. Though I yet have to test on a real client.

klonos’s picture

1) I basically use firefox nightly builds (latest 3.7pre alpha releases) on WinXP SP3 and that was what my previous feedback was based on. I have various testing environments available though (I even have a Mac OSX setup laying around) and I can test if need be. I had the search bar open at the bottom and initially I thought that this was the culprit, but disabling it had the same result. In the meantime I tested it on IE8 as well and it doesn't happen there. All the above was in a 22'' monitor with 1680x1050 resolution.

I also tested both firefox 3.6 (vanilla profile - no status bars) and IE8 on my laptop that has a 1366x768 resolution. There, the menu items left off the bottom end are like a dozen or so. That is in both browsers.

I then went on and tried your test with firebug in order to shorten the viewable area. Again in this case more than a few menu items are left off.

From all the above I came to the conclusion that it is not browser specific. Even in the large resolution monitor the issue might only appear in firefox due to the toolbars + multiple tab bars used making the viewable area shorter.

I can provide screenshots that display the situation if you need them.

2) It happens on 1st level only (my sub-menus aren't that long, sorry). To be exact it only happens on the Site configuration menu, since I have a lot of modules and that is the only menu with enough items so that the menu can reach the bottom of the screen.

3) Actually too fast I think. I noticed that the scrolling effect 'stops' over items with sub-menus, but I guess that it is intentional + I personally want that to behave this way. The only side-effect of this behavior is that if there is a series of items with sub-menus on a row (4 or 5 of them for example), when the mouse pointer reaches the last item with sub-menus and moves down to the next one without, it short of 'jumps' there. That fact in combination with the fast speed makes you miss/skip a menu item or two and you need to move up again.

All the above tests and behavior notices were made in a custom theme. I can switch to a core theme and test again if you want me to.

All these aside, this still remains a great improvement and I didn't expect it to come bug-free in the first run. All I mean to say is that all these quirks seem necessary (minor)evil to me compared to the improvement introduced. I am confident we'll sort these issues out in time ;)

Thanx again.

Dave Reid’s picture

Wow....that's actually...really awesome. Only wish it didn't scroll so fast. :)

sun’s picture

4.7 KB
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

Now including excessive insane menu tree testing code. Make sure you have a max_execution_time suitable for development/debugging sites. ;)

donquixote’s picture

Could someone publish a demo?
I don't have a patch tool and test environment available atm..

sun’s picture

And this testing tree reveals that it's totally broken :P

klonos’s picture

Re-testing all quirks reported in #29 with most current patch v31 from post #31...

- This fixed the issue where a 1 or 2 of the last menu items were off in the large monitor with the 1680x1050 resolution. So, it now works perfectly for both firefox and IE8. The issue quirk still remains in the low res monitor in both browsers and the items off are about a dozen or more.

- The quirk where the menu 'jumps' and skips a few items when mouse leaves a series of menu items that have sub-items, still remains.

- I didn't realize any change in the speed, but it was several hours back since I tested patch v24. So, I either don't remember the feeling of the previous speed or I am simply starting to get the hang of it. Whichever it is, it's good news ;)


klonos’s picture

PS: I've just realized that you use post numbers to version your patches and in #22 CrashTest_ just hit the save button before you ;)

So, in my above post instead of 'patch v31 from post #31', either 'patch 31' or 'patch in #31' would suffice.

[Sorry for polluting the issue queue]

klonos’s picture

If I may... I would like to propose two small improvements.

For most people, the only menu that seems to be getting rather large and reaches the height of their browser's viewable area is the 'Site configuration' (most modules like to add entries there). So, for most of us, this feature would apply mainly (if not only) to that menu. Well... unless we use firebug in small-size monitors of course ;)

Moving from one menu to another feels the same. With this feature added, moving to the 'Site configuration' menu feels as if it uses a different logic. If not much of a trouble, can you please make it so that the css trick is activated only when someone hovers over say the 4th or 5th menu item and moves downwards? Perhaps that threshold could be the 50% of the viewable area or 50% of the menu size?

Also, as it is now, the css places the scrolling menu above the admin menu row. As a result, the current menu's title is not visible while the scrolling menu is activated. Perhaps placing it a level behind the menu row would be better(?).

Trivial thingies. I can live with them though. If you decide they are nice to have additions, but other things are critical right now, you can add them to your @todos.

Thank you in advance.

boabjohn’s picture

This is marked for review?

I've just upgraded to 6.x-3.0-alpha4 and have the tickbox set to keep the menu at top of page. I don't see any change in behaviour for long menus. (FFox 3.6.3/WinVista)

Should I be applying the patch from #31? Wasn't clear: the patch seemed to start off against 6.x-1.5...

The Admin Menu rocks. Thanks for an absolutley core piece of Drupal usability.

stephesk8s’s picture

This worked awesome for me. Super easy. Perfect. Thanks!!!


benone’s picture


I used admin_menu.long_.20.patch and its great in FF3.
This is most admins browser. It should be released like that for dev.


TravisCarden’s picture

26.13 KB
27.81 KB

I tried #31, and it's very exciting! But I do experience some issues with it, namely with submenus that appear incorrectly positioned (as depicted in the attached screenshots) and with items that can't be clicked because the menu disappears when you get close to them or scrolls past three at a time. Great job to everyone that's working on this! It'll be great when we get the kinks ironed out!

klonos’s picture

...the menu disappears when you get close to them or scrolls past three at a time.

True! This issue still remains. @Travis: can you please confirm that this 'jumping' or 'skipping' of some menus happens only after hovering past menu items that have sub-menus?

TravisCarden’s picture

@Travis: can you please confirm that this 'jumping' or 'skipping' of some menus happens only after hovering past menu items that have sub-menus?

I'm not sure I can confirm such a thing, @klonos; I'm sorry. I'm unable at the moment to reproduce the exact behavior I was describing then. Using @sun's massive menu tree, however, I can confirm at least the following problems:

With my browser window sized to 1600 × 1024:

  • Hovering over Dropdown test > 36th-level item > 5th-level item > 3th-level item > 4th-level item > 1th-level item causes the whole menu to disappear.
  • If I Alt + Tab away from the browser and come back, I can't get the final level of the above tree to fly out at all. If I refresh the page it reverts to the above-mentioned problem.

With my browser window sized to 800 &times 600:

  • When I expand Dropdown test > 36th-level item only the first of its children expands at all.
TravisCarden’s picture

22.89 KB
23.59 KB

I meant to attach a couple of screenshots:

chriscoyier’s picture

Hey folks,

Nice to see the menu scroller thing I tinkered with potentially being put to good use. Let me know (emailing me at is the best bet) if there is something I can help with related to that specific functionality. Looking back through the comments on that post someone linked up an idea to prevent the menu from going beneath the fold too, which is kinda neat:


TravisCarden’s picture

In case it got by anybody, @chriscoyier is the curator of CSS-Tricks, home of the article I kicked off this issue with. He created a username just to offer us his help!

klonos’s picture

Good news. Welcome on board Chris!

a5342346’s picture


a5342346’s picture

just checking -- there hasn't been a DevRelease of 6x-3x since 2010-Mar-12 ...

possible to refresh *with* this fix so we can test? or, is the presumption that we apply patch (@ #31 ?) to the 2010-Mar-12 release?


tzoscott’s picture

Here's a quick hack workaround that will work for some people: differently sized menu items for different menu items.

This could solve some user's problems such:

a) Admin Menu "wrapping to two lines" (it does if you have a non-widescreen monitor and then you install Ubercart, Project and a handful of other modules needing "top level" Admin menus).

b) Cascading menus becoming too long to fit on the screen

c) Maybe you want to shrink stuff most of your team never uses, or color-code menu items, etc..

Here's the CSS to do just that. Put it in a CSS file that loads AFTER admin_menu.css. Worst case, tack it onto the end of menu_item.css (but you will need to re-apply when you upgrade the module...)

Here I wanted to style top-level menu for Advanced Help, Help, and Project:
#admin-menu li a[href="/admin/advanced_help"],
#admin-menu li a[href="/admin/help"],
#admin-menu li a[href="/admin/project"] {
font-size: smaller;

OK. Now let's say you want to style all the menus nested UNDER something - meaning all second level menus.
Target the URL same as above, but use the ^= "begins with" in attribute selection so you cat aim at a commonly-shared href value:
#admin-menu li a[href^="/admin/project/"] {

NOTE: [href^="/admin/project/"] would only target the nested items because the parent menu item's href does not match (notice the extra "/" on the sub-menus... as in "/admin/project/...")

EDIT: Here's how you would shrink all the "Create Content" menu items... I should have made that my example as it's the most common request...

#admin-menu li a[href^="/admin/node/add/"] {
... You can also specify font-size in pixels, but the smaller/larger type keywords tend to play nicer with different platforms..

EDIT2: This was tested on FireFox 3.6.3 only. I didn't look into cross-browser testing or browser hacks in the CSS (it's an Admin bar and everyone here uses FireFox).

a5342346’s picture

checking in for news on this, is the available update,

6.x-1.x-dev Download (51.16 KB) 2010-Jul-11 Notes

'real', or an artifact of yesterday's

"Packaging script incorrectly removes -dev tarballs when there's no new code to package"


EndEd’s picture

#31: admin_menu.long_.31.patch queued for re-testing.

lolandese’s picture

Tested patch from #31.

My config:

  • XP
  • Toolbar Style activated
  • Using the latest version of all mentioned browsers
  • Drupal 6.19
  • Trying with a 54 item long list
  • A few other JS inserting modules are active, like Feedback and Floating Manager Menu
  • Tested on both a simple older netbook and a bit more powerful notebook (sorry, I don't use desktops)

Browsers (from best to worst perfoming with this patch):

  • Chrome and Safari (Windows version) OK
    • 14 items not reachable on the netbook screen (h:600px)
    • Scrolling pretty smooth, even on the netbook.
  • Mozilla OK
    • 25 items not reachable on the netbook screen (h:600px). Might depend on my minimum font size settings.
    • Scrolling was the smoothest of all browsers
  • IE8 (on the notebook) OK
    • Could not test how many items were unreachable on the netbook screen. On the notebook all items were reachable.
    • Scrolling pretty smooth
  • Opera (on both netbook and notebook)
    • Functionality works the first time or after cache clear, but might disappear after using it a bit on the same page. Magically it might appear again on a new page. Can not reproduce. Seems quit unpredictable behaviour. It's not crashing though and still working like without the patch.
  • IE7 (on the netbook)
    • Slow, unacceptable slow, to open the dropdown on hover (>20 sec). Made a comparison with a similar site with only Toolbar Style but without the patch applied. Both make the opening of the dropdown on mouseover slower, but the patch in an extreme way. I have to say that I have all mentioned browsers opened contemporarily on my poor netbook.

I use Chrome and Safari, the other ones only for testing purposes, so I am very happy. The patch seems to work for most browsers, except IE7 and partially for Opera. Thanks a lot for your work on it.

After using it a while, noticed that sometimes the dropdown drops down itself, sometimes even disappearing from the pages. Result is a gap between the main menu bar and the dropdown. When you move down your mouse pointer that starts always on the main bar, the dropdown closes before you had time to reach it. Sometimes it happens more than others, on both long and normal dropdowns and doesn't seem to be browser related.

powery’s picture


serenecloud’s picture

As a temporary workaround there is a patch for the alpha4 3.0 release that allows you to disable Admin menu items. #282775: Hide disabled menu items - Comment #11

Macronomicus’s picture


markc0826’s picture

When I use Cygwin to Patch the file "admin_menu.long_.31.patch" at #31
have some error below:

$ patch -p0 -b < admin_menu.long_.32.patch
patching file admin_menu.js
Hunk #1 FAILED at 198.
1 out of 1 hunk Failed -- saving rejects to file admin_menu.js.rej
patching file admin_menu.module
Hunk #1 succeeded at 67 <offset -15 lines>.

How can I do anything?

klonos’s picture

Try to apply the patch manually:

lpalgarvio’s picture

while waiting for a patch, a different approach would be to re-organize the management/admins menus, so they are nested, but is unpratical as automated solution. you have to do it manually per site.

or use instead Admin, as i do

sun’s picture

Version: 6.x-3.x-dev » 7.x-3.x-dev
klonos’s picture

Title: Seeking a Solution for Too Long Menus » Cannot access menu items in too long menus when the menu is set to stick at the top of the page.
Component: CSS / Browser Support » User interface
Category: feature » bug
Status: Needs review » Needs work feature request can be critical and the issue reported here breaks the module's functionality. So, we should definitely consider this a bug. It is not specific to any browser and there is no flaw in the CSS to fix. This has to do with an architectural problem of the UI when menus get too long. When they do, the issue occurs in every browser AFAICT.

The issue was set to "needs review" back in 2010 and there's a patch available in #31, but I believe that it was for 6.x. Anyways, it was a really long time ago and it needs to be rolled for the 7.x branch ...that is if the way we choose to go back then is applicable in 7.x and still viable.

The issue summary does have the original report but does not reflect the discussion. It should sum up any proposals made and/or decisions taken since then. What are we doing here? Do we have a solution figured out? From what I recall, the two most discussed proposal were either to go with #425832: admin_menu: implement mega-menus or implement Chris Coyier's solution for very long dropdown menus.

If everyone (and most importantly @sun) agrees with these changes I propose, I'm willing to go through the issue and update the summary in order to help with evaluating the ideas proposed in the past and possibly coming up with a solution.

Let me know.

klonos’s picture

...just a thought: converting admin_menu to a mega-menu might indeed solve the issue at hand, but I think introduces the risk of 2+ level menus not fitting the screen width (we solve the "too long" issue but risk introducing a "too wide" one). Besides, doing this conversion probably means re-writing the way the module works almost from scratch.

I believe that the js solution for too long menus (btw, should we call this method "scrolling menus"? - it seems fitting) addresses the issue based on the architecture we currently have and thus will require less work. So, I think it's worth trying first.

klonos’s picture

...take a look at this: #1586374: New toolbar

a.hover’s picture

I needed a solution for this on a project and have created a patch based on Chris Coyier's Solution For Very Long Dropdown Menus mentioned in the original issue description. The other patch on this thread is now very out of date and didn't seem to work.

My patch is not 100% there - probably needs cleaning up and any edge case issues fixing so people should feel free to have a bash at sorting what I've done so far.

a.hover’s picture

Updated new patch to fix an issue.

splatio’s picture

Fixed file path in patch from #64.

izmeez’s picture

Patch in #65 doesn't apply to admin_menu 7.x-3.x-dev
Manually applied changes and it works somewhat but not completely.

Without patch a long menu list like the modules list extends to bottom of browser window and is stuck.
With patch the long menu of modules scrolls as an independent column but doesn't show all modules, only goes about three quarters of the way down and then disappears as if user has moved off the menu.

DrCord’s picture

This seemed to work at first but is buggy. You can no longer access the top items in the long menu list as it won't scroll all the way to the top, only the bottom.

robertgarrigos’s picture

Applied manually patch at #65 and works great. No problems reported, nor even #67. This should be included definitelly.

robertgarrigos’s picture

Status: Needs work » Needs review
1.75 KB

Created patch for 7.x-3.x-dev after #65. As I said it works for me.

schifazl’s picture

Status: Needs review » Needs work

This doesn't work for me. I have a long list of views under Structure -> Views and it still goes off screen

robertgarrigos’s picture

This patch works stlitghly better.

robertgarrigos’s picture

Status: Needs work » Needs review

The last submitted patch, 64: admin_menu-overflow-height-687750-64.patch, failed testing.

The last submitted patch, 65: admin_menu-overflow-height-687750-65.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 71: admin_menu-overflow-height-687750-71.patch, failed testing.

robertgarrigos’s picture

Status: Needs work » Needs review
1.88 KB