[development] the past, present and future of drupal admin
larry at garfieldtech.com
Thu Jul 27 18:29:15 UTC 2006
On Thu, July 27, 2006 1:06 pm, Earl Miles said:
> Larry Garfield wrote:
>> On Thu, July 27, 2006 12:05 pm, Earl Miles said:
>>>So, coming back around, my personal belief is that systems with large
>>>administrative pages should have their settings with the administrative
>>>pages. Systems which have, basically, only settings, should have their
>>>settings in the Settings block.
>> Wait, didn't you just say exactly what you just said is bad? That some
>> things are under admin/settings while others are under just admin, and
>> there's no clear reason why for any of them?
> Only if either I misspoke or you misread.
Either is possible, I guess. :-)
>>>Additionally, what I was trying to set up is that contrib modules should
>>>have their settings in the 'modules' block. If for no other reason than
>>>because when you enable new stuff, chances are it'll either create a new
>>>system (ecommerce is something I would expect to just have its own
>>>administrative block) or it will put itself into the modules section.
>> Random data point: For whatever reason, when my brain says "I want to
>> change the settings for the foobar module", my hand clicks the modules
>> link. Why? I think it's because my brain thinks modules -> settings
>> rather than settings -> module. I'm not sure how common that is, but
>> after more than a year my hand still won't pay attention and go where
>> supposed to.
> And this is why I want modules to have their settings in the modules
>> Which brings up yet another question: Should settings be clustered by
>> module that provides them in the first place (admin/settings/foobar), or
>> by the type of activity to which they belong (admin/content_types and so
>> forth)? Right now we do a little of each, which I can't see as a good
> By 'right now' do you mean current Drupal or the patch I'm working on?
Current Drupal. I've not tried your patch yet.
More information about the development