[drupal-devel] [task] Administrator configurable defaults and overriding variables.

[adrian]

Issue status update for 
http://drupal.org/node/25745
Post a follow up: 
http://drupal.org/project/comments/add/25745

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     normal
 Assigned to:  adrian
 Reported by:  adrian
 Updated by:   adrian
-Status:       patch (code needs review)
+Status:       patch (code needs work)

changing status applicably




adrian



Previous comments:
------------------------------------------------------------------------

Sat, 25 Jun 2005 13:57:26 +0000 : adrian

Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes)

When running a mass hosting environment, it is often required to shield
users from the ability to break the sites hosted on your system and
there are very often also good security reasons to remove the ability
to configure certain variables.


This patch does two things : 


1) Introduces an optional sites/global.php file, that will be loaded
after the sites/default/settings.php file and provide a set of global
settings for all sites
hosted on a server. This means the administrator only needs to
configure the variables once.


2) Modifies variable_get and variable_set to check optional
'variable_default($name)' and 'variable_override($name)' functions,
that an administrator can define in the above global.php file.


There already exists the ability to set variables using $conf[varname]
in your settings.php file, but there is no distinction made against
variables that have been set this way, and normal variables, apart from
the fact that trying to change them in the admin section fails silently.


A good example of this would be the need to set up the files dir, and
not allow it to be modified, as a user modifying the files dir to
another site's files directory could be catastrophic.



<?php
  function variable_override($name) {
    $conf['file_directory_path'] = conf_init() . '/files';
    $conf['file_directory_temp'] = conf_init() . '/files/tmp';
    $conf['file_downloads'] = 2;
    return $conf[$name];
  }
?>




These values will now be the only accepted and used values to the
variables. If the user tries to modify them, they will revert to these
values and
there will be a message stating that the variable has been locked.


Another common requirement is to provide sensible defaults for an
install, but not take away the configurability of the option. A common
example of this would be the theme setting.



<?php
  function variable_default($name) {
    $conf['theme_default'] = 'chameleon';
     return $conf[$name];
  }
?>


This will change the default that variable_get falls back on, from the
one provided in the parameter list, to the administrator configured
default. This is a much cleaner method of setting the defaults, than
global search replacing the defaults provided in the code.


This patch is one of the changes we have made to the drupal code base
for our hosting platform @ bryght.




------------------------------------------------------------------------

Sat, 25 Jun 2005 19:47:16 +0000 : killes at www.drop.org

While I like the idea as such, I'd like to see that the form fields that
are affected by such global variables should be disabled. Otherwise
we'll have a lot of confused users/ support requests.




------------------------------------------------------------------------

Sat, 25 Jun 2005 19:52:18 +0000 : adrian

I agree with you .. unfortunately i don't think it's currently possible.
It might be closer to possible with the new forms patch, but I don't
think that's a suitable reason for this patch not to go in.


I use form_set_error to display the locked variable message, so it
already shows which form items have been disabled, but only after you
try to change them.




------------------------------------------------------------------------

Sat, 25 Jun 2005 19:56:20 +0000 : killes at www.drop.org

Heh, ok, let's push this patch in core. But I suggest you upload it
again, I can't look at it for some reason.




------------------------------------------------------------------------

Wed, 29 Jun 2005 11:22:50 +0000 : adrian

Attachment: http://drupal.org/files/issues/variable_default_0.patch (2.25 KB)

uploaded again




------------------------------------------------------------------------

Mon, 05 Sep 2005 14:41:42 +0000 : Jose A Reyero

I think the idea it's interesting, but the idea would be really useful
the other way: having a global configuration that can be overridden by
specific site settings.


>From a security standpoing you've lost the battle from the beginning,
since the admin of a site can create a PHP page and add some db_query
code.


And I dont like too much having functions in the config file. Maybe
better having $conf, $default, $fixed arrays in that files, and then
the variable code handling that.


So +1 to having that global.php settings file, but should be before
settings php, and -1 to the rest of the patch.


Patch bingo :-)




------------------------------------------------------------------------

Mon, 05 Sep 2005 15:47:28 +0000 : adrian

I need to update the patch, once I have the form stuff done .. since I
am planning to filter out the overriden elements on settings pages,
meaning they can't be accessed from the interface.


Also, the general idea has been changed to having "$default", and
"$override" global variables. 


Dries has vetoed the global configuration file though, saying we should
just add it to our config file when neccesary.