Modules Page Confusing - Groups modules by directory.

This has been bugging me for a good long time, and my first attempt at code to fix this proved monstrous. Merlin got it going far more simply than I was attempting, and a few more changes to this patch should make it perfect (as we're discussing on IRC). Woot.

Minor update - changed the default 'modules' (based on the name of the directory) to 'individual modules'. The patch doesn't yet work with sites/something.com/modules.

I will review this properly tomorrow but I'd love to see this in 4.7 -- we always say that UI betterment can get it, aren't we? And this is definitely something that makes the modules screen easier to read.

Also we would like to endorse contrib authors to work together -- it'll be better if modules in a 'bundle' would stay together.

>> we always say that UI betterment can get it, aren't we?
Agree, now can someone please take a look at this one?

Sorry, for hijacking, but I couldn't resist.

Mmm. I've always advocated against using "multi-module modules" (modules groups). This patch would not have been necessary if people were not using multi-module modules to begin with.

At the moment, I don't support this change, but I'll wrap my head around it once more.

Rather than adding small usability improvements, and pushing for inclusion in 4.7.0, please focus on fixing critical bugs. We all want to start writing new features, including myself.

The focus is clear: fixing critical bugs.

I'm making this a "feature request" (meaning I won't see it until after the 4.7.0 release).

I'm sorry, merlinofchaos. I am myself tempted for new or non-critical issues, but Dries is right here:
http://lists.drupal.org/archives/development/2006-03/msg00285.html

Dries: Thanks for that.

I can see this would be very useful for ecommerce. Dries, I was wondering how you would deal with the 30+ ecommerce modules (including contributed modules) issue. Og is another suite. Do you think ecomm and its included modules should have been released as one big module? How do you recommend that modules that relate together or depend on each other be indicated on the modules page? It has become confusing and hard to sort out.

Dries, while I agree with you most of the time, I'm not sure I do this time. People can put off pet projects only for so long. It seems like the list of critical bugs for 4.7 never ends, and there is no end in sight. I don't know if it's because one fix causes something to break elsewhere, as merlinofchaos mentioned in his thread on automated testing. It seems to me people can put off pet projects for months if there is an end in sight, i.e. they know 4.7 will be released by a certain date. I wonder if otherwise it starts to feel like the task of Sisyphus. I guess I'll start a list of useful patches that users can install on their own but are waiting for the 4.8 release. (I do agree with feature freeze in general.)

ae2005, do not give up hope. I count less than a dozen critical issues now, and three is ready to be committed. That makes the count eight. Four has patches to be reviewed. What about revewing http://drupal.org/node/51415 ? Or http://drupal.org/node/42388 ?

@ Dries: Multi-module modules and API modules seem to be increasingly popular, and I'm not surprised. For many complex tasks, it really is the best way to factor down the code. Particularly when a monolithic module would be huge, enabling only the pieces you need is a big performance boost. Some sort of patch like this is or will be necessary, sooner or later.

As for whether or not to commit it now, I'm also very wary about breaking anything at the moment. It seems to work properly for me, but I've not had the chance to test it extensively.

That said, guessing which module group a module should go in based on its directory seems problem-prone to me. Wouldn't a .install-based self-declaration work better, as well as account for modules in any of the various and sundry places that modules can be? Yes, that means a larger fix that should probably wait for early 4.8/5.0.

I am also wondering if fieldsets wouldn't be better than one big table. Especially if, as you say, ecommerce is 30-something modules, that's a BIG list. Collapsing fieldsets make sense there. Of course, with the project module now starting to support categorization of modules, perhaps we'd want to allow modules to be grouped that way as well / instead?

I guess my point is +1 on the concept, but I am wary that this can be solved "right" within what's left of the 4.7 development cycle.

I completelly agree that some sort of modules grouping is a must right now and I don't see an easy workaround. I'm very interested on Drupal as a possible enterprise application platform. On that sense modules as ecommerce, helpdesk, erp or cmr are basic. How to built an all-in-one module for ech of those? The ecommerce module is a good example as it has many submodules that could be required on some installs and not for other users, so that demonstrates that there is no sense to a big all-in-one-ecommerce module.

What is true is that maybe some of this basic options could part of the cms core libraries and that's another issue. That, at least, would require a good whitepaper for addressing future developement.

My impression is that once you set a big project with drupal with lots of modules you got a modules page on your drupal's admin area which is huge, where is really difficult to find things. That's awful. That's something that someone that doesn't manage a big drupal site knows.

I'm bumping this... I'm using the patch from #7.

It is really difficult to work on a cck / ecommerce site without this module. While I agree with Dries notion that multi-module implementations are generally the wrong way to go, they are here and appear to have valid use cases.

I give it a +1, and the code seems to be good.

I'd like to see a screenshot.

This is based on directory, which is isn't ideal. There are 672 'individual' modules in contrib head, 29 doubles, 14 triples, 8 quadruples, and 9 with more. So thats about 8% (yeah, its skewed to modules power users don't use) of modules that will move due to this. One notable example is organic groups, which seems to have 13 modules in it and 17 related, but outside (with some duplicates).

Ideally, this should match the categorization we have on Drupal.org for consistency. That raises some technical issues I won't get into now.

On the code side, I think the 'individual modules' heading should be removed, and those not indented.

Attached are some screenshots...

The directories may be a less than ideal grouping system, but it works. And if you're installing modules you can put related modules (like the og modules) in the parent modules folder and it shows up appropriately.
I have an imagefield folder inside of my cck directory, so apparently only the top level directory is used for the grouping.

here is another screenshot.

based on merlin's comments and the fact that I am using this patch on nearly every install I have, and am thankful for it, I give it a big +1 and set it back to review.

I think the fact that 'packages' will normally come as a single download and probably live in a singlefolder, you can even nest the contribs for a 'package' and they will show up. Is very valid... While seeing 20 modules that are grouped as 'X' on drupal.org is good for finding a module that you need. I think once you've selected the set of modules you are going to use, this classification is less necessary in the admin screen.

Re-Rolled patch for cvs head. I'm sure merlin's current work on the admin page probably supercedes this functionality. But I find the module admin page perfectly acceptable without all the fancy buttons, and the simple checkboxes.

oh yeah.. and a patch...

I have a row called 'individual modules' which looks really ackward. It looks like the table's HTML code is broken, or something. The GUI needs work before it can be committed. Just make seperate tables separated by clear headers (without fieldsets)?

For just labeling the tables without collapsing magic, just use a table caption. Any other pretty-ifying should be done via CSS.

I like the idea of grouping modules, but I question the implementation.

Why are you grouping by what directory the modules are in? There is another patch that is working on a metadata ini file for the modules. This is for dependancy, version control, and other things. Would like not be better to use the metadata for the grouping, instead over what directory the modules are a part of.

If a user of drupal, downloads a module and unzips it into the main modules directory. It has the change of being categorized incorrectly. A good example is with CCK. There are some modules that are not part of the main CCK, but as a standalone module (like some of the date stuff).

Just a thought!

Don't really take this patch seriouly... i'm just keeping it up to date since I use it to simplify module administration, until the modul metadata patch gets done. I don't even think merlinofchaos is keeping up with it, and can be switched to fixed for cvs once http://drupal.org/node/76340 hits core. This is still a potential solution for 4.7 sites and current cvs sites.

module grouping is now possible via the new .info-files. Marking this as a duplicate of http://drupal.org/node/81740