With the recent system configuration / data discussion going on, I thought perhaps I should dredge up this again : http://lists.drupal.org/archives/development/2005-11/msg00882.html Basic outline : Instead of using just 'name' as a key, add additional 'realm' and 'key' columns, which can then be used to build a layered set of variables. During initialisation, every module / system has the opportunity to load it's variables into the tree. For example : variable_init('system'); /// would load the basic system variables variable_init('theme', $GLOBALS['theme']); // would load theme specific settings. onto the stack. variable_init('user', $GLOBALS['user']->uid); // would load user specific settings. onto the stack. Basically this would allow us to do all kind of variable overriding, and could even be extended to use separate tables for each realm. To set a variable, you would still just use variable_set('variable', 'value'); // doesn't break anything that works now or to set it for a specific realm (like on the user profile edit page) : variable_set('variable', 'value', 'user', $edit['uid']); // set the variable for that specific user. This could also be extended to provide the following hard coded realms for install profiles and system administrators (and this is important) [top level] system wide overrides. Hard coded by the system maintainer in the settings.php [3] theme specific [2] user specific [1] system settings [0] install profile wide defaults [ hard coded by the install profile. this allows the 'reset to defaults' to not mess up the site] [-1] The default provided in the variable_get function. Only use this when nothing else is available. You would also need a function to switch around the order the variables are resolved in (for those wondering about expensive for loops, it should get collapsed with array_merge, so the lookups are only against one thing.) What is neat about this method, is modules could add in their own levels , such as node specific configuration , which extends to og specific configuration .. etc. I would also like to see this extended to the point that system wide overrides get disabled in the admin section. So that admins can't muck up things they shouldn't be able to change. (files dir). -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com