I can confirm this behavior occurs, which I believe is intentional.

In order to get the behavior you desire, you need to use the "Batch" option on the Menu Manager: Menu Items screen. You would check off the parent menu item, press the Batch button, select the new menu to move the parent/child set of menu items to, and press Process button.

With that in mind, perhaps an updated language string tooltip would be helpful for users. Something like:

"Menu Location
Shows which menu the link will appear in. If you are editing an existing menu item that has child menu items and change this option, the child menu items will not move with the parent. Use the Batch option on the Menu Manager: Menu Items screen to move parent/child sets of menu items."

I know how the "batch"-Button works. But an ordinary joomla no-programmer user may not use the Button. The "new" tooltip may help.
But the fact that there is another way (a correct way) to change the menu of a parent menu item dosen't change the destroyed menu module back to normal for someone how doesn't know what the problem is.

It is not enough to change the tooltip, the behavior of the Menu Modul should be optimized too.
--> Maybe child items dosen't need a parent to be rendered properly. Or if they have no parent they get a dummy patent via JS or so.

Surely the intended behaviour is not to leave an orphan? It should at least convert the children to parent items rather than leaving them stranded. In the URL structure the parent is still the parent of the child, in which case, surely they should be moved with the parent?

I know this is old, but I don't consider this anything but a bug. Why?

If you move the parent, you get children left in the old menu with no parent, but they're still marked as chiildren. You can't even create that scenario any other way but doing this, so it feels like an accident.

On top of that, the children take on the url string from the original parent like this:

Menu-a
Parent-1
Parent-2

Menu-b

• - child-1
• - child2

Instead of the children being at the url /Menu-b/child-1 they end up at Menu-a/Parent-1/child-1

But again, you can't MAKE something like that happen unless you go into the database and fiddle with the parent fields for a child item or you edit the menu in this manner and move only the parent via the drop down.

If someone does this without realizing what's happened, they're going to wonder why the children either didn't move with the parent, or are now at the wrong url.

So, either they need to move with the parent when you move a parent in this manner (easiest option), or when you change the menu the parent is in and then save the menu item, you should be prompted with a popup "This parent item has children, do you want to move these with the parent, or make them parents in their original menu" or something akin to that.

I can confirm this issue.
The funny thing is, most parts within the database use IDs.
But the "menutype" is based on names instead of ID, the same time we have a database table with the menutypes and IDs.

I think we need to fix 2 things.

1. Child always follow parent
   (change save action query to not only update the changed menu item, but same time all childs from all levels. I would say use the lft and lgt columns but can't seem to find what the current values represent. The lft/rgt ids in my database do not represent any other menu item.

2. Change menutype column to use ids.
   (But this will probably be an B/C break).

Added to the 4.0 task board. This is an issue we do need to address and from the looks of things it will involve a B/C break as it relates to the data schema to get things right.

I agree that this wpuld be a bug, however testing with current 4.0-dev, I can not reproduce this error anymore. Could someone else please check this, too? In the best case we can mark this one as already solved. ?

Changed Status to "Information required".

Unfortunately the screenshots linked in the issue description are not available anymore.
I've tested with current staging and 4.0-dev, and behavior is the same on both.
So if I understand the issue description right, then it is still an issue in both staging and 4.0-dev.
But if I understand it wrong, the issue is solved in both staging and 4.0-dev.
Would be helpful to get info from @RoterNagel , maybe she can restore the links in the issue description.

The way I understand it, the problem is, that menu items were not changed correctly when changing the parent of a menu item. The way that I expect it to work: You have 4+ menu items, parent1, parent2, child1.1, child1.1.1, child1.1 is the child of parent1, child1.1.1 is the child of child1.1. If you change child1.1 to be the child of parent2, then child1.1.1 should still be the child of child1.1, and thus also from parent2. That is what I'm seeing right now in 4.0-dev.

I had 2 menus, in 1st menu 1st item with parent = root and 2nd item with parent = 1st item.
Now edited menu item 1 and changed menu from 1st menu to 2nd menu.
Result: 1st menu item moved to 2nd menu, 2nd menu item remained in 1st menu. Parent seems to be set right (root), but I think level and lft/rgt stuff might be wrong. So it looks weird in menu items list regarding level, and the tab where you adjust the pages for a menu module looks weird, too, regarding structure.

I will later provide screenshots and check database, but have to go shopping now.

What can be is that when you just edit and save the menu items or one of them, structure will be fixed.

In database, parent menu item of 2nd menu item is still 1st menu item, but if you edit the 2nd item, it shows "Menu item root" as parent item. If you now save without having done any changes in the edit view, the display in the list view becomes correct regarding menu level, and the parent item in database (and i guess also the lft and rgt values) are set correct.

This is all true for both current staging and current 4.0-dev branches.

The question is how it should be right. Either

1. Move also the child items of a menu item when changing the menu in the edit view of that item, like it would be with batch processing, or
2. Do as it is now, i.e. the child items stay in the same menu but will have root as parent on 1st sub-level, but then it has to be fixed so that the parent item id and the lft and rgt values in the database are updated correctly for all child menu items and so on.

Solution 1 would throw the question what happens in other cases when something is changed in the edit view of a menu item which has child items, like e.g. changing language: Should that also be propagated to the child menu items, like in batch processing? IF yes: What else shall all be propagated? Will there ever be an end? I think if we chose 2nd solution for 4.0, it should be limited to the parent menu thing, i.e. not done for other changes like e.g. language.

So or so: like it is now it is broken in staging and 4.0-dev.

The 2nd menu item in the list view after having moved its former parent to the other menu:

You can see it is shown as 2nd level, level 1 is missing.

In comparison the 1st menu item, which has been moved from 1st to 2nd menu, looks ok in the list view:

The page assignment for the menu module looks broken regarding levels:

After having opend 2nd menu item in edit view and just clicked save and close, that menu item looks ok in the list view regarding hierarchy level:

And the page assignment for the menu module also looks ok after having saved the menu item:

All the same for J4.

It happens only when you change the menu for a menu item which has childs in the edit view of that menu item:

Please find a fix for this here: #25205

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/7579