[drupal-devel] [feature] Enhance hook_settings - add an optional 'advanced' tab

[Jose A Reyero]

Issue status update for 
http://drupal.org/node/30515
Post a follow up: 
http://drupal.org/project/comments/add/30515

 Project:      Drupal
 Version:      cvs
 Component:    system.module
 Category:     feature requests
 Priority:     normal
 Assigned to:  moshe weitzman
 Reported by:  moshe weitzman
 Updated by:   Jose A Reyero
 Status:       patch (code needs review)

+ 1 for the concept


I think we are always trying to find what is an imposible balance
between ease of use  (less settings) and options/flexibility (more
settings), so having simple and advanced settings would be a good
thing.


However, about the implementation, I wouldn't like having an 'advanced'
tab, so from an advanced administrator's point of view you would have to
guess which settings are in 'simple' and which ones are 'advanced' to
find them.


I'd rather have a single page having all settings -that would be more
if you have that advanced permission. So you can just return all simple
settings as deffault, and then a few more if the parameter is
'advanced', and then we'd need to rewrite that settings hook only when
additional advanced settings are provided.




Jose A Reyero



Previous comments:
------------------------------------------------------------------------

Tue, 06 Sep 2005 16:05:53 +0000 : moshe weitzman

Attachment: http://drupal.org/files/issues/hook_settings.patch (25.19 KB)

This patch opens the door for advanced preferences in Drupal. If you
have sufficient permissions, you will see an *advanced* tab on settings
pages when a module chooses to put stuff there. The permission is global
across all Drupal - 'access advanced functionality'.


This patch enhances hook_settings so that it accepts a $type parameter.
By default, $type='simple' and everything works as today. If modules
return HTML when $type=advanced, a new tab appears on the settings
page. To see this in action, visit admin/settings/aggregator applying
the patch and after giving yourself the permission above. The patch
appears long only because of whitespace changes. It is a minor change
to all hook_settings() implementations.


This 'advanced tab' paradigm can be used outside hook_settings as well.
Just protect your tab/feature with the permission above. 


Contrib modules will continue to work without patching but will show an
duplicate tab called 'advanced'. To fix, just add an if($type ==
'simple') block in hook_settings(). I will add upgrading instructions
to drupal.org and update hook_settings() docs if this is committed. 


I feel that this is a good balance between those who repeatedly yell
for 'fewer settings' and those who want their site to work a specific
way but are uneager to hack the source code. This 'advanced settings'
paradigm has worked well for Mozilla project (about:config) and many
others. If these advanced features clutter and bother you, don't enable
this permission or don't click on the advanced tab. There is no way that
Drupal becomes a cluttering steaming pile of configuration options - our
culture precludes this. Lighten up, and give the people what they want.
We can't expect everyone to hack the source to get commonly requested
behavior.


I also simplified upload config by renaming upload_admin() to
upload_settings() and removing an unneeded menu entry.




------------------------------------------------------------------------

Sun, 11 Sep 2005 05:28:51 +0000 : moshe weitzman

i'd like to hear some comments from CVS review team on this. If not
desired, alternatives are appreciated.




------------------------------------------------------------------------

Sun, 11 Sep 2005 06:10:03 +0000 : Crell

This was discussed recently on the -devel mailing list, and for reasons
discussed there I have to -1 this in concept.  An "Advanced" tab means
the UI designer failed to properly design the UI to discourage the user
from doing stupid things.  That's not something we should encourage.


If there are too many configuration options in some module for them to
be just shown linearly (I don't actually know many modules with that
problem), that's what <fieldset> is for.  


If some module has enough options that even <fieldset> isn't enough,
then rather than hard-coding an "advanced" tab we should allow
arbitrary module-developer-defined tabs that all get the extra magic of
the settings page.  The $delta methodology of hook_block() would be a
good model to follow here.


If you just want to split some options off as "Danger, Will Robinson!",
frankly I can't think of any good examples.  Perhaps you could offer
some?