Look at commands/runserver/runserver-prepend.php for some clever nastiness that we do to work around this.
/**
* Configuration added here will apply to all sites.
* This can be a useful place to apply generic development settings.
* We hijack system_boot (which core system module does not implement) as
* a convenient place to inject values into the $conf array.
*/
if (!function_exists('system_boot')) {
// Check function_exists as a safety net in case it is added in future.
function system_boot() {
global $conf;
$conf_inject = unserialize(urldecode($_SERVER['RUNSERVER_CONF']));
// Merge in the injected conf, overriding existing items.
$conf = array_merge($conf, $conf_inject);
}
}
Does this have to happen in *_boot, or could we do it in the Drush bootstrap?
We already do this:
drupal_bootstrap(DRUPAL_BOOTSTRAP_CONFIGURATION);
// Overriding the $conf array from drupal CONFIGURATION bootstrap with the
// Overrides we collected on the loaded config files on DRUSH_BOOTSTRAP_DRUSH
$conf = is_array($conf) && is_array($drush_conf_override) ? array_merge($conf, $drush_conf_override) : $conf;
I presume that the code in #3 (system_boot) is called by code somewhere inside the drupal_bootstrap process. Is it necessary to initialize our $conf array this early, or can we wait until the end of the bootstrap and do it as above (via $drush_conf_override)? It would be easy enough to include overrides from an alias file in this array. I'm not sure if any of these overrides might be needed durring the Drupal bootstrap process, though.
I actually think that our current placement (i.e. #4) is preferable to system_boot() since that fires a bit later and can't influence as much about the bootstrap. So, the todo is to enhance #4 so that it collects and processes overrides from site alias and commandline contexts. i guess CLI would look something like --override-site_name=foo
Committed this feature to master. The old $overrides feature of drushrc is now gone so not backportable IMO.
We have a new global option --variables. You can set it at the CLI or in a site alias as with any option. If in the CLI, you use a comma delimited list when overriding multiple values. For example, --variables=site_name=bar,anonymous=visitor.
The example drushrc and alias files now document this option, along with the global options viewable with `drush topic core-global-options`
Comments
Comment #1
moshe weitzman commentedAlso, it would be handy to be able to specify $override from the commandline and/or from environment variables.
Comment #2
moshe weitzman commentedIt is possible that the $override system is clunky and in fact override should just be a global option and not its own special thing.
Comment #3
moshe weitzman commentedLook at commands/runserver/runserver-prepend.php for some clever nastiness that we do to work around this.
Comment #4
greg.1.anderson commentedDoes this have to happen in *_boot, or could we do it in the Drush bootstrap?
We already do this:
I presume that the code in #3 (system_boot) is called by code somewhere inside the drupal_bootstrap process. Is it necessary to initialize our $conf array this early, or can we wait until the end of the bootstrap and do it as above (via $drush_conf_override)? It would be easy enough to include overrides from an alias file in this array. I'm not sure if any of these overrides might be needed durring the Drupal bootstrap process, though.
Comment #5
moshe weitzman commentedUnfortunately, they are often needed right after that config phase.
Comment #6
greg.1.anderson commentedI presume, then, that the technique used in #3 should replace the technique used in #4 for all bootstraps, not just for the runserver command?
Comment #7
moshe weitzman commentedI actually think that our current placement (i.e. #4) is preferable to system_boot() since that fires a bit later and can't influence as much about the bootstrap. So, the todo is to enhance #4 so that it collects and processes overrides from site alias and commandline contexts. i guess CLI would look something like --override-site_name=foo
Comment #8
moshe weitzman commentedCommitted this feature to master. The old $overrides feature of drushrc is now gone so not backportable IMO.
We have a new global option --variables. You can set it at the CLI or in a site alias as with any option. If in the CLI, you use a comma delimited list when overriding multiple values. For example,
--variables=site_name=bar,anonymous=visitor.The example drushrc and alias files now document this option, along with the global options viewable with `drush topic core-global-options`
Comment #10
greg.1.anderson commentedAdd "Needs change notification".
Comment #11
moshe weitzman commentedChange notice: http://drupal.org/node/1408624