The inclusion of jQuery: hiding module package grouping has resulted in a net loss of usability on the admin/system/modules page.

a) Now, this page is completely useless until I click something.
b) Imagine you're someone who's never used Drupal before. What happens when I click those links? I have no idea. I won't know until I try clicking it.
c) How can I view at once all of the modules that are available to me to be enabled? I have to click once per grouping.
d) When I choose to set one of the options expanded, such as "Core modules (optional)", it reverts back to collapsed on the next page load.

I would advocate some combination of the following to fix this:

a) Rolling back this patch.
b) Adding some documentation at the top to tell people how to use this now confusing interface.
c) Placing some code like:

$form['#collapsed'] = $form['#collpased'] ? TRUE : FALSE

so that at the very least it remembers what I had done on the previous page load when I enable/disable some modules.

d) Some means of remembering last-collapsed-state of fieldsets so that they will remain that way each time that I visit this (or potentially any other) page. I'm thinking a cookie variable or perhaps something in $user->data.

One way or the other though, this needs to get fixed.

Comments

morbus iff’s picture

morbus iff
they/them
commented

I agree with chx. This is now as useful as admin/content/comment/settings.

Who decided that a form should have /all/ its elements collapsed? I thought collapsed fieldsets were to be used for optional, advanced, not-normal preferences? Both this page, and comments/settings is neither.

morbus iff’s picture

morbus iff
they/them
commented

Er, webchick.

profix898’s picture

profix898 commented

Do you really think the patch 'resulted in a net loss of usability'? I agree it might be a little confusing for new users, but once you know about collabsible fieldsets its much nicer than all modules displayed at once! So rolling back the patch is no solution IMO!
I'd vote for solution 'c': Remember the state of the fieldsets when the page is submitted/reloaded. 'd' could also be a nice one, but its a feature for Drupal 6 to implement a state-saver for fieldsets, I guess.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

@profix898 yes, I really, really do.

Unlike admin/content/comments/settings, which I will probably visit once, setup how I want, and then never touch again.. I am in the module administration page sometimes 10-20 times a day when I'm adding new functionality to my site. I've been using Drupal long enough to know that modules liek "path" and "upload" are one of the optional core ones, so that is one extra click for me each time I enable one of those, which alone is frustrating enough.

However, a new user isn't going to know that. They'll be clicking through all of the field sets trying desperately to find what they need to look for, finally finding it, then cursing up and down when they have to go back and find it again when they want to disable it or whatever.

I'm working on a patch for c), but the problem is that this fieldset stuff looks like it was hacked into the theme layer as opposed to into the form. I can't figure out a way to maintain "state" between one page reload and another, so it's looking like it'll take more time than I have to dedicate to this.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Active » Closed (fixed)

Actually, I'll close this issue and continue discussion over @ the main issue. I was trying not to derail that issue, but since further work is going into that patch, it makes sense to keep it all together.