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.Steps to reproduce:
1.) Create sites directory (sub.domain.com.directory) with writable settings.php (default file).
2.) Launch installer (sub.domain.com/directory).
3.) Enter database information in the "Database configuration" form and submit.
Expected:
Database gets tested, settings file gets written, site gets installed.
Actual:
Database gets successfully tested, but the settings file is not written and the installer reloads an empty "Database configuration" form.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | sites_default-334948-d7-15.patch | 946 bytes | Albert Volkman |
| #11 | sites-default-334948-11.patch | 966 bytes | David_Rothstein |
Comments
Comment #1
cburschkaI have discovered that the (completely unused) "default" sites directory was not writable, and that making it writable fixed the problem.
This is still a bug, because the installer has no business doing anything with the "default" directory when a writable default settings.php file exists in another sites folder with higher priority (such as "domain.com")
Comment #2
swentel CreditAttribution: swentel commentedCan't reproduce this at this moment, works fine for me.
Comment #3
cburschkaOkay then, let's deescalate it for the moment. I'll see if I can get it to happen again...
Comment #5
BerdirIsn't this somehow related to http://drupal.org/node/332730?
Comment #7
Tor Arne Thune CreditAttribution: Tor Arne Thune commented@cburschka: Can you reproduce this in Drupal 7.4?
Comment #8
cangeceiro CreditAttribution: cangeceiro commentedI can easily reproduce this on every d7 installation i have configured on my dev server.
Comment #9
grayb CreditAttribution: grayb commentedI have this same issue. Why exactly does the default directory _need_ to be writable?
Comment #10
cmoad CreditAttribution: cmoad commentedDitto. This has happened on every D7 install I have ever performed. Literally hundreds across dozens of machines.
Comment #11
David_Rothstein CreditAttribution: David_Rothstein commentedI think the bug report as originally described is slightly out of date, but I can reproduce a different version of the same problem. However, I can only reproduce it when the sites/example.com/settings.php file isn't present also. Maybe that's why not everyone can reproduce it above.
Basically, if the settings.php file isn't there, some of the requirement-checking code doesn't recognize sites/example.com as a valid Drupal site directory. So on the requirements warning page, it thinks it should be trying to write sites/default/files instead, and it fails. The result is that in addition to the settings.php error message, you also get an erroneous message saying that sites/default/files can't be written and you need to make sites/default writeable for that reason.
Here's a patch that should fix it. This seems to work, but may need more thought.
Comment #12
David_Rothstein CreditAttribution: David_Rothstein commentedComment #13
skottler CreditAttribution: skottler commented@David_Rothstein's patch works for me. Marking RTBC.
Comment #14
catchMakes sense, looks untestable, committed/pushed to 8.x.
Comment #15
sunDon't see a commit for this.
Comment #16
Albert Volkman CreditAttribution: Albert Volkman commentedD7 backport.
Did the D8 patch get committed? I don't see it in HEAD.
Comment #17
sunBack to #11
Comment #18
catchCommitted/pushed to 8.x, moving to 7.x for backport.
Comment #19
Albert Volkman CreditAttribution: Albert Volkman commentedBackport in #16.
Comment #20
mgifford16: sites_default-334948-d7-15.patch queued for re-testing.
Comment #21
dcam CreditAttribution: dcam commentedI can't reproduce the issue (default site directory non-writable, no settings.php in either site directory), so I can't RTBC the patch.
#16 contains the exact same change that went into D8. So I'll say RTBC +1.