Installer does not warn the user that cookies must be enabled with the correct cookie domain (and fails when they aren't)

Since Drupal requires cookies to do anything useful, I don't think it's a problem that the installer requires them also, but I agree there should be a warning message.

This is still an issue in Drupal 7. Trying it with Lynx, here's the message I got:

   PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to
   your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN ()
   ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 417 of /home/droth/web/drupal/includes/menu.inc).
   The website encountered an unexpected error. Please try again later.

There's a similar (older) issue at #280015: cannot install drupal - menu_router error but that one has been closed for a while, so I think it's fine to start fresh again here.

Also see #2946: Login fails and no warning is issued if cookies are not enabled for the equivalent issue after Drupal has already been installed.

Actually this is a duplicate of #313606: menu_router error during install. But I'll mark the other one duplicate since it got slightly out of hand.

So we're probably just looking at adding code like this to includes/install.inc, right?

setcookie('drupal_install_check', TRUE, time() + 31536000, '/');
if (!isset($_COOKIE['drupal_install_check'])) {
  $domain = ini_get('session.cookie_domain') ? ltrim(ini_get('session.cookie_domain'), '.') : $_SERVER['HTTP_HOST'];
  form_set_error('', t('It seems your browser does not accept cookies. To log into this site, you need to accept cookies from the domain %domain.', array('%domain' => $domain)));
}

I got this error when trying to install Drupal 7 alpha 5 from Google Chrome (with cookies enabled). Retried with Firefox and it worked perfectly.

Here's a patch to start looking at addressing this.

Cookie testing has to be done in two requests: the first request sets the cookie, the second request read from the cookie, so this probably doesn't work as intended:

+  setcookie('drupal_install_check', TRUE, time() + 31536000, '/');
+  if (!isset($_COOKIE['drupal_install_check'])) {}

Also, I would suggest we don't need *cookie* testing, but *session* testing. It's not because we can set a cookie that the session is correctly configured and actually works.

I'm just looking to remove this somewhat fatal install error. Can you re-roll a patch with your changes?

Redirected to here from http://drupal.org/node/910400#comment-3623154

As I was about to re-post the bug and things I've tried to find a specific cause again, I remembered that one thing that differs between the machines on which installation fails with this error and the one on which it does not fail.

The failure occurs on machines that sit behind behind a NAT gateway. I access them through an separate apache instance that routes requests to them via mod_proxy, using ProxyPass and ProxyPassReverse directives. Once I access the site directly, the installer runs as it's supposed to.

My actual problem turned out to be the ProxyPreserveHost setting. That wasn't enabled and the hostname apache was proxying to and the name I was accessing the site via were different, thus probably causing the cookie sent back by the browser to not be accepted by the site.

With ProxyPreserveHost enabled, Drupal also installs fine through the proxy host.

I had applied the patch from comment 5, but that seemed to make no difference; I wasn't warned about a cookie problem.

Saw a person in IRC get burnt by this (to the best of my detection ability) so subscribing.

Expanding this issue a tiny bit, since based on #280015: cannot install drupal - menu_router error and others, the same installation error seems to occur if you have an incorrect $cookie_domain in settings.php.

Probably a correct fix would deal with both situations at the same time.

Posting here because ny original thread (http://drupal.org/node/837260) was closed as a duplicate of this one. I am using 6.19.

Time to set up another site, ran straight into the same problem. I set $cookie_domain in the original default.settings.php to my domain, i.e.:

$cookie_domain - 'mydomain.com';

which results in this value being copied into the site settings.php. This makes not a bit of difference. Same error, same stuck on &%^*^ go, facing same issue of probably spending a LOT of time trying to work-around a bug.

So did I do the $cookie_domain bit wrong?

Note that the database is on a different box...so I enter the IP address of the system as part of the install dialogue. All tables get created, the browser has cookies enabled (and gets some from mydomain.com, I insert one in the Apache configuration for the virtual host)

The last time I created a site I had the same problem and, from memory, worked around it by establishing a full Drupal environment on the database system and creating the site locally. The site works perfectly from the front-ends designated for it after this.

Is there likely to be any progress on the CRITICAL install bug anytime soon?

========================== UPDATE ===========
Work around for me is:

(1) Do all the usual MYSQL setup
(2) Run installer on target web server until it fails with this error.
(3) Enable httpd/drupal on the database server
(4) Delete and recreate the site schema in the database (don't touch the user)
(5) Initialise the site on the database box by going to http://localhost/drupal - this works just fine for me
(6) Delete everything created by the site initialisation in the drupal default site and shutdown httpd again.
(7) Reaccess the original failing URL and the site is there for you to use

Note that the browser used (2) and (5) is out-of-the-box Firefox so cookies are enabled. Note that there was no messing with $cookie_domain in this work-around.

============= UPDATE 2 ================
Presumably if the browser used in a failed site initialisation can be quite happily used for all aspects of site administration after the workaround has been applied then would it be realistic to surmise that:

(1) cookie settings are not the problem
(2) $cookie_domain is not the problem

I solved this on my system:

Also 6.19 here. Fedora 14 all standard packages, no custom builds. I am trying to set up a local dev site, and running into the same problem. The default tables do not seem to be getting populated correctly. I am using the latest FF with all cookies enabled, and all adblockers disabled for the site. I have tried creating the site using localhost, the hostname, and the FQDN. None of those seem to make a difference. I always end up with the error :

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1 query: SELECT * FROM menu_router WHERE path IN () ORDER BY fit DESC LIMIT 0, 1 in /usr/share/drupal/includes/menu.inc on line 315.

What I found was that my httpd conf for Drupal was set for my server where SSL is set up, but on my dev site, I do not have SSL set up, so needed to comment out the line:
# php_flag session.cookie_secure on

I then dropped the tables, and re-ran the install.php from the browser. No issues.

Hope this helps some folks.

We had the same problems in one of our machines.
The time of the machine was wrong. We updated it and it got fixed

Though i somehow managed to get the drupal7.0 release installed ( after upgrade to Debian Squeeze from Lenny ) i cannot find a way to diagnose or work around the bellow error. I'm not proficient with php, mysql so this is a mystery to me and really really bothersome.

I find no errors in log files for apache2, mysql or any php related error.

Error
The website encountered an unexpected error. Please try again later.
Error message
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY fit DESC LIMIT 0, 1' at line 1: SELECT * FROM {menu_router} WHERE path IN () ORDER BY fit DESC LIMIT 0, 1; Array ( ) in menu_get_item() (line 443 of /var/www/drupal7/includes/menu.inc).

I posted more remarks under http://drupal.org/node/1130348

This issue still exists in the stable released edition of 7.2. Managed to find this bug via a google search on the SQL query in menu.inc. I use cookie monster in firefox to block all cookies by default and allow on demand. Enabling cookies for the domain I'm setting the site up for allowed the install to continue past this error.
This happens with both PostgreSQL or MySQL as the database.

I'm not sure if it's affecting anyone posting here, but there is another way to trigger this error.

If one of the modules you're installing (as a dependency in an install profile's .info) has a hook_init() that calls menu_get_object(), boom.

My custom module -- whose hook_init() called menu_get_object('taxonomy_term', 2) -- caused this error during installation. I changed my hook_init() into a hook_entity_prepare_view() instead (for taxonomy_term entities, as the Context module does) and that solved the problem for me.

#5: 791004-5.patch queued for re-testing.

Triaging. This is still a common issue.

Updating tags per http://drupal.org/node/1517250

marked #481758: Fatal error: Call to undefined function field_attach_load() in includes/entity.inc on line 321 during install as a duplicate, appears to be the same issue.

Just a re-roll of my earlier patch.

Ultimately we want a drupal install to be easy. We want to give them information that helps them figure out when there are problems. A simple check for cookies should help.

Rerolled patch on 8.8.x, let's see how does it behave.

A re-rolled patch against 9.3.x. Please review.

Re-rolled patch #38, fixed cs errors. please review.

Tried to fix cs errors from the patch #39.

Removing Needs Reroll tag from the issue.

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Patch #40 doesn't apply anymore to 10.1.x.

Re-rolled patch for 10.1.x. Please review

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

There are still outstanding tags to be done. Still needs tests and issue summary update.