WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 4 months ago

#18271 new defect (bug)

Item hierarchy should be maintained when adding to menu

Reported by: JohnONolan Owned by:
Milestone: Future Release Priority: normal
Severity: minor Version: 3.2.1
Component: Menus Keywords: needs-patch
Focuses: ui, administration Cc:

Description

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.

Attachments (1)

18271.diff (3.6 KB) - added by pento 3 years ago.

Download all attachments as: .zip

Change History (21)

#1 @nacin
6 years ago

Strongly agree with this.

#2 @vparker@…
6 years ago

Strongly agree with this.

#3 @DrewAPicture
6 years ago

  • Cc xoodrew@… added

#4 @SergeyBiryukov
4 years ago

#25483 was marked as a duplicate.

#5 @chipbennett
4 years ago

Yes, please.

#6 @Break5
3 years ago

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

@pento
3 years ago

#7 @pento
3 years ago

  • Focuses ui administration added
  • Keywords has-patch 2nd-opinion added; needs-patch removed
  • Milestone changed from Awaiting Review to 4.1

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?

#8 @celloexpressions
3 years ago

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.

#9 @pento
3 years ago

  • Milestone changed from 4.1 to Future Release

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. :-)

#10 @BuildMyWeb
3 years ago

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?

#11 @JFFBRWN
3 years ago

  • Keywords needs-patch added; has-patch removed

+1

#12 @ocean90
3 years ago

#32013 was marked as a duplicate.

This ticket was mentioned in Slack in #core by jorbin. View the logs.


3 years ago

#14 @jorbin
3 years ago

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.

#15 @DoodleDogCody
18 months ago

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.

#16 @ocean90
17 months ago

#37342 was marked as a duplicate.

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


4 months ago

#18 @melchoyce
4 months ago

#17221 was marked as a duplicate.

#19 @melchoyce
4 months ago

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

#20 @pento
4 months ago

  • Keywords 2nd-opinion removed

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. ;-)

Note: See TracTickets for help on using tickets.