By javanaut on

Module developers,

How many features never see the light of day because they might be too narrowly focused for general use? How many "smart defaults" do you write into your modules that could be tweaked as an admin setting? I tend to want to put way too much into a module's admin settings, rendering it very difficult to use for regular users to learn. Most of the time, "smart defaults" would work just fine, but I'm prone to be a control freak and want to adjust everything from the admin settings (and thus want everything configurable from there).

Could we adopt an "advanced settings" tab in the admin/settings section that handles all of these? I've seen many modules with custom settings pages, but that is as much trouble to maintain as the cluttered admin sections are to learn for users.

How do you deal with admin settings bloat?

Comments

javanaut’s picture

javanaut commented

..with a couple of menu items pointing back to the system site settings handler.

Here's how I did it for the relativity.module:

    // add "regular" and "advanced" tabs to admin/settings/relativity
    $items[] = array('path' => 'admin/settings/relativity/regular',
          'title' => t('regular settings'),
          'type' => MENU_DEFAULT_LOCAL_TASK,
          'weight' => 1,
          'access' => user_access('administer site configuration')
          );
    $items[] = array('path' => 'admin/settings/relativity/advanced',
          'title' => t('advanced settings'),
          'type' => MENU_LOCAL_TASK,
          'weight' => 2,
          'callback' => 'system_site_settings',
          'callback arguments' => array('relativity'),
          'access' => user_access('administer site configuration')
          );

Then, in my hook_settings, I added an optional argument:

// implementation of hook_settings()
function relativity_settings($advanced='') {
  $output = "";

  $advanced = $advanced ? $advanced : (arg(3) == 'advanced');
  
  if($advanced) {
    $output .= // advanced configuration options
  }
  else {
    $output .= // regular configuration options
  }
  return $output;
}

Everything appears to be stored using the regular settings system as you would expect. Me=happy.

This still doesn't address the bigger issue of having too many options, but does make it a bit easier to deal with.

kbahey’s picture

kbahey commented

More often than not, when someone proposes a new feature with a setting to go with it, there is resistance in the development community to add the feature because it would confuse users, clutter the interface, complicate it, ....etc.

I see the Advanced tab as a good solution for site admins to handle the less often used options while allowing flexibility for those who need it, without resorting to local patches, or code hacks.

I recommended the use of an Advanced tab on the mailing list, and some developers seem to endorse the idea.

Let us here from the rest.
--

Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

javanaut’s picture

javanaut commented

I'm already considering an "advanced advanced settings" tab :P
(see here for an example of "too much")

It was easy enough to create here, but I suspect to do this in an "automagic" kind of way would leave at least one loose end: what to do for modules with no "advanced" settings? Do you display a tab that just points to the same settings page? How does a module specify that it wants an "advanced" tab displayed? I could think of dozens of less-than-optimal ways of doing this, but how would you see it implemented in a way that wouldn't require the current settings hook to need modification? That's the legacy code trick.

javanaut’s picture

javanaut commented

BTW, I looked for your post on the mailing list and couldn't find it. When did you post it?

kbahey’s picture

kbahey commented

The last two comments in this thread http://drupal.org/node/13211

At the same time there were similar discussions that were debating whether more options are bad, and how to go about them here http://drupal.org/node/2974 and here http://drupal.org/node/17303

The latter two are not directly related to the advanced options idea, but rather to the "options: good? bad?" debate, which spawned the former.

--

Consulting: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

Bèr Kessels’s picture

Bèr Kessels commented

I would really like a drupal page that lists /all/ variables. From that listing you can edit/remove these settings. A bit similar to about:config in firefox, or GConfi, or even regedit in Windows.

And if this solved you problem, would you be so kind to report back that it helped? This will help others whom are looking for the same solution.

[Ber | Drupal Services webschuur.com]

javanaut’s picture

javanaut commented

I agree that such a page would sometimes be nice to have, but some variables have dependencies that could break functionality if edited manually.

Also, what about serialized data stored in variables? Would that appear as raw serialized data or would we attempt to guess at an HTML structure that best represents it? If it does appear as serialized data, how would this differ from editing the table with PHPMySQL or the db module?

It's a feature worth considering, but many warnings would need to be displayed about taking risk into one's own hands by editing the values ;)

Bèr Kessels’s picture

Bèr Kessels commented

That page should really only be accessible for site admins. We might even consider limiting it for uid 1 (root), but that will have other caveats.

And we must definately warn people, when accessing the page. Something like "Make shure you really know what you are doing when changing any values here, for you can break your site easily".

[Ber | Drupal Services webschuur.com]

javanaut’s picture

javanaut commented

LJ has an admin console for manually overriding various undocumented settings:
http://www.livejournal.com/admin/console/

They publish a console reference for some of the possible settings.

They're also strongly against adding new user options and see this as a way for the few who might want a more obscure feature to turn it on/off.

Gayatri-1’s picture

Gayatri-1 commented

i am new user of this site, and build a module which plays following things
- allows user to enter data
- data is saved to database
- data is displayed in form of table
but now can i change the settings option for
limited entries on a page like 5 entries per page
i have written code for settings block, and it saves the count to database, but what next?
how to apply it
code of settings block is

function functionname_settings()
{
	$output .= form_textfield(t('Number of Entries per page'), 'entries', variable_get('entries', '5'), 20, 20, t('No. of entries.'));
	return $output;
}

plz help
gayatri