The b5media tech team was having a discussion today about what criteria we use when reviewing a WordPress plugin for possible inclusion on one of our sites or across our network. It makes for a good list of what to do (or not do) when writing a WordPress plugin, something that might be generally useful to plugin authors. These things won’t make your plugin good — they’ll just help make it secure and stable.
Don’t ignore security
WordPress plugins have unlimited power, which is a blessing (it makes WordPress very flexible), but it can be a curse if your plugin is not code with security in mind. If things like CSRF, the prepare() method (SQL injection protection), XSS are not intimately known to you, it’s time for you to do some research. When someone installs their plugin, they are potentially putting their site’s security in your hands. Rise to the occasion.
Make proper use of the role/capability system
WordPress controls admin access using a roles/capabilities system. Make sure your plugin is checking against an appropriate capability. If it is the sort of thing that only “admins” should use, you should be checking against the manage_options capability. If this is something that an author should be able to do, you might use the publish_post capability. Do not check against roles. Roles are only containers for capabilities, and you can’t assume that an “author” on one blog means the same thing on all of them.
Use current API functions
WordPress has a lot of legacy code and deprecated functions. We try not to break stuff without good reason, so often times we’ll leave in compatibility for old API functions. If your plugin is using these functions, it tells me that you’re not up on current WordPress development. This means that your plugin might be more likely to break with a WordPress upgrade, and it suggests sloppiness that can lead to security issues.
Mind your performance
The number of queries that your plugin makes can affect its performance. We don’t care how cool your plugin is — if it uses 10 MySQL queries on every page, it’s not going in. You should work to minimize these queries as much as possible. Other performance issues like the efficiency of your PHP code should be taken into consideration as well.
Use existing WordPress data structures whenever possible
Don’t create your own tables unless you’re absolutely certain there is no way to accomplish your functionality within the WordPress data system.
I’m going to go into more detail on these topics at a later date. Maybe even with screencasts, which seem to be a great way of demonstrating these sorts of things.
Mark on WordPress 
I think one important thing that is missing from most plugin is an options to uninstall all their settings from the database.
“A solid and stable WordPress plugin” should have an uninstall options.
I agree with ChaosKaizer, some plugins add alot of info to the database and having them there for no reason is pointless…
Hi Mark, if you need an example for those screencasts feel free to pick any of my plugins, they might need some improvements in some of these areas 🙂
Hi,
For most plugins I would agree to what you said about SQL Queries and Data structure, but for some of them, it’s quite hard not to use any other table or more SQL Queries.
I take as an example my Multilingual plugin, It needs other tables not to interfere with existing structure and takes more than 10 queries as it translates nearly everything into other languages. Of course this is an example, but sometimes using 15 queries per page is not that bad. It just depends on what you want to achieve 😉
Hey Mark. I can’t WAIT for the screencasts/examples. Learning by example is how I work, so seeing what’s good practice when coding plugins is going to be really helpful.
feel free to use my last plugin : MailPress available at wordpress.org
… and to review it.
Thanks !
Great article! I will be updating the WordPress Plugin Framework to include these security features in the near future. If you are not familiar with this framework please take a look at the links below.
http://www.doubleblackdesign.com/categories/wordpress-plugins/wordpress-plugin-framework/
http://wordpress.org/extend/plugins/wordpress-plugin-framework/
The intent of the WordPress Plugin Framework is to standardize the plugin administration interface design and implementation so that the plugin developer may spend more time developing their functionality and not their plugin.
Looks like you provided an opportunity for some to plug their plug-ins.
Oh do I know the pain of plugins that seemingly can’t upgrade. Given that popular plugins like Spam Karma 2 have been solid from 2.0 up through 2.6 without a single code change, I find it incomprehensible how someone else could build a plugin that fails to be forward-compatible. It’s even more confusing when someone releases differing versions of a plugin for different versions of WordPress.
Right now I’m stuck at an old version of WP because the gallery plugin I use suffers from this poor design. If there’s some kind of cheat sheet for deprecated functions, I’d probably go in and upgrade it myself.
WordPress 2.5 started to include some new functionality in that area. Calls to deprecated functions/files now can trigger error handling to log or display the relevant information, when you enable WordPress’ debug mode.
More info here:
http://codex.wordpress.org/WordPress_Deprecated_Functions_Hook
This is a nice write up Mark, thanks. I’d definitely be interested in seeing some screencasts.
I’d say the maximum number of SQL queries also depends on the type of query. 10 simple SELECT queries would be less expensive than 5 queries with complex joins or INSERT’s.
Nice post Mark. I like that you had security at the top of your list, as it’s easy to forget that badly written plugins pose a security threat.
Another thing I see (and I’m guilty of this as well) is that sometimes, plugin developers will recreate functionality that already exists within the API. You covered this a bit in your call to use current API functionality. You didn’t mention, however, another benefit of using the API: Not only will it often future-proof your plugin, but it also simply makes coding your plugin easier.
And every real developer worth his salt will agree that easier coding is usually better. 😉
Cheers
Of course, there’s an issue with deprecated functions, and that is that sometimes you have to use them to maintain backward compatibility. Remember that WordPress is still supporting that 2.0.x legacy branch for another two years! (And Gawd knows what will happen after that.)
Another two years? Sounds to me like a good time to release WordPress 3.0 and remove deprecated functions completely.
This is cool. Its time to start optimizing some WP e-Commerce functionality – this is a really great little resource for plugin developers.
Thanks Mark!!!
I am also looking for some e-commerce functionality in WordPress. It is good field for development
There are still enough themes for WP plugins.
Regarding ‘mind your performance’ – is there anything non-developers can do to determine the impact of any given plugin prior to installation or even while running? I seem to have no way of knowing how well these things are coded…
Here’s another thought – what’s the incentive for folks to write “good” plugins that are secure and efficient? Most of these folks are probably doing this in their free time, many are amateurs, and plugins aren’t being audited by the WordPress org as far as I know. And I imagine there are also “bad people” out there with plugin ideas.
@Dave
One incentive is, if they don’t, it wont’ get used by b5media or our partner sites. I realize we’re only 500 blogs, but still, not being able to use great plugins just because of poor code sucks.
+1 for using the capabilities system properly. It’s a bummer to see “current_user_can(‘level_10’)” as the check in a plugin. Roles are also pretty useless, especially because there is no inbuilt hierarchy (there’s no way to say “is this role HIGHER than that role?”).
For bonus points, create an option in your plugin admin for what capability is required to do a given action, I often find plugins are shortsighted about the fact that different sites have different user structures, and “you must be admin” is often overkill for many tasks. A dropdown with choices for read, edit_posts, publish_posts, and manage_options will go pretty far towards satisfying anyone’s needs (the aesthete in me wants to have a dropdown with every available capability just in case, but I think most site admins would be terrified by the sight of it).
On another note, why isn’t there subscribe to comments for wp.com? Seriously, wtf is that?
Has anybody considerd the term ‘PLUGOUT’ alongside plugin? I mean deactivation is often only half the story and leaves tables, configs and options scattered forever lost in the database. I spend more time cleaning up after plugins than configuring them. Surely there must be a better way to enforce a cleaner uninstall?
Definitely looking forward to your future posts on this with screencasts.
I won’t go with the logic that if a plug has 10 queries, then it is not going in. It depends on the complexity of the query and also how many effectively run during a page load.
Good article, I’d like to see a much deeper presentation, or list of best practices. I’m building my first plugins and I spend a lot of time looking for best structure- practice.
Hi, i’ve made a plug-in just for my site that adds an admin menu as shown here: http://edicionfotografica.com.ar/cateaser.jpg.
I’d like to know how could I make it show up for users with editor capabilities. When I made it I didn’t specify any restrictions, but it only shows up for admin users.
Thanks.
Mark, thanks for this post. Helpful to those of us first-timers diving into WP plugins. 🙂
Thanks a lot Mark i was thinking of making plugins and points mentioned by you are worth considering plugin development. Now i’ll checking your site for more articles on this topic
Hi! keep cool and post really outstanding,its very informative so readers really appreciate this and most all the useful points which is found in it so thanks for the blog,keep up post cont………:)Thanks a lot.
Is there any place where we can find sample plugins to work on.. I want to develop something but need to understand the plugin structure first. I thought looking at a sample plugin would be a good way to start that..