[development] The new menu system

Moshe Weitzman weitzman at tejasa.com
Tue Sep 26 14:17:47 UTC 2006

> What's done? On the menu level, I need to write the navigation block, 
> all else is done. I also need to convert modules -- node and user 
> already done. All this took only a dozen hours or so, beginning with the 
> first evening/night of DrupalCon first day ending on the train to 
> Charleroi converting user and three meetings at DrupalCon / BarCamp.

yes, this is extremely exciting. in my testing, the menu system is the 
slowest part of drupal (beside parsing php code - use an opcode cache to fix).

this new system gets rid of the $may_cache switch in hook_menu(). hook_menu 
is now called only upon module enable/disable and admin/menu. this is 
outstanding. however, we no longer have a place to stick our 
drupal_add_css() and drupal_add_js() type calls.

so, lets create a new hook_signal($op) which fires at various points during 
a request. Initially, it replace hook_init() and hook_exit() with 
$op=precache, $op=postcache, and $op=exit. We shall also add 
$op=postbootstrap  which is where the drupal_add_css calls will go.

One minor complication is that we no longer have hook_init and hook_exit for 
determining which modules need to be bootstrapped (see system.module and the 
bootstrap column of system table). But we do have .install files now so my 
proposal is that modules which require loading during bootstrap perform an 
UPDATE system SET bootstrap=1 WHERE module=<foo> during their hook_install().

This hook_signal() patch should probably go in before this menu system.

More information about the development mailing list