[development] the past, present and future of drupal admin

[Larry Garfield]

On Thu, July 27, 2006 12:05 pm, Earl Miles said:

> Modules that come with Drupal core put their settings largely in the
> 'site settings' block. *However*, systems that also have large-ish
> administration pages put their settings near those administration pages.
>
> As I watched Drupal move through 4.6 to 4.7 and actually 'split' some
> administration tasks between settings and regular administration tasks,
> my brain hurt.
>
> For one, how do I, the user, know which as an administrative task and
> which is just a setting? Unless I'm already familiar with the system, I
> don't. Even if I'm already familiar with the system, I may not, because
> the division may be purely based on how the data is stored, and only a
> developer is really going to know that.
>
> Shining example, or The One That Killed Me:
>
> Menu system. menu.module in 4.7 launches with a 'Primary Links' block,
> and you put links in it for them to become primary. But you can change
> which block that is. But where do you change it? That's right, now where
> the primary links block is, but...yes, in the settings.
>
> Talk about a common question on #drupal-support, too. 'Edit Primary
> Links' takes you to admin/menu but if you want to just get rid of the
> link, you actually have to go to admin/settings/menu ...
>
> 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?

> 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 it's
supposed to.

Which brings up yet another question: Should settings be clustered by the
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
thing.

--Larry Garfield