Setting certain configuration values in settings.php (e.g. conf=1) can make Site-install fail

I think you mean drupal 7.9. that has a header() bug. download dev snapshot of drupal or what for 7.10

this still happens to me with some contrib modules.

WD php: Warning: Cannot modify header information - headers already sent by (output started [warning]
at .../drush/includes/drush.inc:869) in drupal_send_headers() (line 1221
of /.../drupal/includes/bootstrap.inc).

is there some way to better track this down?

you add a print_r(debug_backtrace()) just before the line mentioned in the error message. that will show you all the calls that got you to that point (i.e. the offending module).

also, make sure you are on drupal 7.10 and not 7.9

I'm experiencing this issue under Drupal 7.15 and Drush 7.x-5.6:

WD php: Warning: Cannot modify header information - headers already sent by (output started at /sandbox/drush/includes/output.inc:37) in _drupal_bootstrap_page_cache()   [warning]
(line 2339 of /sandbox/d7/includes/bootstrap.inc).

Here is the ouptut with print_r(debug_backtrace); before line 2339 in bootstrap.inc: https://gist.github.com/fff96d2d35caa1589fa5

Can someone help me debug? Thanks in advance.

I tracked this down to $conf['cache'] = '1'; in our default.settings.php. We need to stand up this setting on all sites and 'drush site-install' doesn't seem to like this.

Is this a bug or support request? If someone knows what the correct resolution is (c.f. #7), please document and mark the resolution here.

@greg.1.anderson: This is still a bug for us, but just a warning we ignore during deployment. We are still setting $conf['cache'] = '1'; in a file included in default.settings.php.

Can you add $conf['cache'] = '1'; to your settings.php after site-install finishes?

This is one setting among many that we need to enforce across sites on our university Drupal instance. We do automated deploys of 15+ sites per week (single codebase, non-multisite) so adding it after is not really an option, and setting the variable with drush inside the build script would still allow the user to disable it later on, which we don't want.

I tend to think that the resolution here will be "won't fix". I think that you could echo "\$conf['cache'] = '1';" >> $path/settings.php immediately after calling Drush site-install.

I will leave this open in case someone wants to submit a patch that fixes Drush. We could also turn this into a feature request: give Drush a list of config values to write to settings.php after site install finishes. That might work too, and could potentially be useful for other things. Syntax might be awkward; --additional-conf='cache=1,foo=bar'?

Other ideas welcome.

Somewhat related: We already have a way specify extra params in site-install but they don't result in $conf entries. They are passed to install_drupal(). From the examples on this command:

'drush site-install standard install_configure_form.site_default_country=FR my_profile_form.my_settings.key=value' => 'Pass additional arguments to the profile'

Nifty. I should have read the help -- I had forgotten this feature. That is a good way to allow multiple values to be passed in.

Do you think it would be too obtuse to overload this feature? For example:

drush site-install standard install_configure_form.site_default_country=FR settings_conf.cache=1

We'd just have to filter out all of the "settings_conf.*" entries from the list that goes to site-install, and then process them later, once the install was finished.

FYI, Strongarm module is another way to force variable values.

@Greg - I had a similar request recently from chx where he wanted to use FileStorage class instead of MTime. In that case, we have to write to settings.php but also have to affect the Drupal environment during the install so late writing to settings.php is not sufficient.

Hm, yes. A separate command to edit settings.php could be introduced; if this was available, the caller could decide whether to call it before or after site-install.

I general-purpose, cli tool to edit a php file would not be too easy to provide. However, I think that we could make a nominally useful function that provided some editing capabilities by the following process.

1. Include settings.php, so that we have the value for the settings it defines loaded into variables.

2. Read settings.php, looking for simple variablename definitions: $foo ... at the beginning of a line (plus optional whitespace). Once we know that '$foo' exists, we can get its value from the php variable initialized when we loaded settings.php. Maybe we don't need to know the variables in settings.php in advance, though.

3. Look at the cli options and modify the variable values as directed.

4. Stream-edit settings.php, removing any variable that was edited. This is the hard step; we need to find $foo again, and remove every character from where it starts until the ending semicolon. Because of constructs such as array(...), there might be multiple quoted strings that would have to be skipped. There may also be $foo['bar'] and $foo['baz'], all of which would need to be removed.

5. Replace the new values for our edited variables, either at the end of the file, or, for extra credit, put them all at the spot where the first $foo was found.

This fails for any $foo that involves composition ($foo['bar'] = $baz . 'xyzzy') - your expression would be replaced by the evaluated result if you edited $foo['other']. I think it would be fairly useful, though. I might use it to set environment indicator values when I create a dev site from a script, for example.

Strongarm is also a good idea. I'm not sure why I still feel like I prefer editing settings.php; maybe I want a tool that can edit $databases et. al.? Not sure that I really need that. There would be more separation using strongarm. Speaking of separation, another alternative here would be to idempotently append an "include mysettingsconf.php" to the end of settings.php; then, you could easily rewrite all of a mysettingsconf.php file when you wanted to change a configuration value.

I did a quick search for others who might be editing settings.php, and found #1878294: Generate settings.php dynamically without using a template.

@greg.1.anderson: that's precisely what we do now - include yale.settings.inc.php at the end of settings.php and maintain overrides there.

That include of settings.local.php is now part of default.settings.php but is commented out. So it is the "official" place to do overrides in Drupal 8.

I don't mind the "overloading" syntax as in #13. At the same time, I am fine with having folks edit settings.php on their own before or after site-install as needed.

marking this as won't fix for now since we don't have a great solution ready.

drupal 7, of course, not 6