| Project: | Drush |
| Version: | All-versions-5.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | adrian |
| Status: | closed (fixed) |
Issue Summary
This is related to #472338: Drush Incompatible With Secure Pages Module.
I also noticed something was wrong with Secure Pages and drush and liked the idea of disabling the module using the $override array in the drushrc.php file. However, as stated in the previous issue, it doesn't work.
I found that the $conf array is loaded from the config files on _drush_bootstrap_drush() but later on, on _drush_bootstrap_drupal_configuration() it gets reinitialized to an empty string because DRUPAL_BOOTSTRAP_CONFIGURATION will set it to an empty array before loading that array from the settings.php file. I looked and this happens on 5.x, 6.x and 7.x.
I think something like this was already detected because of some comments on drush_load_config(), but nonetheless, the bug described here exists.
Attached is a patch that tries to solve this. Basically it stores the $override arrays on a drush global variable ($drush_conf_override) and later on, on _drush_bootstrap_drupal_configuration(), merges it with the initialized $conf array from drupal bootstrap.
| Attachment | Size |
|---|---|
| conf_overriden_in_the_wrong_place.patch | 2.38 KB |
Comments
#1
#2
While I am here, and reviewing the patch one more time, I detected another thing in durpal_load_config();
'dev_query' was arbitrary set to FALSE on each drupal_load_config() so if an early drushrc.php set it to TRUE, later calls to drupal_load_config() in drush_bootstrap_drush() will set it to FALSE again.
Attached is a patch that fixes both problems.
#3
Came across this bug today and this fixed. Thanks a lot. Committed.
Don't know if we should be using drush context object instead of a global. Anyone who has an opinion (especially adrian) is welcome to chime in.
#4
Automatically closed -- issue fixed for 2 weeks with no activity.
#5
Still having problems with overrides not being set. I noticed that drush_load_config function is called for each context. Instead of resetting the $drush_conf_override global array each time, why not keep the values that were passed from earlier contexts and override only the values that are defined in later override variables.
#6
I reviewed this as I posted the patch originally and I noticed that initialization was not part of it but added later (1.10) not to have some warning (according to the log).
Indeed that initialization is overwriting previous overrides of previous contexts and that shouldn't happen.
+1 for the patch on #5
#7
Committed. Thx.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.