Issue Summary
In our quest for a more better admin IA #546956: [meta-issue] Overhaul of Information Architecture, we encountered the settings page for the contact form and came up with a way to get rid of this page by:
1. Removing the UI for the hourly treshold, replace it with a sensible default
2. Move the 'enable contact form for new users' setting to the 'People and permissions' category.
#556174: Move 'enable for new users' under Users
This issue concerns only point 1:
Remove the UI for 'hourly treshold', replace with a sensible default, for wich the current amount of 3 seems fine to me. Relevant contrib modules like Private messages could expose it again to let people override it)
Getting rid of seperate but smallish settings pages is a good thing, fewer chances you'll get lost!
Comments
#1
Across the whole module, there is already a default of 3, attaching very simple patch to remove the setting, I also added a variable_set to hook_install() to ensure the variable is always present (Even variable_get will return the default, I think it's worth setting it, it will prevent "WTF" from contrib developers.
#2
The last submitted patch failed testing.
#3
Just a rerole, to let it test.
+++ contact.install 22 Aug 2009 14:23:38 -0000@@ -12,6 +12,8 @@
drupal_install_schema('contact');
+
+ variable_set('contact_hourly_threshold', 3);
}
Why not just use default variable for variable_get
Beer-o-mania starts in 9 days! Don't drink and patch.
#4
There are Tests, which tests this.
#5
following.
#6
Personally, I had to increase this setting on more than one occasion and removing it would be a bit of a pain. For example, I had it trigger when working on and testing my auto-reply messages. In other words, I'm not in favor.
#7
Sorry, but isn't working on and testing auto-reply messages - totally an edge case thing? Of course it will be more of a pain for developing around this functionality, but I think 80% of the people will never change this default.
#8
It might be an edge case, but it sounds real to me. I know it is real for me on more than one occasion. You want to test your auto-reply messages, not?
Also, the settings is really dependent on the site traffic and volume. So most big sites, might want to change it instantly. Unless it is a setting, it is not easy to discover and they all risk running into a 'bug'.
We should assume that changing a define is hard. It might be easy on your desktop environment, but on a big site, such changes might require to be scheduled and might have to go through a dev-staging-production workflow.
To be honest, this really sounds like an edge case, and I prefer to err on the safe site. Happy to discuss more and to get some extra input.
#9
Still think this is favoring a setting its discover ability for production sites over logical menu items. As this patch will be connected with removing this page as a whole - which will only hold 1 form item. As much as I value personal experience in using this setting, I don't see much trouble in moving it towards the code - we can as suggested higher the default.
We should indeed assume that changing a define is hard, but therefor we shouldn't just push it to the interface?
#10
The value of 3 for one site might not be sufficient for another site. The 80% rule here does not stand and is not back by real data.
Drupal site administrators often need to raise this number, either in development phase, or on a production site.
In general, I am against using invisible default values in web applications. The administrator should always have an interface or a configuration file to override the default values. So, at minimum, the settings.php file could be used to define this threshold value.
I agree with Dries and I'd love to see this issue close with a "by design".
#11
xmacinfo: Yes, this would be configurable from settings.php's $conf array, as are all other variables.
But that said, Dries brings up a legitimate use case that might come up. I believe (but it's fuzzy now) that we have also raised the threshold temporarily when we needed to contact lots of people at once before we had g.d.o for this purpose. In both instances, definitely an edge case, but yet they do come up.
I think the goal of the UX team is not to have to expose a settings page for this since it's something you will only tweak on maybe 1 in 100 sites. And I think I generally agree with that (I've certainly never been contacted by any of our clients in a panic about changing this value).
But yet, this situation is going to come up in contrib, where a module needs to expose a "once in the lifetime of the site" setting, just as we do with things like Clean URLs in core. So, perhaps we do need to go back and think about where this setting could be placed if we do decide to keep it.
I declare myself "on the fence." I can go either way on this.
#12
The last submitted patch failed testing.
#13
I'd volunteer to write a small D7 contrib module called 'flood_control' that would expose an interface to hidden flood control variables like this.
#14
Given the resistance to remove this setting, moving the settings page at #564576: D7UX IA: Roll back contact module settings page tab.
#16
Actually this did get in to 7.x: #570142: Get rid of the admin/structure/contact/settings page.