It's nearly commonplace to commit settings.php to your site's repository which has a few lines at the bottom to include a settings.local.php file which you do not commit. Given this, I've noticed that changes to settings.php for sites sharing an installation profile happen simultaneously with upgrades to the installation profile. Therefore, I'd like to propose a way within DSLM to tie these two things together.

Here's my proposal: DSLM will allow the option to add a settings.php file to your installation profile. If when executing drush dslm-add-profile, DSLM notices that settings.php exists, it will prompt whether or not you'd like settings.php symlinked to the file within the installation profile. (auto-accept with -y). If a real settings.php file already exists within sites/default, DSLM would prompt to decide whether or not to delete the file and replace with a symlink or leave it untouched. (-f to force the deletion and symlink the settings.php in to sites/default).

"Upgrading" an installation profile, ie drush dslm-add-profile --upgrade, would update the settings.php symlink if and only the previous settings.php was symlinked to the version of the profile being updated, prompting the same as add-profile.

When removing a profile, DSLM would remove the settings.php symlink if and only if it's currently a symlink to the profile being removed.

Code will come in a couple of weeks once I have some time to dedicate.

Comments

ultimateboy’s picture

ultimateboy commented

I started this work in the "settings" branch. Initial support is working, but still some work to do.

http://drupalcode.org/project/dslm.git/shortlog/refs/heads/settings

ultimateboy’s picture

ultimateboy commented
Issue summary: View changes

Clarifications

kreynen’s picture

kreynen commented

While the use of a standard settings.php and an include for the site specific settings is very common, the naming convention is not. Adding a copy of the settings.php and the template for the settings.local.php/settings.inc/whatever are really the only file missing to be able to use drush dslm-new to create a working site. Obviously a database needs to be created and the local settings still need to be configured, but dslm could handle all the required files.

Does it make sense to include defining the name of the local settings and adding a copy of that file if the settings is configured or is that taking dslm too far?

fullerja’s picture

fullerja commented
Status: Active » Closed (won't fix)

Talked with @kreynen about this more. Given the variation in naming conventions and the ability to WSOD all DSLM sites at once, we are not going to pursue this further.