Hi,
the Installer of D7,actual HEAD fails after entering the DB and the DB login with

Warning: fopen(/var/www/d7test/drupal/sites/default/default.settings.php) [function.fopen]: failed to open stream: No such file or directory in /var/www/d7test/drupal/includes/install.inc on line 345

Warning: Cannot modify header information - headers already sent by (output started at /var/www/d7test/drupal/includes/install.inc:345) in /var/www/d7test/drupal/includes/install.inc on line 802

Warning: Cannot modify header information - headers already sent by (output started at /var/www/d7test/drupal/includes/install.inc:345) in /var/www/d7test/drupal/includes/install.inc on line 803

it's possible to workaround this by the attached patch, but i've no idea if this doesn't break other stuff like multisites...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

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

CorniI’s picture

Title: Install failes after entering DB credentials » Install failes when default.settings.php is not present
Assigned: Unassigned » CorniI

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.

Dave Reid’s picture

Title: Install failes when default.settings.php is not present » Install fails when default.settings.php is not present

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

CorniI’s picture

Priority: Critical » Normal
Status: Active » Postponed

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.

CorniI’s picture

Status: Postponed » Needs review
FileSize
2.72 KB

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.

earnie@drupal.org’s picture

Status: Needs review » Needs work

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.

CorniI’s picture

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...

CorniI’s picture

Status: Needs work » Needs review

no comment -.-

Xano’s picture

Status: Needs review » Needs work

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.
    3. 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.

CorniI’s picture

Status: Needs work » Needs review
FileSize
2.69 KB

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 ;)

catch’s picture

Status: Needs review » Reviewed & tested by the community

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

$ mv default.settings.php settings.php
$ cp settings.php default.settings.php

- the error message goes away and everything proceeds as normal.

If I do

$ mv default.settings.php settings.php
$ touch default.settings.php

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.

Xano’s picture

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.

catch’s picture

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.

Anonymous’s picture

Status: Reviewed & tested by the community » Needs work

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.

CorniI’s picture

Status: Needs work » Needs review
FileSize
2.74 KB

here you go, I merged both sentences ;)

Anonymous’s picture

Status: Needs review » Reviewed & tested by the community
dropcube’s picture

Status: Reviewed & tested by the community » Needs work
keith.smith’s picture

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

CorniI’s picture

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

CorniI’s picture

Status: Needs work » Needs review
FileSize
2.9 KB

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

dropcube’s picture

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.

CorniI’s picture

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

// Verify that the directory exists.
    if (drupal_verify_install_file($conf_path, FILE_EXIST, 'dir')) {

If you don't get the warning, please describe exactly what you did. In my opinion, still #20 should be valid

Anonymous’s picture

Status: Needs review » Needs work

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

+    $default_exists = drupal_verify_install_file($default_settings_file, FILE_EXIST|FILE_READABLE);
+    if (!$default_exists) {

To

+    if (!drupal_verify_install_file($default_settings_file, FILE_EXIST|FILE_READABLE)) {
dropcube’s picture

Status: Needs work » Needs review
FileSize
2.01 KB

@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.

dropcube’s picture

Oops, there was a slash missing.

Xano’s picture

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.

catch’s picture

@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.

Xano’s picture

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.

catch’s picture

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

Anonymous’s picture

Status: Needs review » Needs work

The last submitted patch failed testing.

dman’s picture

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

beginner’s picture

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

It says:

Copy the ./sites/example.org/default.settings.php file to ./sites/example.org/settings.php.

but the code requires ./sites/default/default.settings.php to exist. (I had removed the default directory as I didn't want any default).

Xano’s picture

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

beginner’s picture

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

dman’s picture

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...

Anonymous’s picture

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.

Dave Reid’s picture

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

Anonymous’s picture

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.

hansfn’s picture

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.

topper910’s picture

Version: 7.x-dev » 6.2
Assigned: CorniI » topper910

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!

Anonymous’s picture

Version: 6.2 » 7.x-dev
Assigned: topper910 » Unassigned

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

Bojhan’s picture

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.

Anonymous’s picture

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

webchick’s picture

Issue tags: +DrupalWTF

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.

Anonymous’s picture

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.)

Damien Tournoud’s picture

Status: Needs work » Needs review
FileSize
1.44 KB

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

catch’s picture

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

Anonymous’s picture

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.

catch’s picture

@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

You may do so
   by making a copy of default.settings.php (or create an empty file with
   this name in the same directory).

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

catch’s picture

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.

Damien Tournoud’s picture

@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.

Damien Tournoud’s picture

And I should have read #51 before writing.

Status: Needs review » Needs work

The last submitted patch failed testing.

YesCT’s picture

Status: Needs work » Needs review

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?

Status: Needs review » Needs work

The last submitted patch failed testing.

webchick’s picture

Status: Needs work » Needs review

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

Status: Needs review » Needs work

The last submitted patch failed testing.

deekayen’s picture

Status: Needs work » Needs review

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

Status: Needs review » Needs work
Issue tags: -DrupalWTF

The last submitted patch failed testing.

Status: Needs work » Needs review
Issue tags: +DrupalWTF

prigupta2 requested that failed test be re-tested.

carlmcdade’s picture

I just downloaded and tried to install D7. The install fails because settings.php is not seen regardless of the permissions (set to everyone 777). This is on a Macbook Pro using Xammp with PHP 5.29

aspilicious’s picture

did you coppied and renamed default-settings.php to settings.php??

carlmcdade’s picture

Yes, copied using the command line. Since this is on a Mac I also tried to use sudo and root with no effect. So the problem is not in the naming or the permissions but rather in the code somewhere. D7 is not seeing the "settings.php" file or is choking on the template file being in the same directory.

carlmcdade’s picture

Okay it seems that this problem is particular to running Xampp on a Mac. Mac os x Leopard does not set the right ownership permissions on the files that are created in the GUI. You have to sudo and create in the command prompt. For some reason being logged as root and creating the file only makes things worse.

dman’s picture

Off-topic to this thread - but since folk not getting their permissions right is such a FAQ...
@carlmcdade FYI this tip may help, I figured it out on OSX myself recently.
I add my own user to the 'www' group, and get the www daemon to share everything with its group by adding umask 0002 to /etc/launchd-user.conf. This means the webserver doesn't make things I can't change.
This also applies to files I create in the GUI, so by default, things I write are readable by the group.

carlmcdade’s picture

Perfect! Thanks Dman! This makes things so much easier. Maybe this should be part of the Handbooks installation section.

dman’s picture

Flagged #208662: Missing default.settings.php produces no warning as duplicate.
Based on http://drupal.org/node/418302#comment-2500118 I'd like to bump this priority if the automated solution (copy the files for you) is now dead in the water.

iantresman’s picture

Having reached the "Set up database" part of the install, I had renamed "default.settings.php" to "settings.php" and set the permissions to 777. On entering the database information and clicking "Save and continue", I also get the error messages:

Warning: fopen(/mysite/public_html/sites/default/default.settings.php): failed to open stream: No such file or directory in /mysite/public_html/includes/install.inc on line 428

and

Failed to open sites/default/default.settings.php. Verify the file permissions.

I was able to resolve the issue by ensuring that my sites/default directory contained:

  • default.settings.php (in default read only), and
  • settings.php (with write permissions)
fabianogoos’s picture

Issue tags: -DrupalWTF
LT-1’s picture

installpatch.patch queued for re-testing.

LT-1’s picture

LT-1’s picture

LT-1’s picture

Issue tags: +DrupalWTF
EvanDonovan’s picture

This still happens as of CVS checkout of Apr. 3rd, if you mv default.settings.php settings.php. And it doesn't fail till after you've gone through the database configuration step. :(

The following error must be resolved before you can continue the installation process:
Error message
Warning: fopen(/Applications/MAMP/htdocs/d7-cvs2/sites/default/default.settings.php): failed to open stream: No such file or directory in drupal_rewrite_settings() (line 439 of /Applications/MAMP/htdocs/d7-cvs2/includes/install.inc).
Failed to open sites/default/default.settings.php. Verify the file permissions.

Check the error messages and try again.

Let me try the patch to see if it resolves it.

EvanDonovan’s picture

Status: Needs review » Needs work

Patch doesn't apply now that install.php has a include. Going to re-roll.

EvanDonovan’s picture

Status: Needs work » Needs review
FileSize
2.72 KB

Patch applies now & has been tested to properly throw a requirements error when default.settings.php is missing. Once it exists again, installer proceeds as expected.

Pretty please webchick, can this get in? :)

It's the least we can to help mitigate the problem #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) was intended to fix...

EvanDonovan’s picture

First ever patch of mine to pass SimpleTest. Yay! :)

chx’s picture

Status: Needs review » Needs work

You have added empty lines with just spaces in it. Please don't.

EvanDonovan’s picture

chx: OK.

I'll try again.

EvanDonovan’s picture

FileSize
2.55 KB

Same patch. Now with no unneeded whitespace :)

chx’s picture

Status: Needs work » Reviewed & tested by the community

Better :)

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs work

Nice, it would be great to fix this! But this patch still needs some work.

  1. As per #32, #45, etc, this patch does not correctly handle installation in a multisite environment - in fact, it breaks a perfectly reasonable workflow that works without this patch, since it (erroneously) requires you to create sites/example.org/default.settings.php even though that's not the one that is used. I think the simplest and correct fix is to define $default_settings_file to always point to sites/default/default.settings.php rather than having it depend on conf_path()?
  2. +    $default_settings_file = $conf_path . '/default.settings.php';
    

    If adding this variable, we should also reuse it in the other part of this function (see $requirements['settings file exists']) which currently has code that duplicates this definition.

  3. +    // If settings.php does not exist, throw error. 
    

    Here, and in two or three other places in the patch, should be "throw an error".

  4. +        $requirements['default settings file exists'] = array(
    +          'title'       => st('Default Settings file'),
    +          'value'       => st('The file %default-file does not exist.', array('%default-file' => $default_settings_file)),
    +          'severity'    => REQUIREMENT_ERROR,
    +          'description' => st('Please ensure that %default-file exists and is not modified in any way from the original download.', array('%default-file' => $default_settings_file)),
    +        );
    

    This entire code block occurs within an else() statement such that it only runs when the settings.php file already exists... however, since the instructions for creating settings.php say to copy this file, those instructions won't be complete if this file doesn't exist either, right? So, I would recommend that this code move above the if (!exists) {...} else {...} block; that way the error messages make sense even in the (admittedly unlikely) case of someone who doesn't have either default.settings.php or settings.php.

  5. +          'title'       => st('Default Settings file'),
    

    "Settings" should be lower case.

  6. +          'description' => st('Please ensure that %default-file exists and is not modified in any way from the original download.', array('%default-file' => $default_settings_file)),
    

    Drupal is no longer polite - see #679890: Using "Please" in the interface :) By analogy with other messages in the installer (and the fact that we already told them in the main message here that the file does not exist, so therefore don't need to say it again), I'd recommend rewording this as:

    "The @drupal installer requires that %default-file not be modified in any way from the original download."

EvanDonovan’s picture

David_Rothstein:

Thanks very much for the review! Your comments are all very specific and actionable. This is my first time helping out with re-rolling a core patch, so I am still learning the ropes to a large extent.

I probably won't be able to work on this more for a few days, but I'll definitely try to come back to it.

If someone else wants to re-roll with these issues fixed, that would be great. I just would really like to see this issue fixed, even though it won't be a full solution to the pitfalls with the necessity for a file copy.

David_Rothstein’s picture

Status: Needs work » Needs review
FileSize
2.98 KB

OK, well I might as well just reroll it while it's fresh in my mind, then :) Hopefully someone can mark this one RTBC.

This will indeed not be a full solution, but it will help a lot, and I also have some hope that we might be able to reopen #418302: Copy default.settings.php to settings.php during install IFF webserver owns files (FTP on shared hosting) with a (partial) fix for D7. But in order to do that, this patch needs to get in first.

tobiasb’s picture

Status: Needs review » Reviewed & tested by the community
tstoeckler’s picture

+++ includes/install.core.inc	4 Apr 2010 22:57:57 -0000
@@ -1546,12 +1547,24 @@ function install_check_requirements($ins
+    // If settings.php does not exist, throw an error. ¶

Unneeded whitespace.

Patch attached. Leaving at RTBC, because I literally deleted one character in the patch file.

Powered by Dreditor.

DanielMendle’s picture

EvanDonovan’s picture

DanielMendle: That patch no longer applies. The patch to test is #88, which has already passed just about a week ago. Please post a review of whether it resolves this issue & hopefully we can get this committed soon.

EvanDonovan’s picture

#88, which is tstoeckler's re-roll of David_Rothstein's patch still applies (with slight offset). Dreditor review indicates no whitespace issues. The patch solves the problem originally reported in the issue, and does it in a cleaner way than my re-roll did.

Thus, I second the RTBC :)

David_Rothstein’s picture

Bumping because it's been RTBC for a month and would be great to get fixed :) Patch still applies.

EvanDonovan’s picture

David_Rothstein: Thanks. I've mentioned it on IRC a few times, but I know that webchick & Dries are busy :)

navidoes’s picture

Issue tags: -DrupalWTF

installpatch.patch queued for re-testing.

navidoes’s picture

installpatch.patch queued for re-testing.

navidoes’s picture

navidoes’s picture

Issue tags: +DrupalWTF
Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

arhak’s picture

wouldn't this need to be backported?
just found this forum topic Error When trying to install drupal 6.17

Damien Tournoud’s picture

Version: 7.x-dev » 6.x-dev
Status: Fixed » Patch (to be ported)

Agreed on the need to backport.

arhak’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.83 KB
EvanDonovan’s picture

Thanks so much, Dries! Legions of newbie Drupal users are grateful :)

Thanks, arhak and Damien, for agreeing to work on a backport. I will try to test in the next few days.

christian.neu’s picture

Issue tags: -DrupalWTF

installpatch.patch queued for re-testing.

christian.neu’s picture

installpatch.patch queued for re-testing.

nitnut’s picture

Issue tags: +DrupalWTF
EvanDonovan’s picture

@nitnut, @csn102: The patches you queued for testing are D7 patches, and this issue has been fixed for D7. The D6 backport is in #101.

My apologies for not testing it yet myself.

klausi’s picture

Status: Needs review » Needs work
+++ includes/install.inc	Sat Jun 05 14:44:59 2010 -0500
@@ -550,6 +550,11 @@ function drupal_install_mkdir($file, $ma
+  ¶

+++ install.php	Sat Jun 05 14:44:59 2010 -0500
@@ -903,14 +904,23 @@ function install_check_requirements($pro
+    ¶

trailing white space

Powered by Dreditor.

shiyaodou’s picture

Status: Needs work » Needs review
Issue tags: -DrupalWTF

installpatch.patch queued for re-testing.

shiyaodou’s picture

mustafalx’s picture

Issue tags: +DrupalWTF

installpatch.patch queued for re-testing.

bhaskarinfy’s picture

rename the default.settings.php to settings.php and then restart installation process. The error is rectified.

amargaikwad1986’s picture

Issue tags: -DrupalWTF

installpatch.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, default-settings-312144-101.d6.patch, failed testing.

pirso’s picture

Status: Needs work » Needs review

installpatch.patch queued for re-testing.

pirso’s picture

Issue tags: +DrupalWTF

installpatch.patch queued for re-testing.

_12345678912345678’s picture

I am on linux mint 13 cinnamon and had this issue as well. I found that moving the file and copying it worked fine. How is the patch coming ?

I ran these commands.

mv default.settings.php settings.php
cp settings.php default.settings.php

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.