Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This is a D8-specific issue for implementing my proposal at #418302-90: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) ... #418302 fixed the WTF for users where the webserver is running as the same user that owns all the Drupal files (i.e. many shared hosting configs). This is for the case where the webserver is running as a different user than the one that owns all the files. Re-pasting the relevant details of the proposal:
A) authorize.php itself isn't going to help us much, since it's depending on bootstrapping Drupal at least to the SESSION, which requires the DB, which requires DB credentials, which we don't have yet. However, all we really need is a FileTransfer object. Most of the form code to prompt the user for their credentials lives in includes/authorize.inc, so we can just re-use nearly all of that to instantiate a FileTransfer object, and then use that to do the file operations with the elevated privileges.
B) authorize.inc isn't quite cleanly separated from authorize.php enough to accomplish (A) yet, so we'll need a wee bit of refactoring to make authorize.inc not care about the SESSION in various places. Should be easy, and a good move. Any API (in this case, authorize.inc) needs at least two things trying to use it to be at all viable as an API. The current split was done very hastily, in the midst of a whirlwind of stress and lack of sleep. So, stepping back a little and seeing how it should really be organized to support being invoked from both authorize.php and install.php would be great.
C) Ideally, once install.php has this FileTransfer object for dealing with settings.php (and potentially db.php), it should pass it off to the install profile in case the install profile wants to use it for anything (e.g. fetching and installing 3rd party code during the install -- (see #594704: Allow packaged install profiles on d.o to pull in code from other sources + sites for more). This is not a hard-requirement. An install profile could also solve this problem itself in contrib, but it'd involve prompting the user for all this information twice, which is clumsy for the UX, for no good technical reason.
Comments
Comment #1
webchickLet's get some tests for boolean fields, then.
Comment #2
webchickWow, that was completely the wrong issue!
Though we should of course try and have tests for this one, too. :D
Comment #3
EvanDonovan commented@webchick: Way to jump the gun on those tests :)
Subscribing.
Comment #4
EvanDonovan commentedOops...forgot to remove tag.
Comment #5
David_Rothstein commentedSubscribing also :)
Comment #6
jhedstromComment #22
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #23
dwwauthorize.php and the FileTranfser classes are now deprecated and slated for the dumpster.