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
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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
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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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/ ]
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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
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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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/ ]
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 9:43 AM To: support@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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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
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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 9:43 AM To: support@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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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@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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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/ ]
Really, I'm not trying to tell you that this is all your problem, but I am trying to help you get to the bottom of what your problem is. I'm also trying to make sure you understand how the api's are intended to be used, so that you don't spend time beating your head against the wall here.
Saying that you're not going to use the variable_set function to get the value into the database, is saying you won't use the api that's intended for doing just that. You've suggested it is a bug, and I'm here to tell you it's by design. It needs to be used or else you need to circumvent all the caching that goes on, and yes that will be hard. The static variable is part of the caching, and there is an additional database cache that also is used. You may try executing a DELETE FROM CACHE statement from your SQL line to see if that's what is getting in your way.
I expect that unless you delete drupal's cache manually every time you alter the database, you're going to have problems getting the value back out, unless you use variable_set to get that value in the database. All the variables are cached, in multiple layers and multiple ways in order to improve performance. I would encourage you to use variable_set to alter the database values, as that's what it's there for.
I certainly had no way of knowing what php version you were running when I sent you that bug reference, but I do know that the static variable is not supposed to overwrite a global in any version of PHP, and that the static $conf='' line is a normal accepted way of initializing a static variable caching that's used throughout drupal. I've even used this in several of my own PHP applications. I'm trying to make sense as to why when you changed the variable names, you get different behavior. That's why I thought of that bug. There may be other reasons, such as you haven't found all of the references to the global $conf in the drupal source code.
I can tell you that I have multiple sites running on php 5.2.2, php 5.1 and a remote hosted php 5.x and the variable_set/variable_get apis are used extensively in all the modules that I have written. I have not used the settings.php override mechanism, but I can tell you that I have extensive experience using the variable_get/variable_set successfully in multiple versions of drupal on multiple versions of PHP. Variable_init as I've said, was not intended to be called directly.
In summary if you don't feel you need to use the settings.php override mechanism then use variable_set to change the value in the database, use variable_get to get the last value set by variable_set (or the default if variable_set has never been called).. Any other manipulations should be done using a different structure such as your own static, global or session construct. In multi-site hosting environments, where you want the value of variable_get to be overridden because you've got to make it dynamic based on the settings.php file in play, only then use the settings.php override mechanism. Don't bother with the database value cause it shouldn't ever actually matter.
If you continue to be disatisfied with the help being provided on this list, and you really believe that there is a drupal core bug here (which I really haven't seen strong evidence of, but I've been wrong before) then I'd encourage you to post an issue on drupal.org.
Anyway, it sounds like you'd prefer to hear from others so, I'll stay silent for a while and let others confirm or refute my expertise here. (really either are welcome).
Dave
________________________________
From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 12:56 PM To: support@drupal.org Subject: Re: [support] Issues with initializing Variables on startup..
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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 9:43 AM To: support@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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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@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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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
I am on my first project using drupal and want to submit this as a bug but needed to get clarification of the usage and if it already is a bug. I'm not saying I'd rather hear from someone other than you, I'm just getting the impression that you, David, are not listening to the issue I'm stating and are simply shooting down my explanations.
I do not have to set this in the database but in trying to find a way to initialize this value that is one of the approaches I attempted.
Your last scenario of a multi site hosting (or in our case deployment: QA, Dev, Production) is what I am attempting to do. You suggest using Settings.php and I'm saying, as well as being acknowledged by one other person on the list, that the value is getting overridden when we do conf_init. My frustration is not that my suggestion is not getting accepted as gospel, it's that my queries are getting shot down with suggestions that things are working as they should without any other investigation.
If this is not the forum for actually getting support questions answered, then I will just submit bugs and hope they have not been entered.
On Jan 29, 2008, at 5:01 PM, Metzler, David wrote:
Really, I’m not trying to tell you that this is all your problem, but I am trying to help you get to the bottom of what your problem is. I’m also trying to make sure you understand how the api’s are intended to be used, so that you don’t spend time beating your head against the wall here.
Saying that you’re not going to use the variable_set function to get the value into the database, is saying you won’t use the api that’s intended for doing just that. You’ve suggested it is a bug, and I’m here to tell you it’s by design. It needs to be used or else you need to circumvent all the caching that goes on, and yes that will be hard. The static variable is part of the caching, and there is an additional database cache that also is used. You may try executing a DELETE FROM CACHE statement from your SQL line to see if that’s what is getting in your way.
I expect that unless you delete drupal’s cache manually every time you alter the database, you’re going to have problems getting the value back out, unless you use variable_set to get that value in the database. All the variables are cached, in multiple layers and multiple ways in order to improve performance. I would encourage you to use variable_set to alter the database values, as that’s what it’s there for.
I certainly had no way of knowing what php version you were running when I sent you that bug reference, but I do know that the static variable is not supposed to overwrite a global in any version of PHP, and that the static $conf=’’ line is a normal accepted way of initializing a static variable caching that’s used throughout drupal. I’ve even used this in several of my own PHP applications. I’m trying to make sense as to why when you changed the variable names, you get different behavior. That’s why I thought of that bug. There may be other reasons, such as you haven’t found all of the references to the global $conf in the drupal source code.
I can tell you that I have multiple sites running on php 5.2.2, php 5.1 and a remote hosted php 5.x and the variable_set/variable_get apis are used extensively in all the modules that I have written. I have not used the settings.php override mechanism, but I can tell you that I have extensive experience using the variable_get/ variable_set successfully in multiple versions of drupal on multiple versions of PHP. Variable_init as I’ve said, was not intended to be called directly.
In summary if you don’t feel you need to use the settings.php override mechanism then use variable_set to change the value in the database, use variable_get to get the last value set by variable_set (or the default if variable_set has never been called).. Any other manipulations should be done using a different structure such as your own static, global or session construct. In multi-site hosting environments, where you want the value of variable_get to be overridden because you’ve got to make it dynamic based on the settings.php file in play, only then use the settings.php override mechanism. Don’t bother with the database value cause it shouldn’t ever actually matter.
If you continue to be disatisfied with the help being provided on this list, and you really believe that there is a drupal core bug here (which I really haven’t seen strong evidence of, but I’ve been wrong before) then I’d encourage you to post an issue on drupal.org.
Anyway, it sounds like you’d prefer to hear from others so, I’ll stay silent for a while and let others confirm or refute my expertise here. (really either are welcome).
Dave
From: support-bounces@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 12:56 PM To: support@drupal.org Subject: Re: [support] Issues with initializing Variables on startup..
I understand that this bug report seems to be the sameissue, 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'shappening 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.
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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 9:43 AM To: support@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
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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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',
# );
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@drupal.org [mailto:support- bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Scott Matthews smatthews@optaros.com:
I am on my first project using drupal and want to submit this as a bug but needed to get clarification of the usage and if it already is a bug. I'm not saying I'd rather hear from someone other than you, I'm just getting the impression that you, David, are not listening to the issue I'm stating and are simply shooting down my explanations.
I do not have to set this in the database but in trying to find a way to initialize this value that is one of the approaches I attempted.
Your last scenario of a multi site hosting (or in our case deployment: QA, Dev, Production) is what I am attempting to do. You suggest using Settings.php and I'm saying, as well as being acknowledged by one other person on the list, that the value is getting overridden when we do conf_init. My frustration is not that my suggestion is not getting accepted as gospel, it's that my queries are getting shot down with suggestions that things are working as they should without any other investigation.
If this is not the forum for actually getting support questions answered, then I will just submit bugs and hope they have not been entered.
On Jan 29, 2008, at 5:01 PM, Metzler, David wrote:
David, I have to agree with Scott; you're not listening. Setting $conf is documented in the default.settings.php file as *the* way to override some variables. The issue Scott is having in doing this was created by a patch [1][2] during the Drupal 5 coding phase[3][4] which removed $conf from the global declarations.
Scott, please open a bug report issue and attach a patch simply adding $conf to the global declarations of conf_init. The issue continues with Drupal 6 as well[5] so you'll need a patch for the Drupal 5 branch, the current Drupal 6 RC branch and HEAD. If you need help, ping me off list.
[1] http://drupal.org/node/56357#comment-391611 [2] http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/bootstrap.inc?r1=1.14... [3] http://api.drupal.org/api/function/conf_init/4.7 [4] http://api.drupal.org/api/function/conf_init/5 [5] http://api.drupal.org/api/function/conf_init/6
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Please believe that I'm listening as hard as I can, and I believe you when you say things aren't working the way you think they should. I'm just trying to make sense about why they might be working differently in your environment than my own and whether that difference is because there's a gap in understanding, whether that difference is because you've got a PHP related problem, or whether that difference is because there's a bug in drupal. We've got a common goal here, yes? My only goal here is to help you get to where your module is done, and working the way you want it to work.
Because you are new to drupal, I'm also trying to figure out if you're using the best technique for what you need to accomplish, and in the absence of further information, I'm trying to clarify what the different options are, and how I've accomplished similar tasks. Perhaps I've read you wrong, but you seemed to be challenging my understanding of how the variable_set/variable_get api's are supposed to work. And seem to be really persistent about believing this to be a bug in the drupal code, rather than a misunderstanding about how you're using the API's, or a PHP environment issue. On at least one occasion you've suggested that designed behavior (that is variable_set storing values into the database) is a bug. I *know* that's how this API is supposed to behave.
Perhaps we could back up a bit. Could you give me more details about what you are trying to accomplish, here? Off list if necessary? Thus far you've only disclosed very general information about what you're trying to do and have been focusing on the specifics on how the drupal code behaves/should behave. If you were willing to describe in more detail what you're trying to accomplish, and the nature of your multi-hosting environment (do different sites share a common database/variable table) then perhaps I could give better help.
As for the right venue, you'll find a lot more application developers on the development list than the support list, as is evidenced by the number of developers who've been responding to you. This is primarily a venue for dealing with issues with regard to configuring installation/configuration of drupal. Although I'll be the first to admit that this line with drupal can be very grey. If you're planning to do a lot of module development, I would recommend that you get on the developers mailing list as well. I'm one of the few developers that monitors and responds to the support list, partly because I understand how grey that line can be.
Anyway, I'm not trying to shoot you down and am still willing to help, if you'd be kind enough to give me additional information about the specifics of what you're trying to accomplish.
Dave
________________________________
From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 2:57 PM To: support@drupal.org Subject: Re: [support] Issues with initializing Variables on startup..
I am on my first project using drupal and want to submit this as a bug but needed to get clarification of the usage and if it already is a bug. I'm not saying I'd rather hear from someone other than you, I'm just getting the impression that you, David, are not listening to the issue I'm stating and are simply shooting down my explanations.
I do not have to set this in the database but in trying to find a way to initialize this value that is one of the approaches I attempted.
Your last scenario of a multi site hosting (or in our case deployment: QA, Dev, Production) is what I am attempting to do. You suggest using Settings.php and I'm saying, as well as being acknowledged by one other person on the list, that the value is getting overridden when we do conf_init. My frustration is not that my suggestion is not getting accepted as gospel, it's that my queries are getting shot down with suggestions that things are working as they should without any other investigation.
If this is not the forum for actually getting support questions answered, then I will just submit bugs and hope they have not been entered.
On Jan 29, 2008, at 5:01 PM, Metzler, David wrote:
Really, I'm not trying to tell you that this is all your problem, but I am trying to help you get to the bottom of what your problem is. I'm also trying to make sure you understand how the api's are intended to be used, so that you don't spend time beating your head against the wall here.
Saying that you're not going to use the variable_set function to get the value into the database, is saying you won't use the api that's intended for doing just that. You've suggested it is a bug, and I'm here to tell you it's by design. It needs to be used or else you need to circumvent all the caching that goes on, and yes that will be hard. The static variable is part of the caching, and there is an additional database cache that also is used. You may try executing a DELETE FROM CACHE statement from your SQL line to see if that's what is getting in your way.
I expect that unless you delete drupal's cache manually every time you alter the database, you're going to have problems getting the value back out, unless you use variable_set to get that value in the database. All the variables are cached, in multiple layers and multiple ways in order to improve performance. I would encourage you to use variable_set to alter the database values, as that's what it's there for.
I certainly had no way of knowing what php version you were running when I sent you that bug reference, but I do know that the static variable is not supposed to overwrite a global in any version of PHP, and that the static $conf='' line is a normal accepted way of initializing a static variable caching that's used throughout drupal. I've even used this in several of my own PHP applications. I'm trying to make sense as to why when you changed the variable names, you get different behavior. That's why I thought of that bug. There may be other reasons, such as you haven't found all of the references to the global $conf in the drupal source code.
I can tell you that I have multiple sites running on php 5.2.2, php 5.1 and a remote hosted php 5.x and the variable_set/variable_get apis are used extensively in all the modules that I have written. I have not used the settings.php override mechanism, but I can tell you that I have extensive experience using the variable_get/variable_set successfully in multiple versions of drupal on multiple versions of PHP. Variable_init as I've said, was not intended to be called directly.
In summary if you don't feel you need to use the settings.php override mechanism then use variable_set to change the value in the database, use variable_get to get the last value set by variable_set (or the default if variable_set has never been called).. Any other manipulations should be done using a different structure such as your own static, global or session construct. In multi-site hosting environments, where you want the value of variable_get to be overridden because you've got to make it dynamic based on the settings.php file in play, only then use the settings.php override mechanism. Don't bother with the database value cause it shouldn't ever actually matter.
If you continue to be disatisfied with the help being provided on this list, and you really believe that there is a drupal core bug here (which I really haven't seen strong evidence of, but I've been wrong before) then I'd encourage you to post an issue on drupal.org.
Anyway, it sounds like you'd prefer to hear from others so, I'll stay silent for a while and let others confirm or refute my expertise here. (really either are welcome).
Dave
________________________________
From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 12:56 PM To: support@drupal.org Subject: Re: [support] Issues with initializing Variables on startup..
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.
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 9:43 AM To: support@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
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 8:19 AM To: support@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',
# );
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@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Scott Matthews Sent: Tuesday, January 29, 2008 7:37 AM To: support@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
Quoting Scott Matthews smatthews@optaros.com:
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?
During the bootstrap phase of course. The $conf variable is a Drupal reserved global variable. You can find the rest of the global variables (and constants and functions and ...) by using the http://api.drupal.org reference.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Okay, you are just proving my point.
The variable_*** methods as well as settings.php are using $conf for the array of set variables. THis documentation on the site just forwarded says it is for the configuration path. That's what I was saying that they are conflicting and my variables are not getting set correct. I'm getting the impression that my concerns are being brushed aside as "All my problem".
http://api.drupal.org/api/global/conf/6
On Jan 29, 2008, at 3:38 PM, Earnie Boyd wrote:
Quoting Scott Matthews smatthews@optaros.com:
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?
During the bootstrap phase of course. The $conf variable is a Drupal reserved global variable. You can find the rest of the global variables (and constants and functions and ...) by using the http://api.drupal.org reference.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Scott Matthews smatthews@optaros.com:
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', # );
The ``bug'' is in conf_init() of includes/bootstrap.ini. The problem is that $conf isn't declared global and settings.php is included within it. This means that $conf isn't registered as a global variable so the settings are never reserved.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
This is partly what I've been saying!! except for the fact that the variable is used by both path configuration as well as variable caching.
Scott Matthews Senior Developer (w) 617-227-1855 x164 (m) 617-710-8430 (f) 617-224-5388 smatthews@optaros.com
On Jan 29, 2008, at 3:52 PM, Earnie Boyd wrote:
Quoting Scott Matthews smatthews@optaros.com:
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', # );
The ``bug'' is in conf_init() of includes/bootstrap.ini. The problem is that $conf isn't declared global and settings.php is included within it. This means that $conf isn't registered as a global variable so the settings are never reserved.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
-
Earnie Boyd -
Metzler, David -
Scott Matthews