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]