You're installing Drupal and, for whatever reason, /sites/default/default.settings.php is missing. When you submit the "Set up database" form, the installation doesn't move to the next step, and it doesn't give you any error message.

default.settings.php shouldn't be missing, but it will halt the installation if it is, leaving the user clueless as to what's wrong. Not good.

#1 default.settings.php-missing-error.patch962 bytesximo
Members fund testing for the Drupal project. Drupal Association Learn more


ximo’s picture

Status: Active » Needs review
962 bytes

This patch adds some logic to system_requirements() that checks if the file is there, and alerts the user if it isn't. Because of the string freeze, I can't write a new error message string (unless goba allows it), so as a dirty little trick I've re-used an existing string from >:)

The error message then reads:

./sites/default/default.settings.php has been deleted.

It's better than nothing. A better error message should be written for Drupal 7, so I added a TODO comment to remind ourselves.

Pancho’s picture

This error message is unacceptable IMHO. I'm pretty sure, Gábor would make an exception to add a new string if asked.
Adding a new string is a lesser breach of string freeze than changing one...
Also I would declare a variable with the whole st() call instead of declaring $default_settings.
Good bugfix otherwise.

Chris Johnson’s picture

This same error occurs if there are path problems to the sites directory, which can easily happen in a multi-site hosting arrangement. This issue seriously needs to be fixed.

The patch works perfectly, but the message it produces is less than optimal.

dman’s picture

dman’s picture

Looks like other action is going on over at
I'm not yet sure if this makes it a duplicate

manicolaus’s picture

As to fixing this (copy default.settings.php and rename copy to settings.php), I wholeheartedly second the motion. Make it automatic.

vesapalmu’s picture

Is there a reason for not fixing this bug in D6? The patch would add a new string to D6 core, but at least it would fix the bug.

This is very common problem for clients and students at Drupal workshops. People just get stuck on this problem since there is no indication of anything going wrong. Sure, people have not been following instructions when they get this problem, but that does happen a lot. To me it seems like most Windows users with previous PHP experience just rename the file on their local environment since that's the way many other PHP systems do it.

dman’s picture

Status: Needs review » Closed (duplicate)