Add package grouping to module page using .info files

tested and works. This is a very helpful addition.

Patched only this diff to fresh head without any of it's dependent patches and it works as advertised.
Added views to test grouping of views package, see attached screenshot.

RTBC?

First commit: http://drupal.org/node/81631

More info:
Due to: http://drupal.org/node/81631#comment-131430 this patch now includes some of the code from 81631 but did not keep up whilst that patch evolved and thus can also not be committed before 81631.
We have two options:
a) First commit 81631 and then reroll this patch to sync with the changes in head after 81631 goes in.
b) Combine the two patches to be committed once.

Seeing this patch is exciting. The attached shows the sense of normalcy that returns to an ecommerce installation.

Option b) from #10: The whole kitchen zink.
This patch is http://drupal.org/node/81631 and http://drupal.org/node/81740 rolled into one patch.
If you feel both are adequite then commit this patch and mark #81631 as fixed and something our children will only giggle about...

This patch serves a secondary purpose in keeping our sanity for it is rolled up against head.

The hidden option c): Ain't there always 3 options.
The difference between two local directories, one which is the patch of http://drupal.org/node/81631 (this patches dependency and also commonly referred to as the notorious dependency patch) and the other the combined effort of grouping packages by name and dependency checking.
I.o.w. this is the split between the two and only caters for package groupings but cannot run as stand alone.
If #81631 was committed first then this diff will take you the full 9 yards.

Based on screenshots I'm all for this patch... Having three sites running cck + ecommerce using merlin's group by directory patchfor 4.7, I'm already using module grouping and would totally freak out if it wasn't a part of my local install base.

So +1 the concept as a very necessary Usability improvement for 5.0.

Local directory diff after re-roll of http://drupal.org/node/81631 because of system.module changes on head as per http://drupal.org/node/82441
This patch is dependent on http://drupal.org/node/81631 because it uses the same form and trying to roll it separately is a nightmare. We all like this visual enhancement but we desperately need dependencies sooner than later. I guess we can live with either/nor, your decision.

Washing my hands on this now.

Tested and all working => See attached scrrenshot.
Hope to see this and accompany work, which has come a long way since, all snugly together again in 5.0.

It's not done till its, done...
Found bug: enabling a dependent whilst disabling a dependency goes through unattended.

bug fixed: the validate hook failed because the $form contains $form['package']['modules']['#value'] to group the modules and this overwrote the $form_values['modules'] instead of using the $form['modules']['#value'] as was intended. Maybe we spotted a bug in fapi?
Changed $form['modules'] to $form['validation_modules'] to use $form_values['validation_modules'] instead.

As per previous patches this patch is dependent on http://drupal.org/node/81631 first run that patch and then this one.

Please review and RTBC.

+1 to patch, it works beautifully! The modules page is much more organized and streamlined with the patch.

Why not group packages in a fieldset? That way we have collapsible built in ;-)

Subscribing

haven't tested the patch, but definitely would love to see this in core this release.

However, looking at the screenshot, would it make sense to move "required" modules down to the bottom of the page so you don't have to scroll past it each time you want to actually do some administration here?

looks real good to me. will be helpful for organic groups. minor nits:

- change 'drupal core modules' to 'Core - optional'. we already know that every row here is a module
- change 'Required modules' to 'Core - required' for consistency.

I am omitting the word Drupal because it doesn't add much, and in the world of install profiles it kinda subtracts from our goal of enabling branded distros.

I also noticed the function module_parse_meta_file($filename) which is misnamed IOM (we use .info files now, not meta) and might duplicate an existing function?

Works perfectly and well done with the neat theme abstraction for this functionality neclimdul.

Rerolled to fresh head since changes to system module: http://drupal.org/cvs?commit=41775
Changed package names as per moshe's suggestion.
Added doxygen comments for the new package key in the .info module descriptors.
Can't find any reference in head to module_parse_meta_file($filename) it is correctly named _module_parse_info_file($filename) in module.inc please advice.

New screenshot with views added as example of other packages.

Nit: the patch for system.module has some extra trailing white space that needs to go.

The re-sorting of groups seems uncessary. Even if you want to force Core - optional to be ahead of Core - required 4 lines later you jam the required modules at the end of the array. Also it seems to me it would just be easier to leave it as an alphabetic sort so you don't hard code any groups in system.module, just makes for more complexity should things need to be changed later on. Required modules won't be at the end of the table, but they should be after the optional modules.

Themeing wise this causes the tables to also be of different width and column widths, seems less pleasing on the eye at least on my widescreen.

I think it's much better not to separate between optional and required modules and to have only one package for drupal core.
And to name it Drupal core. The module dependency uses the term Drupal core too.

And instead of Uncategorized I prefer miscellaneous.

The primary reason to split out 'required' modules was because I feel that when required modules are mixed in with the rest of the modules, it's a little cluttered, and it was a very sensible split. The whole 'required' module aspect is a little daunting to some people, and there is a lot of question from the new user perspective as to why we list them *at all*. They're just taking up space. YOu can't really affect them, they're just there for informational purposes -- yes these are modules. No you can't do anything with them.

Moving them out of the way retains the informational aspect, and gets them out of the way of a user who is trying to accomplish a task. In My Not So Humble Opinion, from a usability perspective the required modules are In the Way; they obstruct usability. Your Mileage May Vary.

We could ALSO do weird things like grouping core modules by basic function, but I don't think we'd ever get agreement on how some of the modules are grouped. So I don't actually recommend that (though it'd be kind of a cool theming remix to do it that way)

Tables are looking much better and much less code.
Lets get this in and add ajax-magic in the next issue.
Screenshot added... RTBC?

I went over this closely. All I did was revert back to Uncategorized since that is a more accurate description of what is going on. Lets send this to the committers.

I happen to agree with merlinofchaos that 'Core - required' group should be forced to the bottom. Not willing to override kjartan right now so lets hear an opinion from other committers. that can happen in a subsequent patch.

Committed to CVS HEAD. Thanks folks! :)

I don't mind some sorting as such, just that the original code to perform it was pretty horrible. Why loop through an array to find two elements when you know exactly what they are called so can just call them directly? Overall I would rather see the amount of code that goes in for grouping modules to be as small as possible, as we are in a code freeze the less new code added the less new issues should be caused by it.

As for the naming of groupings I'd rather leave that to the usability experts out there. I would kinda worry that having the default as Uncategorized might prompt contrib modules to include a package: tag and split the modules admin page into dozens of groupings with one module each. Although having the default be Misc gives a strange impression as well, Non-Core is just terrible as well so that wouldn't do. Contributed modules might work, but not all non-core modules would be in the contrib repo.

Nit: should Uncategorized be wrapped in a t() ? And now that I think of it can the .info files be translated at all?

Kjartan you are probably right about the translation, well spotted. The module descriptions are wrapped in t() :

$form['description'][$filename] = array('#value' => t($file->info['description']));

But this is actually why I am leaving a comment: http://drupal.org/node/87639 for all subscribed.

Dotting i's and crossing t's... after further investigation the package names do pass through t()

$output .= '<h2>'. t($package) .'</h2>';