In most WordPress extensions, a lot of data is hidden in the code.

The massive advantage of Pods is that we can easily store additional data, and manage it very efficiently.

In the first installment of this series, I introduced shrewdBar, explaining it was based on a WordPress plugin that creates a menu by outputting data in the form of a CSS LIst driven menu. This type of menu is quite common – you style a nested list to have hidden items that reveal themselves when the mouse hovers over them. The added attraction of this type of menu is that without the styling, you simply have a nested list of items that search engines can follow.

The CSS issues are for another time. What I need you to realize is that these menus are usually built in code, with a lot of hard-coded links. True, the original menubar, DashBar, on which shrewdBar is roughly based, does have some items that are extracted from WordPress database tables. In my first version of the menu bar, I extended this to extract messages and topics from the Simple:Press forum.

Pods allowed me to put all the menu items into WordPress database tables, and I explain in this article, how I achieved this.

shrewdBar Database

In its current release, I have limited the menu to two tiers, so we have a Pod for the top tier, that you see across the top of the page. Optionally, each of these top level records can have a variable number of child items.

The schematic is:

Pods automatically creates the name and slug fields when we create a new pod. name identifies the record, and I also use it as a sort order. slug is very useful in many Pods packages, and I’ll cover it in depth later, but it is not really required in the current version of shrewdBar.

The text, title and url fields are the menu links that are used to navigate to different pages. The pick fields are used to relate tables – in this case a one to many relationship.

The top level menu records have two additional fields. The boolean hold field allows menu items to be temporarily hidden, without deleting the record. This is not required for second level items, as it is a simple click to break or make the relationship to a top level menu. The display field allows us to enter PHP code which can programatically control the display giving us very powerful dynamic menus. I’ll be discussing this at length in the next installment.

shrewdBar Options

Like most plugins, shrewdBar needs options to control colors and positioning. Unlike most WordPress plugins, these options no longer have to live in the options table where they soon get lost. I put the shrewdBar options in its own table, which makes it very easy to manage. The options data could be managed using the standard Pods edit page, however I find it better to write a special page with information and instructions. I’ll be covering this in detail in a later installment.

In the next installment, I will explain how simple Pods procedures act on the data to produce the list output that forms the shrewdBar menu.

It might become one. It started life as one.

But, for now, it is a Pods package, and this is the first part in a series that explains what a Pods package is, how it improves WordPress functionality, and how you can apply it to your own site.

Before we start, I was reminded earlier about the crucial importance of purpose as your first step. When you set out to add functionality to WordPress, you must be clear about why you are doing it. If you employ assistants, or ask for help on the forums here, or elsewhere, you must communicate that purpose clearly.

Xarzu told me earlier that she wanted to write WordPress plugins and asked if I could recommend a comprehensive list of hooks, actions and filters. I subsequently found she’d asked this in just about every forum on the Internet, irrespective of it’s subject matter. That kind of spam is best ignored, but it does serve as a prime example of what goes wrong when you do not have a clear purpose.

Firstly, I noticed that Xarzu had received lots of positive help, despite the poor question. People want to help, but if the goals are not clear, if the question is too vague, if there is lack of purpose, then that help is often wasted. So before you even think of adding any functionality to WordPress, think long and hard about the purpose of your plugin, and who the typical user is.

My latest project started when I tried the Splix theme, and found the built-in menu bar. It certainly helped me use WordPress as an application, and is a welcome feature of WordPress.com sites. It struck me that as you add functionality to your website, e.g. with forums, polls, news etc, your website becomes an application for your visitors. So I started my WordPress menu bar plugin project.

The purpose of the plugin is to improve navigation efficiency for 3 groups of users:

• Visitors. The vast majority who read your website and leave. You want them to return, so let them find your best content easily. You want them to become contributors, so let them register easily. You want them to feel welcome, so give them help to learn how your site works. The menu bar lets you display all this where it can be found easily.
• Contributors are visitors who add comments or start new discussions. You might run a reference site that doesn’t allow visitor contributions. In that case, ignore this group, but for most websites they are crucial to the growth of your site. The plugin helps by allowing contributors to easily find and edit their own contributions.
• Administrators. As the chief contributor, admins get all the benefits of the other groups, plus easy access to commonly used admin pages. Which pages are commonly used? That’s entirely up to you, as the menubar items are stored in an easy-to-edit Pods database.

All of this raises the efficiency of your site, which is a very shrewd thing to do – that’s why the plugin is called shrewdBar. I will explain the development stages in a series posts over the next few days.

A scary journey, but now the nightmare is over.

Now I can dream happily of a bright WordPress development future.

But, there is no time to dream. Not even time to hack together a pretty picture to decorate this article. I’m fired up for developing, but there is just enough time to let you know what the plan is.

When I finally decided on the SCB framework, I sat down to plan how to integrate my menu system, a hack of DashBar, into that structure. It looked like a project that might also suit Pods, as I would need somewhere to store menu item links.

What’s the first thing I notice in SCB? Routines to handle WordPress options and table data. But can’t I just use Pods for that?

Yes, I can!

To cut a long story, I knocked together a fully customizable menu system in record time. It is not finished yet, but I’m so pleased with the results, and ease of development, that I decided to feature how I have developed it over the next few days.

As of today, it is lurking near the foot of the page, with a list based cascading menu that doesn’t quite work (Note to CSS developers – beware inherited settings that you have assumed will not be used elsewhere). It would have been finished a day earlier, but I was trying to adapt a definition list dropdown menu. All was going really well, until I found that it is impossible to make that kind of CSS structure perform the variable width trick.

Variable width is really a must, as the shrewdBar doubles as a login form. So I will get on with re-wrapping the menu in the same way as the DashBar-based version, then I’ll go through the development stages so you can see just how easy it is to get Pods to do most of your development work.

Once that is finished, I will convert my other plugin work-in-progress) to Pods, and also use it for a full-blown web based application that I have had in the pipeline for well over a year. shrewdChat discussion package soon, then The Big One, just as soon as I get shrewdBar & shrewdChat to good, usable stage.

Easy access to website is always important, but doubly so when you are encouraging members to join and contribute comments and forum posts.

You may see changes to the navigation bar at the top of the page during this week. I’m building and testing new ideas, and I would also like your input.

Purpose of the WordPress plugin

I was inspired by the userbar that is part of this Splix theme. It adds great access and information features to the bar at the top of the page. It does not include all the functionality I need – especially as it has no functions to ease access to the forum. In fact, I was surprised to see functionality like this added to a theme, so I looked at WordPress plugins to see if they offered better solutions.

The one that best suits what I need is DashBar, but it also lacks the forum functions that I need. One advantage is that it is very well written, and can be extended to include other links. However, I wanted to add other features from the Splix userbar, so I decided to build a new plugin to create a functional, attractive access bar.

The purpose of the new plugin is to provide all website contributors, including administrators and casual visitors, with a quick way to see new information that is relevant to them, and a quick way to access that information for viewing or editing.

During this week, you may see two, or possibly three different toolbars as I pool the best ideas from the DashBar and the Splix userbar. I’ll let you know when my WordPress plugin is finished, but there are a couple of issues you can help with…

Help Form This WordPress Plugin

The first issue is a name for the toolbar / userbar / admin bar.

The second issue is that I would really love to hear your opinions on the features that are important to you in a WordPress plugin like this.

Please add your comments below, or discuss this in the WordPress functionality forum.