It seems, reading the news, that nuclear proliferation will be the end of the world. For a WordPress developer, on the other hand, poor plugin programming seems likely be the end of the world. I rarely take shots at other people online (it seems rather trollish to me), but the sheer horror of Fire Studio’s Wordpress Plugin Templates compel me to say something.
While I certainly applaud people who make plugin development easier, if one is going to distribute a plugin framework, it should, at the very least, follow the minimum best practices for WordPress programming. Fire Studio’s Wordpress Plugin Templates is an epic fail in this regard. I fall pray to these mistakes from time to time myself, and there may be differences of opinion and style in programming. Nonetheless, as the Wordpress Plugin Template is designed to be distributed, I must list out the reasons why NOT to use the Wordpress Plugin Templates.
1: Overuse of the options table:
get_option() and set_option() are wonderfully useful features, if used in moderation. If not used in moderation, they result in a hellish jumble of entries in the wp-options table. Instead of using many discreet entries, an “options” object or array should be serialized into a set_option() call. While this may be overkill for a very simple plugin, once you get to any number of options it is a necessity.
2: No NONCEs
This is such an offensive mistake it makes me cry a little. As I(and Mark Jaquith and Vladimir Prelovac and many others) have written, using nonces is a must for any plugin which takes options from a user. Strangely enough, the nonce field is included, but then never checked (WTF?). Without the use of nonces, a nefarious user can arbitrarily change your plugin settings, and possibly even take over your database. Particularly if there are
3: No SQL Injection Security
Not having nonces is one thing. It’s bad, but I’ve forgotten from time to time myself. But not even escaping input before putting it in the database is, to quote “Yahtzee”, pants on head retarded!. Escaping user input is probably the single simplest and most basic security. It’s the last line of defense against people replacing your header image with horrific porn. Don’t write code without it.
4: Unnecessary use of global variables
This exists on two levels:
A) In purpose.php, both $wp_query and $post are called into the function via global. While this probably won’t do any harm, globally including everything everywhere is what made earlier version of php such a nightmare and it looks messy. If you don’t need a variable, don’t include it.
B) $var1-$var4 are declared to static values at the top of the file where they will clutter up the global namespace. They are never accessed from their global context, they are always get_option()ed. In fact, the only reason they are declared here is so that they can be add_optioned into options. EVERY TIME THE CODE RUNS. That’s four superfluous function calls every single time the file loads. This should be done once, on plugin install. Not every single time WordPress loads a page.
5: Include vs. Require
I realize that this is pretty nit-picky, but, when including files that are required for the program to function, the appropriate function is require() (or better yet, require_once(). If the file is missing, the code to break while trying to include the file, instead of mysteriously throwing messages about redeclaration of functions.
In conclusion, while the concept of a plugin framework is laudable, Fire Studio’s implementation falls far short of any reasonable mark of best practices, and only serves to encourage worst practices.
Who's Lookin'
Hey Chris,
While I don’t like your spiteful comments about my templates, I do appreciate you pointing out exactly what is wrong. You made several good points (SQL injection, NONCES, Overuse of Options table), but also some that aren’t correct.
When you reference my “over additions” to the Options table, you are completely right…if this was a large scale plugin. But it’s not (and even large scale plugins use my method). Your opinion is your opinion, but it’s not a guaranteed “must follow” standard.
You’re completely correct on the NONCE and SQL Injection statements and I will be updating my templates to include those.
In regards to the $Post and $WP_Query global variable calls, I added them so that the users would already have access to that data if they need/want it since it’s a high traffic area. Your statement on me adding the variables at the top of the file to the Options table every time the code runs is completely incorrect. the “add_option” function will only run if table isn’t there. so in fact, all I’m doing (after the first run) is checking that all my needed resources are available.
On the topic of require vs. include, either way is a viable option. It may be logical to use both. “include” for the admin page and “require” for the purpose.php file.
@Fire G:
They’re not spiteful, they’re to the point. I took the spiteful ones out.
Spite: A desire to vex or injure. Comments about killing puppies are spiteful.