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.

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.

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.

But are they relevant to WordPress website owners, and will they help or hinder your marketing efforts.

More to the point – what are they?

The buzz for webmasters is that microformats help you on Google. But there are one or two fairly large points missing from that.

Before we look into those, let me explain what microformats are. They are tags in your web page, similar in operation to HTML tags. Whereas HTML tags change the appearance of text, microformats tell search engines and other robots what your text means. More specifically they describe the context of your text as structured data.

Whoopi-f-ing-doo you cry, or at least “so what.”

But wait, this is important.

If a search engine can interpret the type of information you are presenting, it can list you better. It puts your information into the right context. You can explicitly distinguish the author of a work from a work about an author.

Your words, with these descriptive tags, are known as rich snippets. If you currently earn money by providing content that includes reviews, people, businesses, organizations, events or video, then you need these snippets to help you get richer.

Why Microformats?

A search engine that might have sent you a little traffic from time to time has more information on rich snippets (including a validation tool), but before you investigate that, consider what is missing from the “Google & Microformats: Drive More Traffic” article.

There are two ways of providing rich snippets: microformats and RDFa. Microformats are more common, but RDFa is to be implemented in HTML 5, so is more likely to become the standard in future. In fact search volumes for RDFa have just started to outstrip microformats. I believe webmasters should focus on RDFa.

WordPress Rich Snippets

The second missing point, close to the heart of WordPress webmasters, is how can I add some rich snippets without hand-coding all my articles?

There is some good news there. If you are yet to be convinced on the microformats vs RDFa debate, search the plugin database for microformats. You will get 27 results at the time of writing – let me know if any of them help you.

For RDFa, there are only two results in the search, but a third one is hidden in the secret lair of WordPress plugin developers who like to hide their work behind poor tagging and descriptions. I’ll review these in detail sometime soon, but if you’d like to check them for me (and maybe write a guest review?), they are:

Dublin Core for WP

A plugin to add Dublin Core metadata to all posts and pages. I will let you know later if this is currently supported by the author or someone else.

Image Licenser

Provides an easy way to tag embedded images with a CreativCommons license. This uses RDFa, to enable search engines finding your images even if the user filters for CC licenses. A very new plugin from Raphael Mack.

wp-RDFa

wp-RDFa is a WordPress plugin to bring the Semantic Web to your WordPress blog. Currently this plugin supports FOAF and the Dublin Core. WP-RDFa seems very much alive and supported from SquareCows.

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.

WordPress plugins are vital for efficiently functioning websites.

WordPress Plugins Structure Nightmare

Given their importance, I would expect much more effort going into helping new plugin developers get to grips with plugin structure.
 

The WordPress development team resist adding features to the core if they are not universal requirements and can be dealt with by plugins. This is a good thing, and they have recently announced plans to develop “canonical” (i.e. official) plugins to “address the most popular functionality requests with superlative execution”[1].

Significantly, these will be “the best possible example of coding standards”[1]. But just what are these coding standards that are deemed so important?

The first thing I want to do when I write a plugin is adopt a structure that:

• Is the most efficient in terms of performance (i.e. no redundant code, especially admin code loaded for all users)
• Uses core WordPress functions and methods instead of home-grown alternatives.
• Uses latest functionality and best practice, avoiding deprecated functions and methods.
• Is familiar to the majority of plugin developers.

It’s the last point that induces the biggest nightmare. Official coding standards[2] focus heavily on inline documentation and formatting[3][4]. This is all very well, but we need good examples that clearly show best practice in how to organize code in modules. Which bits are best in separate modules, and how should they be organized in sub-folders?

It speaks volumes to me that the biggest plugin competition judging can only produce a list of 10 things to avoid[5]. Developers would avoid these mistakes if they had decent examples to follow. Instead, we are all wallowing in our own vats of spaghetti code, producing our own coding structures (or lack of structure), and never achieving anything that is instantly accessible to other developers.

Don’t get me wrong, the 10 mistakes to avoid are welcome, and the judging comments on which they are based are invaluable. But the advice is difficult to take on board when you are wondering how to best structure an object oriented plugin that will not break as soon as you upload it. There are plenty of other good coding tips[6], including good admin page tips[7]. These are all very welcome, but I’m still struggling with where to put them!

I have tried one or two “plugin templates”, but they are all out of date, and not easily developed. The best I have come across (from my limited perspective) has almost no documentation other than a pointer to an example.

The only good news is that the example in question is pretty good, and I will probably use it here. So by default, I’ll adopt that coding structure, and document it as I go on. My only hope is that it does not break every rule in the “official” WordPress plugin book.

WordPress Plugins References

1. WordPress › Blog » Canonical Plugins (Say What?) [Internet]. [cited 2009 Dec 22]
2. WordPress Coding Standards « WordPress Codex [Internet]. [cited 2009 Dec 22]
3. Inline Documentation « WordPress Codex [Internet]. [cited 2009 Dec 22]
4. [wp-hackers] Coding style [Internet]. [cited 2009 Dec 22]
5. Top 10 Most Common Coding Mistakes in WordPress Plugins « planetOzh [Internet]. [cited 2009 Dec 22]
6. WordPress Plugin Development Tips And Tricks – Hungred Dot Com [Internet]. [cited 2009 Dec 16]
7. How To Design And Style Your WordPress Plugin Admin Panel | Onextrapixel – Showcasing Web Treats Without Hitch [Internet]. [cited 2009 Dec 16]