How to Not Write a WordPress Plugin

Posted by Jacob Santos on June 17, 2009

To often there are articles about how to write a WordPress plugin or theme, but not quite enough on how you shouldn’t write a WordPress plugin. Given how often I find a plugin or theme that just wasn’t written to my standards, I’ve decided to shed some light on this.

  1. Using a single object for every bit of functionality.

    This annoys me. This doesn’t follow proper object-oriented programming of reuse and while it is extensible, it still requires modification to the plugin code, which will be lost on automatic upgrade. The problem I have is that, yes it is easier, but not for the person modifying the code. I suppose the argument is that, if you are going to be modifying the code, that you instead just extend it and replace the parts. I will contend that if it was written properly, I would only have to inject my object into the main class or drop a replacement class.

  2. Adding code in the global scope.

    To often I will see code in the main plugin file that has executable code in the global scope. I should make this clear, all executable code must be within functions. The reason? Well, when a plugin is activated or in some instances, the plugin will be included within a function. This will mean that any code in the global scope will now inherit the function scope, so if you were expecting to replace a certain global or set a global in your plugin file, then you were doing it wrong.

    The argument for getting around this is hackish. If your plugin has the following code, then you are doing it wrong.

    <?php
/*
Plugin Header
 */

global $my_global;

    Sure, it works, but it is not clean code and besides, you are only hacking together the 5% chance that the plugin is being included within the function scope. In most cases, the code would already be called in the global scope and therefore it makes the global redundant. There are two methods for correctly solving this problem. One is procedural and the other is object-oriented.

    I won’t get into the code example, but it should be obvious that the initialize function should create the global and set its value.

  3. Not including documentation.

    Well, not really required, because I mean, who is really going to want to mess with your plugin except for you? Unless you have a popular or really useful plugin, then I don’t think many are going to dive in to your code and modify it. That said, it helps, not only you, but any developer who decides to extend or modify your plugin code.

    Don’t be like the Akismet code base, be sure to include inline documentation.

Well, there are many more, but I believe the topic is more geared towards general best practices when it comes to development. Documentation, testing, and deployment. I’ll probably continue this series based on plugins that I find, but at the end of the day, what really only matters is whether the plugin or solution gets the job down. While mileage will vary, it is safe to say that most do.

Possibly Related Posts:


Programming

Comments are closed.