Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
When a user has a settings.php with database settings and config directories configured but not writable the installer was able to continue before #2466197: Staging directory should not have to be writeable. and create the config directories. Now that does not occur - you get the reported installation error.
This regression appears to have broken Acquia's cloud hosting.
Proposed resolution
When settings.php contains config directory info try to create the directories. If they are not there error - if they are don't worry about if they are not writable.
Steps to test
- The starting permissions need to be something like this:
$ ll sites/default total 224 drwxr-xr-x 4 alex staff 306 14 Aug 13:20 . drwxr-xr-x 6 alex staff 374 14 Aug 13:20 .. -rw-r--r-- 1 alex staff 6762 12 Aug 14:33 default.services.yml -rw-r--r-- 1 alex staff 30223 12 Aug 14:35 default.settings.php drwxrwxrwx 3 _www staff 136 14 Aug 13:20 files -rw-r--r-- 1 alex staff 6762 14 Aug 13:20 services.yml -rw-r--r-- 1 alex staff 31825 14 Aug 13:20 settings.php
- Ensure that settings.php has 644 permissions
- Ensure sites/default/files is writable by the webserver and empty
- Ensure the sites/default has 755 permissions and is not writable by the webserver
- Ensure that settings.php is not owned by the webserver
- settings.php has to have hash_salt, database and config directory configuration already
- The config directory location should point to somewhere web writable - somewhere in sites/default/files is the default
- go to yoursite/core/install.php and install drupal
- Afterwards the config directory should be created
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#16 | 2783749-16.patch | 6.69 KB | alexpott |
#16 | 13-16-interdiff.txt | 949 bytes | alexpott |
#13 | 2783749-13.patch | 5.77 KB | alexpott |
#13 | 10-13-interdiff.txt | 4.93 KB | alexpott |
#10 | 2783749-2.patch | 2.23 KB | alexpott |
Comments
Comment #2
alexpottComment #3
alexpottNote we have test coverage that a read-only config sync directory is possible - see \Drupal\system\Tests\Installer\InstallerExistingConfigDirectoryTest
Comment #5
bircherSo the patch in #2 works, but you are told that the settings.php is not writeable on the "verify requirements" install step. You can then click on "try again" and without changing anything in the files the installation succeeds.
(This of course given a non-writable settings.php containing the database credentials and the path to a non-existing config/sync folder that can be created later.)
The patch attached here makes so that the check that settings.php is writeable can be skipped even if the config/sync folder does not exist. (the "try again" works because this issue is about trying to create that folder if it doesn't exist and the check that leads to settings.php having to be writeable happens before.
Comment #7
alexpottI tested #2 and it works fine. This one is quite tricky to manually test. @bircher what did you do exactly think the change in #5 is necessary? If what you are saying is true that then test this patch adds would fail.
Comment #8
alexpottComment #9
BerdirWe don't have a staging directory anymore, shouldn't this say Sync directory? :) The other issue also had that wrong.
Comment #10
alexpottAdded test to test to the issue summary and re-uploading #2 afrer manually testing again and proving to myself it works.
Comment #11
alexpottComment #12
alexpottComment #13
alexpottBetter and more tests and better help text too.
Comment #14
alexpott@bircher mea culpa... you are right! And the evidence is in the steps to reproduce in the issue summary :)
-rw-r--r-- 1 _www staff 6762 14 Aug 13:20 services.yml
-rw-r--r-- 1 _www staff 31825 14 Aug 13:20 settings.php
So if my settings.php is not writeable by the webserver I see what you are seeing - the need to press try again and then it magically works. This bit of this feels like #2782811: [regression] 8.1.8 newly tries to write to settings.php during install because $settings['install_profile'] gets unset
And is also impossible for the automated test to test I think since even 444 doesn't trigger it - it occurs when it is a different user.
Comment #15
alexpottComment #16
alexpottThis patch makes a similar fix to #5 but also checks that the required hash_salt is set. Obviously our test infra was relying on the settings_verified being false due to config directories not existing however the hash salt definitely is required and if not set we're going to need to write it.
Comment #17
bircherRight! the hash salt needs to be there too of course!
On that note, it may be worth adding a
$install_state['parameters']['profile'] == Settings::get('install_profile', FALSE)
check to either the the place where$install_state['settings_verified']
is set or where it is used to skip the check for write access to settings.php.But that could also be a follow-up because if you try to install a profile and have a different one set in a read-only settings.php you get an error. There are different ways we can treat this case and to fix the regression the patch in #16 works. So RTBC..
Comment #18
alexpott@bircher going to create a followup to deal with the case where the install profile is set in settings.php. I tested 8.1.7 and the current behaviour is not a regression - it behaves exactly the same and makes you choose the profile.
Comment #22
catchCommitted/pushed to all three 8.x branches.
If this bug hadn't been in a patch release I'd have just reverted from 8.1.x, but don't see another option here.
Comment #23
xjmComment #25
xjm