A problem with the yet unreleased versions of Drupal 6 is that in some cases Drupal all of a sudden seems to lose all of its paths. In my case it happened when working on a port of an OSInet module from the Drupal 4.7 to Drupal 6 API.
A symptom of the problem can be seen by checking the
menu_router table and finding it to be empty, although it should contain the default site navigation.
Before reinstalling, a
quick hack/fix can return the site to a better behaviour: since Drupal knows how to install itself, how about asking it to regenerate the
menu_router table ? Luckily, there's a function which does just that: menu_rebuild.
So just edit
index.php at the root of your Drupal install, just like this:
menu_rebuild(); // use just once
die(); // use just once
$return = menu_execute_active_handler();
Now invoke any page on the site, just once, then remove the two added lines, and your menu should return to normal.
Thanks for this one, that really helped my - and you might guess I'm not a php expert :)
Hi. Before finding your method my way was to copy
menu_router content again. Have you found the reason the table is emptied? On my local machine the module I am writing works fine. On the production machine it just empties the table... I am puzzled.
I haven't seen this problem since D6 went out of beta. I expect you'll have some debugging to do :-)
It happened when I tried to write a code to add an action and enabled my module for the 1st time
I cannot see any connection between this and my code I actually just contained empty functions and hooks
This is not the 1st time I got this, last time I recovered from my nightly backup and lost the accesslog, watchdog and some cache I am not backing up nightly
I think this is a critical issue, I'll do my best to investigate it anyway your tip saved me! 10x!
Thanks for your comment. However, if you can find how to reproduce the problem in a current release like 6.1, you should really create an issue on d.o. about it, so a fix can be worked on.
Thanks so much for this. I had the same problem with Drupal 6.1 when uploading the Views Module. It just killed the site and I had no idea how to get it back up. I deleted the module and then followed your instructions and it brought the site back online. Thanks again!!!
thank you thank you thank you thank you
I was configuring Drupal 6 last night and was stopped dead in my tracks by this issue. I was this close to re-installing Drupal when I stumbled upon your blog post. THANK YOU!
thanks thanks thanks thanks thanks thanks thanks thanks thanks thanks thanks
You saved my day either :-)
In that case, make sure you report the problem to the Views issue queue. The Views maintainer will likely never see it if you only mention here.
Here is the submission form for Views issue:
Damn thanks so much! I was pretty worried for a sec.
I just about had a heart attack...
You are a God.
thanks a lot.
I have faced this problem on a live site also in latest 6.x stable versions of drupal. You can clear the all cache with drupal_flush_all_caches(); This will also rebuild the menu router table.
I added this to a separate file so that I can run it frequently while developing, also it helps on live sites where I dont have to install the devel module.
drupal_flush_all_caches() does (much) more than just rebuild the menu. It also clears all caches and the theme registry.
It works like a charm! Thanks a lot!
This is not a permanent solution.
For me, disabling all caching in Admin->Performance (in Drupal 6) resolved the problem.
If you have to keep caching disabled, then you have a serious problem indeed. Sure, if your menu breaks on all page hits and doesn't break with caching disabled, you can keep caching disabled while you fix the problem. But please do not consider disabling caching a production-level solution.
The workaround I suggest here, as well as your mention of disabling caching in settings/performance, is here to get your site running again so you can find the culprit and fix it: Drupal is designed to work with multiple levels of caching enabled, and is real slow without at least the builtin caching: one should neven run with caching disabled past the debugging stage.
For me all these flush-cash tricks in index.php did not work. I could also not log in.
Finally what I did is go to
settings.php and set
$update_free_access = TRUE; and then run the
update.php script - this finally gave me back my
menu_router data. (this was in a multi site environment so maybe the index.php trick was updating the wrong database? I dont know..)
thanks a lot!
Thanks VERY much! Worked for me and saved my ass.
This worked great! Thanks so much!
Thank you very much
This saved me, thanks a ton for this.
Great time saver!! :)
This happened to me working on a hook_menu_alter() function. My menu_router table only had 3 links (including node) in it.
I am getting 404 in all pages of my drupal installation and I am not able to perform any operation on my website (deleted: now a domain parking). Looking at your post I tried to locate the menu_rebuild() function in index.php file but its no present. My webhost is also not able to solve the problem. Please help me so that I can recover my website.
Thanks and regards,
menu_rebuild() is located in
includes/menu.inc, which is loaded during the Drupal bootstrap triggered by these lines on top of