[development] Best practices: Config settings

Daniel F. Kudwien news at unleashedmind.com
Wed Jan 2 13:43:52 UTC 2008

Slightly OT, but admin_menu module is using two approaches that could be
interesting for this discussion:

> -----Ursprüngliche Nachricht-----
> Von: development-bounces at drupal.org 
> [mailto:development-bounces at drupal.org] Im Auftrag von Greg Knaddison
> Gesendet: Mittwoch, 2. Januar 2008 12:13
> On Jan 2, 2008 12:59 AM, Khalid Baheyeldin <kb at 2bits.com> wrote:
> > On Jan 1, 2008 6:49 PM, Gerhard Killesreiter 
> <gerhard at killesreiter.de> 
> >
> >  Also, admin/settings/MYMODULE is the most obvious place to find 
> > settings  for MYMODULE.
> For this specific case I think you are right, but we also 
> have a real problem of "too many menu entries and pages" in 
> the admin/ area.
> People look at that jumble and (still) get overwhelmed.  
> Re-using existing forms reduces that problem.

Especially on full-blown Drupal community sites, the list of settings pages
becomes so big that it no longer fits on smaller screens. The proposed
solution (http://drupal.org/node/196772) is to group all settings pages
below admin/settings after the module 'package' information in .info files
and move all Drupal default system settings into a new sub-group 'System'.

AFAIK, the package info is currently used on the admin/build/modules page
only. While I'm not happy with the categorization there (often finding
myself searching through all collapsible fieldsets for a certain module to
enable/disable), it makes sense to re-use the same categorization for other
purposes like the admin/* and admin/settings screens.

Two benefits: Module settings are comprehensible categorized, and module
maintainers are encouraged to add meaningful package information to their
.info files (which is not always the case).

> For some more concrete evidence - I have never seen an issue 
> for a module that uses admin/settings/MODULE that said "I 
> just installed your module and can't find the settings page." 
>  I _have_ seen issues where core forms are form_altered that 
> say "I can't find the module settings - this module is 
> broken" (e.g. http://drupal.org/node/198015
> )
> We are choosing between the lesser of two evils (busy admin 
> area, easy to find/control settings).

As of now, admin_menu does not provide regular module settings. However,
there are some variables for development to make the output of admin_menu
more verbose. Providing those variable settings on an own settings page
didn't make sense from a usability view of regular users. Thus, admin_menu
allows to configure these variables on the settings page of Devel module.

This adds another benefit (quoting from the corresponding Devel issue

"I my opinion, any development related settings should be kept together at a
central place. Just think of a Drupal site you are developing/releasing for
a client - I assume that you do not want to give your client the chance to
enable or alter any development settings. To circumvent this, a reasonable
solution is to provide all developer settings in the Devel module, because
access to devel can be permitted separately from access to any other module
- without introducing a new developer access permission for each and every
In case of Administration Menu it's even more reasonable: It does not have a
settings page yet. And AFAIK, it is not the only one."


More information about the development mailing list