edited menu items lose the connect to the parent

Still applies to current HEAD.

still applies

confirmed to be a bug.

NOTE: This bug is similar to, if not identical to, the bug found here: http://drupal.org/node/48178

It still exists in 4.7.2

See also:
http://drupal.org/node/55457
http://drupal.org/node/68567

Just to inform all, do not hold your breath on this bug fixed. JonBob is MIA. RHA too. And I am not really willing to fix this, as I will have a complete menu rewrite in Drupal 6 and my knowledge about the current menu is, well, not nil, but not deep enough to fix this.

Subscribing

This is uglier than I would like, but I figure I might as well post it instead of sitting on it...

I took a look and resetting is just deleting an item and letting it get recreated. This (and deleting items) is being done without any regard to children of the menu item :-(

CNW. Need to take another look at it, I think I rolled the patch against 4.7 or something...

See also http://drupal.org/node/64811

Managed to get farther.

This *should* never leave the menu system with unconnected parents now. Resetting now appears to work.

I need to know how much my changes to _menu_build() affect performance, hopefully it's not *too* bad. :-/

There's a problem with the confirmation form. After resetting an item, trying to immediately reset another item never calls the form submit hook. (?!?) Submitting another form and trying again causes it to work again. Like the form doesn't fully submit or something. (?). Has anyone heard of this happening before?

Any chance of this being followed up on, sorry?
(Sorry, but I don't have the familiarity with Drupal's internals to review the patch in a useful fashion.)

I can reproduce this problem but it's not clear (at least to me), if I should go ahead and review this patch. This might have to wait for the other big menu patch to land.

There's another big 5.x menu patch?

Dries, this is five, not six. There is no other menu patch for five I am aware of.

Dries: Which 5.x big menu patch are you referring to?

I can confirm this bug and this patch need testing and needs to get into 5.x

This IS NOT related to 6.x - bc is 6.x the menu system is completely rewritten.

I can confirm the problem on Drupal 5.x. This needs to be fixed and there are no other major menu patches.

The amount of change and complexity of the last patch does not seem appropriate for Drupal 5.x. I would be worried about the risk of creating another bug.

The problem seems to be that if an item is reset, it is deleted and leaves it's menu items without a valid parent id. I see two possible solutions:

1. Reset the item's attributes, but do not change the mid.
2. Or, update pids of all items to reflect the changed mid.

I think #2 might be more feasible. How about this algorithm on delete?

1. Store the old mid and the path in a local variable.
2. Call menu_rebuild().
3. Query to get the new mid for that path.
4. Set pid = new mid where pid = old mid.

Wontfixing due to 5.x EOL.