Menu links are sometimes not properly re-parented

Problem/Motivation

• If the node/add menu item is moved to another menu than Navigation, its children items are not moved with it. See comment #142for details.
• Moving the node/add menu item outside the Navigation menu is not properly registered in the Database, since newly created content types are not grouped under node/add in its new loacation, but instead inserted as top level items in the Navigation menu.
• Manually moving a content type's menu item outside the Navigation menu is possible, but if the content type is later deleted, the menu item is not. It can be manually deleted by clicking the "Reset" link, but this causes a duplicated "node/add" item in the Navigation menu which can only be deleted by editing the database. See comment #145 for details.

Proposed resolution

• Some of the problems outlined in the original post (see below for details) were solved by the patch provided in #105, and committed to HEAD by webchick in (#120).
• The module responsible for the automatic creation or deletion of menu items for content types needs to do a db query to check where the menu items of the existing content types are located. If duplicate entries exist, it should make an intelligent guess on which is the "right" one.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(new or changed features/functionality, modules added or removed, changes to URL paths, changes to user interface text)

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate)

---

Original report by sun

Note: It is possible that the following might not be accurate. However, the patch fixes the bug.

Symptom

• When exposing local tasks in a menu tree, it can (later) happen that those local tasks are rendered on the top-level of the menu tree instead of below their respective parents.

Details

• The issue is not directly replicable. You need a router item having local tasks, and very possibly, a third-party module that somehow manages to hi-jack the information returned by hook_menu() (via hook_menu_alter()) and turns that router item into a MENU_CALLBACK.
• The menu system currently tries to reparent any link by searching for the next available parent in the menu.
• Since our router item link has been turned into a MENU_CALLBACK, the re-parenting fails and the local tasks are stored with a plid of 0 (zero), which therefore makes them appear on the top-level of a menu.

Cause

• menu_link_save() processes all menu links, but simply checks for
  

    if (isset($item['plid'])) {
  

  to invoke the re-parenting process.

• Aforementioned local tasks have a plid set, but it is '0'.
• Therefore, no re-parenting happens, and the local tasks end up on the top-level.

Solution

• Test for
  

    if (!empty($item['plid'])) {
  

  to invoke the re-parenting check.

• This does not affect existing menu links having a plid of 0, because the re-parenting will simply return nothing.

I'd like to mark this critical, because I've spent a lot of time in the last six months with trying to understand what exactly and more importantly, why menu.inc fails.