Mark on WordPress

WordPress puts food on my table.

How to write a solid and stable WordPress plugin

with 36 comments

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.

Written by Mark Jaquith

July 23, 2008 at 11:00 pm

Posted in wordpress

Tagged with , , ,

« Congratulations to Andrew Ozz (azaozz)
One-line plugin of the day »

36 Responses

Subscribe to comments with RSS.

  1. [...] СЕОниста, существует немало рецептов. Сегодня подвернулся еще один, абсолютно тупой и абсолютно [...]

    Как написать плагин в WordPress | Луговсариум

    July 24, 2008 at 12:22 am

  2. 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.

    ChaosKaizer

    July 24, 2008 at 12:28 am

  3. I agree with ChaosKaizer, some plugins add alot of info to the database and having them there for no reason is pointless…

    iswm

    July 24, 2008 at 12:48 am

  4. 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 :)

    Joost de Valk

    July 24, 2008 at 1:05 am

  5. 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 ;)

    Anthony

    July 24, 2008 at 4:56 am

  6. 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.

    James

    July 24, 2008 at 5:12 am

  7. feel free to use my last plugin : MailPress available at wordpress.org

    arena

    July 24, 2008 at 6:56 am

  8. … and to review it.

    Thanks !

    arena

    July 24, 2008 at 6:57 am

  9. 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.

    Keith

    July 24, 2008 at 7:38 am

  10. Looks like you provided an opportunity for some to plug their plug-ins.

    Carson

    July 24, 2008 at 7:46 am

  11. 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.

    Jesse Harris

    July 24, 2008 at 8:42 am

  12. 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

    Otto

    July 24, 2008 at 10:55 am

  13. 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.

    Andy

    July 24, 2008 at 11:02 am

  14. 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

    SmugBaldy

    July 24, 2008 at 11:21 am

  15. 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.)

    Michael Hampton

    July 24, 2008 at 6:57 pm

  16. Another two years? Sounds to me like a good time to release WordPress 3.0 and remove deprecated functions completely.

    Jacob Santos

    July 24, 2008 at 7:05 pm

  17. 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!!!

    getshopped

    July 25, 2008 at 3:13 am

  18. I am also looking for some e-commerce functionality in WordPress. It is good field for development

    SVajdlenka

    July 25, 2008 at 5:39 am

  19. There are still enough themes for WP plugins.

    JS

    July 25, 2008 at 6:38 am

  20. 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… :/

    Dave Zatz

    July 25, 2008 at 8:03 am

  21. 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 Zatz

    July 25, 2008 at 9:38 am

  22. @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.

    Jeremy Wright

    July 25, 2008 at 11:17 am

  23. +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?

    jeremyclarke

    July 25, 2008 at 7:01 pm

  24. [...] Jaquith has put up a nice article on “How to write a solid and stable WordPress plugin“. It’s more fo a rough overview than a detail piece, but he promises more details down [...]

    Nerdaphernalia » How to write a solid and stable WordPress plugin

    July 26, 2008 at 10:09 am

  25. [...] que aqueles que escrevem plugins para o WordPresse seguissem a risca o que Mark fala neste post How to write a solid and stable WordPress plugin, mas enfim, [...]

    Dicas: Firebug e YSlow | ...zezologs

    July 27, 2008 at 7:50 pm

  26. 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?

    Richard

    July 28, 2008 at 4:24 pm

  27. [...] How to write a solid and stable WordPress plugin: Mark Jaquith tells us [WordPress plugin developers] how to develop solid and stable WordPress plugins. [...]

    Weekend Links #3 | OMNINOGGIN

    July 29, 2008 at 1:01 pm

  28. [...] Just wanted to point out a recent post by Mark Jaquith (and, I’m assuming, Brian Layman) that gives specific requirements for plugins to be considered usable by b5media. [...]

    How to Write a Stable and Secure WordPress Plugin

    August 1, 2008 at 11:15 am

  29. Definitely looking forward to your future posts on this with screencasts.

    Kevin Bondelli

    August 1, 2008 at 10:23 pm

  30. 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.

    Rajesh

    August 10, 2008 at 1:47 am

  31. [...] How to write a solid and stable WordPress plugin « Mark on WordPress (tags: wordpress) [...]

    links for 2008-10-09 | /dev/random

    October 9, 2008 at 1:00 pm

  32. [...] How to write a solid and stable WordPress plugin « Mark on WordPress (tags: wordpress) [...]

    links for 2008-10-09 « Mike’s Blog

    October 9, 2008 at 5:00 pm

  33. [...] Mark Jaquith ha apuntado las que, a su juicio, deben ser las premisas para desarrollar un plugin WordPress que sea estable y no comprometa la seguridad y fluidez del blog. [...]

    Como escribir un plugin sólido y estable para WordPress | Ayuda WordPress

    December 14, 2008 at 4:20 am

  34. [...] Tutorial: Your First WP Plugin « Mark on WordPress How to write a solid and stable WordPress plugin « Mark on WordPress 3 simple steps to Create a WordPress Plugin : WPDigger The Tutorial Blog » Blog Archive » [...]

    S1 Team Blog » Blog Archive » Creating WordPress Plugins Tuts

    January 21, 2009 at 12:19 pm

  35. 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.

    twincascos

    January 23, 2009 at 4:25 pm

  36. 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.

    10goC

    June 29, 2009 at 11:25 am


Leave a Reply