install is loaded after successfull installation

I'd just like to point out I'm experiencing the exact same issue.

www.networkpie.co.uk : works
networkpie.co.uk : doesn't

Sorry my issue is the exact opposite.

networkpie.co.uk : works
www.networkpie.co.uk : doesn't

But if you go somewhere specific:

http://www.networkpie.co.uk/?q=user/1

it works just fine.

I have the exact same problem on 3 last installs, on 2 different web hosts! This is becoming a major issue for me.

forgot my details:

MySQL database 4.1.20
PHP 4.4.4
Unicode library PHP Mbstring Extension
Web server Apache/1.3.37 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.4.4 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.28 OpenSSL/0.9.7a

no modules installed, only user #1 registered. Nothing else done.

Huh, after leaving the site for a few hours and trying again everything seems to be working just fine.

Very very odd. It may have something to do with DNS as that can take a few hours to kick in but I don't see how.

It has not resolved itself here over a day in time, and DNS was not updated recently. It just happened on another site I just installed. I added the DB info, click next, it said install completed, click here to see your new site. Click there, and it redirects immediately to install.php.

It is something to do with the hostname detection since www.domain.com works, while domain.com does not.

Have you tried setting $base_url in your settings.php file?

I actually just got this on a site. The steps that caused it for me:

1. Went to example.com and got an "Please select a profile to install." I realized that I hadn't done updated the settings.php db info on the prod server.
2. So I updated the db settings to be accurate and then went to http://example.com and was redirected to http://example.com/install.php which said that Drupal was already installed. At this point we're stuck in a infinite cycle and can't get to the main page.
3. Going to http://example.com/user and logging in works. Then I can access the home page either as auth/anon.

Where is your settings.php file stored (i.e. what is the directory path)?

It sounds like it may be a caching issue.

moved to critical > users cannot have so much trouble installing

more and more people are complaining about this in IRC channels too

Seems like something might be getting cached.

Is the database username/password the default of 'username'/'password'?

this must be a caching problem - I accessed my site through a proxy browser and it worked fine - then i went back to my own browser and viola - problem solved - dont know how this happened but it solved the problem - BTW Itried it in different browsers (which did not access the site before - no cache) and it still went to install.php

I am having this problem to.

My host ( www.nearlyfreespeech.net ) has recommended to use www. rather than just the bare domain for all sites, as it apparently gives more options for load balancing and failover.

I have setup drupal for: www.example.com

I have also setup example.com which only has a .htaccess file in the htdocs root, with just the following in it:

Redirect permanent / http://www.example.com

This way people can still access my site using just "example.com", but it will consolidate search engine rankings to www.example.com and automatically transfer anyone to example.com

The problem could be (being the lazy guy I am) I typed in: "example.com" and just let it redirect me when I did the installation, so Drupal may think that it should be running on "example.com" and try to forward everyone there and then get confused somehow.

www.example.com/index.php works

Problem seems to have gone away, perhaps just a caching issue (I mean in Drupal's setup, not on my computer, as I tested it across several PCs when it was broken)

I just got this on a fresh 5.x-dev install, but it happened when I had a misnamed sites/* directory. So I got the install screen, then realized I needed to change the site/* dir, changed it then kept getting the install page. So I entered all the correct details that were in that settings.php and got the "Drupal is already installed screen" after that.

I'm having this problem, also using nearlyfreespeech for hosting. I've installed numerous 4.7 sites there, and one 5.0 site without this problem. My latest 5.0 site however has this problem something fierce. Here's what I've observed...

If I go to the site using the nearlyfreespeech domain name, http://dailystink.nfshost.com, then sometimes I will be forwarded to install.php, sometimes I will not. I can't predict when the problem will occur.

If I go to the site using it's own domain name(s), ie. http://dailystink.com or http://www.dailystink.com, then I always get fowarded to http://dailystink.nfshost.com/install.php. Note that the domain name changes. There is no file referencing the domain name "dailystink.nfshost.com", so I'm not sure why the redirect leads me there.

Finally, if I go to any internal pages, they work fine. For example, http://dailystink.com/node or http://www.dailystink.com/index.php work exactly as expected.

Very much looking forward to a resolution of this problem!

I am also having this problem. Brand new 5.1 install on a NearlyFreeSpeech.net account.

It is very frusterating because I have no domain yet, and cannot append a www. to the beginning of my address yet. It unfortunately is a deal-breaker for me. If a solution isn't found soon, I've got to switch to another CMS. Please help!

Thank you

nrwilk

It does seem to be some caching/proxy issue with nearylfreespeech.net. I'm having the same problem there, but never see it on my local host.

Here's what I just did that resolved it after a few minutes:

rename index.php to something else.

Go to your site- you should get "not available" error message from the host.

Put index.php back, wait a few minutes and try again.

Hello from NearlyFreeSpeech.NET. :) We do indeed frequently hear about this problem.

This problem is caused because Drupal sends a cacheable redirect during the installation process. We feel it should not do this for something that is so obviously intended to be a transient redirect. To properly resolve this issue, Drupal should set the Cache-Control: header appropriately to prevent this redirect response from being stored downstream.

When this happens, it will eventually fix itself, but it can be annoying in the interim. The easiest workaround that does not require any special help is to add a "?" to the end of the URL, like so:

http://www.example.com/?

(As if it were a CGI GET request with no parameters.)

This will allow you to load the page until the cached redirect expires.

If you know how, you can also issue an HTTP request for the real URL with the "Pragma: no-cache" or "Cache-Control: no-cache" headers and this will cause our network to reprocess the URL and pick up the change. This is unfortunately a bit tricky to do from a standard browser, since it's hard to indicate that the URL you want to force-reload is the one before the redirect, but it can be done with tools like curl or wget.

-jdw

Here's a permanent workaround that doesn't require special tools, only telnet.

Find your site's IP address and do the following from the shell:

$ telnet 10.20.30.40 80
Connected to server-10-20-30-40.example.com.
Escape character is '^]'.
HEAD / HTTP/1.0
Host: www.example.com
Cache-Control: no-cache

(You type the bits in bold, adding a blank line after Cache-Control:)

After this, you should get back a bunch of HTTP headers that do *not* include a Location: header.
This will force any intermediate caches to go back to the origin and throw away cached content.

If you use a service like ours where your site has multiple IP addresses, you'll need to do it once for each associated IP address.

For the site I tested this on, Drupal had told our system to cache the installation redirect for two weeks! This is the "actual bug" that needs fixing, because that's just silly.

Hope this helps!

-jdw

I feel bad submitting a patch that I have not had time to test. I will the next time I install a new site on nearlyfreespeech.net.
However I did want to contribute my changes to this issue, in case it helps others.

This patch should prevent the redirect from being cached in the first place. Thanks to jdw for pointing out a solution.

if drupal_header() is available, we should use that i think.

The patch in #25 is not the same as the workaround in #24. #24 suggests crafting a request which clears out network caches. #25 changes Drupal's response from

  Cache-Control: store, no-cache, must-revalidate
  Cache-Control: post-check=0, pre-check=0

to

  Cache-Control: no-cache

This will require a bit of testing.

About using drupal_set_header(), it is defined in common.inc and prevents sending empty headers and handles Drupal-caching of headers, neither of which we have to worry about.

I have the same problem.

hotfix :)

looking here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

It seems like having the "no-cache, must-revalidate" would insure the correct behavior. Is it a problem with "store"?

The discussion about the meaning of the "store" directive is here: http://drupal.org/node/109941#comment-192542

The patch in #25 didn't work for me.

[Quickfix]
Rename your install.php, create an empty install.php and add the following line into it:
<?PHP header("Location: /Home"); ?>

Or
<?PHP header("Location: /index.php"); ?>

Did anyone find the real reason for the redirect?

The patch in #25 solves the problem for me - I just tested using Drupal 5.x on a new site on nearlyfreespeach.net.

It's a simple change and only affect the install phase.

for some reason the patch in #25 didn't apply for me to HEAD. Anyhow, re-rolled patch is attached. I just tested this with HEAD/6.x on the same host, and it works well.

I have the same problem when testing new Drupal 6 stuff, but I am not sure it is predictable. Oftentimes i get a "Drupal already installed" screen in the middle of doing something (eg. submitting the module list form or somewhere throughout the installer), which is a very strange behavior indeed. I cannot test this right now, but it would be great to get more testing before committing a fix.

@Gabor - have you had a chance to look at this now?

I want to confirm I have seen this behaviour all through the 5.x series, on every install, and I just now got it on 6-dev install. You can force it to bypass the message by manually adding /index.php to the URL, and the symptom goes away after a few days (caching expires I guess).

has anyone else actually tested this patch? Either to see if it prevents the bug or if it causes problems?

The patch has worked for me on my latest nearlyfreespeech.net install. I think it's RTBC, but I'm not installing sites frequently enough to have tested it well.

Well, it will not worsen the situation in any case, it's worth trying.

I reread the discussion here, and all the analysis points to the need to add a no-cache rule. Some tests already show that it works. Committed.

does the 5.x installer have this problem too?

Drupal 5 has a similar install_goto() function which might have the same issue. It probably would not hurt to add this. The existing patch does not apply.

I had this same problem for nearly a week. My host is nearlyfreespeech.net, and I tried solution #24, but that didn't solve the problem for me. I also tried #22, and that didn't work either. So, I created a new index.php and removed install.php. My new index.php looked like this:

 header("Cache-Control: store, no-cache, must-revalidate"); 
print "<html>\n hi.. testing\n</html>"

I called both http://www.example.com/? and same thing without the ? from my browser. (I may have also called example.com/index.php)

After that, it stopped forwarding to install.php. :)

@bandrew - I did test the committed patch on my account on nearlyfreespeech.net.

For some reason the D6 patch above doesn't apply to D5, even though the code change is exactly the same. Attached is a D5 patch. I just tested this on nearlyfreespeech.net, and without the patch a new D5 site redirects to the installer, with the patch it's fine.

Issue still exists in drupal6-beta1 :( No-cache line is present in install.inc, but still when I go to site without www. prefix, I get "Drupal already installed".

changing version up to 6-beta1

@svladcjelli - this is fixed in 6.x-dev/HEAD (which with be 6.x-beta2). beta1 is a static release and will never be fixed/altered. see: http://drupal.org/node/97368

unfortunately I have just seen this bug in Drupal 6.x-dev as well.

This time is a little different:

1. I performed the install using the www. as in www.example.com
2. Install completed, click here to go to your new site, this works as expected, I get sent to www.example.com
3. Manually remove the www. from the url and submit brings me to "Drupal already installed" at example.com/install.php
4. Forcing url to be example.com/index.php brings up correct page, clicking on site title returns you to step "Drupal already installed"

@svladcjelli: that sounds like a different bug, and this patch would not fix it. Please open a different issue or look for one related to that issue.

The patch here that is RTBC is already in 6.x-dev, and needs to be back-ported to 5.x-dev.

I am sorry to have to keep bringing this back up, but I just confirmed again with 6.x-dev downloaded today that this bug exists exactly as original poster submitted.

I can reproduce this bug at will. All I need to do is install a clean install, go through install wizard, and when it says 'click here to visit your new site' you get redirected to 'drupal already installed'.

This time I did it exactly as bug report, installed not using the www. It does seem from my previous report that whether you use www. or not when installing, it is always the non-www. URL that throws you back to install.php.

Please see http://pastebin.ca/727078 for a transcript of trying to curl the server... you will see I am redirected, because I hit the cache on my gateway... There is no no-cache header sent when it should be IMO (which is not the curl command, but rather the first 302 that is issued to lead into install process).

If I force no cache with "curl 'http://example.com' -v -H 'Cache-Control: no-cache'" it fetches the correct page.

I understand it is hitting my own cache, but the cache could be provided in many different venues, so I feel that drupal should be the one forcing the cache to not be used at this step.

ok, I think I may have had a previous cache in my proxy. This stuff is not easy to troubleshoot. Bumped back down, I apologize for annoyance.

Committed to 5.x.