WordPress Plugins – Beginners Nightmare
December 22nd, 2009 by Keith from shrewdies | Filed under Function.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
- WordPress › Blog » Canonical Plugins (Say What?) [Internet]. [cited 2009 Dec 22]
- WordPress Coding Standards « WordPress Codex [Internet]. [cited 2009 Dec 22]
- Inline Documentation « WordPress Codex [Internet]. [cited 2009 Dec 22]
- [wp-hackers] Coding style [Internet]. [cited 2009 Dec 22]
- Top 10 Most Common Coding Mistakes in WordPress Plugins « planetOzh [Internet]. [cited 2009 Dec 22]
- WordPress Plugin Development Tips And Tricks – Hungred Dot Com [Internet]. [cited 2009 Dec 16]
- How To Design And Style Your WordPress Plugin Admin Panel | Onextrapixel – Showcasing Web Treats Without Hitch [Internet]. [cited 2009 Dec 16]
