[development] Best practices: Config settings

[Daniel F. Kudwien]

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
http://drupal.org/node/126646):

"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
module.
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."

Regards,
Daniel