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

Whilst the best solution would be to delve into the NicEdit code, and change the parts that present problems, I have found workarounds that mean I can get by without this for now.

In fact, I am not certain if this is truly a NicEdit issue, or the way WordPress builds it’s comments forms. I’ll leave the strict coding debate until I’ve fully investigated why it works in FireFox but not in MicroSoft Internet Explorer (MSIE).

In my first investigation I explained how wrapping elements in HTML Paragraph tags will break NicEdit under MSIE. The symptom is a small disabled NicEdit toolbar that renders it useless. I explained in that article about modifying the comments.php to remove the paragraph tags (or change them to DIV tags) re-enabled NicEdit. However, WordPress 3 has changed the way the comments form is built.

The good news is that there is no need to hack the WordPress core that serves the form. All that is needed is a simple change to the way the comments form is called in your theme.

Restore NicEdit As Your MSIE WordPress WYSIWYG Editor

If you are using a pre-WordPress 3 theme, your comments form is built directly in comments.php. Current themes replace many lines of code with a simple call to a new function – comment_form().

This is much tidier, but the default settings are very NicEdit unfriendly. Not only does it retain the MSIE-breaking paragraph tags, but default width settings do not get passed to MSIE at the toolbar rendering stage.

Additionally, the default form displays the allowed HTML tags. This is something very dear to my heart in a normal comments textarea. Visitors should be told which tags are allowed to save those frustrating times when you type a long and interesting comment, only to see it posted as garbled rubbish because the pre or code tags are not allowed. With NicEdit, such vital information is unnecessary, as the tags are all processed before the code is saved, and you can even configure which buttons are available.

So how do we get the comments form to display NicEdit properly?

The call to comment_form() is near the end of comments.php in the theme editor area. If you are not happy with editing themes, get in touch with the theme author and ask them to add comment form parameters in the theme options. Or if the theme is not supported, then let me know, and I’ll produce a NicEdit enabled version of it.

If you cannot find comment_form() then chances are that you have an older theme, in which case search for the textarea line, and adapt the following.

The comment_form() function allows most aspects of the comment form to be changed by passing an array of parameters. More details are in the WordPress codex, but all you need to do is paste the following between the brackets() of the comment_form function:

array('comment_field'=>'<div class="comment-form-comment"><label for="comment">' . _x( 'Comment', 'noun' ) . '</label><textarea id="comment" name="comment" style="width:350px" rows="8" aria-required="true"></textarea></div>','comment_notes_after'  => 'Thank you.')

This simply changes 2 settings, comment_field and comment_notes_after by slightly changing the default WordPress code. I’ve cheated a little by including an inline style statement – my site is about getting things done quickly, and then we can argue with the purists to find more elegantly coded solutions. The important thing is that the following 3 NicEdit defeating issues are overcome:

1. p is replaced with div to prevent MSIE “Unknown runtime error Line: 8 Char: 721″
2. cols=”45″ is replaced with a width setting. Alternatively, you could probably set this in the style sheet, but I have not tested this.
3. The allowed tags are replaced with a simple ‘Thank you’ message. You could change this to something else, or just the quotes to remove it entirely.

Change Defaults To Make NicEdit Your Best WordPress WYSIWYG Editor

In my previous article I explained the quick way to enable NicEdit to be your editor for WordPress comments or Question2Answer questions, answers and comments. Posting the default code certainly works, but you are at risk of losing the editor if the NicEdit site is unavailable.

The first thing you should do is copy NicEdit to your own server, and amend the first NicEdit line in your header.php to:

<script src="path-to-your-nicedit/nicEdit.js" type="text/javascript"></script>

If you like to keep images in a separate folder from js files, you will also need to change the NicEdit defaults. You will probably need to do this anyway to change the default buttons and add extra features. So, amend the second NicEdit line to:

<script type="text/javascript">bkLib.onDomLoaded(function() {nicEditors.allTextAreas({iconsPath : 'path-to-your-nicedit/nicEditorIcons.gif'})});</script>

In this instance we are only changing the iconsPath, but any nicEdit parameters can be amended in a comma separated list.

If you’ve implemented these improvements and still have unresolved issues, please let me know below. As I mentioned earlier, I will soon publish complete step-by-step guides for NicEdit enabling Question2Answer and WordPress, combined and in isolation. I’d appreciate your help in making it as complete as possible by clarifying any issues you may still have.

I’ve switched between NicEdit and TinyMCE for a few months. I like the simplicity of NicEdit, and had it working nicely on WordPress sites.

Then all sorts of weirdness started happening when I tried the beta of Q2A on a development site. I’d taken what I thought were sensible precautions. The site in question was new and had no visitors. I prefer to experiment with this sort of site if possible, as running development sites under localhost on my PC is not always a good representation of the real world. I had an absolute nightmare with this, and suspected all the new stuff I was trying out (beta Q2A and beta WordPress 3.0!)

Turned out it was nothing to do with the beta software, and everything to do with lousy server configuration backed up by lousy tech support from Bl** Host.

In the process of trying to get back to something that worked, I tried different settings on this site. I didn’t realize that I’d left WYSIWYG turned off here until vince told me.

For now, I’ve left tinyMCE alone. It looked like a good solution, but there are a whole bunch of formatting issues, so I’ve decided to focus on NicEdit.

I use it to make WordPress commenting better, and for Q2A. Within those setups (either of Q2A, WP, or both) there are installation and configuration options, so I’ll try to cover all the permutations.

Preparing Q2A

Q2A strips out any html code from multi-line text, so we have to tweak it. If you are uncomfortable with tweaking code, raise the issue on the Q2A site, and ask for an Admin option to disable it.

We have to edit the qa_html() function in qa-base.php, which sits in the qa-include folder. Find (Ctrl-F) qa_html, and you should see lines similar to those below. They change $html, but we want it to stay as entered. I simply comment out the string manipulation, and set the return value to the string that was passed in:
if ($multiline) {
// $html=preg_replace('/\r\n?/', "\n", $html);
// $html=preg_replace('/(?<=\s) /', ' ', $html);
// $html=str_replace("\t", '    ', $html);
// $html=nl2br($html);
$html=$string;
}


If you do not do this, NicEdit will still work, but the HTML tags will get stripped before your questions, answers, or comments get saved.

This change will need to be reapplied whenever you upgrade or reinstall Q2A.

WYSIWYG Question2Answer

The simplest implementation is to copy the from NicEdit front page:

<script src="http://js.nicedit.com/nicEdit-latest.js" type="text/javascript"></script>
<script type="text/javascript">bkLib.onDomLoaded(nicEditors.allTextAreas);</script>

Then paste it into the Question2Answer Admin area. All you do is go to the Layout settings, and paste the above code into the 'Custom HTML in <HEAD> section of every page:' and save the settings.

You should see that all your multi-line text boxes have a WYSIWYG display with edit buttons across the top. The buttons are disabled until you click into the textarea.

Now check that NicEdit works OK on your question, answer and comment boxes. The easiest way is to edit existing items.

This has worked successfully every time I have tried it, but there may be some formatting issues on some browsers. I will cover these in my next article.

WordPress Default WYSIWYG Editor

For most of my sites, I want both WYSIWYG for Question2Answer and for WordPress. I always wrap my Q2A theme inside the WordPress theme, so it makes sense to apply NicEdit to the WordPress header. In this setup, you do not have to also apply it to NicEdit, unless you want different editor configurations in each area.

So to make NicEdit the WordPress Default WYSIWYG Editor and also apply it to Question2Answer, simply post the NicEdit code into header.php within the HEAD tags. This also applies if you just use WordPress without Question2Answer.

Test your comments both at the article level, and (if you use threaded comments) the reply to comment level. NicEdit should work nicely, but there may be issues in some browsers. You really need to try as many browsers as possible, but certainly common ones that your visitors use. See your server logs or analytics program - Google Analytics is very good - to get a list of browsers that your visitors use.

In my next article, I will look at some of the issues that WordPress themes can cause, especially with MSIE. I'll explain how to overcome these issues, and approaches to investigating problems. I will also explain how to avoid the pitfalls associated with simply pasting the NicEdit code from their site. You will see how to create the best WordPress WYSIWYG editor.

You might notice that I do not use the NicEdit/WordPress default WYSIWYG editor that I have described on this site. That is because I intend to move all the interactive features to a separate site, and add more discussion and feedback tools. When I've done that, I will produce a complete step-by-step guide for integrating NicEdit and Question2Answer under a WordPress theme.

Let me know if you want to see it in action before you commit to these changes, and I will show you sites where it works so that you can see the improved front end.

You seem disappointed that the next version is where the real promotion potential lies, but the good news is that you do not need to wait.

If you have downloaded and activated Happiness Today, then you already have a tool for displaying random (or selected) promotion messages in your WordPress posts, pages or sidebar.

The main appeal of Pods is the way it makes extending the WordPress database so easy. But stored data is of little use if you cannot present it to your visitors. My first release of Happiness Today was just to prove that, like Hello Dolly does for standard WordPress, it is very easy to build a basic plugin. That basic plugin instantly demonstrates how Pods stores and displays data. In keeping with the Hello Dolly tradition, I displayed random lyrics in the Admin area – but the real life potential was always to be able to produce something simple yet useful, that can display random promotion messages to visitors.

Those promotional features are included in the current release, just not obvious. Here’s how to use Pods inbuilt features to get more from the Happiness Today plugin. Start your marketing campaign now.

WordPress Pods Presentation Features

In the plugin, I present the messages via a Pods template that is called whenever an admin page loads. That template adds formatting to match the admin color scheme, and configurable link buttons. I also present the full set of lyrics on the happiness_today information page using a very simple template that adds nothing but a line break.

Pods output is not restricted to templates that can be as simple or as complex as you need them. Neither is it restricted to Pods pages such as the example mentioned, where you can build a page similar to a WordPress page, but with easy access to your data. You can also include Pods output in regular WordPress posts and pages with a simple shortcode call. Like this:

Think of happiness today
All is one in their own way

That is a simple Pods shortcode wrapped in blockquote tags, but you are only limited by your imagination, and css talents. How about:

In this second example, I’ve set the limit to two records. Note that records are called randomly, but I have included the chorus several times, so that will appear more frequently – just refresh your browser to see the random effect.

All you need to do is add the following shortcode to your post, page or text widget:

[pods name="happiness_today_text" order="RAND()" limit="1" template="happiness_today_list"]

WordPress Plugin Promotion Tool: Next Steps

All the data in the Happiness Today plugin is easily edited using the Pods data table editing features. In my example, I use couplets from the Think Of Happiness Today lyrics. Though I limit the example text to two lines so that it displays in the admin area properly, you can use any HTML text you like. The Pods WYSIWYG editor allows the usual formatting including hyperlinks, or direct entry of HTML code.

Using Happiness Today for longer visitor messages might make your admin area a little cluttered. No problem – simply deactivate Happiness Today – the data management and presentation features that I have discussed here are all part of standard Pods, and will work fine.

In future versions, I’ll add the ability to import and export different campaign text sets, with other options to make life even easier than it is with the basic release. But you do not need to wait – the current release can be used for any promotion campaign you can think of, including random advertising. In fact, it does not even need to be random, for instance specific records can be called on specific posts. The only limit is your imagination.

It is also vital to have a clear plan of the presentation outcomes that you need.

When describing the data aspect of my first plugin, I wrote of the importance of thoroughly analyzing the relationship between the presentation of content required, and the structure of data needed to support it. Recently, I saw a question on the Pods Support Forum that seemed to relate to this area. I was particularly interested in it because the issues seemed to be similar to matters I had encountered with my shrewdBar WordPress menu bar plugin.

The difficulty with forum discussions is fully understanding what the issues are. If one is sat with a client, or even on a video link, it is easy to mock up a quick display and discuss what the presentation should actually look like. Difficulties are compounded with cultural and time-zone differences. But, “All is one in their own way,” and the power of the Internet allows the following attempt at understanding the problem and suggesting a solution.

I hope it solves the problem it tries to address, but even if it doesn’t, I’ve learned a neat CSS trick that I’ll be using again.

Basic Pods Data Display

First, create the Pod (Pods – Setup – Pods – Add new pod) using the data supplied.
Second, add some test data (Pods – Add {name_of_pod}). We could have used the Pod menu settings to make this title more meaningful, or even used a separate menu out of the Pods hierarchy.
Third, create the Template (Pods – Setup – Templates – Add new template)

^{Happiness Today screenshot note}

Fourth, test the output without any styling using

<ul>[pods name="shrewdies_cafe_menu"  template="shrewdies_cafe_menu"]</ul>

Fifth, go back to the template, change the list (li) tag to anchor (a – because we need to hover), and add the labels for the prices. Then apply some styling.

The span tags in the template seem redundant up to now, but they are there for a very good reason. The popup display in the “client brief” didn’t seem relevant for the small amount of information to display. Given it’s complexity, I searched for something simpler, and found Eric’s pure css popups. So, adding some CSS styling, our list is transformed into:

WordPress Style Notes

The transforming CSS is called by wrapping our Pods call in an appropriate div:

<div id="links">[pods name="shrewdies_cafe_menu"  template="shrewdies_cafe_menu"]</div>

I’ve taken Eric’s CSS style and included it in this post, though in practice, you would probably paste it into your theme’s style sheet. Eric uses his for a menu positioned absolutely near the top left, so I have removed the container styling, and changed the span positioning to relative. I also added the bold line below – a duplicate of the preceding span line, with a greater than to signify anchor text that is a child selector of a span. Without both versions, the span element refuses to hide – I assume this is a conflict with the styling from my theme.

<style type="text/css">
<!--
div#links {width: 166px; height: 300px; font: 16px Verdana, sans-serif; z-index: 100;}
div#links a {display: block; text-align: center; font: bold 1em sans-serif;
   padding: 5px 10px; margin: 0 0 1px; border-width: 0;
   text-decoration: none; color: #FFC; background: #444;
   border-right: 5px solid #505050;}
div#links a:hover {color: #411; background: #AAA;
   border-right: 5px double white;}

div#links a span {display: none;}
div#links a > span {display: none;}
div#links a:hover span {display: block;
   position: relative; top: 0px; left: 100; width: 125px;
   padding: 5px; margin: 10px; z-index: 100;
   color: #AAA; background: black;
   font: 10px Verdana, sans-serif; text-align: center;}

-->
</style>

Happiness Today Screenshot Note

Though the two screenshots show the same lyrics from Think Of Happiness Today, do not think that the program has stuck, or in some way does not work. Those lines are the chorus, and I have repeated them in line with the original lyrics. This means that this particular couplet will display more regularly in the display area. If you adapt the plugin for your own promotional purposes, repeat your most important messages, and they will display more frequently.

My Happiness Today plugin release joins the Pods UI plugin to double the number of examples of Pods CMS use.

Though this is released as a teaching tool, you should not assume it is perfect. Though it works perfectly, there are a few rough edges in the implementation. But that is the point of Open Source tools – we can improve all aspects of Happiness Today, collectively.

I like the idea of the Hello Dolly plugin as a teaching tool. Though it is criticized for it’s limited usefulness, the WordPress developers have defended it, by rightly explaining:

I think Hello Dolly is a good little example plugin. Users can turn it on, see that it does something, turn it off, see that it doesn’t do it anymore. Plugin functionality exemplified.

This is perfectly true, and useful for novice WordPress users who want to understand what a plugin is, without being intimidated by reams of PHP code. But Pods developers are a different breed. We have varying PHP & HTML skills, but we are bound by a common desire to learn and extend WordPress functionality.

So Happiness Today goes beyond the remit of Hello Dolly, and achieves useful outcomes. Using the simple Pods data edit screens, you can transform Hello Dolly into a client support tool, or promotion tool for any campaign where short messages to WordPress website builders are going to win you a click or three.

Simple Pods WordPress Plugin Output

Though I have used plain text in the distributed plugin, the data is stored as rich text, so you can easily include images and hyperlinks in the message display. This is in addition to the included customizable link buttons. After editing the data files with whatever text you need, you can easily import it as a Pods Package for your client sites.

I prepared the plugin in minutes using the Pods Plugin Builder that is the real goal of this project. In fact, most of the time is spent writing the readme.txt file that is generated as part of the plugin distribution package. That tool is still under development, but when available, it will make distribution of your own version of Happiness Today, or any other Pods Package, a very simple process.

Happiness Today Next Steps

Please contribute ideas to the wishlist. Also, if you are a superb PHP programmer, I would love to here your thoughts on code improvement.

I would also like to you to rate the Happiness Today Pods WordPress plugin, but if you cannot give it a 5 star, at least give me the opportunity to fix any problems you have before you vote.

I can reveal that this will be an homage to the ubiquitous Hello Dolly plugin – with some extras, and some Pods magic.

Just to remind you. I love Pods as it is intended to be used – a Content Management System that extends WordPress Pages and Posts to allow developers to provide new content styles. This is extremely important to me as I develop new tools for webmasters, and new web applications to extend my health sites.

But for the moment, I’m hooked (pun intended) on using Pods to hook rapidly developed packages into WordPress as plugins. This series of articles explains the Pods features used to create WordPress plugin files complete with readme.txt. WordPress explains what a plugin is by way of the Hello Dolly example. In a similar way, I needed a very simple plugin application to test and demonstrate my WordPress Pods Plugin Builder.

Enter Soft Charisma, the music company run by Scott Kingsley Clark, one of Pods lead developers. Scott has written the perfect song to complement Hello Dolly – Think Of Happiness Today.

Happiness Today Plugin - click for large size

My plugin, Happiness Today, displays random lyrics from the song on the admin pages. So far, so Hello Dolly, but there are extras:

• Up to 3 link buttons
• Customizable lyrics, position & links
• Easily editable content & options through the Pods interface

It is currently at ‘proof of concept’ stage. A complete, usable plugin, but incomplete readme.txt file, no deactivation routine (though easily tidied up manually via Pods administration), and untidy code structure. Also, it borrows its styling to match the selected admin scheme in a way that is best described as Borrow Code.

Borrow Code is a semi-original term, coined by me, to explain the style of programming I borrow and use. The style of Borrow Code reflects how I use snippets of code without understanding the original concept, shape it with a big hammer until it just about works, then refine it properly for public use, or discard it in favor of suggestions from better coders.

I will add it to the WordPress extensions database once it is fit for public consumption, when we can also discuss potential uses and enhancement suggestions.

WordPress Happiness Today Plugin

Potential uses:

• Promotion for musicians, poets, authors, etc to randomly present their own lyrics and links
• Promotion for website developers to randomly present support tips and links
• Random product benefits and links
• Fund raising quotes & links
• Your suggestions

Enhancement suggestions:

• Widget support to display random messages, adverts, etc to visitors
• Single click data import, export, delete routines
• Remote data updates
• Your suggestions

WordPress Pods Projects: Next Steps

That’s enough background for now. In the next article I’ll explain some specific Pods techniques used in the WordPress Pods Plugin Builder, and its example project, Happiness Today.