Closed (won't fix)
Project:
Devel
Version:
5.x-1.x-dev
Component:
devel
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
11 Mar 2007 at 01:38 UTC
Updated:
10 Oct 2011 at 12:52 UTC
Jump to comment: Most recent file
Attached patch renders devel module settings in collapsible fieldsets.
This is a basic step for turning devel module into a development settings API. Screenshot follows.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | Devel_Drupal_50.png | 20 KB | sun |
| devel.module.fieldsets.patch | 4.21 KB | sun |
Comments
Comment #1
sunI hope you get an idea about the aimed 'development settings API' on this screenshot. The last fieldset contains development settings for the Drupal Administration Menu.
Comment #2
dwwi'm not sure i understand what you mean about a "development settings API". the "API" is variable_(set|get). if your module has additional development settings related to it, seems like those belong with your module's settings page, not buried under the devel module's settings page. if you want to get crazy and only have your "development" settings show up if devel.module is enabled, see module_exists()...
that aside, from briefly looking at the patch, it seems that the "error handler settings" and "mail settings" fieldsets each only have 1 setting in them. that's lame. a "set" of 1 seems rather pointless to me. it just makes the UI require more clicks, and doesn't make the information easier to understand or sort through.
so, i'd say this patch needs some help and more thought/justification before we'd consider committing it.
thanks,
-derek
Comment #3
sunLet's separate both topics:
IMHO, Error handler and Mail settings shouldn't be merged into one fieldset since both fieldsets might be extended in the future. smk-ka already announced to contribute a patch for devel to redirect any outgoing email to a pre-defined email address. That will be extremely helpful for developers of messaging-related modules.
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.
Comment #4
salvisD5 is obsolete.