The new D6 book module uses the menu system to manage a book hierarchy. This is great. Every book page now has a menu item, which is stored as an entry in the 'menu_links' database table.

BUT: these menu items are part of non-existent menus! They're listed (in the 'menu_links' table) as being part of the 'book-toc-%' menus (where '%' is the nid of the top-level page in that book). However, no such menus exist in the 'menu_custom' table - contrary to all the other menu items on a site.

This presents a number of problems. For example, what if I want one of the books on my site to be used as primary/secondary links? (For this to be possible, http://drupal.org/node/160168 needs to be resolved as well). Since books are now handled by the menu system, this should be possible - but it's not. Similarly, what if for some reason, I want a regular, menu-module-generated navigation block for my books (rather than the book-module-generated blocks)?

As well as the problems described above, the current behaviour is wrong, simply from a database referential integrity POV. For book pages, the 'menu_name' field in the 'menu_links' table is an invalid foreign key. I know that we don't strictly have, or enforce, foreign keys in Drupal - but we're heading in that direction, and when we get there, things like this will not be tolerable.

Comments

pwolanin’s picture

pwolanin commented
Status: Active » Closed (works as designed)

@Jaza - this behavior is entirely by design. Menu module doesn't know anything about the {book} table, so if it acted upon the book module's links, things may break.

I'm hoping other will write/update new and intersting modules for D6 where the menu links are also connected to other properties that menu module doesn't know about. The {menu_links} table and menu.inc is a storage/retrieval mechanism that shold not be exclusive to any one module.