#11817 closed task (blessed) (fixed)
Better Site Menu Management
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 3.0 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Menus | Keywords: | has-patch |
Focuses: | Cc: |
Description
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.
Attachments (39)
Change History (397)
#3
@
15 years ago
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.
#5
in reply to:
↑ 4
@
15 years ago
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.
#8
@
15 years ago
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().
#9
follow-up:
↓ 12
@
15 years ago
+1 to Appearance > Menu.
I can weigh in on UI to make it consistent with other screens, or wireframe it first if needed.
#10
@
15 years ago
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.
#12
in reply to:
↑ 9
@
15 years ago
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.
#14
@
15 years ago
I've attached my nav menus plugin in case there is interest to fetch part or all of the ideas in it.
#16
follow-up:
↓ 20
@
15 years ago
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 :)
#17
follow-ups:
↓ 18
↓ 22
@
15 years ago
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?
#18
in reply to:
↑ 17
@
15 years ago
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.
#20
in reply to:
↑ 16
;
follow-up:
↓ 21
@
15 years ago
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.
#21
in reply to:
↑ 20
@
15 years ago
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.
#22
in reply to:
↑ 17
@
15 years ago
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:
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.
#23
@
15 years ago
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.
#24
@
15 years ago
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.
#25
@
15 years ago
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!).
#26
@
15 years ago
menus.2.diff has a working menu admin (the items are saved properly)
Also replaced 'menu_item' with 'menu-item' where appropriate.
#27
@
15 years ago
- Cc ptahdunbar added
register_menus() is just a wrapper for register_menu() which just creates multiple menus based off the same $args? Is that functionality even necessary?
#28
@
15 years ago
I don't know; it doesn't hurt being there, though.
The patch still requires a lot of cleaning.
#29
@
15 years ago
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.
#30
@
15 years ago
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.
#32
in reply to:
↑ 1
;
follow-up:
↓ 33
@
15 years ago
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.
#33
in reply to:
↑ 32
@
15 years ago
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.
#34
@
15 years ago
<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.
#35
@
15 years ago
You can see a preview of the current patch here:
http://wpdevel.wordpress.com/2010/01/17/menu-management-ui/
#36
@
15 years ago
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.
#37
@
15 years ago
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.
#38
@
15 years ago
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.
#39
@
15 years ago
scribu: could you explain the difference between "Special Menu Items" and "Available Menu Items"?
#40
@
15 years ago
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.
#41
@
15 years ago
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.
#43
@
15 years ago
- Summary changed from Better Menu Management to Better Site Menu Management
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. :)
#44
@
15 years ago
- 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)
#45
@
15 years ago
Screenshot.png for menus.4.diff
#47
@
15 years ago
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.
#49
@
15 years ago
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?
#50
follow-up:
↓ 58
@
15 years ago
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.
#51
follow-up:
↓ 52
@
15 years ago
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.
#52
in reply to:
↑ 51
@
15 years ago
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.
#53
@
15 years ago
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?
#54
follow-up:
↓ 59
@
15 years ago
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
#55
@
15 years ago
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".
#56
@
15 years ago
That would imply that we support hierarchical menus.
Either that, or we only auto-add first-level pages.
#58
in reply to:
↑ 50
@
15 years ago
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.
#59
in reply to:
↑ 54
@
15 years ago
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.
#60
@
15 years ago
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.
#61
in reply to:
↑ 1
@
15 years ago
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!
#62
follow-up:
↓ 63
@
15 years ago
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?
#63
in reply to:
↑ 62
@
15 years ago
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...
#64
@
15 years ago
An interesting take on the menu admin from Woo Themes:
http://www.woothemes.com/2010/01/the-awesome-custom-woo-navigation/
#65
@
15 years ago
@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.
#66
@
15 years ago
- Keywords has-patch added
demetris, try menus.5.diff (it's diffed against r12883).
#67
@
15 years ago
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.
#68
@
15 years ago
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.
#70
@
15 years ago
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.
#71
@
15 years ago
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.
#74
@
15 years ago
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.
#75
in reply to:
↑ 73
@
15 years ago
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.
#76
@
15 years ago
+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.
#77
@
15 years ago
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.
#78
@
15 years ago
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.
#79
follow-up:
↓ 82
@
15 years ago
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.
#80
@
15 years ago
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.
#81
@
15 years ago
- 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.
#82
in reply to:
↑ 79
;
follow-up:
↓ 83
@
15 years ago
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.
#83
in reply to:
↑ 82
@
15 years ago
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.
#84
@
15 years ago
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.
#85
@
15 years ago
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.
#86
@
15 years ago
- Cc ev3rywh3re added
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.
#87
@
15 years ago
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 :).
#88
@
15 years ago
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.
#89
@
15 years ago
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.
#90
follow-up:
↓ 92
@
15 years ago
@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.
#92
in reply to:
↑ 90
@
15 years ago
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.
#94
@
15 years ago
The zip contains a diff and images. The diff is too large to upload separately, alas.
#95
@
15 years ago
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.
#96
@
15 years ago
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.
#97
@
15 years ago
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;
#98
follow-up:
↓ 99
@
15 years ago
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.
#99
in reply to:
↑ 98
@
15 years ago
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.
#100
follow-up:
↓ 101
@
15 years ago
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.
#101
in reply to:
↑ 100
;
follow-up:
↓ 102
@
15 years ago
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.
#102
in reply to:
↑ 101
;
follow-up:
↓ 103
@
15 years ago
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.
#103
in reply to:
↑ 102
;
follow-up:
↓ 104
@
15 years ago
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 :-)
#104
in reply to:
↑ 103
@
15 years ago
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.
#107
@
15 years ago
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
#108
@
15 years ago
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.
#111
@
15 years ago
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().
#112
@
15 years ago
Should the taxonomy be registered for post_type of 'post'? Shouldn't it register for 'menu_item'?
#114
follow-up:
↓ 115
@
15 years ago
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.
#115
in reply to:
↑ 114
@
15 years ago
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.
#120
@
15 years ago
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 :-)
#125
@
15 years ago
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.
#126
@
15 years ago
@nathanrice - When I was reworking the code I thought the same on switching to metaboxes. Patches would be welcomed :)
That schema works for me.
#127
@
15 years ago
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.
#128
@
15 years ago
Did anyone update and try this out? Whenever I add multiple items to the nav bar, only 1 of them is being saved.
#129
@
15 years ago
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..
#133
@
15 years ago
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.
#134
@
15 years ago
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.
#135
@
15 years ago
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.
#137
@
15 years ago
That's getting in the range where some work could start on the output to the front of the site.
#138
@
15 years ago
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>
#145
@
15 years ago
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! :)
#147
@
15 years ago
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.
#149
@
15 years ago
It follows "Custom Header" and "Custom Background". Personally, I wouldn't mind dropping the Custom.
#150
@
15 years ago
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.
#153
follow-up:
↓ 157
@
15 years ago
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?
#157
in reply to:
↑ 153
@
15 years ago
+1 on dropping custom "Custom" and and using the "Menus" terminology.
#160
@
15 years ago
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.
#163
@
15 years ago
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.
#167
@
15 years ago
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.
#171
@
15 years ago
Found a bug
If the Page has " in its name it is not working I have a page called: The "Other" Stuff
#173
@
15 years ago
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.
#174
@
15 years ago
@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.
#176
@
15 years ago
- Cc junsuijin@… added
Created ticket #12339 a bit ago. I'll be sure to post future patches in this ticket :)
#182
@
15 years ago
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.
#187
follow-up:
↓ 190
@
15 years ago
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.
#188
@
15 years ago
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
#189
@
15 years ago
really impressed with whats been done here since I last checked. Seems to be moving pretty fast!
#190
in reply to:
↑ 187
;
follow-up:
↓ 191
@
15 years ago
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.
#191
in reply to:
↑ 190
@
15 years ago
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.
#192
@
15 years ago
Updated cleanup patch (see above). Also fixes the encoding issues reported above -- htmlentities breaks non-ASCII strings.
#195
@
15 years ago
- Cc ocean90 added
@nbachiyski
Thx for cleanup. On my little cleanup I add a missing </form> tag. I miss it on your patch, or?
#198
@
15 years ago
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.
#200
@
15 years ago
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.
#202
@
15 years ago
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).
@
15 years ago
Design for Menus preserving original structure but using standard WP admin interface elements.
#203
@
15 years ago
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?
#205
@
15 years ago
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.
@
15 years ago
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).
#208
@
15 years ago
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.
#209
@
15 years ago
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.
#210
@
15 years ago
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.
#211
@
15 years ago
@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.
@
15 years ago
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)
#213
@
15 years ago
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.
#214
@
15 years ago
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/
#215
@
15 years ago
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.
#216
follow-up:
↓ 217
@
15 years ago
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?
#217
in reply to:
↑ 216
@
15 years ago
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.
#220
follow-up:
↓ 221
@
15 years ago
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.
#221
in reply to:
↑ 220
@
15 years ago
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
andrel
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
#224
@
15 years ago
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.
#225
follow-ups:
↓ 226
↓ 227
@
15 years ago
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.
#226
in reply to:
↑ 225
@
15 years ago
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
#227
in reply to:
↑ 225
@
15 years ago
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.
#228
@
15 years ago
@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.
#229
follow-up:
↓ 233
@
15 years ago
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.
#230
@
15 years ago
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.
@
15 years ago
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)
#231
follow-up:
↓ 232
@
15 years ago
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]]
#232
in reply to:
↑ 231
;
follow-up:
↓ 235
@
15 years ago
Replying to ptahdunbar:
New Screenshots:
http://i47.tinypic.com/22yg44.jpg
http://i49.tinypic.com/167nk9l.jpg
http://i46.tinypic.com/2a8lpmx.jpg
oops.
#233
in reply to:
↑ 229
@
15 years ago
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.
#234
@
15 years ago
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".
#235
in reply to:
↑ 232
@
15 years ago
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.
#236
@
15 years ago
@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.
#237
@
15 years ago
We should add some caps for menu management: edit_menus and delete_menus for starters.
#239
follow-up:
↓ 241
@
15 years ago
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.
#240
@
15 years ago
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?
#241
in reply to:
↑ 239
@
15 years ago
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? :)
#243
@
15 years ago
If you add a menu item and change your mind, you have to save the menu before the item can be removed.
#245
follow-ups:
↓ 246
↓ 275
@
15 years ago
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.
#246
in reply to:
↑ 245
@
15 years ago
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.
#247
follow-up:
↓ 248
@
15 years ago
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.
#248
in reply to:
↑ 247
;
follow-up:
↓ 264
@
15 years ago
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.
#249
@
15 years ago
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.
#250
@
15 years ago
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?
#251
follow-up:
↓ 253
@
15 years ago
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.
#252
@
15 years ago
The URL for Pages and Categories should not be editable. Instead we should show what Page/Category the menu item is linked to.
#253
in reply to:
↑ 251
@
15 years ago
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?
#254
@
15 years ago
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.
#255
follow-up:
↓ 256
@
15 years ago
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
#256
in reply to:
↑ 255
@
15 years ago
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.
#259
@
15 years ago
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?
#260
@
15 years ago
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.
#261
follow-up:
↓ 263
@
15 years ago
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).
#263
in reply to:
↑ 261
@
15 years ago
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
#264
in reply to:
↑ 248
@
15 years ago
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.
#265
follow-up:
↓ 266
@
15 years ago
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.
#266
in reply to:
↑ 265
@
15 years ago
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!
#267
follow-up:
↓ 268
@
15 years ago
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.
#268
in reply to:
↑ 267
;
follow-up:
↓ 269
@
15 years ago
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.
@
15 years ago
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!
#269
in reply to:
↑ 268
@
15 years ago
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.
#271
@
15 years ago
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).
#275
in reply to:
↑ 245
;
follow-up:
↓ 276
@
15 years ago
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
#276
in reply to:
↑ 275
;
follow-up:
↓ 277
@
15 years ago
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 nameBut, calling a menu by ID does work?
wp_nav_menu( array( 'menu' => '100' ) ); // By ID
Try the patch attached above.
#277
in reply to:
↑ 276
@
15 years ago
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()
.
#282
@
15 years ago
@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.
#284
in reply to:
↑ 283
@
15 years ago
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().
#285
follow-up:
↓ 286
@
15 years ago
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.
#286
in reply to:
↑ 285
@
15 years ago
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.
#287
follow-up:
↓ 288
@
15 years ago
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)
#288
in reply to:
↑ 287
@
15 years ago
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();
#290
follow-up:
↓ 292
@
15 years ago
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.
#291
@
15 years ago
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?
#292
in reply to:
↑ 290
;
follow-up:
↓ 293
@
15 years ago
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".
#293
in reply to:
↑ 292
;
follow-up:
↓ 294
@
15 years ago
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.
#294
in reply to:
↑ 293
@
15 years ago
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.
#295
@
15 years ago
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.
#296
@
15 years ago
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
#298
@
15 years ago
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.
#299
@
15 years ago
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">
#301
@
15 years ago
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.
#302
@
15 years ago
Here's a screenshot of attachment menus_super_nova.diff: http://i41.tinypic.com/2nsx0i.jpg
#304
@
15 years ago
- Cc aaron@… added
Create is lacking an e at the end of the widget when no menu has been created
#306
@
15 years ago
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).
#307
@
15 years ago
- Type changed from task (blessed) to enhancement
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?
#308
@
15 years ago
@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.
#310
@
15 years ago
@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.
#311
@
15 years ago
No documentation yet since we haven't even finished coding. :-) There will be contextual help soon that will describe how to nest menu items.
#312
@
15 years ago
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.
#315
@
15 years ago
$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.
#316
@
15 years ago
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?
#317
in reply to:
↑ 314
@
15 years ago
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?
#318
@
15 years ago
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.
#326
@
15 years ago
(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.
#331
follow-up:
↓ 332
@
15 years ago
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.
#332
in reply to:
↑ 331
;
follow-up:
↓ 333
@
15 years ago
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.
#333
in reply to:
↑ 332
@
15 years ago
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.
:-)
#334
follow-up:
↓ 335
@
15 years ago
- Component changed from General to Menus
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.
#335
in reply to:
↑ 334
@
15 years ago
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.
#336
@
15 years ago
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
#339
@
15 years ago
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.
#340
@
15 years ago
- Owner set to ptahdunbar
- Status changed from reopened to accepted
- Type changed from enhancement to task (blessed)
#341
@
15 years ago
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 :)
#342
@
15 years ago
ignore menus_awesomesauceem_patch.diff, thought menus_awesomesauce_patch.diff had a bug. false alarm :)
#343
@
15 years ago
Hiding the extra meta boxes in screen options until needed: brilliant. (And consistent.) Latest patch works great with my custom types and taxonomies.
#344
@
15 years ago
Updated the patch to add some logic for cases when the user's theme doesn't support menus.
#345
follow-up:
↓ 347
@
15 years ago
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.
#347
in reply to:
↑ 345
@
15 years ago
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).
#348
@
15 years ago
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.
#349
@
15 years ago
Displaying nicename is even worse for non Latin alphabets. It will just be a mess of octets.
@
15 years ago
patch updated to address the translated strings being saved in the db. Append is now generated on the fly.
#353
@
15 years ago
The last updates broke the menu page. It does not even completely load and menus can no longer be created or edited. Please refer to the following post for details:
http://wordpress.org/support/topic/379231?replies=4
I'm thinking of a new admin page under Appearance -> Menu:
On one side, we would have 3 dropdowns (?):
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.