Beware The Sanitized Title Value

One victim of my current project to build my own theme & plugin replacement is the shrewdBar menu. If you are quick, you will still see it at the top of the screen, and if I remember, I will save an example for posterity before I replace it.

I found it to be the best, most flexible, way to build a dynamic navigation structure. I need dynamic navigation to adjust the menu to reflect the changing importance of different pages. More importantly, I need it to present a customized navigation menu for each user.

I experimented with other formats, but nothing was as easy to use, and as easy to recognize as a strip of buttons across the top of the page. WordPress also saw how good this was, and continued to evolve the Admin Menu Bar. I felt this was too good to keep for administrators, and resolved to replace my shrewdBar with the WordPress Admin bar, enhanced by functions to add and remove menu items based on the visitor, and my page priority process.

This is very easy to do, and there are hundreds of websites with articles about amending the Admin bar. The codex page on the add_menu() function is quite clear, and so you probably do not need to read articles about it. In any case, it is deprecated from WordPress version 3.3, to be replaced with the add_node(), and Admin bar is now called Toolbar.

There is additional functionality in add_node() compared to add_menu(), but the function calls for my menu manipulation work just the same, so all you need to change in any example code is to replace add_menu with add_node. Then everything works OK, except it doesn’t.

It might work OK in simple cases, but it is unlikely to work in most practical cases where you want to add a useful menu navigation system for your visitors. I have worked on, and with, menu systems for many years, in many forms. I do not like the approach of many programmers who dictate that they will group links to features as they think fit, and users must learn the right way to access them. The tradition has followed through applications into operating systems and websites. Adding bookmarks, and favorites goes some way to giving users choices, but the hierarchical menu tradition is the default setting for many. The WordPress Toolbar follows this tradition, but I want to offer more choice.

I am a firm believer in a structured approach to website building. It helps visitors, and it helps search engines, to organize topics into sections. A hierarchical menu to access each section and it’s main topics is a must. However, a large website has pages that relate across sections. It has priority pages that I want to draw attention to. I want visitors to be able to access their favorite pages, those of their buddies, and also see recommendations from like-minded people. Most websites do this by creating various tables or menus above, below and at the side of their articles. I want to stick all my navigation links in a menu at the top of the screen. And I want to be able to show pages in more than one menu.

The Perils Of Sanitized Title Value

I do not like hacking around in the WordPress code, and I only look at it as a last resort to try and work out what is wrong. Several WordPress commentators build articles from snippets of WordPress code, to show how easy it is to extend or apply basic functions. They often copy and paste code that is amended from WordPress code, which is a good thing, as it goes back to the heart of open source programming. Whilst I was removing skin from my scalp trying to work out why my multiple menus seemed to be playing random tricks, I looked more closely at the snippets I had copied from a web article about building menus.

Menus are all about creating one root menu with a unique id, then adding sub-menu items in a loop for however many items you want to drop down when the mouse hovers over your root menu entry. It all starts falling apart from thereon, and I wont bore you with the details. Just to say that whatever you read about Admin bar add_menu(), or Toolbar add_node(), ignore what it says about id. The original code was confused between title, id, and defaults for id, and though later versions say id is compulsory, it isn’t, and if you do not specify it properly, your menus will fail to show properly.

The add_menu() function includes the fateful description for id:

“defaults to a sanitized title value”

The id argument, which must be unique, defaults to title if you do not specify it. Title is the wording you see for the menu item. It should be called MenuItemText to differentiate it from the HTML title property but it isn’t. I’ll call it MenuItemText, and I will accept that it should be unique in a single menu list. I might not want it to be, if I have a long list, and I want an important item to appear top and bottom, but I will accept that it has to be. I cannot accept that it has to be unique across the entire Toolbar. If you rely on default settings, even sanitized ones, then you must have unique titles. If you do not, then be sure to specify the id on all child menus. You have to set it on the root menu, so on the child menu, add the root id to the child MenuItemText (called title, remember), and make that the child id.

If you get stuck, ask in the WordPress Functions forum