Install fails when default.settings.php is not present

That's weird. What files do you have listed in the sites folder of your drupal install?

I talked to dave on irc about this, and we came to the conclusion that the installer needs default.settings.php and settings.php, I renamed the default.settings.php to settings.php instead of copying it...
The new bug is now that the installer needs to issue an Error of default.settings.php doesn't exist. I'll try to come up with a patch for this tomorrow.

Fixed title spelling error. Once you get your patch written, I'll help test!

I've a patch present but it needs #312677: drupal_verify_install_file sometimes issues a php warning resolved first, so I'm marking this as postponed. Also this is not critical anymore (the installer doesn't fail always), so I'm marking this as normal.

As #312677: drupal_verify_install_file sometimes issues a php warning should get in soon, I'm pposting my patch for review here. The warning when default.settings.php is fixed after applying my patch from the other issue.

The error message should mention the fact default.settings.php needs to match the one that is delivered with Drupal. One that exists and is empty or a modified settings.php is of no value.

This reroll fixes some whitespace issues of my code and adds a md5-check of default.settings.php with an extra message. This needs to be updated every time default.settings.php changes...

no comment -.-

Both the default Drupal message about a missing settings.php as the new settings.default.php are talking about permissions, but only the first message actually provides a link to a handbook page about settings those permissions. I would use this link as a separate message that is being displayed if either settings.php or settings.default.php are missing.

I also think the original message could then be made smaller. Before:

• The Drupal installer requires that you create a settings file as part of the installation process.
  1. Copy the ./sites/default/default.settings.php file to ./sites/default/settings.php.
  2. Change file permissions so that it is writable by the web server. If you are unsure how to grant file permissions, please consult the on-line handbook.

  More details about installing Drupal are available in INSTALL.txt.

• Please make sure that ./sites/default/default.settings.php exists and is readable by the webserver.

After:

• The Drupal installer requires that you create a settings file as part of the installation process. Copy the ./sites/default/default.settings.php file to ./sites/default/settings.php.
• Please make sure that ./sites/default/default.settings.php exists and is readable by the webserver.
• Change $file permissions so that it is writable by the web server. If you are unsure how to grant file permissions, please consult the on-line handbook. More details about installing Drupal are available in INSTALL.txt.

$file would be 'settings.php' or 'settings.default.php' or a combination of the two, depending on which of them cannot be read/found.

I talked to catch, and we decided to move the md5 thing in another patch. Also, I removed the is readbale by the webserver, cause when the webserver can't read that file (and not fix it!), all is borked anyway. this is hopefully the final patch ;)

I reviewed this in irc with Cornil, and tested manually. This last patch looks great to me.

Quick summary of the issue:

If you do $ mv default.settings.php settings.php drupal's installer simply fails with nasty warnings.

This patch ensures that the file exists in update_check_requirements() and allows you to install.

It's got a couple of interesting side-effects which we should deal with in the md5 followup patch.

So, if I do

If I do

The error message goes away and I can install Drupal, but I get a settings.php with just the database connection information. That's what the md5 patch will attempt to deal with, I don't think we should concern ourselves about it here - since we're only helping people who aren't really following the instructions here anyway.

I wouldn't think so lightly about this. The installation is part of the first impression new users get. If this fails the first impression won't be good, no matter whose fault it is.

Well, the patch stops the installer from failing in this particular edge case. A side effect is that it also stops it from failing in sub-set of that edge case where we might not want it to - which is what the md5 of default.settings.php attempts to deal with. However, adding the md5 is a lot of extra work, and work that's easy to forget we need to do, every time we want to edit default.settings.php - so it seems sensible to break the patches up.

But 'Please make sure that %default-file exists.' needs to read 'Please ensure that %default-file is not modified in any way from the orginal download.' regardless.

here you go, I merged both sentences ;)

This patch no longer applies after #281446: Add 'status report' for installer requirements

Also, the patch in #15 uses "orginal" rather than "original".

i'll have a look at it soon, thanks for the report :)

Patch completly redone in a way like the stuff from #281446: Add 'status report' for installer requirements

Didn't worked for me. I renamed the file default.settings.php but did not get the requirements error. The problem was that the check was included in a condition, and only executed if a settings.php exists. The attached patch based on #20 fixes it.

Would you mind exactly describing your problem? The check is executed in the conditional is sies/default directory exists, nothing else.

I agree with @dropcube but if we move the $default_exists to just before the if why not just use the result of drupal_verify_install_file directly in the if condition? There is no use of the variable any further.

Change

To

@CorniI: The first time I reviewed the patch I tested but didn't get the error report. Now I see that the check is executed in the conditional is sites/default directory exists.

Attached a new patch based on #20, adding some comments and cleaning up.

Oops, there was a slash missing.

Don't have enough time to test this patch thoroughly since I'm working on another patch, but I though I'd mention that with a fresh checkout I get both the "The settings file does not exist." and "The settings file is not writable." errors. I think the latter shouldn't be shown if the former is.

@Xano, that was introduced with the new status report for the installer. webchick requested they be split in the issue, and I was planning to do the same with the files directory when some of the other installer cleanup patches are in.

It's logical Drupal hasn't got permission if the file doesn't exist, but for novices this might be confusing, since they can see both errors as separate problems while in this case they are one.

Xano, please open a separate issue for that if you think it's a problem.

The last submitted patch failed testing.

Duplicated effort of some sort over at http://drupal.org/node/208662

Note that the current instructions are misleading anyway if you have already created a sites/example.org folder .

It says:

That's why it says "copy". This means you will have to leave the original intact.

@xano: read better #32. Even by copying (i.e. following the instructions to the letter), it fails in that specific configuration.

So it doesn't count as renaming because you actually copied first, then deleted the original. But that's different from renaming, and is actually copying, even though the original was destroyed.

Hm.
I guess the lesson to be learned here is that yes,
if you delete configuration files that were distributed as part of the core of an application package just because you think you had no use for them then yes, unknown things can break.

[insert story here about uncle who decided he was tired of looking at that boot.ini file - which he clearly never used...]

Does the file have to be called default.settings.php.do.not.delete.me ?
Those instructions do need to be worded more strongly, just to cover the cases of other things that people should NOT do when following the instructions.

Copy the file. Do not rename it. Copy it. Leave the original default/default.settings.php where it was. Do not delete it after successfully copying. Do not rename it. Do not move it into another place. Do not delete any file that was originally distributed with Drupal. Do not rename them either. Do not wave a big magnet over your hard drive. Do not pour honey into the drive slot.

Alternative wording suggestions welcome...

I need to look at this more but I'm not so sure why we should be so dependent on a file that is seemingly a template in the first place. If you ask me a template configuration file is to be used once (on initial installation) and requiring default/default.settings.php when a settings.php is found is a bit overboard in the saneness checking.

earnie, it needs to be re-used for multisite installations.

If the need for default.settings.php is so great perhaps it needs to be moved to the system module folder. This would make it look less like an unimportant file that can be deleted.

dman wrote:

if you delete configuration files that were distributed as part of the core of an application package just because you think you had no use for them then yes, unknown things can break.

I agree, but the problem here is that the file is named default.... and you are asked to copy it, indicating strongly that the default file is really just a sample. Sample config files are very common, and in all OS-es I have tried they can be removed without any side-effects what so ever.

Something has to be done with location/naming of that file - I agree with earnie on that.

Hans

PS! I normally like Drupal a lot and I use it for all classes I teach (at college), but that the installer (in Drupal 6.9) simply failed when I moved default.settings.php to settings.php, without any explanation, was a very bad experience - in front of my class. I and my 70 students found Drupal extremely stupid when we realized that it actually required the sample file to be present to work.

Comment #9 gives the best advice here. There was no need for a patch just simply making sure I had a copy of settings.php and default.settings.php This fixed worked. Thanks!

Resetting fields to more appropriate values. Unfortunately I can't revert the Assigned field to the previous value.

I spoke with DamZ this weekend about this issue, and we should remove the default.settings.php copy step and just let it be rename. Which means that it doesn't have to check for default.settings.php and we just move the php settings and all that stuff in an other file or in the database.

My opinion is that such things belong in a file in the system module.

Marked #479006: Cannot rename sites/default/default.settings.php a duplicate of this bug. That is pure ugliness. I'd sure like to see this fixed.

Beginner in comment #32 has a good point. He/she correctly identifies that the documentation instructs the installer to create a copy within the target directory (note that it doesn't say default directory). In a multi-site implementation I would suggest that using a "default" directory is not a best practice. By defining each of the domains, you better control risks associated with later installations. Consider the following environment:

• sites/mydomain.tld
  (an established domain/directory)
• sites/yourdomain.tld
  (an established domain/directory)
• sites/newdomain.tld
  (target directory containing original, unmodified default.settings.php and settings.php files)

Because the default.settings.php file must exist in the "sites/default" directory as required (hard coded) by line 176 of "includes/install.inc" ("$default_settings = './sites/default/default.settings.php';")(Drupal 6.12), the following must also exist:

• sites/default
  (directory only containing original, unmodified default.settings.php file)

So besides the issue with the install not checking for the existence of the file, I propose that it isn't even looking for it in the correct place. It is searching outside of the scope defined by the installation in a multi-site environment. I have given thought to the process of creating all environments within a default directory that can be renamed to the correct site name but consider the following objective:

• sites/mydomain.tld
  (an established domain/directory)
• sites/subdomain.mydomain.tld
  (target directory containing original, unmodified default.settings.php and settings.php files)

Starting the process by initially naming "sites/subdomain.mydomain.tld" as "sites/default" and running the install process has the unfortunate effect of going to the "sites/mydomain.tld" directory and the "sites/default" directory is never touched. The only way to mitigate this is to also rename the "sites/mydomain.tld" directory, thereby breaking that environment.

My suggestion would be to also change the "includes/install.inc" file to search for the file in the same location as the "settings.php" file. Perhaps with a change similar to the following:

- $default_settings = './sites/default/default.settings.php';
+ $default_settings = './' . conf_path(FALES, TRUE) . '/' . $prefix . default.settings.php';
$settings_file = './'. conf_path(FALSE, TRUE) .'/'. $prefix .'settings.php';

(Not sure how the "$prefix" variable is used so am not sure if it should be excluded.)

With this patch, Drupal makes writes settings.php based on itself, without trying to use default.settings.php. This:

* allows mistakes in the workflow (you can either rename or copy default.settings.php)
* solves the issues described in #45

What happens if you do touch sites/default/settings.php?

Thanks for the contribution Damien (#46). I would agree that your suggestion would make more sense from a design perspective but I hadn't taken the leap to make the statement that default.settings.php was unnecessary in the overall flow. I would have thought that using a copy of this file, renamed to "settings.php" which would then be updated within the install process, would have sufficed. In fact this was how I thought it would have worked and resulted in early install failures until I noticed that you had to have both files.

Catch (#47), I'm not sure which senario you are referencing from your question. If you are asking about the one where installing a multisite instance for a subdomain, any objects in the "sites/default" directory will not be part of the process because of the cascading nature of directory selection found in the Drupal environment. The subdomain is tried first, followed by the main domain, before any default directory is tapped. If this isn't the question that you are asking please let us know.

@james.tank - usually I install by creating an empty settings.php - i.e. touch sites/default/settings.php - simply because it's less typing than cp sites/default/default.settings.php sites/default/settings.php.

This is documented as an option in INSTALL.txt

I should probably just try it to see if it breaks, but about to head out.

@catch - what you would want to test is having the default.settings.php file exist anywhere other than the "sites/default" directory. The install process will fail if "sites/default/default.settings.php" does not exist. In a multi-site environment, the "sites/default" directory may not be an available install location. The hard-coded requirement within the "includes/install.inc" file is what I would consider a bug.

james.tank I'm aware of the original bug, just want to make sure there's no regressions elsewhere. I tested Damien's patch with an empty settings.php and still ended up with a proper settings.php afterwards, so no objections here.

@catch: nothing should break in that case, you will just end up with a settings.php containing only the database credentials.

The only two ini_set() we have in default.settings.php are useless in most case, and we should move them out.

And I should have read #51 before writing.

The last submitted patch failed testing.

I'm confused. What is the next step for this patch? Is the approach valid? (I originally came to this patch, because I did a mv instead of a copy, and I thought it should have given me a warning message that default.setting.php needed to be there.)

I dont understand why it failed the testbot.
I tried the patch on cvs, and it applies (with 3 line offset), and it installs with the patch [both when "copy" default.settings.php and when "mv/rename" default.settings.php.

I set to needs review to have the testbot try again. Maybe it was a testbot problem?

The last submitted patch failed testing.

Oh, slave #26. Why must you be so buggy?

The last submitted patch failed testing.

trying out a new testing bot that apparently wasn't working

The last submitted patch failed testing.