Item hierarchy should be maintained when adding to menu

[JohnONolan]

Situation:

Create a hierarchy of categories or pages and go to create a custom menu. In the meta boxes on the left hand side, the categories and pages are shown in hierarchical arrangement. Select all categories (for example) and add to menu.

Expected behaviour:

All links are added to custom menu and the hierarchy is maintained appropriately

Actual behaviour:

Hierarchy is lost and all menu items are top-level

This was originally raised by Jane in #17029 however the changeset in the ticket only applies to showing hierarchy in the meta boxes and doesn't cover maintaining hierarchy when adding to menu.

[nacin]

Strongly agree with this.

[vparker@…]

Strongly agree with this.

[SergeyBiryukov]

#25483 was marked as a duplicate.

[chipbennett]

Yes, please.

[Break5]

Is there any patch/plugin to solve this, it's really frustrating ever since

[pento]

18271.diff​ works, but I'd like a second opinion from someone more familiar with the menus code than I. In particular, is it sane to assume in wp_save_nav_menu_items() that the parent item will be saved before the child item?

[celloexpressions]

Might be worth noting that this may not make sense UX-wise in various scenarios. For the Menu Customizer project, I've also currently removed the checkboxes entirely in favor of adding directly on click of the item.

If you add a sub-item but not the parent, should it be added as a top-level item or as a child of something else? If you add a sub-item and its parent is in the menu somewhere, should the new item be added as a child of that parent, regardless of its position in the menu? If you add a parent item, should children automatically be added with it?

In terms of the horrific scaling problems menus have right now, I'd be very hesitant to add an additional field to all menu items to accomplish this (menu-item-parent-object-id), that will make #14134 worse.

I think the best option might be to try to flag something from the JS when the item is being added, to set the parent Id when it's first added, then add it to the appropriate part of the menu instead of the bottom one the ajax call comes back. But given the way that's structured right now, I'm not sure something like that would be feasible. I'd also be interested in a better/completely re-thought approach to all of this in the Menu Customizer feature-plugin, if anyone's interested in helping there.

[pento]

I don't think this ticket needs to do anything fancy with edge cases - it's a matter of, if a parent and child are added at the same time, they should be parent and child menu items, too. Anything else can be assumed to be the user wanting to do something their own way.

Regardless, #14134 is a giant rabbit hole, and clearly a blocker for this. I'll do some thinking about it. :-)

[BuildMyWeb]

i cant believe this problem has gone unresolved for so long. thank you pento for a temp fix. ive made these edits to core files and it seems to work: https://core.trac.wordpress.org/attachment/ticket/18271/18271.diff

obviously this will be a problem everytime we update Wordpress. i imagine there isnt yet a better solution or pento would have updated this?

[JFFBRWN]

+1

[ocean90]

#32013 was marked as a duplicate.

[jorbin]

This remains blocked by #14134. It may be something that is invalidated by the menu in the customizor project, depending on the UI that takes and if the current menu screen is removed as a part of it.

[DoodleDogCody]

Any update here. As long as the regular Menu UI is staying around I feel like this is something that should definitely be added to core.

If selecting a parent item and a child item at the same time and inserting them into a menu they should retain their hierarchy.

[ocean90]

#37342 was marked as a duplicate.

[melchoyce]

#17221 was marked as a duplicate.

[melchoyce]

Looks like #14134 is done? Can we resume this? :)

[pento]

Quite probably, though I don't remember how 18271.diff​ worked. It also doesn't apply properly, and doesn't know anything about the work done on #14134.

What I'm saying is, it's probably better to ignore that patch and start fresh. ;-)

[swissspidy]

#46558 was marked as a duplicate.

[SergeyBiryukov]

#59081 was marked as a duplicate.