Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Unfortunately, litwol fails to understand the meaning of setting a project release to 'unsupported'. I've contacted him multiple times and reset the status of Util 5.1, but no luck.
So, attached patch collapses all fieldsets on admin/build/modules - doing it via JS turned out to be actually the proper and easier way to do this. :)
Missing:
- Configuration setting needed for this?
- JS code should be dynamically invoked by a variable in Drupal.settings to not slowdown performance on all other pages.
Questionable:
- Should only fieldsets containing no selected modules be collapsed?
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | admin_menu-DRUPAL-5--2.js-modules.patch | 726 bytes | sun |
| #7 | admin_menu_js.patch | 549 bytes | chellman |
| #6 | admin_menu.patch | 525 bytes | chellman |
| #4 | admin_menu.patch | 578 bytes | chellman |
| admin_menu-DRUPAL-5--2.util_.patch | 679 bytes | sun |
Comments
Comment #1
sunComment #2
chellman commentedThis isn't working for me with the 2.5 release, and it certainly seems like it's supposed to. I'm using the default, 1.0.4 release of jQuery — does this require jQuery Update to work, by any chance?
Comment #3
sunow... that's possible. We might need to replace
[id^="system-modules"]by#system-modules. This code was actually in preparation for #111719: FAPI fails to check auto-generated IDs for uniqueness - XHTML validation fails..Comment #4
chellman commentedOddly enough, I just tried this, and it worked much better. I've attached a patch that updates this, and also has a regex that checks whether the page we're viewing is, in fact, the module admin page.
Comment #5
sunThat regex is not needed, because Drupal.settings.admin_menu.tweak_modules is only enabled on admin/build/modules.
Comment #6
chellman commentedRe-rolled. I don't even know if it helps for me to do this or not, but I'll do it anyway.
Comment #7
chellman commentedIt's definitely not helpful to roll the patch with a bug in it. Trying again.
Comment #8
sunJoe, do you see a jQuery 1.0.x compatible way for selecting the form id?
I'm running several sites where #111719 actually is guilty for XHTML Strict invalid output. For any reason, also the system_modules form gets a cleaned ID, even though it is only output once on the page. Anyway, that is the reason why I had to use jQuery's attribute regex selector.
Comment #9
chellman commentedThis seems to work:
$('[@id^="system-modules"] fieldset:not(.collapsed)').addClass('collapsed');
The difference is the @ sign at the beginning. You take a pretty big performance hit doing it this way; Firebug's profiler is giving me around 60ms for the # version, and over 1200ms for the attribute selector version. Still, it does work.
If I read that issue correctly, I guess the patched form.inc is going to give you something like id="system-modules-1"? Because the # version is so cheap, I'd almost be inclined to go with two or three calls that use it instead of the attribute selector version. A hack, yes, but quite a bit faster.
$('#system-modules fieldset:not(.collapsed)').addClass('collapsed');
$('#system-modules-0 fieldset:not(.collapsed)').addClass('collapsed');
$('#system-modules-1 fieldset:not(.collapsed)').addClass('collapsed');
By the way, this is the page where I found the jquery information.
http://docs.jquery.com/API/1.1.2/DOM/Traversing/Selectors
Comment #10
sunok, if we go that way, does this patch work for you?
Comment #11
chellman commentedIt does work, yes. And it's nice and snappy.
Comment #12
sunGreat, thanks for contributing.
Comment #13
sunCommitted.
Comment #14
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.