Presumably because of #2466197: Staging directory should not have to be writeable. (but maybe not), when I go to install 8.1.8 on Acquia Cloud, it's yelling at me that it can't write to the settings.php file right after selecting the language.
Upon further debugging, it appears settings.php gets initialized twice during install.php, and the second time the existing Settings object gets blown away by empty defaults. This in turn leads the installer to attempt to write the install_profile value, and it can't because settings.php is read-only in our setup for security reasons.
This all worked fine in 8.1.7, with no known changes on our end.
Comments
Comment #2
xjmThis is potentially critical, so promoting for visibility.
Comment #3
alexpottIs your settings.php writable - if it doesn't contain the database information it still has to be writable.
In order to work out what's going on it'd be useful to have all the steps you are taking to prepare Drupal for installation, who owns the files and which user is running the webserver.
Comment #4
xjmThis just looks like the error when I accidentally use a settings.php file from a previous installation. Does the staging directory exist? Does it have that exact name or a different one?
Comment #5
webchickDemoting this back to a support request for now, because after doing some digging, I'm reasonably sure this has something to do with the specific way that Acquia Cloud preps its settings.php that it writes into the directory on behalf of a user (since settings.php is read-only in our setup).
That said, if anyone has any pointers on why code that worked fine two weeks ago suddenly broke, they would be much appreciated. :)
Comment #6
webchickHm. Putting a bunch of debugging crap in the files, it appears that
$settings['install_profile'])
is getting unset somewhere between when settings.php is included and when install_run_tasks() happens, because it's calling out to install_write_profile() and$settings['install_profile'])
is now NULL, despite it was set to "standard" earlier. Hm.Comment #7
webchickFurther debugging.
Just before this line,
Settings::get('install_profile')
returns 'standard' as expected.Just after it, it's back to NULL again. :(
Comment #8
webchickLots and lots and lots of debugging later... Nothing makes sense and I'm rocking back and forth in a corner drooling on myself. ;)
So. The way we have this set up is by putting our settings.php innards in another file (actually a few of them). Which isn't too uncommon:
For some reason, settings.php is being initialized twice (this seems like a separate bug we could fix, along with the fact that the install page is cached by varnish which makes reloading debugging code "fun" :P).
And the first time, in install_begin_request(), everything is hunky dory. This line gets called:
And afterwards, my
hash_salt
andinstall_profile
settings are set correctly. Yay!Then further down below in that function, you see:
Before that line, all my settings are there. Afterwards, they're NULL. :(
Specifically, they get killed during this line from initializeSettings():
And all that's really doing is:
That require statement is successfully importing code from sites/default/settings.php. Which is in turn successfully pulling code from /var/www/site-php/$site/$site-settings.inc. But for some reason never gets to /var/www/site-php/$site/D8-dev-$site-settings.inc, despite it working just hunky dory the previous time. :\ As a result, none of the custom settings.php stuff gets picked up, and so everything resets back.
(*@(#
Comment #9
webchickAlso, the bug has moved on some from the initial issue summary, which was indeed related to the path not pointing to the right place. Updating.
Comment #10
webchickComment #11
webchickComment #12
alexpottThe original report of this bug included the bug reported in #2783749: [regression] Config directories should be created by installer if present in setings.php and if possible.
Comment #13
bircherI could not reproduce this bug unless I was doing "require_once" instead of "require" in settings.php to include the additional settings files..
Comment #14
webchickOoooh! That's a good thought. I'll need to dig into that more.
I'm wondering though, isn't it an actual bug (or at least a performance issue) that we're instantiating settings.php twice? Like should Settings::initialize() bail out if it detects Settings have already been instantiated?
Comment #15
webchickSpun off #2784451: Settings get initialized twice during install to discuss that aspect.
Comment #16
webchickOk yep, I'm 99.9% sure this is a Cloud-specific thing, related to require/include vs. require_once/include_once, so marking this one closed. Thanks so much for all the help!