We had a project that uses the book module as if it was integrated into the main menu system, even though the top level book item is the termination of the Menu modules menu and the start of the Book modules menu. This had two blocks, one for the Menu modules menu and another for the Book navigation. By default, the book pages resulted in the Menu modules block not having any active trail and this was not being rendered correctly.

This was the hack that I used on 6.x-2.2 and have (untested) patched against HEAD (2010-02-17). This adds an option to "Activate top level book pages" which tries to activate the correct non-book menu item before the menu is rendered using menu_set_active_item(). After rendering, the menu is reset to the original menu item.

This seems very hacky, but I could not think of another simple way of doing this.

Looking at drupal_alter('menu_block_tree', $tree, $context); didn't seem like a possible way to hook into the module, but maybe code like this should be wrapped into two new alternative hooks:

<php
module_invoke_all('menu_block_prerender_block', $context);

// The menu tree & block rendering code goes here...

module_invoke_all('menu_block_postrender_block', $context)
?>

This would them allow other modules to bypass many of the core menu bugs such as only having the main menu being set, etc

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Alan D.’s picture

Duh; the bit "wrapped into two new alternative hooks" should have been "wrapped into two new additional hooks".

Cheers

JohnAlbin’s picture

Status: Needs review » Closed (won't fix)

In the -dev release, there is a hook_menu_block_tree_alter() that allows you to alter the tree data before it is rendered. You could write a helper module that uses that hook and manually sets the active trail to the proper place in your non-book menu.

The rest of this patch seems a bit beyond the scope of where I'd like menu_block to be. Sorry! :-(