3.6-Nav Menus Tracking Ticket

[DrewAPicture]

This ticket is for tracking any tickets related to the 3.6 Nav Menus Refresh action item.

The mammoth ticket that was formerly our home (#23119) has been closed as fixed and any further related tickets should be added here.

• #23119 - The original 3.6-menus ticket. Substantial changes to the UI were commited via [23441] and [23453].

Other ​3.6-menus tickets:

• #23449 - Refactor the Customizer accordion to be reusable elsewhere in core.
• #23450 - Refactor menu item meta boxes into an accordion via #23449
• #14045 - Give the menus page an accessibility mode (like widgets)
• #23608 - 3.6-Menus Help Text changes
• #23610 - Relocate the 'Delete Menu' link on the Menus screen
• #23641 - Tweaks to menu management box
• #23645 - RTL fixes for Nav Menu UI refresh
• #23714 - Remove menus message slide down effect
• #23716 - Discuss theme locations as meta box vs checkboxes
• #23770 - Restore 'Locations' meta box functionality as secondary tab in Menus UI
• #23813 - Menu select should use get instead of post

Other tickets for consideration:

• #23508 - get_nav_menu_locations() should always return an array

If there are others that were missed, post a comment and we'll add them to the list.

[DrewAPicture]

Added:

• #23608 for 3.6-Menus Help Text changes
• #23610 for relocating the 'Delete Menu' link on the Menus screen

[bobbravo2]

Here it is in IE7: ​http://cl.ly/image/0a0v1D0h2E0P All JS Functions properly (tested w/ script debug against 3.6-alpha-23451)

[Viper007Bond]

More UI hooks please! #18584

I currently have to resort to using JavaScript to add a checkbox to the menu UI: ​http://wordpress.org/extend/plugins/add-descendants-as-submenu-items/

[DrewAPicture]

Added #23645 for RTL fixes

[DrewAPicture]

Added #18584 - Nav Menu UI needs more hooks

[DrewAPicture]

Removed (Future Release):

• #16075 - Add post type archives support to menus

[DrewAPicture]

Removed:

• #18584 - Nav Menu UI needs more hooks (it's still very much up in the air due to #14134)

[anointed]

Run into a situation where we are using multiple themes on a single website. Basically each page can be assigned a custom theme.

The issue I have run into is the only way to assign a menu to a new page with a 'custom theme' for that page, is to temporarily activate the new theme on the website, assign the menu to its location, and then reactivate the original theme.

While this works, it obviously disrupts the entire system as I have to change the active theme for the site to make this change.

I spent a bit of time looking, but I do not see anywhere that I can hook into to define the theme that I am working with on the menu admin page.

As this is an unusual situation, I don't expect a lot of traction, but one thing that does come up A LOT is people hating that they loose their menu locations when changing themes. It might be nice to have the option of selecting a theme to apply the menus to in this new revamp or at least a hook, else I am afraid it could be a very long time before this would ever be addressed again.

[DrewAPicture]

Replying to anointed:

As this is an unusual situation, I don't expect a lot of traction ...<snip>

You're correct, that's pretty edge. I suggest you take a look at #18584 as it's more in-line with proposing additional hooks on the menu screen(s).

[DrewAPicture]

Added:

• #23714 - Remove menus message slide down effect
• #23716 - Discuss theme locations as meta box vs checkboxes

[DrewAPicture]

Added:

• #23770 - Restore 'Locations' meta box functionality as secondary tab in Menus UI

[helen]

Thinking the select a menu form should be get instead of post. Also that the form actions should probably not just be the bare admin URL (that is, without any query variables). Can make a new ticket if that seems right.

[lessbloat]

Replying to helen:

Thinking the select a menu form should be get instead of post.

Done in 23607.diff​.

Also that the form actions should probably not just be the bare admin URL (that is, without any query variables). Can make a new ticket if that seems right.

Sorry, not sure I follow. The query vars are auto added to the base URL on submission of the form.

[DrewAPicture]

Replying to helen:

Thinking the select a menu form should be get instead of post.

Created a ticket for that: #23813

[helen]

Replying to lessbloat:

The query vars are auto added to the base URL on submission of the form.

Not if we switch to get instead of post for the switcher :) It's the difference between these (see URLs):

[DrewAPicture]

As of [23844], the last ticket on our list is closed.

Any other menus issues that come up in beta should be opened as separate tickets.

[jb510]

Move select menu to edit into menu edit box

[jb510]

I'm still really uncomfortable with the new menu layout. I'm usually pretty pro-UX change, but I've been using this for a couple weeks and this still just feels wrong. Things are redundant... things are not logically organized.

I've manage to begrudingly get used to setting menu locations in two places. It's confusing, but I'm not sure what else you could do.

Selecting which menu to edit still seem laid out wrong. Why would it be visually separated from the dialog being used to actually edit the menu. It seems to me the layout should be like the attached.

[ericlewis]

Can someone point me to (or summarize) the decision on the "Common Links" box that would've included things like "Log in," Log Out," etc?