Better Site Menu Management

[scribu]

As per the dev chat on  January 7th 2009, one of the features that was scheduled for the 3.0 milestone was better menu management, i.e:

Make it easier to customize the menu displayed on the front-end.

Currently, the template tag for this is wp_page_menu(), which can use the menu_order field in the wp_posts table.

Related ticket: #2702.

I'm thinking of a new admin page under Appearance -> Menu:

On one side, we would have 3 dropdowns (?):

* Add a page

* Add a category

* Add a link

On the other side, we would have a sortable list with the current menu items. Each item would have a series of options, similar to widgets.

Suggestions and patches welcome.

Assorted thoughts:

• Themes use add_theme_support('page-menus') or 'custom-menus' to advertise that they use wp_page_menu() and support menu customization.
• If current_theme_supports('page-menus'), then show the menu management UI.
• Support show/hide of pages, page reordering, and adding links. Implement in that order if we need to do this a little at a time.
• Storage could be a simple array in the options table.
• Decide what to do when new pages are added. Always show them at the end of the menu? Add a checkbox to the page edit form that defaults to show?

I'll leave UI suggestions to others, although I do like the idea of Appearance->Menu.

Related plugins:

* Page Menu Editor

* My Page Order

* PageMash

Just wondering if it would be useful to incorporate the concept of my plugin into core:

 http://wordpress.org/extend/plugins/list-pages-at-depth/

It is basically the wp_list_pages function but with an additional argument for start depth.

This means that you can easily create a secondary navigation menu that is separate from your primary navigation menu. Just pass a startdepth parameter of 1 and it will display secondary level for the current context, wether you're in a primary, secondary or tertiary level. If there is no secondary level, it just won't show.

Really useful for putting together themes if you want primary navigation along the top, and secondary navigation elsewhere.

It might be an ideea for further down the road.

By the way, I think we should have a new function: wp_custom_menu().

Agreed, new template function. Will also need a new "Menu" widget to wrap it and choose which menu to display (if we are planning on supporting multiple menus). Lots of users who would move to this are going to migrate from the Page widget.

Branding it as "Navigation Menu" might make its purpose more clear. Then we'd have wp_navigation_menu() and a "Navigation Menu" widget.

Thinking about how this could be implemented I'm not sure it would really address the current menu_order situation. The order would be stored in an options array and not pulled from the menu_order. menu_order would stay specific to wp_list_pages().

+1 to Appearance > Menu.

I can weigh in on UI to make it consistent with other screens, or wireframe it first if needed.

The problem with menu_order is that it has no context. Is it for wp_list_pages(), is it for wp_page_menu(), is it for edit-pages.php? It also burdens every page with a piece of info needed for only a subset. It is also useful only for internal WP pages, whereas what we want will allow other elements as well. I'm thinking menu_order would remain for wp_list_pages and the new function would store items in an array. The navigation menu usually has a much smaller subset of pages than the full pages list. For most sites it will have only a handful of items (sites that have dropdowns with lots of children could have a lot though). Sticking those in an array in the options table would be fast and easy.

Replying to froman118: Agreed, new template function. Will also need a new "Menu" widget to wrap it and choose which menu to display (if we are planning on supporting multiple menus). Lots of users who would move to this are going to migrate from the Page widget.

Yeah, a menu widget would be useful.

Replying to janeforshort:

+1 to Appearance > Menu. I can weigh in on UI to make it consistent with other screens, or wireframe it first if needed.

Cool. I think I'll make a copy of the widgets code and hack away on that.

see also #11545, #11517, #11539

nav menu widgets plugin

I've attached my nav menus plugin in case there is interest to fetch part or all of the ideas in it.

Thanks. Will be taking a look at it.

I was intending to write a plugin to do essentially what you guys are talking about here. I make a living from building menus from WordPress, so this is something I'm quite heavily involved in on a day to day basis. Unfortunately my skill area is CSS, and my PHP skills are not up to scratch for writing anything into core, but I'm keen to give input if possible.

My own concept was essentially what Scribu suggested above. It would be important to make sure there was a way to hook in extra menu options via plugins, ie: lists of posts, archives etc. etc.. This is essentially what my own plugin does at the moment:  http://pixopoint.com/pixopoint-menu/

I'm working on a total rebuild of my own plugin at the moment (with much better PHP, current plugin sucks on that front). My new version also looks a lot better on the admin side. It doesn't use the "three dropdowns on the right" approach yet though as I haven't added the sort of complexity you guys are suggesting here (yet).

My initial plan (before hearing this might end up in core), was to build my plugin with lists of potential menu items on the right, just as Scribu suggested, and there would be a drag and drop sortable list on the left like the PageMash plugin. Within those drag and drop items, would be the ability to click a pull-down to modify the menu item link titles, URL, text etc. It wouldn't be limited to just pages, links and categories but many, many other options. This would be too complex for core I think, but thought I'd mention it here in case the concepts are useful.

I was planning to serialise all the options into a single option just like Ryan B suggested above. I actually thought there would be a better way to do it, so nice to know a core developer thinks it's a good idea too :)

The users of my own plugin often give feedback on other plugins. The most popular one for modifying pages is the PageMash plugin. However I think froman118's MyPageOrder plugin is more simple and easy to use (plus PageMash uses MooTools).

Why do you guys think that a new function is necessary? I thought that wp_page_menu() was ideal for this. And for extra menus, wp_page_menu('num=2'); (or something similar) could be used to designate that the second menu should be generated.

If the wp_page_menu() function is used, it would be a good idea to add a way to modify the ID of the DIV or UL created. At the moment, only the class can be altered via the function which causes some problems as themes (Darren Hoyt's Gravy theme springs to mind) end up using a filter just to apply an ID to it. Adding this sort of functionality in by default rather than using a filter would be a nice addition IMO.

I think that's enough of a rant by me for this morning. It's 4:24am and I haven't been to sleep yet so hopefully everything I wrote makes sense :)

It's great to see the interest in this ticket. I think rather than getting caught up in too many details too soon, we should start with the big picture.

It seems to me that there are 4 somewhat distinct areas of menu functionality:

• Admin UI experience: how the user determines the structure of her menu.
• Menu logic: how the menu data is stored and the algorithms that determine things like the current active menu item and whether certain sub-menu items should be active.
• Final markup: how the menu is rendered (a list, or nested divs, etc.)
• Styling and behavior: CSS and JavaScript affecting menu markup. (In my opinion these are best left to the theme.)

Considering those areas, how would you answer the following questions?

• What do you think users typically want?
• What are the best menu plugins doing and why?
• What do you see as the thorniest problems you'd like to solve?

Replying to filosofo:

* What do you think users typically want?

Based on what I get asked for at WordCamps and via email, I'd say the most common requests are the ability to determine the show/hide and order of menu items, and the ability to mix together pages and categories in a menu. It's a common complaint that themes typically choose pages or categories for you, and unless you're a coder, you can't get the menu items you want.

Related: #10597

Replying to ryanhellyer:

Why do you guys think that a new function is necessary? I thought that wp_page_menu() was ideal for this. And for extra menus, wp_page_menu('num=2'); (or something similar) could be used to designate that the second menu should be generated.

Because wp_page_menu() has 'page' in it, whereas the new functions allows all sorts of things besides pages.

Replying to scribu:

Replying to ryanhellyer: ... wp_page_menu() has 'page' in it

LOL. That is rather obvious now that you point it out. Yes, a new function name is needed. It seems that wp_page_menu() may as well become depreciated in that case as it would become essentially useless now. Perhaps when add_theme_support() is used in the theme, the pages functionality of wp_page_menu() could be unhooked and the new function used instead. That way backwards compatibility with all the existing themes which use it will be in place.

Replying to filosofo:

* Final markup: how the menu is rendered (a list, or nested divs, etc.)

Unordered list or a definition list are the only two real options here at the moment. Unordered lists are the standard approach used by most people so would make a lot more sense I think. Having said that, HTML5 is on the way and I'm sure there will be those within the next your or two who will start making early use of the <menu> tag, so the ability to easily change the wrapper tag(s) would be great. wp_page_menu() gives the ability to control the class, but to remove the entire DIV or UL you need to use a filter which is slightly messy. If it didn't add to much complexity, then the ability to control the tags used would be darn handy. Something like the following for example:

wp_custom_menu( 'markup=<div id="nav" class="sf-hover"><ul>' );

Which would output the following:

• bla
• bla
• bla

Replying to filosofo:

* Styling and behavior: CSS and JavaScript affecting menu markup. (In my opinion these are best left to the theme.)

Definitely not something for core. I guess the Superfish jQuery plugin and a Suckerfish script could be added as built in scripts for themes to utilize, but they still seem a bit too much like theme related features. Each theme is likely to want to implement them in a slightly different way anyway.

Replying to filosofo:

* What do you think users typically want?

Drag and drop interface to arrange their own menu of pages and categories. They also want the ability to add all sorts of other stuff, but that's best left for plugins IMO. They also want the ability to add multiple menus, not just one or two.

Submitted menus.diff in pre-alpha state, just to get the ball rolling.

Basically, I copied all the code related to widgets and transformed sidebars into menus and widgets into menu items.

Made some modifications to use current_theme_supports('menus').

There are currently 4 default menu item types: Home, Link, Page & Category.

@ryanhellyer: The register_menu() function has 2 arguments to deal with markup: 'before_menu' and 'after_menu'.

Saving menu items into menus is currently broken.

WP_Menu class

We have nice classes for handling individual menu items: WP_Menu_Item and WP_Menu_Item_Factory, but the code that deals with entire menus relies on a lot of global variables.

So we need a WP_Menu class that holds all the information about a particular menu.

We might also need a WP_Menu_Map class to hold all the menus in one place.

Hierarchical items

For page and category items, we need to handle child elements. I'm thinking of an option for each item to specify the depth to which child elements should be displayed.

pre-alpha

Populate menu button

To speed up menu creation, a blank menu should have a button on it that, when clicked, populates the menu with all the top level pages. Maybe another one for categories.

After that, the user can delete unwanted pages, shuffle them around, add extra items etc.

Great work scribu :)

I actually started building something like that a few hours ago, but it looks like you beat me to it (and did a whole bunch more on top!).

menus.2.diff has a working menu admin (the items are saved properly)

Also replaced 'menu_item' with 'menu-item' where appropriate.

functional menus admin

register_menus() is just a wrapper for register_menu() which just creates multiple menus based off the same $args? Is that functionality even necessary?

I don't know; it doesn't hurt being there, though.

The patch still requires a lot of cleaning.

We should lose the wp_[un]register*() functions and use only the menu classes. This is new API so we can lose the old widgets api cruft.

Those globals can probably be eliminated too with some rework. The widgets code is the way it is because it supports three different API and storage iterations and a lot of history. We don't need that baggage in the menus code.

Replying to scribu:

I'm thinking of a new admin page under Appearance -> Menu: On one side, we would have 3 dropdowns (?): * Add a page * Add a category * Add a link On the other side, we would have a sortable list with the current menu items. Each item would have a series of options, similar to widgets. Suggestions and patches welcome.

With more developers using custom taxonomies, it would be great to have an "Add a Taxonomy" dropdown as well.

Replying to sbruner:

With more developers using custom taxonomies, it would be great to have an "Add a Taxonomy" dropdown as well.

That should work by extending the WP_Menu_Item Class. A default taxonomy menu item would be sweet though.

<a href="http://core.trac.wordpress.org/attachment/ticket/11817/menus.3.diff">menus.3.diff</a> adds a new section with dropdowns: one for pages and one for categories.

When you select an item from a dropdown, it's automatically added to the current active menu.

Props to hakre for helping me with the JS.

Link and Home menu items are created by dragging them to a menu, just like adding widgets to a sidebar. Maybe we can move these to a single dropdown: Other Items.

A video demonstration should follow soon.

menu admin with dropdowns

You can see a preview of the current patch here:

 http://wpdevel.wordpress.com/2010/01/17/menu-management-ui/

I love it so far. It's similar to  NAVT, but with a much cleaner UI. Looking forward to seeing it with the depth options in place.

Depth

You could achieve ultimate flexibility by allowing menu items to display menus themselves.

It's possible, from a code perspective, but building a good UI for something like that would be quite hard, IMO.

The semi-flexible route would be to allow each item to display child items of it's own, i.e: page items to display child pages down to a certain depth, etc.

Oh, another possibility would be to allow nested items inside a menu, similar to what pageMash does.

Anyway, the next important thing that needs to be done now is cleaning up the PHP code.

scribu: could you explain the difference between "Special Menu Items" and "Available Menu Items"?

A "special menu item" is linked to another WordPres object, like a page or a category.

Other menu items are standalone, like external links*.

I plan to move all the non-special menu items into a single dropdown.

* You could make the case that bookmarks are essentially external links. Perhaps they can be merged with the menu items at some point.

I just sent something over the hackers list about widget design for MU sites and more than one theme. Maybe we should consider a 'Walker' type system like my Walker Widget system on #11387 before we get to far into this.

I saw. #11387

I just changed the title from Better Menu Management to Better Site Menu Management so there will be less confusion when I open a ticket about menu management of admin menus. :)

put all available items in dropdowns

menus.4.diff:

* move Home and Link menu items into a single dropdown

* drop Inactive Menu Items

* 5 visible items per dropdown instead of 1

Current issues with the UI:

* hard to remove items (you don't have anywhere to drag them off to, except another menu)

* can only add items to the first open menu (see this  discussion)

screenshot for menus.4.diff

Screenshot.png for menus.4.diff

I propose putting the menus side by side on the top of the page and a single available items area below them. This makes te dragging distances generally shorter, which is good in my opinion. The “special items” could be dragged just like any other item, just open the select item menu when the user releases mouse button or clicks a button on the menu item widget. I have images to clarify these changes, just don’t know how to put them here.

Also, I think users would find useful to have “subpages of a page” and “subcategory of a category” items with exclude fields.

Lari, use the "Attach file" button in the attachments box.

Menu management Layout

Menu 2 after the user has dragged the “Page item” on it

Menu 2 after the user has clicked the select page button

Ok, it’s very rough but I think you can get the idea. The state in 3.png could be triggered right after the user releases the mouse button (drag & drop). This would probably require changes to the menu box layout, though.

I think this would be simpler, faster and easier to use but what do you think?

I think your approach actually slows down menu creation: for each menu item, you have to do the extra step of dragging the item to the menu.

With the dropdown approach, you choose a menu once, and then add items to it with a simple click.

We have to find a more intuitive way of choosing the active menu, though.

Also, the layout you suggest for the Select menu doesn't allow hierarchies, which can be really useful for users that have a lot of pages / categories.

Your idea of putting the menus side-by-side might be good, but I think they should go below the available menu items, not above.

Replying to scribu:

Your idea of putting the menus side-by-side might be good, but I think they should go below the available menu items, not above.

+1, so available items always in view, even if a particular menu winds up being really long with sub items etc.

Hm... come to think of it, if we put the AMI (Available Menu Items) on top, we would have to insert new items at the top of the menu, and not at the bottom. Otherwise, with long menus, users won't get visual confirmation when adding items.

So, if we were to put menus side-by-side, it would be best that the AMI stay at the bottom, as Lari suggested.

What puzzles me is what would happen when a theme has 4+ menus defined. Should we move the forth below the first 3 or just let the admin page extend to the right, indefinetly?

I think it would be better to have multiple rows of menus, each row having at most 3 menus.

Since menus are collapsible, there's no danger of users having the AMI too far down.

As for choosing the active menu*, I was thinking of having a "Highlight me" button on each menu box.

* active menu = menu to which new items are added from the AMI

It's important that there is a menu with all pages in it by default, as there is currently. By default, all newly created pages should automatically be added to the menu. A checkbox would allow turning this off, "[] Automatically add new pages to menu".

That would imply that we support hierarchical menus.

Either that, or we only auto-add first-level pages.

Only adding top-level might be a good compromise.

Replying to scribu:

I think your approach actually slows down menu creation: for each menu item, you have to do the extra step of dragging the item to the menu.

Ok, fair enough. But it is simpler than the current solution.

Also, the layout you suggest for the Select menu doesn't allow hierarchies, which can be really useful for users that have a lot of pages / categories.

I’m sorry, I don’t quite follow. Do you mean it’s not possible to show child pages in that list? It doesn’t show it but surely it could be done if it can be done with a regular select element. I mean, you can layout the pages any way you want.

Replying to scribu:

we would have to insert new items at the top of the menu, and not at the bottom

Indeed. That was my reasoning.

What puzzles me is what would happen when a theme has 4+ menus defined. Should we move the forth below the first 3 or just let the admin page extend to the right, indefinetly?

Show a horizontal scroll bar. How often does one have more than four menus? Less than 20% of the cases?

Also, I think there should be a way to define a menu to be second (or nth) level menu. So that the contents of the menu automatically change based on the current page.

Replying to scribu:

I think it would be better to have multiple rows of menus, each row having at most 3 menus.

That could work.

As for choosing the active menu*, I was thinking of having a "Highlight me" button on each menu box.

This doesn’t sound good to me. I would try to keep it similar to widgets, in that you can drag any widget / menu item to any sidebar/menu. If there is going to be some kind of activation, I would then change the whole layout and not try to mimic the widget screen.

I don’t want to imply that my proposition is perfect but at least every menu item gets added the same way, drag and drop that is, and there are no special items or a need activate a menu to baffle the user. I like the simplicity of it.

Hey, I would like it to be as simple as widgets, too. Unfortunately, menus have different requirements, so we have to adapt the UI accordingly.

As for choosing the active menu*, I was thinking of having a "Highlight me" button on each menu box.

This doesn’t sound good to me. I would try to keep it similar to widgets, in that you can drag any widget / menu item to any sidebar/menu.

You can still drag items from one menu to another. The highlighting is for adding new menu items from the AMI.

Hey guys. I think a lot of the ideas being discussed here are touched upon / implemented in a plugin called the NAVT List Plugin (  http://wordpress.org/extend/plugins/wordpress-navigation-list-plugin-navt/ ). The plugin is extremely functional in its design, but very buggy and it's future life is questionable. (we can’t get it to install on brand new WP installations, but older installations that started with older versions of the plugin work fine except for lots of random bugs).

I bring this up because I believe that it's UI screen and layout already incorporate a lot of the ideas being discussed and might be worth taking a peak at. I believe It may be a very good starting point when discussing the menu UI or at least as a reference wire frame.

Since I can’t do the plugin justice with words, I have created a quick video showing the features we find the most important and giving a quick look at how we incorporate it into our sites. You can view the video here:  http://www.youtube.com/watch?v=LkbV4x4SjVM

My hope in posting this is that it may give another perspective that can positively affect the UI design as is discussed in this ticket. Thanks!

Hey, thanks for the informative vid.

One thing isn't quite clear to me with the NAVT interface: once you've created a "group", how can you add extra items to it?

Replying to scribu:

Hey, thanks for the informative vid. One thing isn't quite clear to me with the NAVT interface: once you've created a "group", how can you add extra items to it?

When you click on an item that is in the "Assets" section on the left hand side it appears in the empty "Assets" box ... then you simply drag it to the group of your choice, almost exactly like you would with widgets..... sorry I didn't demonstrate that...

An interesting take on the menu admin from Woo Themes:

 http://www.woothemes.com/2010/01/the-awesome-custom-woo-navigation/

@scribu:

Is the latest patch (menus.4.diff) functional?

I applied it to have a look and maybe give some feedback, but the menu admin page is in disarray, and I can’t use anything in it.

5 items / dropdown; more compact menu item listing

demetris, try menus.5.diff (it's diffed against r12883).

To test, make sure these are set in wp-config.php.

define('SCRIPT_DEBUG', true);
define('STYLE_DEBUG', true);

Otherwise you have to minify the modified CSS and JS.

BTW, here are some shell scripts you can use to minify.

java -jar /path/to/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar --type css -o $1.css $1.dev.css

and

java -jar /path/to/yuicompressor-2.4.2/build/yuicompressor-2.4.2.jar -o $1.js $1.dev.js

Pass in the name of a WP js or css file, minus the .dev.css.

Screenshot of Menu Item widgets

Possible Menu UI with Submenus

Hi, this is my first submission.

My own method of creating reorderable menus is to create a "Menu Item" widget. This is dragged on to a sidebar where there is the option to choose a page from a drop down list and enter a title which becomes the anchor text.

Here is a screen shot: Screenshot of Menu Item widgets

And here is the source code of the widget: Menu Item Widget Class.php

I believe the same approach should be used for the Menu UI. The user is presented with various types of menu item widgets e.g. Page, Post, Category, Tag, Url etc, which can be dragged onto a "Menu" which is the equivalent of a sidebar. The user can enter a title and select the link destination from a drop down list.

scribu said that dragging and dropping is slow. I disagree because as it currently works in the video, new menu items are added to the bottom of the menu, if I want it to be in any other location I have to drag and move it. Thus it is just as quick to drag the menu item directly to the preferred location - both approaches require two actions.

Editing is also kept in one place, at present you choose the link from the left and edit the title on the right, you affect the functionality of the menu item in two separate locations. The widget UI is already familiar to users so it makes sense to emulate it.

As for nesting of menu items to create submenus, my idea is to allow the user to drag a menu item inwards, creating an indented effect just like bulleted lists.

Here is a mockup: Possible Menu UI with Submenus.png

Each indented menu item is created by clicking and holding the heading and instead of dragging up and down to reorder, you drag inwards (to the right). If there is a submenu (1 indent) directly above you are allowed to indent a 2nd time creating a third tier. When dragging inwards the menu item automatically shrinks horizontally.

This approach is the same as the Mac application by Circus Ponies called Notebook. When in outline view you can drag bullets inwards in the same way I describe.

A further refinement would be to move the children of a submenu when it's parent is dragged i.e. as in my mockup if I where to move the "MP3 Players" menu item above "Notebooks" the child item "iPod Nano" would stick to the parent and be moved at the same time.

The page layout could have the menu items on the left of the screen which are dragged to a menu on the right of the screen. Menus could be collapsable so that the menu you are editing can take up the maximum screen real estate.

Just like how widgets and sidebars work.

Here's the problem with putting the dropdown in each menu item:

If you have 100 pages, you will have to create a dropdown with 100 options for each menu item.

That will cause the entire page to be slow.

In what way do you mean slow scribu?

I mean unresponsive, by creating hundreads of DOM nodes.

Have you seen specific browsers where this happens?

I have tested creating a 500 item list with Safari and had no problems.

Just wondering if this is solvable or not, I'm not a DOM expert.

Replying to scribu:

I mean unresponsive, by creating hundreads of DOM nodes.

I think the widget approach is the way to go. Though I am new here and would not want to presume that my opinion is of equivalent weight to others posting here.

I am happy to test the widget live on Chrome, Opera, Safari, FF and IE 6 through 8.

It would be useful to know which browsers are posing the DOM Node - too slow problem.

As I expressed on the Dev Updates site: I do believe that widgetizing the menus and using existing sidebar areas is ideal from a usability/familiarity point of view.

+1 To simonsharks idea of draggable menu items.

It's much more intuitive to control each menu item on the right, just as we would with widgets. And, it feels faster because I put the menu item exactly where I want it on the first go. With the current implementation, the menu item is added, followed by me having to drag it to its proper place.

Regarding responsiveness: I did some informal testing, using a custom widget that contained the page dropdown; created 100 pages and then created 10-20 instances of the widget. I saw no apparent slowdowns in Firefox 3.6 or the latest Chrome. So it seems there is no performace block, as I had suggested.

But then again, if they're all just blank menu items, you might as well have a button that says "Give me 5 new page menu items". Then, you can choose the page for each one from it's respective dropdown.

The whole issue is that, unlike most widgets, menu items aren't stand-alone entities. They're tied to another object on the site; or at least, that's the idea.

Otherwise, we could just make a menu out of arbitrary links. Much easier to manage, but might cause broken links if, for example, a user removes a page and forgets to update the menu.

Here's what I see as the biggest issue.

With the current menu, there's 3 steps:

• Select an item.
• Drag into place on the menu.
• Configure.

With more of a widget-like system, there's 2 steps:

• Drag item into place on the menu.
• Configure.

The latter is something that users are completely familiar with. It works, and I haven't seen a lot of big debates on the widget system in the WordPress community since pre-2.8.

The whole issue is that, unlike most widgets, menu items aren't stand-alone entities. They're tied to another object on the site; or at least, that's the idea.

If you break it down into the basic parts, they are essentially the same:

• Container.
• Items.
• Container holds items.

We could avoid page dropdowns by doing what we do with tags on the post edit form. Auto-completion as you type coupled with a list of the 10 most popular tags. This would require some extra work since pages are hierarchical, but it might be doable.

2. In addition, referencing the ongoing concern about multilevel menus: I believe it may unnecessary to clutter the widget with hierarchical options. When a user first adds a new Page or Category ( or Term of a custom hierarchical Taxonomy), the parent/child relationship is then defined and registered. In the new Menu Management System, I propose that: If a user includes both a child and its parent in a menu instance, then the pre-existing hierarchy should be preserved and spat out in the html with relevant <ul> <li>. If the user includes a child without its parent, that menu item should be treated as top level menu item, even though it is defined as a Child when first registered. This avoids the need to add a second tier of hierarchical levels.

I courteously disagree with Ryan. I think dynamic suggestions in this context would be frustrating and compromise usability. Previous popularity of an item is not logically related to current intent.

Replying to greenshady:

Here's what I see as the biggest issue. With the current menu, there's 3 steps: * Select an item. * Drag into place on the menu. * Configure.

Remember that you can select which menu item you add next. So you could have the items ordered right from the first pass, without any dragging.

Replying to scribu:

Replying to greenshady:

Here's what I see as the biggest issue. With the current menu, there's 3 steps: * Select an item. * Drag into place on the menu. * Configure.

Remember that you can select which menu item you add next. So you could have the items ordered right from the first pass, without any dragging.

Assuming I never want to change my menu by adding new items in various positions. That's the "first pass."

I'm trying to think of it in a way that would be more usable and familiar for my theme users because menu management is something I have to deal with every day via theme support.

I can also foresee quite a bit of accidental clicking of items, which get added to the menu unnecessarily.

Just wanted to add my two cents. I have implemented a menu builder as a add-on for a specific theme here is what it looks like  http://img.skitch.com/20100203-fb3fqf61f5y1ejtqnq7guterd2.gif

How it works is: You click on a link that adds a box of pages, categories, links, or a blank text box.

For example if you want to add a number of pages in a row. You would add the pages box and the check off all the pages that you want to add to the navigation. Help full links such as check all and collapse make it easier to add pages if you have a large site.

If after that you want to add a category you would add the category box and do the same. You can continue building you navigation that way. By adding boxes of page and categories or links or static text.

The static box helps with the addition of a search form for example.

Currently there is no way to reorder the boxes by dragging and dropping them around. Which could definitely improve the usability.

Also a way to maximize the box would be great. You can see a whole site map without having to scroll in a small box.

Per discussion during the #wordpress-dev meetup, Jane and some of the UI volunteers are going to do some wireframing this weekend. Wireframes will go on the UI blog sometime next week for discussion and voting. From there we decide time frame and implementation details.

Menu Management Wireframe, 2-6-2010

Isn't it funny that this interface renders a simple list of links as it's final result? I gnawed on it for while and thought I would ad a quick and dirty wireframe. I think the notations in the wireframe should explain it.

Menu Management Wireframe - Sortable with Properties

When I did the wireframe I was thinking of multiple menu sets, and each menu item comprised of: Menu Item Type, Menu Item Type Properties, Menu Item List Location, Menu Item Link Text: Title

Of course the data is more complex than that, but just thinking in simple terms.

Just realized that along with that wireframe it could be possible to add a menu type of "Text" that could have properties related to wrapping tag (DIV, H1, H3, etc), CSS Classes, and maybe a URL field.

It might sound silly, but this could let you have Headings for sub-lists and do stupid things like "mailto:" if you are completely insane :).

ev3rywh3re - I like it.

The concept of adding a generic menu item, then selecting its type (page, post etc) in an options pallet which changes to display the relevant options is simpler than multiple widgets.

You can also change the menu item type without deleting the item and dragging on a new widget of a different type.

I am a fan of dragging menu items inwards to create hierarchies but in addition, adding a indent and outdent arrow in the options pallet would make it obvious to users who don't know you can drag.

The tabs are nice as well.

It's good to see some progress is being made on making the UI more flexible. I think the widgets UI was too constraining and not well suited for the navigation.

One thing I will suggest is keep things consistent with the rest of WordPress. One direction you could take this is making Navigation an actual menu item with Edit and Add New just like Posts/Pages.

Instead of tabs to toggle between menus, you have a list of menus just like you have a list of Posts/Pages. You can then select one to edit where you get a UI similar to the latest wireframes (menu on the left, toolbox on the right).

This is more consistent with the rest of WordPress and would be more intuitive for users to use if it was along the same lines as Posts/Pages only instead of editing a Post you are editing a menu... keep things consistent.

@carlhancock: Menus would fall under Appearance, not as a top-level content type. I posted to wpdevel yesterday about menus, but might as well post it here while waiting for the patch... since a lot of people really seemed to like the Woo Custom Navigation and it did all the things we had IDed as what we were going to do (combine pages, categories, other links; allow renaming of nav links; re-ordering items etc), Ryan and I reached out to Woo and they have agreed to become core contributors by turning their custom nav system into a core patch. Win-win. Will be discussed in today's dev chat.

Replying to janeforshort:

@carlhancock: Menus would fall under Appearance, not as a top-level content type. I posted to wpdevel yesterday about menus, but might as well post it here while waiting for the patch... since a lot of people really seemed to like the Woo Custom Navigation and it did all the things we had IDed as what we were going to do (combine pages, categories, other links; allow renaming of nav links; re-ordering items etc), Ryan and I reached out to Woo and they have agreed to become core contributors by turning their custom nav system into a core patch. Win-win. Will be discussed in today's dev chat.

Fantastic! Sounds like a win. I've used the Woo Navigation and it is indeed very nice and i'm sure will only get better as part of the core.

Integration of the WooNav into WordPress 3.0 initial patch

The zip contains a diff and images. The diff is too large to upload separately, alas.

Let's get the contentious stuff out of the way first. :-) Two new tables are introduced as well as a copy of jQuery 1.3.2. We definitely need to move it to the bundled copy of jQuery 1.4.1.

Also a custom jQuery UI 1.7.2. We can move core to 1.7.2 if need be. We already have a patch for that.

The schema:

CREATE TABLE $wpdb->custom_nav_records (
 id mediumint(9) NOT NULL auto_increment,
 position bigint(11) NOT NULL,
 post_id bigint(11) NOT NULL,
 parent_id bigint(11) NOT NULL,
 custom_title text NOT NULL,
 custom_link VARCHAR(55) NOT NULL,
 custom_description text NOT NULL,
 menu_icon text NOT NULL,
 link_type varchar(55) NOT NULL default 'custom',
 menu_id bigint(11) NOT NULL,
 custom_anchor_title text NOT NULL,
 new_window bigint(11) NOT NULL default 0,
 UNIQUE KEY id (id)
) $charset_collate;
CREATE TABLE $wpdb->custom_nav_menus (
 id mediumint(9) NOT NULL auto_increment,
 menu_name text NOT NULL,
 UNIQUE KEY id (id)
) $charset_collate;

What "custom" changes were made to jquery and jquery ui? One thing I see is that sizzle was added into the custom-navigation-custom-jquery-1.3.2.dev.js file.

It won't be easy for me to tell what changes were made so that we can remove the duplicated JS.

Replying to sivel:

What "custom" changes were made to jquery and jquery ui? One thing I see is that sizzle was added into the custom-navigation-custom-jquery-1.3.2.dev.js file. It won't be easy for me to tell what changes were made so that we can remove the duplicated JS.

Ok, seems that sizzle is in our 1.4.1, ignore the sizzle part for now then.

Two avoid the two new tables, there have been suggestions of using a custom post type. The posts table has most of what we need. It has title, content/description, menu order, parentage. And the existing posts functions could be leveraged. Top-level items (those without a parent) would be the equivalent of custom_nav_menus. Items within those menus would have parent fields that point back to them.

Replying to ryan:

Two avoid the two new tables, there have been suggestions of using a custom post type. The posts table has most of what we need. It has title, content/description, menu order, parentage. And the existing posts functions could be leveraged. Top-level items (those without a parent) would be the equivalent of custom_nav_menus. Items within those menus would have parent fields that point back to them.

It sounds good in theory, but -1 on that idea. Menus are 1) not a post type, and 2) shouldn't be in the wp_posts table regardless.

Replying to ptahdunbar:

It sounds good in theory, but -1 on that idea. Menus are 1) not a post type, and 2) shouldn't be in the wp_posts table regardless.

"post_type" is just a database field. For a long while, thanks to being able to modify "post_type," we've been able to use the "post" object API to handle all kinds of things (in projects I've done recently, they include calendars, menus, and business directory listings). Much of the recent work on the flexible post_type admin API will make it even easier to have non-"post"-link things be stored as a post_type in 3.0.

In the sense that matters--property isomorphism--"post" objects are much like menu objects as conceived by WooThemes: both have textual content, titles, associated URLs, hierarchy, IDs, and meta-data.

Replying to filosofo:

"post_type" is just a database field. For a long while, thanks to being able to modify "post_type," we've been able to use the "post" object API to handle all kinds of things (in projects I've done recently, they include calendars, menus, and business directory listings). Much of the recent work on the flexible post_type admin API will make it even easier to have non-"post"-link things be stored as a post_type in 3.0. In the sense that matters--property isomorphism--"post" objects are much like menu objects as conceived by WooThemes: both have textual content, titles, associated URLs, hierarchy, IDs, and meta-data.

I would agree with this. But it's probably further evidence that "post_type" is really not the best label for this (object_type or content_type would be better). But I'm sure that debate has already come and gone, though :-)

Replying to nathanrice:

But I'm sure that debate has already come and gone, though :-)

The debate was over here: #9674. I was arguing for "object_type" too, but it lost out to hodgepodge.

Related: #12273

(In [13257]) introduce custom menus, props jeffikus, See #11817

Notes on initial functionality:

menu item hierarchy is not saved to the DB

I didn't rewrite the front end output to use the menu data from the posts

Cleanup suggestions:

• Rename WP_CustomNavWidget to something like WP_Navigation_Widget.
• Rename custom-navigation-functions.php to custom-navigation.php.
• Lose -functions om the js.
• Lose custom jQuery and jQuery UI in favor of core versions.

How about an overview on how the post types, post statues, and taxonomy relate?

autocomplete can go to wp-includes/js/jquery/autocomplete.js.

The menu taxonomy was showing in the Post submenus. Turned that off. It still shows in the edit form. Edit form show probably respect show_ui. We might need to add some visibility flags to register_taxonomy().

Should the taxonomy be registered for post_type of 'post'? Shouldn't it register for 'menu_item'?

(In [13260]) Remove custom post states. Register taxonomy against menu_item post type. see #11817

The UI needs a bit of tweaking. The original version populated a couple menus with pages and categories. I removed the defaults. When the user visits the screen before any menus have been created and they create a menu, the left side does not populate the menu name as the title of the metabox.

Replying to wpmuguru:

When the user visits the screen before any menus have been created and they create a menu, the left side does not populate the menu name as the title of the metabox.

Temporary workaround for testing: create a menu, then reload the page.

(In [13262]) Rename file. see #11817

(In [13263]) Move autocomplete to standard jquery directory. Use core jQuery. Use jQuery instead of $. see #11817

(In [13264]) Remove custom jquery. see #11817

(In [13265]) Update paths in custom nav css. see #11817

This is probably a premature question, but I assume the boxes on the menu edit screen will eventually be restyled as regular metaboxes (collapse and rearrange).

Assuming they will be redone as such, I don't really see the point of having the "menu selector" option. If you can collapse and rearrange menus, then there's nothing holding you back from having ALL the menus load in the left (main) area.

Also, I don't really understand the need for the "enable/disable" menu options. I would think that if you don't want a menu to be active, then you won't be placing a call to it in your theme and/or delete the menu. Even if you do need the "enable/disable" options, I think that would be better to put inside the actual menu metabox.

So, it seems like the "setup custom menu" box could be totally removed, and the "menu selector" box could be renamed to "Add Menu" or "Create Menu" and just have a textbox that lets you create new menus.

That's all :-)

(In [13266]) Make js noConflict compat. see #11817

(In [13267]) Add icons. see #11817

(In [13269]) Use core jQuery UI. see #11817

(In [13271]) Cleanups. see #11817

Schema overview (not all of this is implemented yet):

Menu items are posts table entries with a post_type of 'menu_item'.

Menus are terms in the 'menu' taxonomy. Menu items are assigned the term for the menu that contains them.

posts->parent is 0 for top-level menu items. For sub menu items, parent point to the parent menu item.

menu_type is added to postmeta for the menu item and notes what type of menu item it is (page | category | custom).

object_id is added to postmeta for the menu item and points to the page or category associated with the menu item.

@nathanrice - When I was reworking the code I thought the same on switching to metaboxes. Patches would be welcomed :)

That schema works for me.

Possible consideration: can 'post_type' be 'wp_menu_item' and taxonomy 'wp-menu' just in case someone decides to do some custom posts type/taxonomies for a restaurant, (menu: lunch, dinner, daily-special, low-fat, glutten-free, etc). Less chance at collisions.

Did anyone update and try this out? Whenever I add multiple items to the nav bar, only 1 of them is being saved.

Did anyone update and try this out? Whenever I add multiple items to the nav bar, only 1 of them is being saved.

Its not just you, I'm having the same problems.

Possible consideration: can 'post_type' be 'wp_menu_item' and taxonomy 'wp-menu' just in case someone decides to do some custom posts type/taxonomies

Completely agree, Best to prefix them just to prevent any clashes, Its for internal use only, so the slug is not really important..

(In [13279]) Fix New Menu term handling. See #11817

see #12319

(In [13281]) Fix Typo. Props TobiasBg. Fixes #12319. See #11817

Some small things:

If the 'edit menu item'-box is moved, the height of the box is changed and you can't see the buttons anymore. Before:  http://grab.by/2zm2 After:  http://grab.by/2zm3

And we should add border-radius for webkit browsers.

I agree with @nathanrice.

I'm noticing that once I've saved changes, the interface no longer shows the levels of the menu items (in other words, you can't tell what is a sub-menu of another item).

Additionally, while the Menu Selector allows me to create new menus. I'm unable to switch between any of the new menus. When I click on a different menu and then "Switch" I am brought back to the original menu along with it's configuration.

This is mostly broken right now as we get the new schema in place. Submenus do not work. Switch does not work. Frontend display does not work.

(In [13286]) add custom menu hierarchy support to admin, See #11817

That's getting in the range where some work could start on the output to the front of the site.

Hi Guys, Some small things from me:

Grammatical Error When enabling, the status message says: "(site name)s Custom Menu has been updated!"

This should say: "(site name)'s Custom Menu has been updated!" Where the added apostrophe is possessive.

Confusing Element It is unclear that the user is expected to "add a menu" prior to creating menu items. This should either have a large call to action, or the other options should not be available until a menu has been created. When adding menu items without having first "created a menu", clicking on "save all changes" causes all the menu-items to be immediately deleted.

Links Opening in a New Window When adding a custom url to the menu, the default functionality assigned to "open link in a new window" is "yes" - causing any site using this to immediately fail xhtml1.0 strict validation, as well as being of questionable usability value!

Feature Request It would be incredibly helpful if the "edit menu item" options included a way of adding a custom class to the <li>

(In [13293]) improve custom menu hierarchy logic, See #11817

(In [13294]) add apostophes to custom menu update messages, See #11817

(In [13295]) Some gettext and formatting. see #11817

(In [13296]) More gettext. see #11817

(In [13298]) More gettext. see #11817

(In [13317]) Formatting cleanups. see #11817

On line 84 of /wp-includes/custom-navigation.php I think it should be // Override for menu descriptions and not //O verride for menu descriptions right now, just a space in the wrong place, nothing major! :)

(In [13322]) add function for deleting individual menus, see #11817

Curios as to why the link to the Navigation in the dashboard under Appearance is being called "Custom Navigation" instead of simply "Navigation" or "Site Navigation"?

It implies that there is some sort of non-custom navigation built in, and while it follows the convention for custom capabilities of the default theme, other items such as Posts and Pages aren't called "Custom Posts" and "Custom Pages".

Can anyone shed some light as to why this naming convention was used? Just curious.

(In [13331]) Nav cleanup. see #11817

It follows "Custom Header" and "Custom Background". Personally, I wouldn't mind dropping the Custom.

I did small cleanup of the admin section: proper HTML labels, checked and selected are handy WP functions, whitespace, dashes are preferred than underscores, coding style, i18n, underscores preferred than either camelcase or no separation between words, removed some of the obvious comments.

(In [13332]) Start consolidatinh menu item outupt into output_menu_item(). DRY. see #11817

(In [13334]) More output consolidation. see #11817

I'd like to change "Custom Navigation" to "Menus" per earlier discussions. It's more like widgets than like the custom header, but really, I think we could get rid of the word Custom from everything under appearance. The fact that you have the ability to control each thing makes all of them custom. Getting rid of Custom in the labels will also make translation strings shorter. Can we get rid of Custom across the board, and change Navigation to Menus?

+1 to removing "Custom." It's all obviously customized.

Menus, Header, Background -- I like dropping "Custom" on all three.

(In [13336]) More output consolidation. see #11817

+1 on dropping custom "Custom" and and using the "Menus" terminology.

(In [13338]) More output consolidation. see #11817

(In [13339]) Drop 'Custom' from menu names. Use 'Menus' instead of Navigation. see #11817

In the API I'd like to drop "custom_navigation" in favor of "nav_menu". The nav is to help distinguish from the admin menus.

(In [13340]) Use 'Menus'. see #11817

(In [13342]) Cleanups. see #11817

You might be able to do this with CSS, but one of my sites that currently uses the Blogroll system for navigation is here:  http://thisibelieve.org/. Note how we have images associated with the top level navigation items. Might I suggest a field and interface be added for menu item icons including images or entities/characters.

We also reuse that navigation in the footer of the site so that it's both at both the top and at the bottom in the form of a footer site map. Thus, I would hope that once a navigation query was performed, it could be cached and recalled for later use without making a second trip to the database.

With the new system in place, I won't have to use the blogroll or custom page/category queries to get the kind of results I wanted for that site or others so I'm very excited about this new feature in 3.0.

Missing question mark ? in <?php messes up PHP.

(In [13344]) Some nav menu API. see #11817

(In [13345]) Fix php open tag. Props TobiasBg. see #11817

fastpipe, all of that is planned.

Hierarchy is still a bit broken. If you add an item from the sidebar, drag it under another item, and then save, the hierarchy is properly saved. If you save again, all hierarchy is lost. Sidebar addition is doing something right and the regular listing is doing some wrong when it comes to setting the parent.

(In [13348]) fix custom menu hierarchy support in admin, See #11817

(In [13352]) add menu delete & other custom menu cleanup, See #11817

(In [13354]) dont show items when menu empty, See #11817

Found a bug

If the Page has " in its name it is not working I have a page called: The "Other" Stuff

(In [13355]) move menu selection to a top nav links, See #11817

Has anyone thought about how is the Menu/Navigation functionality going to take into account custom post types that will start being used more with the release of 3.0?

I ask because with the nav you can add pages and categories, what about a way to add posts or other custom post types (maybe the ability to add a new selection box to the menu UI via a hook when you declare a new post type?) to the navigation as well? It could use the same UI only it would allow you to search for posts or custom post types to add to your navigation.

At the very least it might be good to have the ability to create a new menu item selector via a hook... just a thought.

@carlhancock: I'd say we have more than enough to do for v1 of this feature. Looking up individual posts (or custom post type items) within the menu screen is outside scope, IMO.

(In [13362]) Return menu object from wp_create_nav_menu(). Fix trailing separator in menu list. Disable menu delete because it deletes the current menu when a new menu is added. see #11817

Created ticket #12339 a bit ago. I'll be sure to post future patches in this ticket :)

(In [13364]) Clean up the JS/no-JS CSS. Fix up the no-JS message. see #11817

(In [13365]) Increment the menu ID so the first menu works. props junsuijin. fixes #12339

(In [13366]) Reorg nav menu files. see #11817

(In [13367]) Reapply stomped part of [13364]. see #11817

(In [13368]) Fallback to wp_page_menu() from wp_nav_menu() if no menus are setup. Use wp_nav_menu() in twentyten. see #11817

wp_nav_menu() is the template function themes use to output a nav menu. A menu id or slug can be passed to identify the menu to output. If neither ID or slug is passed, the first non-empty menu is used. If there are no non-empty menus then wp_page_menu() is called. A means of specifying a "main" menu is needed so that themes calling wp_nav_menu() without a requesting a specific menu (the most common case) won't have the menu that's picked change as menus are added and deleted.

(In [13369]) Remove Resetting, remove Enabling, enable deletion, etc. see #11817

(In [13370]) Fix menu links. see #11817

(In [13371]) Use esc_js() so pages with quotes can be added to custom menu. see #11817

(In [13372]) Fix menu selection CSS, menu selection alignment, right meta boxes alignment. Disable alert fading for custom menu admin. see #11817

I think that the defaults need adjusting for this... I just updated my test site to current trunk and thought I would check out the 2010 theme.. Switched to it, and found that my index page now has over a screen and a half of menu at the top.

<?php wp_nav_menu( 'sort_column=menu_order' ); ?>

Is the culprit, so maybe there could be some more sensible defaults for sites with a lot of Pages. Potentially a default limit of say 10 Pages in the menu which could be user-defined...

Can attach a jpg if required, but hope it is obvious what I'm talking about.

There is and encoding issue since r13338.

In nav-menus.php, category names saved in UTF-8 are displayed as ISO-8859-1. To reproduce:

• Rename one of your categories to, say, Новости or Ειδήσεις (Russian and Greek for News).
• Go to Appearance, Menus
• Go to Add an Existing Category, and click Show All

really impressed with whats been done here since I last checked. Seems to be moving pretty fast!

if needed, some fixes

Replying to mrmist:

I think that the defaults need adjusting for this... I just updated my test site to current trunk and thought I would check out the 2010 theme.. Switched to it, and found that my index page now has over a screen and a half of menu at the top. <?php wp_nav_menu( 'sort_column=menu_order' ); ?>

If you switch back to wp_page_menu() do you see the same thing? If no menus are set then we should be falling back to the exact same thing that was done before.

Replying to ryan:

If you switch back to wp_page_menu() do you see the same thing? If no menus are set then we should be falling back to the exact same thing that was done before.

Yep if I change the code to page_menu instead I still see the same thing... However, I'd suggest that there should be some default limit, still. It just looks ridiculous otherwise.

Updated cleanup patch (see above). Also fixes the encoding issues reported above -- htmlentities breaks non-ASCII strings.

(In [13375]) Nav menu cleanups. Props nbachiyski. see #11817

(In [13378]) Rename nav menu widget. see #11817

@nbachiyski Thx for cleanup. On my little cleanup I add a missing </form> tag. I miss it on your patch, or?

(In [13381]) Some XSS escaping love for nav menus. see #11817

(In [13383]) Add missing form ending tag. Props ocean90. see #11817

When editing an existing page or category menu item, it looks like you can edit the URL for that item. When you click save to close out of the edit screen, the "View Page" link URL updates to the new address, but when you save the menu it gets reverted. I'm sure this is the desired functionality since the menu item is linked to the page or category ID, but the URL input field should probably be disabled to avoid confusion.

(In [13388]) Formatting cleanups for the nav menu widget. see #11817

Today I started to fix the layout.

Latest:  http://grab.by/2ECl for classic and  http://grab.by/2ECF for fresh

I think we should use more from the global css classes, because there are some duplications and then its also more WordPress like. If its okay, I will finished it for tomorrow.

(In [13390]) Hide URL editing UI for page and category menu items. TODO: eliminate all usage of guid. Use custom field instead. see #11817

Cleans up nav-menus.php to use standard WP UI elements

attachment ticket_11817_nav-menus.php_beastmode.patch

This patch cleans up the nav-menus.php layout to use WP's UI elements. It also prepares the layout for the ability to add custom menu items (custom post types, taxonomies, etc).

Design for Menus preserving original structure but using standard WP admin interface elements.

Menu data should probably be exportable and importable... which means the old  http://svn.automattic.com/wpcom-themes/test-data.2008-12-22.xml file should be updated when that functionality is completed.

Should this be in its own ticket or under this one?

(In [13394]) minify custom-navigation.css, See #11817

It looks like Custom Links are opening in new windows regardless of what I have the open in new window flag set to. Pages and Categories seem to be working fine.

Menu items are now fully clickable instead of just the green plus image. Added a scrollbar when there are more than 7+ menu items. Refactored custom-navigation.dev.css. Moved custom link to the top. Minified all the CSS changes (using the YUI Compressor).

(In [13395]) Nav Menu enhancements. Whole item is clickable to add. Refactored CSS. Scrollbar when more than 7 menu items. props ptahdunbar. see #11817

(In [13397]) Use custom fields for custom URL and new window data. Links no longer automatically open in a new window. see #11817

The gif uploaded by @ilovecolors is not an approved change. Menus are by nature not a static list as the gif suggests, and should not use the UI conventions of the listing screens, but be closer to widgets. We will need to do a little UI touching up, but this is not the direction we will be going.

Are the colored icons really necessary (or GPL)? They REALLY stick out in the UI. Maybe that's the point, but I'd really love to see some custom icons (like the admin menu icons) that fit a little better with the default UI.

I agree with nathanrice. For example on Edit Posts' we haven't icons too. So instead of icons I would prefere Edit - Remove - View, btw: remove, should we use instead of the remove better atrash function like on comments/posts? This would be good, if someone want to hide a page only temporarily.

The widgets on the right side have now the postbox class with the move cursor. So the widgets should be draggable or we should change the cursor, at the moment it's confusing.

@nathanrice @ocean90: I'm writing up some UX points for discussion to post on wpdevel.wordpress.com so that they can be hashed out there/in today's dev chat, rather than cluttering Trac. I agree the icons are inconsistent, and would like to make everything more WordPress-like. There are a couple of ways to go about it, though, and it would be ideal to keep the ticket traffic here focused on the coding.

(In [13400]) Set meta after new menu is inserted. see #11817

Overhauled the pages, and category list to use standard WP UI elements ( http://i45.tinypic.com/2gtyvwy.jpg), tweaked the drag-n-drop js to allow for bulk selection before adding items to the menu, nav-menus.php layout cleanup. (updated script loader + included minifed versions of the js/css changes)

How is the menu order determining what menu is loaded if you don't explicitly tell the front end function call what menu to load?

For instance with a fresh install with the 2010 theme if I add a new menu called "Main Menu" and populate it with fields, the 2010 theme doesn't explicitly say which menu to load so it pulls in the only menu that exists. That is fine if you have one menu.

Now if I add another menu called "Footer Menu" the 2010 theme now switches and starts using this menu as the main menu, although I didn't create it with intentions of necessarily using it right away.

How is it determining which menu to display of no menu is specified? It's not the first because Main Menu was the first menu I created. It appears to be displaying the last... just seems like this could cause come confusion and temporarily disrupt some sites if someone running 2010 goes in and plays around with adding a new menu not realizing because of how the menu call is made that this new menu is now all of a sudden being used as the main menu on his live site...

Can anyone clarify? Hopefully my description above was not too confusing.

I didn't want to post a novel here, since Trac isn't really good for threaded discussion, so I posted my menu UX/UI issues list on wpdevel here:  http://wpdevel.wordpress.com/2010/02/25/menus-ux-manifesto/

Re @ptahdunbar's UI changes, the only thing that should be changed is the button text, since it's not adding pages, it's adding them to a menu. I'd change button text to Add to Menu or just Add if space is a concern with translation.

I know @jane mentioned that custom post types won't be possible in the Menu toolbox for the 3.0 release because it is out of scope. Would it be possible to at least add some hooks so that a plugin could add a new toolbox to the menu builder? So if you do have a custom post type it would be possible to create a plugin that adds it to the menu builder using those hooks to users could add those to their menu if they want to?

Replying to carlhancock:

I know @jane mentioned that custom post types won't be possible in the Menu toolbox for the 3.0 release because it is out of scope. Would it be possible to at least add some hooks so that a plugin could add a new toolbox to the menu builder?

Once things get a bit more stable, hooks will be added. I'm working on abstracting the menu item sections so you can easily add a new one for say, custom post types as an example.

(In [13406]) Create a default menu containing the first 15 top-level pages. see #11817

(In [13407]) Order menus by ID so that the lowest ID is always used when guessing which menu to use in wp_nav_menu(). see #11817

So far, the work here has been amazing. I'm loving how everything is coming together.

Since menus are only really useful if themes support them, I have a few suggestions:

• Use add_theme_support( 'nav-menus' ) so that users won't be confused when their menus aren't appearing.
• Create a nav_menu_exists() function that checks if a menu already exists.
• Create an is_active_nav_menu() function to check if a menu has items in it.
• Don't fall back on anything (e.g., page menu). Allow themes to create their own fallbacks.

Combining the last three ideas will allow theme authors to do something like this:

• Create Menu 1. On display, if no items have been saved, fall back to wp_page_menu().
• Create Menu 2. On display, if no items have been saved, fall back to wp_list_categories().
• Create Menu 3. On display, if no items have been saved, fall back to wp_tag_cloud( 'format=list' ).

---

Can we drop the "Open link in a new window" functionality? Should we even be supporting this at all?

Probably a more useful feature would be the ability to add custom class and rel attributes.

Replying to greenshady:

So far, the work here has been amazing. I'm loving how everything is coming together. Since menus are only really useful if themes support them, I have a few suggestions: ... Can we drop the "Open link in a new window" functionality? Should we even be supporting this at all? Probably a more useful feature would be the ability to add custom class and rel attributes.

I agree fantastic work so far, it's coming together very nicely. Kudos to those working hard on the code.

+1 for your suggestion for handling menu order and the ability to add custom class and rel attributes

(In [13415]) Allow themes to specify a menu fllback other than wp_page_menu(). see #11817

(In [13417]) Note theme support for custom background, header, and menus. see #11817

If !current_theme_supports( 'nav-menus' ) then we can show a message at the top of the menus admin nothing that the theme doesn't have custom menu support but that you can create a menu to use as a widget.

Add 'class="button-primary"' to main save button

Still left to do:

- switch the dialog box to thickbox
- Several items from the menu manifesto:  http://wpdevel.wordpress.com/2010/02/25/menus-ux-manifesto/
- Possible tweaks to the output of the menus in the front-end.
- Hooks and Filters galore
- Last but not least: Accessibility. See #12380. This will start once we hit feature freeze as things still might change.

Replying to ptahdunbar:

- Possible tweaks to the output of the menus in the front-end.

A good suggestion in this respect would be making it possible to hide the home link on the home page only. If others agree, I'm willing to look into how to do it (have done it recently for a custom menu system). IMHO it would be the right choice as a default.

See number 10 on this page, from Jakob Nielsen:  Don't include an active link to the homepage on the homepage

Replying to ptahdunbar:

I'm not sure that the buttons in the action column need to have the primary class. For instance, when adding tags to a post on the edit post screen, the add button has the standard button style:  http://i50.tinypic.com/35ttd.jpg

I think the policy is to have only primary save buttons have the primary "blue" style applied.

@nabha: If you mean just removing the link, not removing the label, then yes, we should. All navigation links should become regular text labels rather than links when the user is on the page for a particular navigation label.

@nathanrice: Correct. The 'add' buttons on the post editor are secondary/white, with only Publish carrying the primary blue style. If the 'add' here doesn't actually publish and we have a screen-wide Save button, then the 'add' ones should be secondary style.

I think many would regard having the "Custom Menu Links" category and storing custom links in the links table as unwanted pollution of their blogroll. To enable "View All" for custom post types we can list all menu items with a post type of custom and maybe the existing links from the links table.

So, ticket_11817_nav_menu_enhancements.diff looks good except for the link stuff. Let's not add anything to the links table. The information is already stored as a menu item so there's no need to add it to links.

Overhauled the pages, and category list to use standard WP UI elements ( http://i46.tinypic.com/2ih8rr9.jpg), tweaked the drag-n-drop js to allow for bulk selection before adding items to the menu, custom links overhaul ( http://i49.tinypic.com/2u54yvb.jpg and  http://i45.tinypic.com/2moshmo.jpg), nav-menus.php layout cleanup. (updated script loader + included minifed versions of the js/css changes)

Replying to nathanrice:

Replying to ptahdunbar: I'm not sure that the buttons in the action column need to have the primary class.

My fault. I misinterpreted this:

Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.

Patch updated.

New Screenshots:  http://i47.tinypic.com/22yg44.jpg[[BR]]  http://i49.tinypic.com/167nk9l.jpg[[BR]]  http://i46.tinypic.com/2a8lpmx.jpg[[BR]]

 http://i46.tinypic.com/2a8lpmx.jpg

Replying to ptahdunbar:

New Screenshots:  http://i47.tinypic.com/22yg44.jpg
 http://i49.tinypic.com/167nk9l.jpg
 http://i46.tinypic.com/2a8lpmx.jpg

oops.

Replying to ryan:

I think many would regard having the "Custom Menu Links" category and storing custom links in the links table as unwanted pollution of their blogroll. To enable "View All" for custom post types we can list all menu items with a post type of custom and maybe the existing links from the links table.

Gotcha. I'll upload a new patch in a few hours to fix that.

Talked to Jane and the add boxes should have a search box, and then a submit button, and then a View All link on the next line that changes to Hide All on expansion. We need a submit button for accessibility. Let's also consider having the button below the checkboxes say "Add to Menu".

Replying to ptahdunbar:

Replying to ptahdunbar:

New Screenshots:  http://i47.tinypic.com/22yg44.jpg
 http://i49.tinypic.com/167nk9l.jpg
 http://i46.tinypic.com/2a8lpmx.jpg

oops.

Isn't it redundant the fact that the action button of the 'Add Menu' box is also labeled 'Add Menu'? 'Add' might be enough, in the same way you labeled the buttons to add a page or category. Maybe 'Add New'? to state that it is an entirely new entity, pretty much like the Add New for posts or pages.

@ilovecolors: We're going to be moving away from "Add New" as a label, so that's not going to work. I'd suggest waiting until there's a revised patch rather than commenting based on old screenshots.

We should add some caps for menu management: edit_menus and delete_menus for starters.

Related: #12399

attachment ticket_11817_menu_management.diff

this patch is based off ticket_11817_nav_menu_enhancements.diff.

What's new?
Thickbox support
Tweaks to the menu settings sidebar
Custom Links storage is now based off the nav_menu_item post type.
Added jquery animations when items are added, edited, and deleted.
Removed button images and the view link.
Lots of code cleanups and refactoring and documentation.

Still much to do, but this should be a nice update.

HOORAH!

Screenshots based off attachment ticket_11817_menu_management.diff

 http://i45.tinypic.com/2wnmqo6.jpg
 http://i50.tinypic.com/w2m1ck.jpg

Also: What are you guys thoughts on adding a scroll bar to the menu when it gets really long?

Replying to ptahdunbar:

Still much to do, but this should be a nice update.

I actually like what you've done, don't know about others? :)

(In [13473]) more menu improvements, props ptahdunbar, see #11817

If you add a menu item and change your mind, you have to save the menu before the item can be removed.

ignore that last comment - it worked after reloading the browser.

Any reason that the UI has the available items on the right and the drop target on the left? This is the opposite way around to the Widgets screen where the available items are on the left and the drop target on the right.

Replying to johnbillion:

Any reason that the UI has the available items on the right and the drop target on the left? This is the opposite way around to the Widgets screen where the available items are on the left and the drop target on the right.

But, the widgets do things the opposite way of everything else in the admin. Most WordPress screens have the content area in the middle and the meta boxes on the right. Menus are more in line with how things are currently done.

A few more issues with large numbers of Pages being present when you first enable the 2010 theme..

By default the system seems to generate "Menu 1", with everything in it. However, with a large number of Pages, when you visit the Menus setting area, only the first 14 are shown. There's no way to see the rest of the manu on this settings page.

Secondly, the 14 that appear in this list are not the same 14 that appear first in the menu as shown on index.php when you visit the site.

Thirdly none of the delete buttons seem to work.

And lastly no matter what else I try do with regards to creating new menus, the menu 1 comes back, full of everything.

I think this could all be pretty confusing. Heck, I'm confused and I've been using WP for years now.

Replying to mrmist:

A few more issues with large numbers of Pages being present when you first enable the 2010 theme..

What issues specifically?

By default the system seems to generate "Menu 1", with everything in it. However, with a large number of Pages, when you visit the Menus setting area, only the first 14 are shown. There's no way to see the rest of the manu on this settings page.

By default, if you don't have any menus, it grabs the first 14 pages and creates a menu out of it. It's there just to get you started. Perhaps this could be modified to show all.

Secondly, the 14 that appear in this list are not the same 14 that appear first in the menu as shown on index.php when you visit the site.

Probably because when you don't have any menus, it uses the fallback wp_page_menu() function.

Thirdly none of the delete buttons seem to work.

Can you reconfirm that they are not working? Try reloading the page. The delete button works fine on my end.

And lastly no matter what else I try do with regards to creating new menus, the menu 1 comes back, full of everything.

As I said above, if you don't have any menus, WP creates 'Menu 1' automatically. If you create a new menu, you can delete 'Menu 1'.

I think this could all be pretty confusing. Heck, I'm confused and I've been using WP for years now.

Maybe WP shouldn't create a default menu automatically. Ryan built this in so we'll see if he has anything to say.

wp_nav_menu() still needs some more attention. Right now NO ".page_item .current_page_item" classes are added.

And there should be a filter "wp_nav_menu" that works the same way "wp_page_menu" does.

I was under the impression when reading the later replies, that each menu would be assigned an ID, which in fact it is, but rather at what ID it started? Am I right in thinking it'll start at 1, being the only menu created, therefore meaning the next would be 2 and so on...!

You see, I get nav-menus.php?edit-menu=200 and nav-menus.php?edit-menu=201 which is miles off from what I thought was happening? Not everyone is going to understand, if that IS indeed the case, that menus start off with ID 200!

And before anyone asks, no I haven't gone and created 200 menus, that's exactly how it shows up, anyoneone got any ideas, meant to be like this, or a bug?

The menu ID is whatever term ID the menu happens to get when it is created. The ID could start anywhere, depending on how many terms you already have.

The URL for Pages and Categories should not be editable. Instead we should show what Page/Category the menu item is linked to.

Replying to ryan:

The menu ID is whatever term ID the menu happens to get when it is created. The ID could start anywhere, depending on how many terms you already have.

Guess it slipped my mind we're using a Custom Taxonomy here, and how it just so happened to start with ID 200, so doesn't that virtually make the ID option of wp_nav_menu(); pointless as no developer is going to know what ID is what?

attachment ticket_11817_nav_menu_bugfixes_tweaks.diff

Started doing some work on the front-end side and did a sweep through, documenting functions, cleaning out stale code, more refactoring and some bug fixes.

Removed the id, and slug args from wp_nav_menu() in place of 'menu' which can take the menu id, slug, or name.

New function: is_nav_menu() checks whether a menu exists. Pass an id, slug, or name.

New wp_get_nav_menu() returns the nav menu.

All the js code is abstracted so it can handle any menu item type. Started doing some work on hooks. Removed the advanced stuff from the nav menu widget. Overall things are getting stable at this point.

Still to do from the Menu Manifesto:
* Hooks
* Accessibility

And

The URL for Pages and Categories should not be editable.

If I have the time, I'll update the available menu items (custom links, pages, categories) to support any taxonomy type.

This is a fairly small thing, but could the Menus option under Appearance appear a little higher up? It looks a bit redundant down there underneath Add New Themes

I would suggest that it appear right after Widgets

Also still hopeful for the possibility to add custom classes to menu items

Replying to JohnONolan:

This is a fairly small thing, but could the Menus option under Appearance appear a little higher up? It looks a bit redundant down there underneath Add New Themes

See #12412. Add New Themes will likely be removed. If not, I would suggest we move it to a very high priority, that way Background, Header and Menus are all above it.

(In [13512]) Menu enhancements. Props ptahdunbar. fixes #11817

Why is the "Save All Changes" button right justified and the "Delete Menu" link left justified? My eyes keep going to the Delete Menu link and NOT the save link which isn't a good thing from a UI perspective.

I understand the "Save" buttons typically appear right justified in other areas.. but those are areas where those save buttons appear in the right side column.

Anytime a save button appears in the main content column it is always left justified. Look at any of the pages under the "Settings" area, all the Save buttons are left justified under the content. Look at the Add Category page, the button is left justified.

If the "Save" button is not in the right hand toolbar column I think it makes most sense for it to be left justified with the "Delete Menu" link located to the right of it (not right justified, but to the right of the save button with them appearing side by side).

Thoughts?

Also, why is the button called "Save All Changes" instead of simply "Save Changes"? It implies there is another button that saves some changes... but not all? All the Save buttons on the Settings pages simply say "Save Changes".

Is there any reason why it can't just be "Save Menu"?

If you are adding a menu for the first time, "Save Changes" implies you are changing something that already exists... which doesn't make sense when adding a new brand new menu that didn't already exist because you aren't changing anything.

Ideally it would say "Save Menu" when you are creating a brand new one and "Update Menu" when you are editing an existing menu. This is how other areas work such as when you are editing a comment the button says "Update Comment", pages and post simply say "Update". But if it's possible to say "Save Menu" when adding a new one and "Update Menu" when saving changes to an existing menu, that would probably make more sense.

Three things from me:

• I agree with carlhancock that Save All Changes is not good. The All does not add anything.
• The View (target document) link that was removed a few days ago could be helpful for those who have many pages/categories. Maybe we should consider bringing it back?
• I am not happy that the TITLE attribute defaults to the anchor text. WordPress should stop doing that. It should default to an empty TITLE unless it has something useful to say with the TITLE attribute. I think that now, with the new Menu Manager, is a good time to start changing that.

About TITLE attributes in WordPress, see this good and short article:  http://www.technokinetics.com/wordpress-and-title-attribute-abuse/ (by the author of the Page Lists Plus plugin).

+1 RE save button wording

Replying to demetris:

* I am not happy that the TITLE attribute defaults to the anchor text. WordPress should stop doing that. It should default to an empty TITLE unless it has something useful to say with the TITLE attribute. I think that now, with the new Menu Manager, is a good time to start changing that.

+ 1

Replying to ptahdunbar:

By default, if you don't have any menus, it grabs the first 14 pages and creates a menu out of it. It's there just to get you started. Perhaps this could be modified to show all.

I don't mind it only picking 14 items to show in the menu, that's great. What I dislike is that the menu that actually appears is not the same as the one that's shown in the settings. The menu that appears is all the Pages, not just the 14.

Probably because when you don't have any menus, it uses the fallback wp_page_menu() function.

Then I guess it's that that makes no sense. It shouldn't be falling back *and* creating a Menu 1. It should be doing one or t'other.

Thirdly none of the delete buttons seem to work.

Can you reconfirm that they are not working? Try reloading the page. The delete button works fine on my end.

Confirmed. With a full "Menu 1" none of the menu edit/delete options are working (In IE6.)

Maybe WP shouldn't create a default menu automatically. Ryan built this in so we'll see if he has anything to say.

So long as it's presented consistently I don't mind either way.

Since there is no "Trash" for Menus, it might be a good idea to prompt an approval dialog box when a user clicks on the Delete link. It will help avoid accidental deletion, especially when a Menu structure could be complex and time consuming to put together. Would be highly annoying to accidentally flush a lot of work down the toilet.

Replying to carlhancock:

Since there is no "Trash" for Menus, it might be a good idea to prompt an approval dialog box when a user clicks on the Delete link. It will help avoid accidental deletion, especially when a Menu structure could be complex and time consuming to put together. Would be highly annoying to accidentally flush a lot of work down the toilet.

+1 on this too, however long term it'd be great if there was a Trash for menus. Not sure what the scope for possibility on that one is though!

Replying to carlhancock:

Why is the "Save All Changes" button right justified and the "Delete Menu" link left justified? My eyes keep going to the Delete Menu link and NOT the save link which isn't a good thing from a UI perspective.

Taken from  Menu Manifesto:

Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.

Perhaps we could go with carl's approach as we didn't switch the columns. If anyone is against his way, comment now or else it's going in the next patch sprint.

Also, why is the button called "Save All Changes" instead of simply "Save Changes"?

Valid argument. I didn't touch it yet as my thinking was that since the user can do a lot of changes (e.g. create links, and/remove items, and edit items), it made sense that the button reads: "Save all changes". If anyone is for leaving it how it is, comment now, the next patch will change it to "Save/Update Menu" so it's consistent with WP's UI conventions.

Since there is no "Trash" for Menus, it might be a good idea to prompt an approval dialog box when a user clicks on the Delete link.

Done. I already started on the trash feature, but I need to consult Jane on the UI part.

Replying to demetris:

I am not happy that the TITLE attribute defaults to the anchor text. WordPress should stop doing that.

Done.

Replying to mrmist:

Then I guess it's that that makes no sense. It shouldn't be falling back *and* creating a Menu 1. It should be doing one or t'other.

Very true. Removing the functionality that creates a default menu. WP already defaults to wp_page_menu() as a fallback. Plus, it could get confusing when you have custom menus in your theme (basically anything pre 3.0) but it's not using the new wp_nav_menu() API. Users can get confused that the default menu being shown in the backend isn't what's appearing in the frontend.

Confirmed. With a full "Menu 1" none of the menu edit/delete options are working (In IE6.)

Keyword: IE6. No testing has been done on this 9yr old browser. Perhaps it will during the accessibility pass, but don't take my word on it.

Replying to ptahdunbar:

Replying to carlhancock:

Why is the "Save All Changes" button right justified and the "Delete Menu" link left justified? My eyes keep going to the Delete Menu link and NOT the save link which isn't a good thing from a UI perspective.

Taken from  Menu Manifesto:

Buttons. The Save button should use the primary button class (blue). It should also be furthest to the right. Delete should not be a button, but a red link, and to the left.

Perhaps we could go with carl's approach as we didn't switch the columns. If anyone is against his way, comment now or else it's going in the next patch sprint.

The SAVE button is always furthest to the right when it is in a toolbox in a sidebar area. In this instance the SAVE button is with the content column, and in other areas of WordPress if it is in this area it is always left justified.

Examples are any of the Settings pages, the Theme and Plugin Editor interface, the add Category page, etc. All utilize a left justified save, add or update button. But I can't think of an example where a delete link is incorporated this way. Delete links are typically

Honestly I wish the Menus worked like Pages, Posts, Media Library, etc. I don't like the create, edit and manage all from one screen UI. It strays from everything else in WordPress.

Ideally when you went to Menus you would first get a table/grid of all your Menus (just like Edit Pages) and then from that page you could edit or click Add New which would then show the menu builder interface. Then on the menu builder interface in the right hand column you could have the first widget box contain the SAVE button and the delete link just like it is on pages, posts, etc.

Yes it would split it up into 2 screens, but it just makes sense because thats how Posts, Pages, Media, Categories, Tags, etc. work. Yes, Categories and Tags have add forms integrated on the first screen... but i'm not a fan of that either. It could just as easily be behind an "Add New" button just like Pages/Posts/etc.

Removes a stray comma ('after_link' => ,) that made it's way into the end of the default array() for wp_nav_menu(). Plus a little couple of cleanups, as in whitespace, which I think have been done properly and as they should? :) Main thing was to just remove the stray commas!

Replying to carlhancock:

Honestly I wish the Menus worked like Pages, Posts, Media Library, etc. I don't like the create, edit and manage all from one screen UI. It strays from everything else in WordPress. Ideally when you went to Menus you would first get a table/grid of all your Menus (just like Edit Pages) and then from that page you could edit or click Add New which would then show the menu builder interface. Then on the menu builder interface in the right hand column you could have the first widget box contain the SAVE button and the delete link just like it is on pages, posts, etc.

Yes it would split it up into 2 screens, but it just makes sense because thats how Posts, Pages, Media, Categories, Tags, etc. work. Yes, Categories and Tags have add forms integrated on the first screen... but i'm not a fan of that either. It could just as easily be behind an "Add New" button just like Pages/Posts/etc.

+1 on this. But it's a low priority right now. There's still a few more things to tackle beforehand. Perhaps this can be done during the accessibility pass or maybe 3.1.

RTL CSS for the nav-menu

Added

I just looked at the updated menus and it looks like some things are going in a different direction than I thought they were going (ex. popup for editing instead of slidedown postbox like we use everywhere else). I want to focus on getting the UI back on track for consistency. I'll try to catch people in #wordpress-dev today so we can get things settled, since leaving feedback on this ticket is starting to feel like a hodgepodge of people's Christmas lists (to paraphrase something Denis once said to me).

(In [13532]) Fix notices inside wp_nav_menu(), Ensure echo => false is passed to fallback callbacks so the function doesnt print HTML directly. See #11817

(In [13542]) Hide All/Show All buttons should be links. see #11817

(In [13544]) Clean up whitespace in nav-menu.php see #11817

Can anyone confirm that calling the menu by slug or name doesn't work? It's only pulling the first available menu when I do one of these:

wp_nav_menu( array( 'menu' => 'primary-menu' ) ); // By slug

wp_nav_menu( array( 'menu' => 'Primary Menu' ) ); // By name

But, calling a menu by ID does work?

wp_nav_menu( array( 'menu' => '100' ) ); // By ID

wp_nav_menu now works when called by slug or name

Replying to greenshady:

Can anyone confirm that calling the menu by slug or name doesn't work? It's only pulling the first available menu when I do one of these: {{{ wp_nav_menu( array( 'menu' => 'primary-menu' ) ); // By slug wp_nav_menu( array( 'menu' => 'Primary Menu' ) ); // By name }}} But, calling a menu by ID does work? {{{ wp_nav_menu( array( 'menu' => '100' ) ); // By ID }}}

Try the patch attached above.

Replying to Utkarsh:

Replying to greenshady:

Can anyone confirm that calling the menu by slug or name doesn't work?...But, calling a menu by ID does work?

Try the patch attached above.

Patch works great for me and also fixes the same issue with is_nav_menu().

additional tickets:

#12470, #12471, #12472, #12449, #12442

also #12410

(In [13550]) Fix is_nav_menu(). Props Utkarsh. see #11817

(In [13580]) use correct variable, see #11817

@Ryan - when the user goes into the menu option for the first time no menu is displayed although it was created. I think it tracks back to the term caching where it looks like the first call to get the menu terms gets an empty set & the second call gets the empty set from cache. I wasn't sure where the cache clearing should be handled (ex. wp_insert_term), so I didn't attempt to fix.

The URL field on Edit Menu Item isn't focusable in Chrome.

Replying to miqrogroove:

The URL field on Edit Menu Item isn't focusable in Chrome.

The url field is disabled for pages and categories.

@wpmuguru: the default menu is being created late in the stack which is why it takes a second page load to appear. I think there was an agreement to axe the default menu creation as there's already a fallback function call for wp_nav_menu().

The default menu creation was to avoid confusion over why the theme showed something and the menus admin showed nothing. Also, having no menus at all present by default was confusing. Those were the motivations, anyhow. There is perhaps a better way to address them.

Replying to ryan:

The default menu creation was to avoid confusion over why the theme showed something and the menus admin showed nothing. Also, having no menus at all present by default was confusing. Those were the motivations, anyhow. There is perhaps a better way to address them.

IMO, wp_nav_menu()'s fallback function is good enough as it provides an optional replacement if the menu doesn't exists. Having WP create yet another fallback method makes things confusing. Plus, for those who don't use wp_nav_menu() it makes things even more confusing as what's being displayed in the backend is not what's actually in the front-end.

If a theme didn't register support for nav_menu, a message would be displayed in the admin custom nav page explaining lack of support:
"The current theme does not support Custom Navigation."

If a theme does support, it should display a message that WP is using the fall-back wp_pages_menu (wp_menu_pages?) and a message suggesting customizing. (perhaps prepopulating the menu with the pages in use in the fall back to clarify)
"You haven't yet customized your menus! Currently we are simply providing a list of your pages, but feel free to change it as you see fit!"

And if their is a way for theme devs to specify a default fallback menu (perhaps by registering like a sidebar and defining options) then it should populate and use that menu until user overwrites with customizations, no? (if this is too much, perhaps in 3.1)

Replying to WraithKenny:

If a theme didn't register support for nav_menu, a message would be displayed in the admin custom nav page explaining lack of support:
"The current theme does not support Custom Navigation." If a theme does support, it should display a message that WP is using the fall-back wp_pages_menu (wp_menu_pages?) and a message suggesting customizing.

+1 on this idea. Added to my patch.

And if their is a way for theme devs to specify a default fallback menu (perhaps by registering like a sidebar and defining options) then it should populate and use that menu until user overwrites with customizations, no? (if this is too much, perhaps in 3.1)

The fallback is set for each menu using the 'fallback_cb' argument in wp_nav_menu();

Small patch for fix HTML attributes in trunk.

Fix HTML

Someone brought up an interesting question in the Woothemes comment thread about the integration of their menu plugin: The conditional display of menu items. Currently, it seems to me, there doesn't seem to be a way to conditionally restrict the display of menu items - say only display the second level if the top level is active, or show certain menu items on one page, but not on another.

It seems it's currently impossible to add a line break to a menu item, the html is cleaned out. I suppose it is a rare case, but I attempted a menu with both German and English item descriptions for the same item, separated by a line break. Maybe a short code would be an option instead of HTML?

Replying to youngmicroserf:

Someone brought up an interesting question in the Woothemes comment thread about the integration of their menu plugin: The conditional display of menu items. Currently, it seems to me, there doesn't seem to be a way to conditionally restrict the display of menu items - say only display the second level if the top level is active, or show certain menu items on one page, but not on another.

Does Woo do that? The version of Woo Custom Navigation I have does not support display context. WP doesn't currently support display context for Widgets or Menus because the UI for it needs a lot of work. All display context UIs I've seen for Widgets are variations on "a bunch of check boxes for every widget".

Replying to ryan:

Ryan, no Woo does not do that, which is what the commenter -  http://www.woothemes.com/2010/02/update-custom-navigation-in-wp-3-0/#comment-30300 - pointed out. He also mentioned a menu plugin that does offer contextualized display -  http://www.ibsteam.net/blog/web-development/simple-sidebar-navigation-plugin-wordpress. The UI is isn't particularly beautiful, though. I think contextualised display is important, even though a lot can be done with CSS/JS, if needed, of course.

Still, always better to get the structure right than merely have a display work around. I think this is an important feature. I can't really speak about the complexity of the required code, or potential performacne issues, but wouldn't this be mostly about the potential parsing of an array of "is_xyv ()" (probably starting with something like 'is_conditional()') conditionals before the inclusion of either the <ul> or the <li> elements of the menu?

As for UI - how about this - have a dropdown for the operator (is, is_not, is_child, is_not_child), another dropdown for the type of condition (page, catgory, taxonomy, tag) and a context-based search field like the post-tag one for the name/ID/slug of the condition. Has all the problems of conditional forms, of course.

Replying to youngmicroserf:

Replying to ryan: Ryan, no Woo does not do that, which is what the commenter -  http://www.woothemes.com/2010/02/update-custom-navigation-in-wp-3-0/#comment-30300 - pointed out. He also mentioned a menu plugin that does offer contextualized display -  http://www.ibsteam.net/blog/web-development/simple-sidebar-navigation-plugin-wordpress. The UI is isn't particularly beautiful, though. I think contextualised display is important, even though a lot can be done with CSS/JS, if needed, of course.

While I like the idea of contextual display, and I have a good idea for how that could be integrated into the system, I have to say that it's a low priority for 3.0. We're focusing on getting the most essential functionality working first in addition to making sure the menu is accessible, before adding things like that into core. I will however keep this in mind for a possible 3.1 inclusion.

As of r13638, the initial menu creation on a fresh install is still a little funky. It doesn't get created when you first load the Menu page; you have to refresh. If you don't know about the refreshing bug and you go create a new menu thinking it's the first one, you'll end up with two as soon as the page reloads.

feature suggestion.

I currently use the woo nav on the canvas theme, and it's lacking an important ability for me.

I am trying to create a button using the custom navigation that has this value: <a class="trigger" rel="Close" href="#">Click here:</a>

Currently there is no way to 'wrap' my url with class and rel attributes.

Would you please consider this addition for those of us who like to play with js?

thnx

#12566

Just trying out the Menu Admin Page. Here are some of my thoughts after just five minutes of playing with menus.

1: Add an existing page should allow for adding individual posts and custom type content and not just pages. 2: Editing a menu item should be more uniform with editing other WP options and not use a pop-up. I believe it should be more like editing widgets with an expandable box. 3: Menu context need to be able to be added as a plugin such a the widget content plugin. 4: There needs to be an inactive menu area like the inactive widget area. 5: All menus should be listed on the page at once to enable dragging of menu items between different menus. 6: when editing a 'page' or 'category' menu item it should not list the url, but a drop down / list of pages / categories. 7: It needs to be clearer what the 'description' does - does it show on site pages, or is it just for admin clarification. 8: Dragging / reordering existing menu items is difficult. 9: There needs to be accessibility mode as there is in the Widget admin area. 10: It should be possible to rename and/or clone a menu.

There's no space between the id and the class which will result in a HTML validation error.

Example:

<li id="menu-item-487"class="menu-item-page">

(In [13694]) Spacing between attributes. Props momo360modena. see #11817

attachment menus_super_nova.diff

What's new?
- Menu name is now editable
- Added support for all public post type and taxonomy menu item types with show_ui == true
- Quick search works on all menu item types
- Removed the default menu creation script
- Menus remembers the last edited menu
- Standardized the nav menu item post_meta keys
- Fixed $menu variable conflict
- AYS confirmation for delete button
- added nonces to all actions
- only custom menu item urls can be editable
- attribute titles are not auto set to the link title
- Removed wp_enqueue_script( 'jquery-ui-dialog' );
- add custom css classes and xfn (rel) support
- clicking on one 'add to menu' button only adds items selected in that list and not all
- metaboxes are drag and droppable
- Fixed bugs in saving menu ordering/positioning
- Changed the 'format' param in wp_nav_menu() to 'container'
- Added a 'container_class' param to add css classes to the container div.
- Moved 'menu_class' class to the ul
- Nav menus will fallback if the menu has no items in wp_nav_menu()
- Menu item caching
- Added filters to wp_nav_menu to hook in more <li>
- Changed 'Save all changes' to 'Save Menu'
- Moved Save Menu/Delete to the top right to make it more accessible.

And as always, refactored the entire menus codebase along with tons of JS optimization. This patch should fix a lot of the tickets related to menus, (e.g. #12544, #12540, #12538, #12470 to name a few.)

Known bugs:
- In nav-menus.php, nested items are broke in Opera. It's broke in trunk too, but I'm working on a patch for this.

Here's a screenshot of attachment menus_super_nova.diff:  http://i41.tinypic.com/2nsx0i.jpg

[13704]

Spelling fix to menu navigation widget when no menus are active

Create is lacking an e at the end of the widget when no menu has been created

(In [13712]) fix spelling/typo in nav menu message, props jorbin, see #11817

In [13712] when selecting the "View All" no scroll bar appears for Add Existing Page widtget. The scroll bar does appear for Existing Posts and Categories widgets.

Also when adding pages as sub-menus, each page becomes a sub-menu of the one listed above rather than maintaining the level as defined by admin (shows as soon as you hit "save menu" button).

Is there a plan to support dropdowns or children in the menu management I'm running the latest build but don't see that feature in...

I know it's not a total requirement but we're in the 21st century it would make sense to have support for dropdowns and children out of the box... thoughts?

@raptor235: This is v1 of the menu feature for core, and we are past feature freeze. At this point, the only thing happening for 3.0 is continuing the effort to bring the feature fully in line with the existing WordPress UI, making an accessible version of the feature, and squashing bugs. Suggestions for additions to the menu system would be better made at  http://wordpress.org/extend/ideas so they can be discussed prior to the determination of features for version 3.1.

That said (which was largely just to put it on record), the menu system allows for submenus, so what you're asking for really just depends on theme support.

(In [13714]) Use get_permalink() instead of get_post_permalink(). Limit to published post types. see #11817 #12566

@jane Thanks for the note jane... is there any documentation on the submenu support? As I mentioned it's not apparent that the feature exists so I guess I"m missing something. Thanks for your help.

No documentation yet since we haven't even finished coding. :-) There will be contextual help soon that will describe how to nest menu items.

The sidebar is pretty long now that posts, pages, cats, tags, etc. are shown. You have to scroll down and then end up with blank space on the left. You can't see the actual menu. We might have to limit to Pages and Categories and make turning on the others require a plugin, at least until we devise a UI that can handle lots of post types and taxonomies.

 http://wpdevel.wordpress.com/2010/03/16/im-kind-of-thrown-by-what-has-turned-u/

(In [13716]) Introduce taxonomies_allowed_in_menus and post_types_allowed_in_menus. Show only pages and categories by default. see #11817

$id = sanitize_title_with_dashes( $post_type->label );
$id = sanitize_title_with_dashes( $tax->label );

should be:

$id = $post_type->name;
$id = $tax-name;

The label changes with translations and does not make a good ID.

Before we get to string freeze, I'd like to suggest that the name 'Menus' would be improved by calling it 'Navigation Menus' instead. On the Widgets screen, the term 'Navigation Menus' is already used and actually refers to what we're calling 'menus' on this screen. Thoughts?

Replying to ryan:

(In [13716]) Introduce taxonomies_allowed_in_menus and post_types_allowed_in_menus. Show only pages and categories by default. see #11817

Sorry, but would it not make sense, or rather be more appropriate to do something similar to Posts/Pages with the Screen Options? Let the user easily decide what they want on show, wanting a plugin to further the menus, I mean, what...? Why have Custom Taxonomy, and Custom Post Type support, can't a plugin do it Jane?

Before we get to string freeze

That's a good thought, though we won't be in string freeze for a while.

Resetting to task. Also, might be a fine idea to close this ticket and open new task and bug tickets on this, as we're up to 300+ comments and its unwieldy to handle at this point.

(In [13719]) Default target to _self. Add some sanitization and gettext. see #11817

(In [13722]) Menu item -> append should be a key/name, not a label. see #11817

(In [13726]) Remove half-baked transient caching of nav-menu source results from [13704]. Todo: reimplement with proper cache invalidation. see #11817

(In [13727]) Unlimited number of pages and custom links for nav-menu. Todo: AJAX-based autocomplete, so this scales better. see #11817

(In [13730]) No need for three separate JS files if they are only ever enqueued together. see #11817

(In [13731]) Fix menu item type labels. see #11817

(In [13732]) Separate update/create menu logic so new menus have name created properly. see #11817

nav_menu taxonomy should be _builtin

(In [13739]) Nav Menus: blur/Focus behavior for Create Menu and Add Custom Links. Route "return" presses in each of those areas to proper button press. Better create/save logic on the PHP side.

(In [13741]) nav_menu taxonomy should be _builtin. props sillybean. see #11817

(In [13742]) Remove JS nav-menu functions that we no longer use. see #11817

(In [13743]) Fix notice for when no menus are located. see #11817

Related #12618

WOW I AM HORRIFIED AT HOW MENUS HAS EVOLVED IN WP.

I have just been digging into the code for menu creating and management for the last 4 hours and cannot believe how convoluted, complicated and WAY over the top it all is. I cannot understand why simple menus require to be linked in with taxonomy, taxonomy relationships etc. I then looked at the number of data options stored in the wp_options DB totally ridiculous, there's something like 15 different entries just for nav_menus.

THE WHOLE MENU CREATION / ADMIN coding needs to be really looked at again with some type of DIRECTION and PATH mapped out. It is really a MESS, with just code piled up on top of each other.

There needs only to be one DB entry for nav_menus and one for nav_menu_items in WP_options thats it. None of this taxonomy linking BS, none of the over the top nav_menu options currently in place.

Each instance of nav_menu should have an id, name, array for items and array for options. Each nav_menu_item should have an id, name, link, type, and array for options.

That is seriously all that is required.

All the BS surrounding custom post types different taxonomy (eg tag, categories) can be handled through an extend-able nav_menu class based on the nav_menu_item type and store the unique options for the type in the nav_menu_item options array.

I am really sorry but the whole situation is making me really angry.

Replying to ceenz:

Each instance of nav_menu should have an id, name, array for items and array for options. Each nav_menu_item should have an id, name, link, type, and array for options. That is seriously all that is required.

I don't think that's true. For starters, the classes that get applied to menu items are heavily dependent on data relationships and pageview context.

All the BS surrounding custom post types different taxonomy (eg tag, categories) can be handled through an extend-able nav_menu class based on the nav_menu_item type and store the unique options for the type in the nav_menu_item options array.

But why? If WordPress is going to offer menu management AND custom post-types and taxonomies, then why would the two not have some sort of "official" relationship?

I am really sorry but the whole situation is making me really angry.

No kidding.

Replying to nathanrice:

Replying to ceenz:

Each instance of nav_menu should have an id, name, array for items and array for options. Each nav_menu_item should have an id, name, link, type, and array for options. That is seriously all that is required.

I don't think that's true. For starters, the classes that get applied to menu items are heavily dependent on data relationships and pageview context.

Menu and menu item classes should be applied at display runtime based on pageview context etc using display menu hook and extenable php class, not stored in DB.

All the BS surrounding custom post types different taxonomy (eg tag, categories) can be handled through an extend-able nav_menu class based on the nav_menu_item type and store the unique options for the type in the nav_menu_item options array.

But why? If WordPress is going to offer menu management AND custom post-types and taxonomies, then why would the two not have some sort of "official" relationship?

Because it is really only adding greater complexity to an already complex system for VERY LITTLE gain. Taxonomy is a descriptor of data (eg type of category for a post). A menu does not describe data in any useful way and therefore should not be stored as taxonomy.

I am really sorry but the whole situation is making me really angry.

No kidding.

:-)

Menu items are stored in the posts table and menus are a taxonomy. Nothing is stored in the options table.

Please don't clutter this ticket any more than it already is. We're not changing the storage schema. You can take this onto the wp-hackers mailing list if you'd like.

Replying to nacin:

Menu items are stored in the posts table and menus are a taxonomy. Nothing is stored in the options table.

The only reason menus are taxonomy is because menu_items are currently stored as posts. Have you had a look at the options table recently?

Please don't clutter this ticket any more than it already is. We're not changing the storage schema. You can take this onto the wp-hackers mailing list if you'd like.

The schema it very poor, thats what I am trying to get at. Please explain how classing a menu_item as a post type helps? And how many of the wp_posts fields actually apply to menu_items? While we're at it we might as well place all widget instances in wp_posts because really the have more right to be there as the often actually have content.

Berate me all you like about whether or not this is the valid forum to air my views, however with development on this issue so intense right now I feel this is the perfect place to discuss something which I feel is of great importance.

Hi ceenz - I don't think Nacin is trying to berate you at all, what he's saying is true: there has been a lot of discussion about this on the wp-hackers list - which would be the most appropriate place to raise this sort of concern.

Let's try and keep this ticket just specifically about the menus component and getting it implemented for 3.0

(In [13748]) Coding standards: When vertically aligning for readability, use spaces (not tabs). see #11817

In SVN 13754 on two different servers it seems that having more then a single entry in a sub menu isn't working.

So if you have a top level menu item and add 3 other items under it, each item becomes a sub menu of the previous item.

When your trying to create:

1

->1.1 ->1.2 ->1.3

You end up with something like:

1

->1.1

-->1.1.1

--->1.1.1.1

This seems to being happening after you save the menu since it looks correct until you do.

attachment menus_awesomesauce_patch.diff

What's new?

• Sub menu items fixed in opera
• Fixed various bugs related to adding custom links
• Add to menu button no longer drops below the list when clicking the "show all" button for better usability.
• Visually show droppable areas
• Namespace nav menu js (wpNavMenu)
• Introduce Walker_Nav_Menu, fixes #12566
• wp_nav_menu() arguments are consistent with other wp_lists_* functions
• Added hooks when a menu is added, deleted, and updated
• Removes taxonomies_allowed_in_menus and post_types_allowed_in_menus filters.
• Enabled screen options and limit the meta boxes to just links, pages, cats for first time use.
• Use get_posts() instead of WP_Query
• Removed WooNav icons
• Hide nav menu post meta from custom fields
• Cleaned out unused post meta keys and such from the db.

Menus should be pretty stable now. I'll be focusing on any last minute bugs that pop up and start working on accessibility #12380. This is my last big patch before beta :)

ignore menus_awesomesauceem_patch.diff, thought menus_awesomesauce_patch.diff had a bug. false alarm :)

Hiding the extra meta boxes in screen options until needed: brilliant. (And consistent.) Latest patch works great with my custom types and taxonomies.

Updated the patch to add some logic for cases when the user's theme doesn't support menus.

The append field was changed so that it uses proper keys based on taxonomy and post types rather than translated strings. The patch changes it back to translated strings. Is the object field now being used in its place? What is append for? It seems fairly useless. We should not be persisting translated strings. Translations can change.

This appears to revert [13722] and [13731], which is no good. Translated strings should not be used as keys.

Replying to ryan:

The append field was changed so that it uses proper keys based on taxonomy and post types rather than translated strings. The patch changes it back to translated strings. Is the object field now being used in its place? What is append for? It seems fairly useless. We should not be persisting translated strings. Translations can change.

Append is used for displaying the object's nice name in the UI. Using keys gives you the machine version of the object name which doesn't display nicely in the UI (e.g. Post Tag and post_tag).

There was code in there to derive the proper label given the menu and object type. Append was a fallback. append should be removed entirely. If the translation changes users will still be stuck with an old name. Plus, it's a nicename which is not good for display. Only because the styling does all caps on it does it look decent.

Displaying nicename is even worse for non Latin alphabets. It will just be a mess of octets.

patch updated to address the translated strings being saved in the db. Append is now generated on the fly.

(In [13802]) Various bug fixes and improvements to menu management. props ptahdunbar, see #11817.