[development] Modules page rework

Ray Zimmerman 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  
> enable
> 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  
specified sort.

My 2 cents,


More information about the development mailing list