Check new url aliases against existing hook_menu() declared items.

When I disable the module book.module, this strange behaviour stops.

To reproduce, try enabling the 'books' menu item, or create a menu item with the path leading to top page of the book.

This problem has been existing for a long while BUT it was NOT visible so far. Check directly in your {menu} table for numerous duplicate entries that otherwise do not show on the site.
I had noticed those before, but they didn't bother me, so I ignored it. But since the latest primary_links upgrade, those entries show and keep accumulating (I have a primary link to the head of the book)...

Meanwhile, the query that shouldn't run is here:
line 560 in menu.inc

    if (count($new_items)) {
      foreach ($new_items as $item) {
        db_queryd('INSERT INTO {menu} (mid, pid, path, title, description, weight, type) VALUES (%d, %d, \'%s\', \'%s\', \'%s\', %d, %d)', $item['mid'], $item['pid'], $item['path'], $item['title'], $item['description'], $item['weight'], $item['type']);
      }

QUESTION: if you have both menu and book modules enabled, do you have rows of duplicate entries in your {menu} table?

QUESTION: if so, do you see one more entry in your database each time you visit admin/menu?

I noticed that the function book_menu() has two items with the same path:

function book_menu($may_cache) {
    $items[] = array(      'path' => 'book',
      'title' => t('books'),
      'access' => user_access('access content'),
      'type' => MENU_NORMAL_ITEM,
      'weight' => 5);
   $items[] = array('path' => 'book', 
      'title' => t('books'),
      'callback' => 'book_render',
      'access' => user_access('access content'),
      'type' => MENU_SUGGESTED_ITEM);

Thus, in admin/menu, the menu item 'books' is disabled, but the link to enable it points to admin/menu/item/edit/-28.
Notice the negative sign in front of the integer 28.
When I click it, it leads me to a blank add menu item form (i.e., I cannot edit the 'menu' book item).

When I change the path in the book_menu fonction to $items[] = array('path' => 'bookdebug' ..., and then reload admin/menu, the enable link is correct.

QUESTION: is it normal to have to menu items declared in hook_menu() with the same path?

Still, if I remove or modify the duplicate declaration, the problem mentionned above persists. It is not a bother as long as I don't insist having a primary link item to the 'book' page.

:-/

The problem was due to the fact that I created a path alias with the same name leading to the book page.
Removing the path alias solved the problem.

You can replicate the behaviour above by enabling menu, path and book module, and creating a url alias called 'book' pointing to any node.

The whole mess above could be avoided for other administrators by doing the following two checks:

1- when adding a new path in admin/path, check that the path does not conflict with any of the hook_menu() paths.
2- when enabling a module, check that its declared menu items to not conflict with any existing url aliases.

Those checks assume that we agree on what kind of path is acceptable, and what kind isn't.

3- Would it be ok to accept a duplicate path (i.e. having an identical hook_menu item and path alias item)? If so the code needs to be reviewed to correct the odd behaviour described above.
4- Would it be ok to accept a sub-path to a path declared in hook_menu()?

Taking my case as a concrete example.

book_menu() declares the path 'book' : http://drupal.org/book or http://www.wechange.org/book .
In the wechange case, there is only one book, so I wanted the path to lead to the head of the book: http://www.wechange.org/node/5 .
My problems started when I created the path alias node/5 => book but it became only apparent two months later when upgrading to the code with the new primary_links set in admin/menu: see story above!
This is an example of point 3 above.

The reason I wanted the path book/ to point to node/5 was so that I could have sub-pages set appropriately:
http://www.wechange.org/book/positive_action ,
http://www.wechange.org/book/positive_action/netizens_communication_and_... .
so that when using the up button in Konqueror (or any other browser with that button), one could land on the page up the book.
But now, going up the directory structure, doesn't lead me to http://www.wechange.org/node/5 anymore.
I know, I can change all the book/* urls, but that's beside the point.
This is an example of point 4 above.

If we disallow point 3, it makes sense to disallow point 4, too. If we allow both, the code needs review.

Here is another concrete example where a 'book/' path does not necessarily mean anything to do with the book.module:
this site has a treeware book for sale:
http://www.reuniting.info/peace_between_the_sheets .
the site could also use the book.module to organize the rest of the content of the site (see science and wisdom sections for example).
If so, the book/ url would lead to the top of the wisdom/science sections, but it won't have much to do with the book for sale (only indirectly, anyway).
It's lucky they choose the path alias peace_between_the_sheets/* instead of book/* for the subpages, otherwise going up the directory structure from a page like:
http://www.reuniting.info/peace_between_the_sheets/fan_mail (which would then be called book/fan_mail ) would lead to an unrelated page (the top of the book module pages with the science/wisdom material).

I hope you are not utterly confused, by now! ;-)