[development] Modules page rework
rz10 at cornell.edu
Sat Jul 29 16:49:59 UTC 2006
Nice step forward, Earl.
On Jul 29, 2006, at 12:18 PM, Earl Miles wrote:
> It's greyed out in the 'enable modules' section because you can't
> an already enabled module.
I suggest filtering the enabled modules out of these lists
completely. I.e. enabling a module moves it up to the enabled
section, so the only thing listed below is disabled modules. This
gets rid of greyed checkboxes in the lower section, as well as a
bunch of duplicate info on the page.
> 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?
I think it's a good idea. Whether some functionality is implemented
in a required module or somewhere else in drupal core is completely
irrelevant to the users of drupal, no? I'd completely get rid of the
required modules from the modules page. This gets rid of more greyed
I suppose a "Show required modules" checkbox somewhere, un-checked by
default, would be even better.
> 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.
With Derek's (and others) work to real versions/releases for contrib,
this is clearly an essential piece of info.
>>> 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.
Going with my first suggestion to remove enabled modules from the
lower section, turning it into a disabled modules section, why not
have a consistent layout for enabled and disabled sections? Either
include a packages column and put them all in one table (as you have
for enabled modules) or put them in separate sections and leave out
the packages column. The latter allows you to collapse a section and
hide details, the former would allow the possibility of a user
My 2 cents,
More information about the development