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:

And inbetweens don't feel left out
What makes you think that you're not proud?

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.

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.

With it’s easy to use interface, it is good for novice writers, but it also stands on a very powerful data management platform.

This makes it a real candidate for Rapid Application Development, but how to package and distribute those applications?

Before I present my latest project for building structured WordPress plugins, packaged with properly formatted readme file, straight from the Pods interface let me explain what Pods is.

WordPress Pods Background

Pods builds applications by creating data tables and presenting that data on pages, using display templates to keep presentation simple. Going beyond basic table administration, Pages and Templates can include any HTML or PHP code you like to manipulate data. And going beyond that, there are Helpers that can manipulate data before during or after it has been entered.

This means that any extension to WordPress can be coded in Pods. Tasks that do not require data manipulation probably do not need Pods. On the other hand, most plugins do need to use the WordPress database, even if only to store some options. Using Pods makes that data easy to maintain and it’s structure means that it is very easy to build reusable code libraries.

I will explain Pods Data, Template, Page and Helper features in more detail when I explain how my Pods projects work. First let’s look at my current to build WordPress plugins using Pods.

WordPress Pods Plugin Builder

Pods already does a good job of easing distribution of projects. It is extremely easy to bundle your project components together and export them as a Pods Package. The Pods CMS site has several examples of these packages which as well as being useful in their own right, can be used to learn various techniques.

These packages can be pasted directly into Pods, or loaded programatically, as demonstrated in the Pods UI demo. This makes distribution very easy, but there is one vital thing missing for most projects, and another missing for many.

The vital missing part is data. Though pods can export and import data, this is not part of the Pods package process. If you are handling a project for a client, it is very easy to move data to your clients site by exporting and importing, but it is not possible to supply a single package including code and data.

For most Pods projects, that data problem is the only one, and the import and export routines simply mean you have to distribute code and data separately. For many of my projects, I want to provide WordPress plugin functionality. This means that I need at least one plugin file to hook the functions into WordPress.

My Pods Plugin Builder produces standard format WordPress plugin files from Pods. The plugin it produces will load a Pods package, load the data, and add the hooks that WordPress needs. It also produces a correctly formatted readme.txt file which is so important if you want people to be able to find your plugin in the WordPress repository.

I passed a milestone today when I used the package to produce my first plugin.

WordPress Pods Plugin Builder: Next Steps

In the next few articles I will:

• Describe the package in detail, including work still to do, and potential additional features.
• Introduce the plugin that this package has produced, and describe how key features of Pods work.
• Apply the package to my shrewdBar & shrewdChat projects.
• Release the package for wider testing and distribution.

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.