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.

Files: 
CommentFileSizeAuthor
#1 default.settings.php-missing-error.patch962 bytesximo

Comments

Status:Active» Needs review
StatusFileSize
new962 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 user.pages.inc >:)

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.

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.

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.

Looks like other action is going on over at http://drupal.org/node/312144
I'm not yet sure if this makes it a duplicate

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

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.

Status:Needs review» Closed (duplicate)