[development] Modules page rework

[Earl Miles]

While waiting for the admin patch to finish gelling, tonight I got 
started on the modules page rework I want to do.

First, here's the screenshot (thanks sepeck): 
http://www.blkmtn.org/node/347?size=_original

1) I'm using a module metadata file. It's a .ini file, because that's 
easy. All the discussions I've read/been involved with in the past 
showed the .ini file as being the least offensive of the various 
possibilities (of which there are many) due to the fact that it's 
extremely simple to code, and very familiar to use. One problem I 
immediately have with the .ini file, however, is translations. My best 
solution is to run items from the meta file through t() and modify the 
string grabber to grab appropriate strings from the meta file 
automatically? Not sure how we tag them, though. Maybe we put them as 
t() and then strip them? I welcome suggestions.

2) The meta file contains the following:
* description (replacing the hook_help call)
* version (arbitrarily filled in by module author)
* package (currently: required modules, drupal core modules, contrib -- 
contributed modules can make stuff up if they need, but are otherwise 
encouraged to list themselves as contrib. *this is just an idea for now, 
but I think it's the easiest to get behind because it doesn't do *much* 
categorization but allows us to solve the problem I think needs solving).
* links -- a list of administrative links (I couldn't think of a way to 
collect this automatically; possibly we could modify the menu system to 
mark them in some way which would be more consistent?)
* dependencies -- (not implemented, but basically a list of modules that 
must be active before this module can be activated. It's a very simple 
dependency system and has flaws but we should start simple and improve 
over time rather than trying to get it completely right the first time).
* drupal version -- what drupal version(s) this module works on. Only 
the major and minor numbers (i.e, 4.8) will be used. 4.8.x is assumed to
have a stable API).

3) Given the above, I've reorganized modules by 'package'. The checkmark 
is moved to the left which is slightly easier. Throttle is gone entirely 
from here and will be its own page. The uncategorized module you see 
there is a module without a metafile; it will probably actually be 
disallowed in the future, rather than listed as uncategorized. This 
forces modules from 4.8 onward to have meta files, which forces a lot of 
useful things, such as modules only being allowed to be turned on if 
they have the password. I mean meta file with drupal version #.

4) Oh yea, I meant to automatically put 'help' links in the links 
section, but those aren't there yet. Those can appear, however, with 
relative ease.

I'm actually much happier with what I've started than not, but I'd like 
to get some discussion on this. I think this is a good direction to take 
the module administration page.

Some specific questions I have:

a) Enabled modules are currently sorted only alphabetically. Should they 
be sorted by package, then alpha? I'm torn on this one.

b) is 'drupal core modules' too long and should maybe just be 'drupal 
core' (and by extension, 'required' ?)

c) There isn't a c) that's all I can think of just now.