Rethink the system settings form

I'd support a confirm_form, but I can see /some/ usefulness for keeping them in.

But, I wouldn't complain if they were removed entirely either.

I'm for removal, but I'll defer to the UX gods.

Sure, I thought developers where harshly defending this functionality :)

On it.

I vote remove!

Fixed the failed tests.

I have actually used the reset button occasionally. How would I go about doing this without the provided submit? Removal--

I'm happy to remove the button as well. It is a pretty exotic feature.

I've used it on scary forms with lots of knobs, but that is rare. I agree that the vast majority of the forms don't need it.

Never used it apart from trying it out to see what would happen. When and if hook_variables() gets in, you could reset things on a per module basis quite easily from contrib, for now it's just potentially destructive cruft.

What if it's optional, defaulting to FALSE. Something like $form['#reset'] = TRUE to show the reset to defaults button?
Having the option is always better than not having it.

tic2000, if it is rarely useful, it probably shouldn't be a feature of the form API. Modules can always add their own Reset button. It's not hard.

Committed to CVS HEAD. Thanks.

Hmmm. We only looked at this from the end user perspective. I know as a developer that I have formed my coding decisions in these forms with the knowledge that the button is there, and that my end users can always click it to get sane defaults. What I don't see in the comment thread is how to get back to default values for an entire form without having to code custom logic (in essence duplicate that which was just removed), or use the #description field and have people type the stuff in.

Had I seen the issue in the last two days I would definitely have voted for a confirmation. I don't remember anybody having complained about this in the past, until killes forgot to train his client ;-) How can we be sure the that 9 people who commented here (two or three of which were either against removal or unsure about it) are representative of the thousands of user experiences we're trying to take care of?

In other words, this is a change in the programmer api and in the end user experience. I find myself feeling like Damien did a couple days ago .... too fast! Not enough review!

#19: I'll second that. I think there is a definite use case for reset-to-defaults buttons, and the fact that they're easy to mistake for the submit button is a fault of the theme, not of the general existence of a reset button.

I'd say that making it optional, but there by default would be preferrable. At least having a general mechanism for adding them (a parameter for system_settings_form()?) – otherwise, a rather useful feature of the Drupal settings system will probably go missing overnight when people upgrade to Drupal 7.

I suggest the following:
1) Make it optional, i.e. leave it to module developers to decide whether it should be there or not by passing an argument to system_settings_form. The drawback of this is that it doesn't enforce consistent interface design in Drupal. However, removing the button from the form array of your settings forms is a piece of cake as it stands now.
2) Move it or change its appearance so that you do not hit it by mistake. The button is larger than the "Save settings" button and placed right beside it, increasing the chance that someone clicks it by mistake.
3) Require confirmation: "All your settings will be lost. Are you sure?".

I always hate these buttons no matter what piece of software I see them on. IMO, if some form is too entirely complex for a user to understand, to the point that their sole recourse is to hit the 'Return to Sanity' button, then we've screwed up the UI elsewhere. That is to say, I see them as a cop-out to making user-understandable forms and settings. I realize there exist other reasons to have it, just none compelling enough to keep it that I have heard.

Just my $0.02

The floor is open.

+1 for removal. Personally I've never used it, but I have come across users who can't get lb2 to work and often try the reset button to start afresh, not that that normally fixes their problem of course, but they do try it. However, I don't think there would be any need for a reset button if settings forms were cleaned up and had useful short, to the point, help texts. Users only seem to use the reset button if they don't understand the configuration options on the form.

The issue for me is not so much HOW we can get back to the defaults in the code, but that we CAN. If the hook_variables that catch mentions gets in, that would probably answer my concern.

For the record, 7 people responded to me on twitter that they never use this button, and nobody responded that they use it, so it seems that the patch probably does more good than harm.

+1 for removal. Resetting a local subset of variables back to system defaults almost never helps to diagnose a problem, and is sufficiently dangerous that it's far more likely to cause them.

On my own system forms, I tend to use a hook_form_alter to turn the button back into a nice in-browser reset button, which is much more useful (or at any rate reassuring) for the novice site administrator.

In my opinion, as developers we are not the right people to decide the usefulness of this button. I think the button is used by those who do not really understand what is happening, and realize they have messed something up. I would definitely vote for a stern warning, as killes has suggested, but I am not in a position to give any valid feedback on the usefulness of the button, since I have a general understanding of the system, and I know where to look in the code to find the defaults.

Wow. Some of the opinions here are, let's say, revealing.

I've used the reset to defaults a number of times, on a number of forms. On other forms, I never use it, because they are simple enough I don't need to.

So one could argue the need is based upon other UI problems. But since we are not solving those UI problems, removing this feature is a big step in the wrong direction.

I feel for killes -- that's exactly what we don't want to happen any time a reset to defaults button is pressed. The UI needs a better way of resetting to a sane configuration, and it needs to tell the user what that is and warn about what might be lost (if anything).

We need to solve the bigger problem, the many instances of variable_get('important_setting', 'secret default') in configuration settings.

Don't remove this until the bigger problem has a solution.

From a quick search, here's a quick sample of recently committed issues cleaning up settings forms in the last six weeks, suggesting this is being done in isolation is just wrong.

#506218: Remove collapsed comments and tidy up settings
#504074: Improve description for teaser length
#168437: user registration settings: more logical order
#497590: Remove pointless "system paths only" warning from admin/settings/site-information
#361277: Remove the 'post settings' admin screen and relocate contents
#423196: Clean up clean URLs settings page
#455576: Rework admin/user/settings

So we are solving the other UI problems with settings pages. Part of solving those problems is removing unnecessary form elements and text from the UI to make them more concise (multiple radios into select lists, radios with two options into checkboxes, not having descriptions which repeat the title), and to me this change is in line with that streamlining process.

On consistency, there's plenty of 'settings' pages which for whatever reason can't use system_settings_form(), it's not like this shows up on every page in /admin. For example admin/settings/language and admin/settings/language/configure don't have a reset to defaults button at all.

+1 to removing the Reset Everything button.

Web forms don't need a reset button. The only reason that button was even invented was because somebody coded a form with five inter-related, JS-powered checkboxes, and humans couldn't comprehend what all those settings really did, so they fiddled with them. It turns out that if they got the five checkboxes into the 'wrong' configuration, it was almost impossible to figure out how to make it 'right' again. Hence, a Reset Everything button.

Reset buttons are useless, unneeded, and crufty clutter. Get rid of it, and the programmers who used to rely on this crutch will figure out how to write forms that humans can comprehend and even come to love. :)

"How can we be sure the that 9 people who commented here (two or three of which were either against removal or unsure about it) are representative of the thousands of user experiences we're trying to take care of?"

We never can :) - well probably can a bit, but unless you want to pay for that extensive level of research :) I think this issue might have required more reviews, but it's more an opinion battle to me - then something to reach consensus on with reasonable arguments. I feel that the UX part is taken care of, by saying that the functionality this imposes is to recover from mistakes - although a worthwhile goal to pursue we don't really do it correctly by this functionality.

Erm, @Senpai: reset buttons have existed long before that ;)

I've seen reset buttons in use all the way back to mah first web pages back in 1997. Those reset buttons, however, merely reset the current state of the form, which is in stark contrast to what Drupal's most-commonly-used reset button does: reset the configuration of the modules settings, something which is impossible to get back to after you've submitted the form with your own changes.

My vote's already been cast: keep 'em but make 'em confirmable. If the hook_variables patch gets in and allows me to reset a module's configuration to its original state, without uninstalling and reinstalling (which would delete data), then I'd support their entire removal, given another alternative.

Leave it to Morbus to predate me on the reset button's history. ;) Ok, so if they aren't there, and a module which really needs it can add one to the same form that module is generating, does FAPI have to provide them to all forms by default?

It's not FAPI per se, system_settings_form adds them. You generally call systems_settings_form for forms that expose persistent variables to users, in most cases the settings page of a module, as it means you won't have to implement your own submit handler to store and load those values.

Morbus makes a good point regarding resetting forms, the behavior users expect is not what Drupal exhibits. It would appear the reset button is way more flawed than many of us think. If there's a confirmation step it must make it extremely clear to the user what the button does as it's not what most users would expect.

#35: FAPI doesn't provide them to all forms by default, merely those that use system_settings_form(), which is the only use case I really argue they should be there for - resetting a module's variable_set'd configurations.

For those like me who were wondering what the "hook_variables" issue was...

#145164: DX: Use hook_variable_info to declare variables and defaults

As for the reset button -- I didn't know it deleted the saved variables. It makes sense, now that I think about it. Never used the button on the 20+ sites I've worked on over the last year.

removal++

Another problem with the reset buttons that no one has brought up yet is that they reset to the defaults provided by the module, which do not necessarily have any relationship to the defaults that the site started out with.

Example: You set up Drupal with an installation profile that sets several user.module variables for you (overriding the core defaults) - maybe it sets some of the default mail texts, for example. Your site has been like that along; you have never seen or heard of any other values for those variables. Then one day you hit the reset button, and suddenly your site goes into a state that it has never been in before -- the core defaults are now being used, and the default values saved by your installation profile are gone forever.

The default installation profile already has/had some problems like this, and it seems likely that more are more settings are going to be added to that profile as time goes on, so the problem would only get worse. Although I think the reset button has some use in theory, it's better to have no button at all than to have a completely broken one, so I'd vote for removal as well...

/me scratches chin.

@David_Rothstein brings up a very good point. I support this (already-committed) patch fully now.

I agree with Morbus :D

I was just referred to this thread which is long ago closed.

Personally, while I do not use the reset defaults often I remember when learning Drupal changing settings and being able to reset the defaults being great. There might be issues as to which users have permission to reset defaults. I think there is a risk that long time developers may have a different perspective than newer users of Drupal and removing the reset defaults may create problems/obstacles for new users of Drupal. My 2 cents.

@izmeez: See http://drupal.org/project/settings_reset_button

As per #1205042: Document removal of the reset button from system_settings_form(), opening this because this doesn't seem to have been documented.

I think this needs a change notification, which we're de facto using for d6/7 changes as well as going forward (I'm adding a note to the 6/7 update page).

Added change notification http://drupal.org/node/1357914

Too late, but I would have preferred leaving the reset button in, with a warning/confirmation page.

This was a useful (albeit dangerous) feature, especially when trying to provide end-user support for contrib modules: It's helpful to be able to have an end-user reset the module settings if they really gummed things up. Or, when doing module development work, it was often helpful to reset the module settings.

Now, module developers will have to build their own 'reset' functionality, or recommend installation of Yet Another Module to offer what was once built-in functionality.

It would be helpful to contrib module developers (and those who do Drupal support) if proposed core changes like this one could go through a more predictable process: When there's a proposal (and decision) to drop a feature, why not leave the feature around for a while but document the decision, and deprecate the feature for a while so module developers and supporters have time to deal with the change?

Thanks for listening.

The API documentation is still out of date.
http://api.drupal.org/api/drupal/core%21modules%21system%21system.module...

I agree that the documentation of that function is not great, but I don't think it's related to this issue. It doesn't say anything about having a reset button in the docs, and that is the change this issue made.

If you want to report a problem with those docs, please file a separate issue.

Documentation says about default buttons.
The issue already exists and it is marked as duplicate.
#1205042: Document removal of the reset button from system_settings_form()

OK, if you want to make a patch that removes the "s", go ahead. I personally don't think it's really even worth fixing.