Quick news

  • 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
  • 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
  • 2013-10-18: My first commit went into MongoDB today. And, guess what ? It's in JavaScript
  • 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
  • 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
  • 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
  • 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ? Bets are on Later

Latest sites

  • 2014-08-18: 400% speedup in 3 weeks for http://france3-regions.francetvinfo.fr/ : who said Drupal back-offices had to be slow ?
  • 2014-02-07: Sotchi Olympics traffic not a problem for http://www.francetvsport.fr/ , which I rearchitected on Drupal 7 in 2013
  • 2013-08-04: Classified Ads 3.1-beta1 for Drupal/Pressflow 6 and Drupal 7
  • 2011-09-14: Completed migration of FranceInfo.FR from SPIP to Drupal
  • 2011-07-13: The new social network features of Le Figaro are now powered by an OSInet-designed MongoDB implementation
  • 2010-12-21: Madame Figaro brand new site by OSInet and others
  • 2010-08-16: France.FR is back online with OSInet and Typhon
  • 2010-06-15: the new France Culture, which OSInet helped reach its performance goals, is now online

When Drupal 6.x dev always returns "page not found"... pages can still be found

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.

saved my day! thx!

saved my day! thx!

This advice was a lifesaver

Thanks, this advice was a lifesaver. My problem happened after Drupal 6 RC1 was working well for a while but then I tried to use the views module and the site died.

Good one!

Thanks for this one, that really helped my - and you might guess I'm not a php expert :)

have you found why this happens?

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.

No problem with non-beta D6

I haven't seen this problem since D6 went out of beta. I expect you'll have some debugging to do :-)

I just got this error in drupal 6.1

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!

Critical issues should go in the issue queue

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

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

thank you thank you thank you thank you

I was configuring Drupal 6

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 :-)

I also had this issue when

I also had this issue when installing the Views module, version 6.x-2.0-beta3.

Hopefully it gets fixed before it's out of beta!


Views issue

Hi Jim,

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

Damn thanks so much! I was pretty worried for a sec.

I just about had a heart

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 more

Note that drupal_flush_all_caches() does (much) more than just rebuild the menu. It also clears all caches and the theme registry.

You saved me hours and a lot of rework

Thank you!


It works like a charm! Thanks a lot!

This is not a permanent

This is not a permanent solution.

For me, disabling all caching in Admin->Performance (in Drupal 6) resolved the problem.

Disabling caching is not a solution

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.

didnt work

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 a lot!

Thanks VERY much! Worked for

Thanks VERY much! Worked for me and saved my ass.

Thanks you so much!

This worked great! Thanks so much!

Thank you very much

Thank you very much

This saved me, thanks a ton

This saved me, thanks a ton for this.

Great time saver!! :)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.

Not able to find the menu_rebuild() function in index.php

Hello Sir,

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 menu.inc

menu_rebuild() is located in includes/menu.inc, which is loaded during the Drupal bootstrap triggered by these lines on top of index.php:

require_once './includes/bootstrap.inc';