How implement global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file. How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal? Thanks, John
On Thu, Mar 17, 2011 at 11:40 AM, John Mitchell <mitchelljj98@gmail.com> wrote:
For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file.
How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
Well, I usually put those in the setting.php files. For one thing, anything you set as $conf['blah'] in settings.php will then be the value when the code does variable_get('blah') later on. -- John Fiala www.jcfiala.net
You can use different settings.php files for each environment via Drupal's multisite capabilities. See http://drupal.org/node/516608 On Thu, Mar 17, 2011 at 1:43 PM, John Fiala <jcfiala@gmail.com> wrote:
On Thu, Mar 17, 2011 at 11:40 AM, John Mitchell <mitchelljj98@gmail.com> wrote:
For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file.
How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
Well, I usually put those in the setting.php files. For one thing, anything you set as $conf['blah'] in settings.php will then be the value when the code does variable_get('blah') later on.
-- John Fiala www.jcfiala.net
I create a second config file, local_settings.php. Then I configure it to override anything in the main settings file by adding this to settings.php: if (file_exists('./'. conf_path() .'/local_settings.php')) { include_once './'. conf_path() .'/local_settings.php'; } settings.php is placed in version control, and local_settings.php is not. Upon deployment, the local settings file is then symlinked to a shared directory in each server. In my case the symlink is created by the :after_update_code task in capistrano, but you could manage this local config file any way you want. If the cap stuff sounds interesting, there's code on my blog: http://metaltoad.com/132 On Mar 17, 2011, at 10:40 AM, John Mitchell wrote:
For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file.
How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
Thanks,
John
Use this instead: /** * Load local development override configuration, if existent. */ if (file_exists(dirname(__FILE__) . '/settings.local.php')) { include dirname(__FILE__) . '/settings.local.php'; } And make sure it's at the very end of settings.php. sun
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Dylan Wilder-Tack Sent: Thursday, March 17, 2011 11:08 PM To: development@drupal.org Subject: Re: [development] How implement global variables that varydepending on the server (i.e. production, test, demo) within Drupal?
I create a second config file, local_settings.php. Then I configure it to override anything in the main settings file by adding this to settings.php:
if (file_exists('./'. conf_path() .'/local_settings.php')) { include_once './'. conf_path() .'/local_settings.php'; } settings.php is placed in version control, and local_settings.php is not. Upon deployment, the local settings file is then symlinked to a shared directory in each server. In my case the symlink is created by the :after_update_code task in capistrano, but you could manage this local config file any way you want.
If the cap stuff sounds interesting, there's code on my blog: http://metaltoad.com/132
On Mar 17, 2011, at 10:40 AM, John Mitchell wrote:
For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file.
How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
Thanks,
John
On 17 Mar 2011 17h40 WET, mitchelljj98@gmail.com wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] For java webapps within Apache Tomcat I use a web.xml file which contains the global variables that are specific to that server so that the production server will have one web.xml file and the test server will have a different web.xml file.
How can I do something similar for global variables that vary depending on the server (i.e. production, test, demo) within Drupal?
Several ways to do that. 1. There's the approach of using a diferent setting.php with a conditional inclusion as already described in this thread. 2. There's the approach of using a *single* settings.php file and instead do the conditional logic inside where you set the global variables you want. Use drush to activate/deactivate the settings. drush vset mysite_dev 1 This creates a variable that can be used in a if like: // Do site specific stuff here. if (variable_get('mysite_dev', 0)) { /* do stuff for dev site */ } You can use drush vdel to delete the variable. If you want to have a more structured approach create constante like like this: define('MYSITE_DEV', 1); define('MYSITE_STAGE', 2); define('MYSITE_PROD', 3); and do: drush vset mysite_version 1 for making it dev if (variable_get('mysite_version' 0) == MYSITE_DEV) { /* do stuff for dev site */ } and so on for the other versions. --- appa
participants (6)
-
António P. P. Almeida -
Carl Wiedemann -
Daniel F. Kudwien -
Dylan Wilder-Tack -
John Fiala -
John Mitchell