[development] Modules page rework

[Earl Miles]

Morbus Iff wrote:
>> 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
> 
> * We've moved away from .sql to PHP .install files. * Inis are easy
> to parse for PHP, but PHP is even easier! * It presumes a "new"
> format that a developer has to know. * Your comments about
> translations are valid.

All of these are valid.


> Likewise, I don't like the idea of having multiple meta-files hanging
>  around. There's been lots of talk about not having to load in help
> files for every module load, and that means sticking them in an
> external file. I'd hate to have an .ini, a .help, an .install, and a
> .module. There should be a .module (the code), an .install (get the
> code running) and a .meta (or whatever, to describe the code).

Where'd you get that there'd be a .ini and a .help, etc? I only have one
.meta file and it never even occurred to me that there might be multiple
meta files. This confuses me.

> * The page is too wide. I /hate/ tables that are meant to be single
> lines that then wrap (yes, that drupal.module description assaults my
> sensibilities every time!). Remove the word "modules" from the
> package name. We know we're on the modules page.

Are you saying this just because sepeck took his screenshot at an
unusually wide browser width? Otherwise, I don't get what you mean by
'too wide'.

> * I'm not sure I "get" the links thing. Why should they be in here?

Many (many many many) have said that they feel the most logical place to
look to administrate a module is in the modules section. And it makes a
great deal of sense to me as well. I consider this an additional set of
links to a module's administration pages. It makes things easier to find
by providing an alternate path.

> * Why is help greyed out? In fact, I don't "get" what the greyed / 
> active checkboxes are for? What's the purpose of this entirely new
> and unfamiliar UI element?

It's greyed out in the 'enable modules' section because you can't enable
an already enabled module.

> * I don't like the "required modules" section. It doesn't seem 
> important to have this bit of information break from the alphabetical
> listing of the modules page. To some degree, I wonder if we even
> should list these modules /at all/. If they're so important as to be
> absolutely required (yes), then why should the user need to know
> about them? They are as necessary as bootstrap.inc, so should be as
> invisible as that. This can reduce the size of the page too.

I'd never really thought about simply hiding the required modules
entirely. I'm not sure that's completely a good idea, but I'm not
against it, either. What are other opinions?

> * The version number is irrelevant and useless for a huge number of
> reasons. One, users don't upgrade core modules with out updating
> core, so there's no reason to have the version number for every damn
> line. Two, contrib modules don't have version information at all. A
> views.module that is a  4.8.0 release doesn't tell me anything when
> your July 2006 version is miles better than your January 2006
> version. Here, you're using version to mean Compatibility, and if
> that's what we're aiming for, we need big red warning letters, not a
> string of numbers that can get lost in a column of duplicates.

This is a step toward allowing contrib to *have* version numbers. And
no, I'm not using version to mean compatibility, it's just that core
modules are going to have all the same version numbers. But as I said,
what a contrib module puts there *is arbitrarily set by the author*. So
even without the nice product release system, at least with this a
module author can set a version number in a module's release, and when
some commits go in, increase the version number. Now, when bug reports
are filed, the module version number can be reported. Please, tell me
again this is a bad thing.

> * "drupal core modules" -> "core modules". Think Civicspace.

Well if I do away with the word 'modules' in the list (go all the way
back to the top of this message) as you suggested, that's just 'core'
and a little too short. Also, I think 'drupal core' is more descriptive.
  I like moshe's suggestion that 'drupal' could maybe be replaced by the
install profile name or descriptor, perhaps. But even if you're using
Civicspace, there are still drupal core and civicspace core modules and
they are different things, and personally I'd want them categorized
differently. It makes upgrading Drupal a little easier.

>> a) Enabled modules are currently sorted only alphabetically. Should
>> they be sorted by package, then alpha? I'm torn on this one.
> 
> If the packages mean anything to contrib, then yes. This would be how
> ecommerce and CCK and og would stick together on the page, no?

Yea, this was a silly question and I knew the answer was yes as soon as 
I typed it.