As we all know, one of Drupal's major shortcomings is exporting configuration. I believe that the source of this problem is that there is no standard way to store and retrieve settings. Most modules use variable_get and variable_set. The problem with this is that there is no association between a variable and a module.
I propose an api for saving and retrieving settings. I am currently working on a settings module as a proof of concept.
Here is a glimpse of the current api:
setting_get($module, $setting) (gets a single setting for a module) OR setting_get($module) (gets all settings for a module)
setting_set($module, $setting, $value) (sets a single setting for a module) OR setting_set($module, $settings) (sets an associative array of settings for a module)
setting_delete($module, $setting) OR setting_delete($module)
settings_form($form, $module) (analog to system_settings_form)
MODULENAME_settings() (a hook to provide information like title, description, access arguments, default values for settings, etc.)
MODULENAME_settings_form($form_state) (the settings form for the module)
Here are the main benefits I see to having this module:
- Consistent import/export code. You only have to call setting_get($module) to get all the settings for a module that uses the settings api instead of variable_get/set.
- Less work to write settings page. You can create a MODULENAME.settings.inc file with a MODULENAME_settings() and a MODULENAME_settings_form(...).
- All default settings in one place. All the default settings will be in hook_settings. Calling setting_get for the first time will transparently pull the default setting from hook_setting if it doesn't exist in the database.
I would really like to get some feedback on this idea and improve Drupal! Thoughts anyone?
Comments
Different from Features?
Have you looked at Features and Strongarm2? Are your trying to achieve something totally different?
I have looked at Features and
I have looked at Features and Strongarm. I plan to provide Features integration. I am trying to achieve something similar to Strongarm but with a different approach.
I think modules should use setting_set(module, setting, value) and setting_get(module, setting) instead of variable_get(module_setting, value) and variable_set(module_setting). The benefit is that, without any configuration, you know which settings belong to a module.
Also, I feel that you need write a lot of plumbing code to provide a settings page. I want to make it faster and simpler to create a settings page by allowing the module to do most of the work for you.
I completely agree. I put in
I completely agree. I put in a lightning talk proposal for Drupalcon making the case for this exactly. I have looked at the settings module and I have some ideas about how we can push it further and get more out of it.
I'll be writing more about this (and maybe working on some code) tomorrow. I'll follow up here.
overrides?
how would module Z override a variable originally set by module X? would it need to know which module "owns" that variable? if two modules use the same variable name, would that end up defining two separate values? (accidental override vs deliberate)
I have written a draft module
I have written a draft module for a settings api. I will upload it to this thread when I get some free time.
For module Z to override a variable set by module X, module Z would have to call setting_set('X', 'mysetting', 'myvalue'). So yes, it would need to know which module owns the variable.
All settings are namespaced, the calls are of the format setting_set($module, $setting, $value). and setting_get($module, $setting). Modules are expected to keep their settings in their own namespace.
If anyone has ideas for a settings module, please post them!
Its called strongarm
checkout http://drupal.org/project/strongarm used with features module you can set any variables from the variables table in code.
Ideally, the core functions variable_get and variable_set should be changed to include module scope:
<?php/**
* Retrive a value from a module's configuration.
*/
function varaible_get($module, $key, $default_value) {
//....
}
?>