menu_router error during install

This is a blocker for testing.drupal.org.

To clarify I'm using SimpleTest 6.x-2.x to install D7. Submit the database configuration page...then it sticks and only ends up inserting database structure. Appears to be JavaScript/batch API related.

Once this has a patch I'll try it out and make simpletest to ensure this is tested.

It would appear, after looking at Zlender's code and trying in Firefox with JS disabled that changing the op to do_nojs works.

Ending up with something like:

So this may just need some JavaScript detection. (possibly removed?)

#4: In order to test whether Drupal installs without JavaScript with Firefox I had to remove the has_js variable from the cookie. Without this variable, D7 installs fine with a JavaScript-disabled Firefox. Maybe I'm stating the obvious, but I just tripped over that.

It seems to me that #2 is not related to the original issue (?).

Now, what I found next may be related. If I disable cookies altogether, submit the install script's DB configuration page I wind up on the web site's root, empty screen except "Fatal error: Class 'DeleteQuery' not found in /path/to/website/root/includes/database/database.inc on line 762 "

When I look at the database, I find 33 tables installed.

When I go back to the install script, on /install.php?profile=default&locale=en I get this error message in a drupal_set_message() box:

Line 369 of menu.inc is the same query as in the original issue.

I'm pretty sure now that the menu_router error occurs if the install script can't jump over the first installation step _after_ the DB configuration form has been submitted. In non-js mode, Drupal sends 5 pages with 200 response code before it jumps to the site configuration page (you can look at it with a http logger like tamper data). This throws off some clients. For example curl: In the attached shell script you'll see that I'm pulling

4 times
install.php?profile=default&locale=en&id=1&op=do_nojs

followed by 1 time
install.php?profile=default&locale=en&id=1&op=finished

to simulate Drupal's install script behavior.

If you remove the tail part of the shell script that starts with the comment "# Step through install script, this shouldn't be necessary" you will wind up with a broken site that throws a menu router error as described in the issue.

Ok, I spend some time debugging this issue during the evening.

It turns out that (at least for Lynx), it is a cookie issue. Here is the mechanism:

• install.php does the first steps of the installation, then call batch_set($batch) and batch_process($url, $url): you are redirected to http://xxx/install.php?locale=en&profile=default&op=do_nojs&id=1
• on the next page load, install.php calls _batch_page(), which tries to load the batch. The token verification fails because you don't have the same session, because you have no cookies. The Batch API redirects you to the frontpage by calling drupal_goto(). You have an half-backed install, you see strange error messages.

I'm now convinced that this whole class of errors is simply caused by browsers don't accepting cookies. Lynx doesn't accept the cookie set by Drupal because it sticks to the standards: RFC2109 that browsers should reject cookies that have a domain-path not "domain-matching" the one of the host, and define "host name A domain-matches host name B" as:

* both host names are IP addresses and their host name strings match
exactly; or
* both host names are FQDN strings and their host name strings match
exactly; or
* A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)

So the cookie set by Drupal with a cookie domain of ".myhost.com" should not be accepted for "myhost.com".

The issue describe by alex_b with curl is different: curl doesn't support the meta refresh urls used by the batch API, so it never redirects.

#6: #2 is related...sounds like for same reason as Lynx.

Curl doesn't support meta refresh, but SimpleTest does :) as of teh patch. Another reason why I would prefer [#366978] instead of custom scripts.

I think I'm getting this on a fresh install of Drupal 7 (HEAD) against Apache 2.2.20, PHP 5.2.8, PostgreSQL 8.1.11 with Firefox 3.0.6 (with cookies enabled and allowed) on "localhost/drupal7".

With JavaScript enabled it finishes the install but has this error:

PDOException: INSERT INTO menu_router (path, load_functions, to_arg_functions, access_callback, access_arguments, page_callback, page_arguments, fit, number_parts, tab_parent, tab_root, title, title_callback, title_arguments, type, block_callback, description, position, weight) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15, :db_insert_placeholder_16, :db_insert_placeholder_17, :db_insert_placeholder_18), ([...]), (:db_insert_placeholder_2261, :db_insert_placeholder_2262, :db_insert_placeholder_2263, :db_insert_placeholder_2264, :db_insert_placeholder_2265, :db_insert_placeholder_2266, :db_insert_placeholder_2267, :db_insert_placeholder_2268, :db_insert_placeholder_2269, :db_insert_placeholder_2270, :db_insert_placeholder_2271, :db_insert_placeholder_2272, :db_insert_placeholder_2273, :db_insert_placeholder_2274, :db_insert_placeholder_2275, :db_insert_placeholder_2276, :db_insert_placeholder_2277, :db_insert_placeholder_2278, :db_insert_placeholder_2279) -
Array
(
)
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "," at character 359 in _menu_router_build() (line 2614 of /srv/http/localhost/htdocs/drupal7/includes/menu.inc).

Without JavaScript it doesn't even finish the install, and gives this error:

PDOException: SELECT menu_router.*
FROM
{menu_router} menu_router
WHERE (path IN ())
ORDER BY fit DESC LIMIT 1 OFFSET 0 -
Array
(
)
SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near ")" at character 70 in menu_get_item() (line 369 of /srv/http/localhost/htdocs/drupal7/includes/menu.inc).

@Freso: Drupal 7.x-dev only supports PostgreSQL 8.3. Make sure to use this version.

The same problem on 6.x: #234539: Critical SQL error in installer with {menu_router}
Here is some backtrace and description of the problem: http://drupal.org/node/234539#comment-1425476

Delete the has_js cookie?

I got the same SQL error after playing with menu_rebuild().

It turned out that
$masks = variable_get('menu_masks', array());
in menu_get_ancestors() did not return anything, because I messed up that part of menu_rebuild() that should generate these masks and write them to the DB. As a consequence, menu_get_ancestors() returned an empty array.

Is it possible that we have the same problem here?
The functions that call menu_get_ancestors() are not prepared to get an empty result. Imo, this has to change! We should not rely on having the masks properly stored in the DB. There should be either a fallback or a clear error message (I would rather throw an exception, but that is not very useful in the Drupal universe).

Proposed solution:
If menu_get_ancestors() returns an empty array, we set

Somehow it seems that the follow-ups in here are talking about 4 different issues... on top of that, we have a very fuzzy issue title. Is this still critical?

Sun, I bumped into this issue searching for a resolution to an issue installing Drupal 6.15. I kept getting sql errors on the install where the menu_router table was the first of many issues. I eventually found that somehow Drupal had partially loaded tables into the DB giving this issue. My resolution was to drop the database and recreate it. Once I had completed that it worked like a charm. Note make sure the DB is created with UTF8-GENERAL-CI collation; I've seen issues with creating it in a different collation.