I’m kind of thrown by what has turned up in menus since I looked at it two days ago. It appears that you can now add everything under the sun to a custom menu. The feature we talked about adding in 3.0 was to support adding pages, categories, and links. As v1 of the feature, I think it’s important we rein ourselves in here. Advanced menu stuff belongs in a plugin, not in core. It could be a core plugin, but having the default menu creator in v1 have that many options (post, page, link, tag, category, media file) is going too far and is outside the scope we all approved. We need a *basic* menu feature that plugins can build on; we should not put the whole kit and caboodle in core. If we want to put out a core plugin to add all the other stuff, I would support that, but for core I think we need to strip it back a little and focus on making it accessible.
Recent comments
newtonsongbird on Suggestions Kim Parsell on Core Contributor Handbook Lance Willett on We’re getting very close… Muhammad Abdi on Core Contributor Handbook Maor Chasen on We’re getting very close…
Crago 4:36 pm on March 16, 2010 Permalink
Terrible idea! Let the menu spread its menu-wings and fly!
scribu 5:03 pm on March 16, 2010 Permalink
I agree that all we need in core, at least for 3.0 is page, category and link menu items.
Ryan 5:14 pm on March 16, 2010 Permalink
A plugin to turn them on would be trivial. Perhaps we can add flags to the post type and taxonomy registration to enable showing them in the menu admin.
Nathan Rice 5:20 pm on March 16, 2010 Permalink
I totally agree. A plugin to support custom post types (which are now a part of core, lest we forget) would be nonsense. However, a flag in the post type creation would be perfectly legitimate, and a much more elegant solution, IMO.
Pulling out perfectly functional features seems like a bad move. It makes no sense.
Ryan 5:27 pm on March 16, 2010 Permalink
I added a couple filters that will allow plugins to turn on other types and taxonomies. Since a registration flag could become obsolete in the future, I thought some dedicated filters would be better.
Peter 6:03 pm on March 16, 2010 Permalink
What is the point of removing the capacity to have a menu of tags, when doing so neither increases nor decreases accessibility, nor does it affect the present subject of concentration.
Having tags as menus actually INCREASES accessibility, because nav menus are more controllable, when it comes to accessibility features, than , for example, tag clouds.
Secondly, post, page, link, tag, category, media file does not equal kit and kaboodle. It adds three extra types of links.
I am concerned that removing elements from something so important, and for which people have waited a long time, will be done without logical reason. And, respectfully, I would say that Jane’s post contains no logical reason, just an appeal to restraint – perhaps on moral grounds?
Peter Westwood 6:22 pm on March 16, 2010 Permalink
We do need to focus on getting the core functionality we agreed on in the dev chats working fully before we add all these extra menu item types and ideally we should only support for 3.0 the core types we discussed.
I have been receiving personal reports that the current functionality is still very alpha in quaility and effort would be best expounded on making the core functionality rock solid than adding loads of extra menu item types.
ocean90 6:24 pm on March 16, 2010 Permalink
I like the last update really. I show it some of my friends and they really like this feature.
I think the Custom Menu is THE eyecatcher of 3.0 and so we should make it as # nice as possible. So that every user can make his own custom menu without searching any plugins to add some things again, then I don’t need the menu and add directly a plugin which can all of this.
It should be easy.
But I like the idea of ryan. +1.
Eventuelly we can add screen options and add checkboxes for the ‘widgets’ and hide for example media on default.
Rich Pedley 6:37 pm on March 16, 2010 Permalink
Surely the default menus system should actually include pages/posts/categories/links/tags because they are bulk standard to a WP install? So to me the current set has one extra that should be removed – that of adding a custom link. That one should IMO be handled via a plugin.
Also please accept my apologies, have been trying to find time for the 2 of us, esmi(from the WP forums) and myself to look at the accessibility side of things and failing miserably as other projects get in the way.
Carl Hancock 6:45 pm on March 16, 2010 Permalink
If you have the ability to add categories to your nav why not include tags? They are both taxonomy. I agree Media is taking things a bit too far and I don’t even use the Link functionality so I don’t find that very useful. But I think an Add Tag menu option would be extremely useful as part of the core.
Carl Hancock 6:47 pm on March 16, 2010 Permalink
Forgot to mention +1 for a flag on custom post types to add a menu option in the menu builder when you add a custom post type. It seems that would round out the custom post type capabilities of 3.0 and make the Menus actually usable with custom post types. As they are now yes you could do custom post types, but your nav would have to be all manually done using links which would be a pain.
Idealien 8:14 pm on March 16, 2010 Permalink
I agree. While 3.0 might happen to numerically be “just the next release” from 2.9, the opportunity to bring a combination of significant new features to core (UI for custom post types and dynamic built menus that support them) is worth shooting for with this symbolic major version release.
Peter 6:49 pm on March 16, 2010 Permalink
I think too that removing tags is, to be frank, absurd. It assumes that, in the use of wordpress, categories occupy a position of greater importance when navigating a blog, than tags. And that is not true. Adding media files is, I agree, unnecessary.
Ryan 7:10 pm on March 16, 2010 Permalink
With just Pages, Categories, and Custom Links the screen is already scrolling, especially once you click View All. If we add more things we have to solve that.
Categories are the correct taxonomy for menus. Almost all themes use Categories for menu purposes. Using tags in the menus is a bit of a misuse, technically. Of course, everyone has their favorite means of using taxonomy, with many not using Categories at all. I personally would like to have Tags present, but the underlying UI issue would have to be addressed. The scrolling makes for very bad UI. You can’t the see menu when you click Add to Menu. After clicking, all you see is the selections in the checklist clear. There is absolutely no useful feedback when you are scrolled.
Keep in mind that Custom Links allow linking to anything. Tag menu items can be added as custom links.
Carl Hancock 7:15 pm on March 16, 2010 Permalink
Make the add menu boxes collapsable like sidebars in the Widget editor. Then just open the first one. A user can expand/collapse the others as needed. This would leave plenty of room to include Tags, which are core to WordPress and users ARE going to want to add tags to their menus. Sure you can add anything you want with the Custom Links functionality, but shouldn’t it at least cover the core WordPress features of posts, pages, categories and tags and then leave the rest to Custom Links or plugins?
Ryan 7:29 pm on March 16, 2010 Permalink
They are collapse-able. They can also be made hide-able. It’s still bad UI once you show those things though. If we allow displaying those things we need to have a UI that can handle them.
Tags seem to be the main point of contention. I would like to have them in there, but we need to figure a way to eliminate the scrolling. Moving Create Menu and Menu Settings out of the sidebar might help. “Delete Menu” and “Save Menu” could move back below the menu. Menu name editing could be exposed on the menu bar on hover like we do with the dashboard boxes.
Carl Hancock 7:39 pm on March 16, 2010 Permalink
Remove menu settings. Move the menu title to above the menu itself just like where you edit a Post/Page Title in the post editor. Then put the save link below the menu again instead of on the right sidebar.
Remove the “Create Menu” box. Place an “Add New” button to the right of the Menus page title that then creates a new menu… name it and save it. Make the name required.
That frees up space for Tags on the right side by eliminating two of the existing boxes. At that point the only thing that would appear on the right side are the “Add…” toolboxes. Leaving space for Tags and hooks to allow additional boxes to be added (Custom Post Types, etc.).
Nathan Rice 7:33 pm on March 16, 2010 Permalink
What screen resolution is assumed for UI purposes? On my netbook, I’d be willing to bet there’s going to be scrolling no matter what you guys do
But I don’t necessarily think that’s a problem, since netbooks aren’t the norm.
Carl Hancock 7:55 pm on March 16, 2010 Permalink
I put together a quick mock up that shows what I described in a comment above as far as re-arranging stuff to free up space on the right sidebar so that it is strictly the “Add” toolbox area. It’s obviously just thrown together quickly.
View it here:
http://www.twitpic.com/18zl8j
Carl Hancock 7:56 pm on March 16, 2010 Permalink
Forgot to mention, the “Add Existing…” seems redundant. It could probably just be “Add Page”, “Add Category”, etc. Add Custom Link doesn’t use that terminology despite the fact whatever you are linking to obviously already exists.
Idealien 8:01 pm on March 16, 2010 Permalink
I agree “Add Existing…” is redundant, but “Add Category” gives the impression it (might) add a new category to the db. What about “Add [Item] to menu” as the title and then a consistent ‘Add’ button across all of the entry boxes?
Ryan 7:57 pm on March 16, 2010 Permalink
That looks good to me, regardless of the scrolling issue. I like having the sidebar be exclusively for adding menu items. I’m just the code monkey though, and will leave further discussion to you UI/UX folks.
Mark McWilliams 8:10 pm on March 16, 2010 Permalink
I was thinking, do we really need the ability to alter the Menu Name? Am I not right in thinking that a theme author could register a menu in the functions.php file to work with their particular theme? – If the user ended up changing that, wouldn’t it mess with the theme? (Maybe unrelated yes, but while I’m here!)
Carl Hancock 8:27 pm on March 16, 2010 Permalink
Not having a way to edit the name and having it basically set in stone would be obnoxious from a usability standpoint IMO. Can menus be called via id instead of name on the front end? If so call the menu by the id and then it doesn’t matter what the name is.
Mark McWilliams 1:32 am on March 17, 2010 Permalink
OK I’ve obviously not tested it out, but I’d take a guess and say that registering a menu in the functions.php file isn’t going to work well just by giving it an ID…? Yes they can be called on the front end via an ID, maybe it’s just a personal thing!
On the other hand though, to alter a Custom Taxonomy or a Custom Post Type, we’d have to alter the plugin or functions.php file itself, kind of a swings and roundabout situation here!
djeckhart 8:25 pm on March 16, 2010 Permalink
Agree that “Media Files” could go. The rest, particularly support for post types, is/should be core functionality.
ceenz 11:14 pm on March 16, 2010 Permalink
All the ‘add existing…’ boxes on the right side of the menu admin page make no sense. Why not just have one for existing items and have a drop down for the type you want to add.
EG:
[Add Existing Content Title]
Type: [Drop Down of Types Available]
[Search Box] [Search Button]
[View All Link]
Ptah Dunbar 7:56 am on March 17, 2010 Permalink
@jane, I sent you an email re: menus last week or so asking for UI advice, but haven’t heard back so I just went with what felt right. Here’s some of my reasoning.
The save/delete button being at the button isn’t the best location as users will have to scroll all the way down to save when their menus become long. So I added them to the sidebar along with the ability to edit the name.
The ability to support any post type/taxonomy was not me drifting away from bug fixing to adding features, but it was actually an added benefit while I was cleaning up the menu codebase to make the menu item types more abstract so plugin authors can add their own stuff. Based on the way the menu system works, adding additional menu item types would require the plugin author to create their own meta box along with the some js which is not WP standard. Before the last patch, they couldn’t even do that. So I added support for all types under the hood so I don’t mind the UI being limited to just pages and cats. The code is their to support any type so plugin authors only need to modify a filter and boom, it’s there.
Also, instead of the filters, a better approach would be to just enable the pages and cats metaboxes to be ON by default while the other types are hidden and just a checkbox away in the screen options. win win?
Right now, I’m focusing on fixing the saving/positioning bugs and making the core functionality solid. All my patches up until now were working towards this. But bug fighting is a combination of js and cross browser issues so I just have to do more testing with different browsers and such.
Menus needs a combination of UI and bug fixing work. I can do the bug fixing part, but I’d very much like to get some explicit direction from you regarding the UI and what needs to happen. I’m just a code wrangler with aspiring UX/UI skills
Frank 12:01 pm on March 17, 2010 Permalink
Thanks Jane,
please give WP not s much features, please more features in core-plugins (my benefit to Core plugins). To many features in a new version ,in the core, this is a ko for the users, not realy good for WordPress.
Stephen R 12:23 pm on March 17, 2010 Permalink
As a matter of general principle, I’m with Jane on this one. Best to show a bit of restraint than to cram the UI on the first iteration. You can always add later if the need is there, but it’s troublesome to remove things later…..
dd32 12:31 pm on March 17, 2010 Permalink
I’d just like to back up the choices made during the development of the menu’s a bit.
While Custom Post type and Custom taxonomy was not an agree’d part of the spec, Leaving them out is actually an increased amount of work, leaving them out doesnt make the functionality any easier to implement.
The obvious reason to this is, that Posts and Pages are just post_types, Categories are just Taxonomies. Since WordPress offers such decent API’s, it makes it possible to use the Internal API’s and mearly create a generic post_type and generic Taxonomy functionality, and loop over it.
Since this post has been written, I’m pretty certain that the functionality was extended further, so that post_type’s and custom taxonomies have to register a flag during registration to allow them to appear in the menu editor. (A Screen option would’ve been another option there, but not all objects are menu-usable anyway)
For everyone else just stumbling across this post now, The menu editor as of this comment, only displays “Custom Links”, Pages and Categories by default.
Hold your horses, it’s alpha software. - Ptah Dunbar - Web Craftsman, WordPress hacker and Entrepreneur. 2:50 pm on March 17, 2010 Permalink
[...] story short, after one of my patches got committed, Jane Wells posted her thoughts on it’s current in-development state along with comments pretty much [...]
ceenz 1:48 am on March 18, 2010 Permalink
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.
Peter Westwood 8:39 pm on March 25, 2010 Permalink
I’m not sure how storing everything is big serialised arrays really helps.
There are a number of issues with doing it that way including the fragility of the php serialisation format with International characters in the strings and the issues around caching and interactivity if more than one person edits a menu structure which make it a sub optimal solution.