Best practices: Config settings
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, my question is: Where should contrib module authors put config options for their modules? 1) Should this always be the individual module's settings page? 2) Should it try to add the config option to a more generic place (either provided by core or another module it depends on)? 3) Should it add it to both places? Concrete example: I've added a performance related variable to event module. The value of the variable decides whether to do a full node load for each event on a calendar or to only use title, start, and end date from one mysql query. Now I need to put the UI for this variable somewhere... The variable also has influence on the theme you use since you can't print out any other node content fields if they aren't there. The event functions that event.module ships with for example expect the presence of a teaser field. In principle, I think that the variable should be set at admin/settings/performance but who is going to look there again after each newly installed module? Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHetFwfg6TFvELooQRAtEXAJ9sU3W05FUyTydSeI85m5XeQRL0RQCeO78A pXSmapndM+S87aiVN3gYed0= =Ood9 -----END PGP SIGNATURE-----
In principle, I think that the variable should be set at admin/settings/performance but who is going to look there again after each newly installed module?
killes and I were discussing this in IRC, and I took the view that contributed modules should try not to modify core settings pages. But I can see both sides. In the case of extending a theme, for example, you want to add to the theme configuration page. But I typically never look twice at the 'performance' settings page. So I'm not sure that my original stance of "contributed modules should never add settings to core screens" is correct. The best case may be: make sure you document that you add settings to default screens. Has this ever been debated? Documented as best practice? - Ken Rickard agentrickard
Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
my question is: Where should contrib module authors put config options for their modules? <snip> In principle, I think that the variable should be set at admin/settings/performance but who is going to look there again after each newly installed module?
Right. That's why I'd advocate for under admin/settings/<yourmodule>. If you want, what you could do as a workaround is place a drupal_set_message() (or hook_help()) on other pages that could be affected by your setting that point back to the settings page. For example: admin/settings/performance: Event module has an option that can increase the performance of your site by reducing the amount of data retrieved when showing a list of events. See the <a href="@settings">event settings page</a> for more details.
As a usability advocate I would push more for form_alter()-ing core forms when appropriate (like your example). As this makes logical sense. However, considering that most users who care about this variable are probably advanced drupal users, they will look for it first at admin/settings/YOURMODULE.
If you want, what you could do as a workaround is place a drupal_set_message() (or hook_help()) on other pages that could be affected by your setting that point back to the settings page. For example:
I think a better compromise is to put the form item ON BOTH forms. AFAIK there is nothing wrong with this technically, but I'm not sure. Bevan/ -- Drupal.geek.nz | Gtalk bevan@lucion.co.nz | YIM rudgy_m_nz | .Mac/AOL b.rudge | skype b.rudge | Twitter.com/BevanR
I agree that the best answer is both places. There is no reason to get caught in either/or thinking. I also I think this is the right answer to Khalid's issue about per-node type settings as well. Sometimes you want to deal with all the settings a particular node type has, but other times you want to just change one setting for all the node types at once. -tao Bevan Rudge wrote:
As a usability advocate I would push more for form_alter()-ing core forms when appropriate (like your example). As this makes logical sense. However, considering that most users who care about this variable are probably advanced drupal users, they will look for it first at admin/settings/YOURMODULE.
If you want, what you could do as a workaround is place a drupal_set_message() (or hook_help()) on other pages that could be affected by your setting that point back to the settings page. For example:
I think a better compromise is to put the form item ON BOTH forms. AFAIK there is nothing wrong with this technically, but I'm not sure.
Bevan/
Tao- Is this double positioning an acceptable solution from a general usability standpoint? If so, I'm all for it and we should make it standard practice. - Ken On Jan 3, 2008 4:23 PM, Tao Starbow <starbow@citris-uc.org> wrote:
I agree that the best answer is both places. There is no reason to get caught in either/or thinking.
I also I think this is the right answer to Khalid's issue about per-node type settings as well. Sometimes you want to deal with all the settings a particular node type has, but other times you want to just change one setting for all the node types at once.
-tao
Bevan Rudge wrote:
As a usability advocate I would push more for form_alter()-ing core forms when appropriate (like your example). As this makes logical sense. However, considering that most users who care about this variable are probably advanced drupal users, they will look for it first at admin/settings/YOURMODULE.
If you want, what you could do as a workaround is place a drupal_set_message() (or hook_help()) on other pages that could be affected by your setting that point back to the settings page. For example:
I think a better compromise is to put the form item ON BOTH forms. AFAIK there is nothing wrong with this technically, but I'm not sure.
Bevan/
On 1/4/08, Ken Rickard <agentrickard@gmail.com> wrote:
Is this double positioning an acceptable solution from a general usability standpoint?
I think so, but I'm not certain. This is perhaps something we could test in the lab http://groups.drupal.org/node/7878 (although probably not this session) Bevan/ -- Drupal.geek.nz | Gtalk bevan@lucion.co.nz | YIM rudgy_m_nz | .Mac/AOL b.rudge | skype b.rudge | Twitter.com/BevanR
I also think 'both" is the right answer. On Jan 3, 2008, at 8:50 PM, Bevan Rudge wrote:
On 1/4/08, Ken Rickard <agentrickard@gmail.com> wrote:
Is this double positioning an acceptable solution from a general usability standpoint?
I think so, but I'm not certain. This is perhaps something we could test in the lab http://groups.drupal.org/node/7878 (although probably not this session)
Bevan/
-- Drupal.geek.nz | Gtalk bevan@
On 04 Jan 2008, at 3:10 AM, Ken Rickard wrote:
If so, I'm all for it and we should make it standard practice.
If we do so, I don't think we should leave it up to module developers to have to do the heavy lifting of form_altering the forms it should appear on too. Perhaps we should provide a mechanism for registering settings, that also allow you to specify groups for them. This would move away from just providing a form (passed through system_settings_form), but might also end up being more consistent (all modules would have settings pages automatically created for them, provided they have settings, and it would allow module uninstall to delete those related settings, and an easy way for install profiles to provide defaults).
And since I was just visiting http://drupal.org/node/197720, I'd like to mention it would also reduce memory usage -- a Good Thing. :-)
All I know about usability comes from reading the book "Don't make me think", so I won't pretend to be an expert. But this seems like common sense, like having the same function in an application be available in the menu and as a right-click context popup and as a keyboard shortcut. cheers, -tao Ken Rickard wrote:
Tao-
Is this double positioning an acceptable solution from a general usability standpoint?
If so, I'm all for it and we should make it standard practice.
- Ken
On Jan 3, 2008 4:23 PM, Tao Starbow <starbow@citris-uc.org <mailto:starbow@citris-uc.org>> wrote:
I agree that the best answer is both places. There is no reason to get caught in either/or thinking.
I also I think this is the right answer to Khalid's issue about per-node type settings as well. Sometimes you want to deal with all the settings a particular node type has, but other times you want to just change one setting for all the node types at once.
-tao
Bevan Rudge wrote: > As a usability advocate I would push more for form_alter()-ing core > forms when appropriate (like your example). As this makes logical > sense. However, considering that most users who care about this > variable are probably advanced drupal users, they will look for it > first at admin/settings/YOURMODULE. > > >> If you want, what you could do as a workaround is place a >> drupal_set_message() (or hook_help()) on other pages that could be >> affected by your setting that point back to the settings page. For example: >> > > I think a better compromise is to put the form item ON BOTH forms. > AFAIK there is nothing wrong with this technically, but I'm not sure. > > Bevan/ > >
Ken Rickard wrote:
Is this double positioning an acceptable solution from a general usability standpoint?
When I have two pages to configure a certain option: 1. I ask myself, is this really the same option, or is the setting on one page overriding the setting on the other page. 2. I will look at the other page anyway, to see if I missed something.
On Jan 1, 2008 6:49 PM, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Hi there,
my question is: Where should contrib module authors put config options for their modules?
1) Should this always be the individual module's settings page?
2) Should it try to add the config option to a more generic place (either provided by core or another module it depends on)?
3) Should it add it to both places?
What peeves me is that some modules put their settings in the content type page, while it is just an on/off thing. This way, on a site with 10 content types, and I want to enabled that module's feature for 9 out of those 10, I have to visit 10 pages, and select from a drop down and click submit. The module could simple list all content types under admin/settings/MYMODULE with a check box next to each. One page to visit, and much better usability. Also, admin/settings/MYMODULE is the most obvious place to find settings for MYMODULE.
Concrete example:
I've added a performance related variable to event module. The value of the variable decides whether to do a full node load for each event on a calendar or to only use title, start, and end date from one mysql query.
Now I need to put the UI for this variable somewhere...
The variable also has influence on the theme you use since you can't print out any other node content fields if they aren't there. The event functions that event.module ships with for example expect the presence of a teaser field.
In principle, I think that the variable should be set at admin/settings/performance but who is going to look there again after each newly installed module?
In your specific case, the settings may be in the module's setting page or under performance. But if you decide to do the latter you MUST provide a link in admin/settings/event to that settings page, so users can find it. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Jan 2, 2008 12:59 AM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 1, 2008 6:49 PM, Gerhard Killesreiter <gerhard@killesreiter.de> The module could simple list all content types under admin/settings/MYMODULE with a check box next to each. One page to visit, and much better usability.
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. 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). I like the idea of presenting some one-time-help-text in a drupal_set_message right after install as long as it is truly helpful like instructions on where to find the module settings for modules that alter existing forms. I know "making me read" is bad, but neither of our alternatives are great either. In this specific case, it seems like a pretty specific thing to expose to the user. Given your past comments I'm surprised you agreed to make it an admin option. I think this is a case where the hidden variable idea I brought up after FactoryJoe's review could work well. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Slightly OT, but admin_menu module is using two approaches that could be interesting for this discussion:
-----Ursprüngliche Nachricht----- Von: development-bounces@drupal.org [mailto:development-bounces@drupal.org] Im Auftrag von Greg Knaddison Gesendet: Mittwoch, 2. Januar 2008 12:13
On Jan 2, 2008 12:59 AM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 1, 2008 6:49 PM, Gerhard Killesreiter <gerhard@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
Quoting Gerhard Killesreiter <gerhard@killesreiter.de>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi there,
my question is: Where should contrib module authors put config options for their modules?
A very good question. With 5.x, after installing a contrib module, I usually check admin/by-module for the settings of the module. I find it much easier to find if there are any I need to consider.
1) Should this always be the individual module's settings page?
This is what I would look for.
2) Should it try to add the config option to a more generic place (either provided by core or another module it depends on)?
I would not tend to look here.
3) Should it add it to both places?
Perhaps.
Concrete example:
I've added a performance related variable to event module. The value of the variable decides whether to do a full node load for each event on a calendar or to only use title, start, and end date from one mysql query.
Now I need to put the UI for this variable somewhere...
The variable also has influence on the theme you use since you can't print out any other node content fields if they aren't there. The event functions that event.module ships with for example expect the presence of a teaser field.
In principle, I think that the variable should be set at admin/settings/performance but who is going to look there again after each newly installed module?
Probably not many would think to look on initial configuration of the module. I would look for the settings for the specific module and not for a modification to an existing module or core settings page. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (13)
-
adrian rossouw -
Angela Byron -
Bevan Rudge -
Chris Johnson -
Daniel F. Kudwien -
Earnie Boyd -
Gerhard Killesreiter -
Greg Knaddison -
Ken Rickard -
Khalid Baheyeldin -
Moshe Weitzman -
Oswald Jaskolla -
Tao Starbow