This is my first attempt at writing something like this, to me it's not as much about creating a useful DEP out of this, as it is getting a working format going. I apologise for having left this so long, it's been in my drafts for week now. I am just sending the incomplete document to see where we can go from. If you have any other suggestions, please make them. I'd like to keep the format as simple as possible. Title : Cascading variable system. Abstract: This DEP defines a method to allow for more flexibility in the way we handle variables. Author: Adrian Rossouw Dependencies: None Repository: Core Status: Suggestion? 1. Introduction : This DEP specifies a way to clear up and centralise the variable system in Drupal, and hopefully abstracts some code that we are often using for specific cases. 2. Motivation : Variables in Drupal ( records in the variable table ), are primarily used to store settings for the site. Frequently however, we have the need to override the specified variable. Two such cases are a. variables that can be overridden for each user (the theme setting, for instance) b. variables that can be overridden for each theme (such as whether or not to display the site title). This is done to allow us to specify defaults for the site, and then allow these defaults to be altered. In the case of (a.), we manually test for the overridden value with each occurence of the variable, and in the case of (b.) we have centralised all the theme variable changes by introducing the theme_get_variable() function. This has the benefit of allowing us to define even more layers of variables, such as .. blog specific settings, node specific settings, locale specific settings (allowing us to localise the variables like site_name etc.) and even install specific settings (so install profiles can provide default values for the system). Additionally, it allows host administrators to specify system wide overrides. variables that an administrator can define as non-changeable (the files path, for instance) 3. Approach : This DEP proposes that we add 2 columns to the variable table, namely 'domain' and 'key'. This extra information would be used to store data against a certain object. In the case of the user system saving variables, it would save the variable with 'user' as the domain and $user->uid as the key. In the case of themes, it would save the variable with 'theme' as the domain and the theme name as the key. By default, only the system wide settings would be loaded, and then each module that wants to add a new layer to the variable stack, can add it's own layer of settings. (ie: user module will load all the settings related to the user). The only variables that will actually be overridden are variables that an explicit interface element is defined for, and the only variables that will be saved are the ones that differ from the original variables. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com