[support] Issues with initializing Variables on startup..

Tue Jan 29 20:56:12 UTC 2008

	I understand that this bug report seems to be the same issue, but  
I'm a little troubled at the fact that I'm running PHP 5.2.3 and this  
is listed as having been fixed about a year and a half ago.  I really  
do not mean to come off as being too forceful but can anyone on this  
distribution say that with PHP 5.2.3 and Drupal 5.3 that they have  
tried setting a variable in the database directly (not specifically  
using variable_set or variable_init) and their application was able  
to pick up the value using variable_get?  Or even, been able to  
follow the suggested feature of setting the $conf array in  
settings.php to override a variable set previously.

	I see this is a problem.  I see the code where it's happening and I  
would like to know if this case has been done and it really is only  
happening on the multiple machines as well as my local that my  
application is deployed on.

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 1:42 PM, Metzler, David wrote:

> Ahh,  static variables are supposed to be local in scope to the  
> function that they are in.    And they behave a bit differently  
> than normal variables.
>
> static $conf=’’ assignment doesn’t execute the second time the  
> function gets called.  It only executes at the initial creation of  
> the static variable.  This variable later gets converted to an  
> array, but the next time the function gets called it should retain  
> the previous value of  $conf.  It would not be reset to a string.  
> You actually need to set static variables to this empty strings to  
> get them to work properly with arrays.  I’ve done that several  
> times before.
>
>
>
> It’s worth noting that this $conf SHOULD be completely independent  
> of the global $conf variable, and that doesn’t appear to be the  
> case for you.
>
>
>
> It’s possible this is a PHP bug, but I’m not really sure here.  
> There are some references to such a bug at:
>
> http://bugs.php.net/bug.php?id=38287
>
>
>
> Is it possible that you are being bitten by one of these?
>
>
>
>  I have many modules that work as you want.  The variable_get call  
> pulls the database value without problem.   It’s quite possible  
> that once the PHP bug is resolved, everything will work they way  
> you initially tried it.
>
>
>
> And, no you should not need to call variable_init.
>
>
>
> Hope that helps.
>
>
>
>
>
> Dave
>
>
>
> From: support-bounces at drupal.org [mailto:support- 
> bounces at drupal.org] On Behalf Of Scott Matthews
> Sent: Tuesday, January 29, 2008 9:43 AM
> To: support at drupal.org
> Subject: Re: [support] Issues with initializing Variables on startup..
>
>
>
> Conf_init calls conf_path.  the first line in conf path is:
>
>   static $conf = '';
>
>
>
> As I said, once I globally changed the intended array variable to  
> something other than $conf ($config_vars for instance) it worked as  
> expected.
>
>
>
> Now, as I mentioned before, before I tried to initialize in the  
> settings.php file, I just relied on the database value that I set.   
> This was not being retrieved when I called variables_get() and  
> variables_get() was only returning the value I had as the default.   
> The only thing I can think of from what you are saying is that in  
> my module I have to specifically call variables_init() for it to  
> work.  Is that true?  when in the stack is variables_init called?
>
>
>
> 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 12:04 PM, Metzler, David wrote:
>
>
>
>
> Yes true, I was mistaken about the variables being instatitated.  
> But these values are initially loaded from the database by the  
> variable_init function, called in the drupal bootstrap process  
> before settings.php is loaded.  Yes you can override these in  
> settings.php, in which case the database value doesn’t matter, but  
> hey are still meant to be site configuration values that do not  
> change.  As the settings.php file indicates you don’t normally use  
> this method, unless you’re rally trying to something vhost  
> specific.  They are not intended to house global variables that you  
> intend to change during the page load.   Variable_set is designed  
> to change the database given values and is functioning as  
> designed.  It’s used by the admin pages to alter the site specific  
> values.
>
>
>
> 90% of all use cases are handled using variable_get() to get the  
> site specific configuration settings from the database and loaded  
> in cache.   It’s only in weird multi-site hosting cases that you  
> would ever be overriding the values retrieved by variable_get in  
> settings.php.  It is not the preferred method of handling values  
> that you expect to change during a page load or between page loads  
> on a site.
>
>
>
> Conf_init() in my inspection of the source code on drupal_api  
> initializes conf to an array() not a string. Where do you see this  
> behavior?
>
>
>
> Dave
>
>
>
> From: support-bounces at drupal.org [mailto:support- 
> bounces at drupal.org] On Behalf Of Scott Matthews
> Sent: Tuesday, January 29, 2008 8:19 AM
> To: support at drupal.org
> Subject: Re: [support] Issues with initializing Variables on startup..
>
>
>
> 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/ ]
>
>
>
> -- 
>
> [ Drupal support list | http://lists.drupal.org/ ]
>
>
>
> -- 
> [ Drupal support list | http://lists.drupal.org/ ]

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