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

[adrian]

Issue status update for http://drupal.org/node/25745

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     tasks
 Priority:     normal
 Assigned to:  adrian
 Reported by:  adrian
 Updated by:   adrian
 Status:       patch
 Attachment:   http://drupal.org/files/issues/variable_default_0.patch (2.25 KB)

uploaded again




adrian



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

June 25, 2005 - 15:57 : 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.




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

June 25, 2005 - 21:47 : 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.




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

June 25, 2005 - 21:52 : 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.




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

June 25, 2005 - 21:56 : 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.