Proposal: attempt to make settings.php writable on re-install

[greg-1-anderson]

TL;DNR:

I want to add @chmod($settingsfile, 0666); (and equivalent for $conf_dir) at the beginning of site install, leaving any failures for the installer to detect and report. I will make PRs for the master and 8.x branch if this sounds okay.

Background:

If you attempt to run site-install on a site that has already been installed, there is a risk that the installation will fail, because Drupal makes settings.php and the config directory unwritable during the installation process. This is usually not a problem, as the installer will also skip writing settings.php if the installation profile remains the same from one install to the next.

Switching installation profiles usually doesn't work; however, there is one use-case where it does work -- switching to the config_installer.

My use-case involves a Drupal site that is configured for the user. On the initial install, the standard installation profile is used. Using the config_installer on the initial install doesn't work, because config_installer requires config files be exported in the sync directory, and I don't want to maintain these.

In the past, I would use drush site-install with the --config-dir option with the minimal installation profile. This works fine, but if you want to start with the standard installation profile, and then switch to minimal, you have to hand-modify your exported configuration files, which is awkward. The transition to the config_installer is much smoother.

I don't think there's any downside to making settings.php writable in drush site-install; the Drupal installer will reset it back to unmodifiable in short order.

Workaround (for Drush 8):

reinstall.drush.inc

<?php

/**
 * Attempt to make site-install on an already-installed site a little
 * more likely to work, we will make the 'default' directory and
 * 'settings.php' file writable, if possible.
 *
 * If we cannot make settings.php writable, then we will do nothing,
 * and let the installer report errors.
 */
function drush_reinstall_site_install_validate() {
    // Find the $conf_path the same way that drush site-install does
    $alias_record = drush_sitealias_get_record('@self');
    $sites_subdir = drush_sitealias_local_site_path($alias_record);
    // Override with sites-subdir if specified.
    if ($dir = drush_get_option('sites-subdir')) {
        $sites_subdir = "sites/$dir";
    }
    $conf_path = $sites_subdir;
    $settingsfile = "$conf_path/settings.php";

    // If the conf directory exists but is not writable, try to make it writable
    if (is_dir($conf_path) && (!is_writable($conf_path))) {
        @chmod($conf_path, 0777);
    }
    // If the settings file exists but is not writable, try to make it writable
    if (file_exists($settingsfile) && !is_writable($settingsfile)) {
        @chmod($settingsfile, 0777);
    }
}

[weitzman]

Drush really tries to chmod as little as possible. It tends to upset people. I don't really love this idea.

FYI, the install profile is no longer written to settings.php as of 8.3. That might improve your re-install case. See https://www.drupal.org/node/2156401

[greg-1-anderson]

Well, in this case, Drush is only chmod'ing something that Drupal is already chmod'ing.

Feel free to close this and the PRs if this is just off-the-table. As for https://www.drupal.org/node/2156401, though, that is only applicable for sites with exactly one distribution, right?