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

webchick created an issue. See original summary.

xjm’s picture

Version: 8.1.8 » 8.1.x-dev
Category: Support request » Bug report
Priority: Major » Critical

This is potentially critical, so promoting for visibility.

alexpott’s picture

Is 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.

xjm’s picture

This 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?

webchick’s picture

Category: Bug report » Support request
Priority: Critical » Major

Demoting 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. :)

webchick’s picture

Hm. 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.

webchick’s picture

Further debugging.

  // Only allow dumping the container once the hash salt has been created.
  $kernel = InstallerKernel::createFromRequest($request, $class_loader, $environment, (bool) Settings::get('hash_salt', FALSE));

Just before this line, Settings::get('install_profile') returns 'standard' as expected.
Just after it, it's back to NULL again. :(

webchick’s picture

Lots 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:

sites/default/settings.php # does a require on...
-> /var/www/site-php/$site/$site-settings.inc # figures out the Drupal version and the environment, then does a require on...
  -> /var/www/site-php/$site/D8-dev-$site-settings.inc # Sets up various variables like install_profile, hash_salt, etc.

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:

Settings::initialize(dirname(dirname(__DIR__)), $site_path, $class_loader);

And afterwards, my hash_salt and install_profile settings are set correctly. Yay!

Then further down below in that function, you see:

  $kernel = InstallerKernel::createFromRequest($request, $class_loader, $environment, (bool) Settings::get('hash_salt', FALSE));

Before that line, all my settings are there. Afterwards, they're NULL. :(

Specifically, they get killed during this line from initializeSettings():

Settings::initialize($this->root, $site_path, $this->classLoader);

And all that's really doing is:

require $app_root . '/' . $site_path . '/settings.php';

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.

(*@(#

webchick’s picture

Title: [regression] 8.1.8 has new errors on installation » [regression] 8.1.8 newly tries to write to settings.php during install because install_profile gets unset
Issue summary: View changes

Also, 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.

webchick’s picture

Title: [regression] 8.1.8 newly tries to write to settings.php during install because install_profile gets unset » [regression] 8.1.8 newly tries to write to settings.php during install because $settings['install_profile'] gets unset
webchick’s picture

alexpott’s picture

bircher’s picture

I could not reproduce this bug unless I was doing "require_once" instead of "require" in settings.php to include the additional settings files..

webchick’s picture

Ooooh! 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?

webchick’s picture

webchick’s picture

Status: Active » Closed (cannot reproduce)

Ok 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!