[support] Issues with initializing Variables on startup..

Scott Matthews smatthews at optaros.com
Tue Jan 29 16:18:54 UTC 2008


I don't believe you fully understood me.

First off, variable_get does NOT retrieve from the database.  if you  
look in the code it ONLY retrieves from that $conf variable that  
variable_set stores the variable in when it sets to the database.   
If, as you suggest David, it really should retrieve from the database  
then it is not working as defined.

function variable_get($name, $default) {
   global $conf;

   return isset($conf[$name]) ? $conf[$name] : $default;
}



Second, according to the comments in the settings.php, you can  
initially override any variables stored in the database in the  
settings.php file by setting the same variable that variable_get and  
variable_set uses:

/**
  * Variable overrides:
  *
  * To override specific entries in the 'variable' table for this site,
  * set them here. You usually don't need to use this feature. This is
  * useful in a configuration file for a vhost or directory, rather than
  * the default settings.php. Any configuration setting from the  
'variable'
  * table can be given a new value.
  *
  * Remove the leading hash signs to enable.
  *
/# $conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
# );



Scott Matthews
Senior Developer
(w) 617-227-1855 x164
(m) 617-710-8430
(f) 617-224-5388
smatthews at optaros.com




On Jan 29, 2008, at 11:04 AM, Metzler, David wrote:

> I think you’re confusing two completely independent constructs.
>
>
>
> Variable_get and variable_set are used to store system wide  
> settings that should persist in the database.  They are never (to  
> my knowledge) instantiated as PHP variables. The caching structure  
> is meant to reduce the number of database hits involved in loading  
> variables, and should not generally be accessed directly.  Multiple  
> calls to variable_get should leverage the cached variables as  
> appropriate.
>
>
>
> The variables in settings.php can be used, you can define your own  
> global variables there, but if you want them to persist between  
> page loads you need to do that yourself.  IN your hooks you can  
> reference these variables after defining them as globals, but be  
> careful with namespace collisions.  I usually create a global  
> variable that has the same name as my module and store everying  
> inside it (as an associative array).
>
>
>
> Finally session variables can be used and will persist in the  
> database for the duration of a session.
>
>
> Hope that clarifies things.  It sounds like drupal is behaving as  
> designed here.
>
>
>
> Dave
>
>
>
> From: support-bounces at drupal.org [mailto:support- 
> bounces at drupal.org] On Behalf Of Scott Matthews
> Sent: Tuesday, January 29, 2008 7:37 AM
> To: support at drupal.org
> Cc: Ron Trevarrow
> Subject: [support] Issues with initializing Variables on startup..
>
>
>
> I found what Appears to be a bug (or two) with initializing  
> variables in Drupal.
>
>
>
> It is suggested that you can uncomment and set initial variable  
> values in settings.php with the $conf array.  In doing so, and not  
> seeing my variables set when retrieving using variable_get, I  
> discovered that conf_init(), when called to initialize the  
> configure file path, it sets $conf to a string.  I know that since  
> it initializes settings.php within the context it conceptually  
> SHOULD reset it to a variable, but it doesn't.   I proved this by  
> changing the variable array name in settings.php, variable_get,  
> variable_set, variable_init and conf_init to $config_vars and the  
> values I initialized in settings.php were reflected when my  
> application later retrieved them using variable_get.
>
>
>
> This bug is currently hindering the flexibility of an application  
> that I'm writing that will be deployed to different environments.   
> I initially tried to set the variables in the 'variable' table of  
> the Database in order to retrieve them with variable_get but that  
> method only accesses the cached variables in $conf (or in my case,  
> $config_vars.  Is this on purpose?  I see that variable_set will  
> not only set the cached variable but will also set into the  
> database.  This seems to be a bug as well to me.  Can someone  
> clarify this for me?
>
>
>
> Scott Matthews
>
>
>
>
>
>
>
>
>
> -- 
> [ Drupal support list | http://lists.drupal.org/ ]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20080129/bf8646c0/attachment-0001.htm 


More information about the support mailing list