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.