I have discovered a bug with menu.module when a Drupal install is setup using a table prefix in MySQL. Versions are Drupal 4.5rc (cvs) and MySQL 4.

I can describe the problem, and how to recreate it, but I don't know where in the code this issue comes up. I'm not sure I could find it, and I sure wouldn't know how to patch it. Sorry. :(

Anyway, to reproduce the problem, please follow these steps.

1. Setup a new Drupal install with table prefixes, by adding something (I used prefix_) to all statements in database.mysql. Also add the table prefix to conf.php (All files are at the root of my website directory, I doubt that makes a difference, but who knows.)

**Now, as soon as you create the first user and log in, if you go check out the prefix_sequences table in phpMyAdmin, there are two entries. menu_mid and prefix_users_uid, both with values of 1.

2. Now, go to administer/modules and activate the menu.module. You may not even be able to save the changes (i.e. the page won't reload with the changes saved.) If it does save the change, now try to go to administer/menu, and you should get a hung page (it will eventually time out with a 500 Server Error).

**At this point you should be stuck. The only way I can recover here is to use phpMyAdmin to go into the system table, reset the status of "menu.module" to 0.

**Next if you want to do Step 2 again, it will hang immediately (without saving changes). This is because the menu table is already populated. Drop that content and you can do this all again.

What I'm thinking is that menu_mid entry in the sequences table is causing some problems. First, it gets inserted somehow, when it shouldn't be. Then when you activate the menu.module, prefix_menu_mid gets inserted, but something somewhere is still calling on menu_mid.

**(I think that maybe inserting the prefix_ with the table names in the sequences table is not the best way to do it. menu_mid probably should be used, and users_uid should also be used. Then the functions calling them from the module php should add the table prefix variable. Having it hardcoded in the data makes changing the prefix unduly hard, if necessary. But this is a side issue.)

My host says the httpd error logs have the 500 Server Error, and says
"[Sat Oct 09 06:44:30 2004] [error] [client 68.125.000.36] PHP Fatal
error: Maximum execution time of 60 seconds exceeded in
/usr/home/username/domains/domain.net/public_html/includes/menu.inc on
line 653, referer: http://domain.net/?PHPSESSID=9b76e8341f0a2a514b545a2fa32c78"

Anyway, please try this out, and see if you can reproduce the error. I can reproduce it consistently on my domains.

-joshua

Comments

jonbob’s picture

jonbob commented

Our database.mysql definition has:
INSERT INTO sequences (name, id) VALUES ('menu_mid', 1);

This is present because menu ID 1 is reserved for the "Navigation" menu. The first additional menu item thus needs to be menu ID 2. The calls to db_next_id() respect the prefixes, thereby causing a new sequence to be created that has a duplicate menu item with ID 1. I'm not sure how best to fix it, but your comment about hardcoding the prefix in data seems germane. Can anybody with more prefixing experience chime in?

Steven’s picture

Steven commented

So basically, the prefixing happens on the sequences table? This seems like odd behaviour: the sequences table tself is already prefixed. If you share the sequences table, it would seem that this does not synchronize the sequences.

What happens if the statement
INSERT INTO sequences (name, id) VALUES ('prefix_menu_mid', 1);

is put into the prefixed database.mysql?

Steven’s picture

Steven commented

Yup I just tested this bug. The problem is that the sequence names should also be prefixed in database.mysql/pgsql. Otherwise a menu item with mid 1 gets inserted.

The easiest fix for now is just to explicitly check for menu id 1. If everything goes well, we'll have an install system for 4.6 to end prefixing worries once and for all.

Applied a fix to CVS.

Anonymous’s picture

(not verified) commented