Writing Dependent WordPress Plug-Ins

WordPress is a fantastic system in many ways, but one place that it’s really lacking is the ability to extend existing plug-ins. There is no built-in system of dependency when it comes to WordPress plug-ins, unfortunately.

Therefore, if you’re thinking of adding on to an existing WordPress plug-in, you basically have two options:

  1. You can modify the plug-in itself
    Using this method isn’t all that ideal, because any changes you make will obviously be overwritten whenever the plug-in is updated.
  2. You can write a plug-in that attempts to depend on the other plug-in
    With this method, if something changes in the other plug-in that causes your dependency check to fail, you could end up breaking the WordPress installation (which results in a blank white screen on most installations)

I would love to see WordPress implement some sort of dependency check or prioritizing method for plug-ins similar to the way they’ve implemented the method of using javascript and stylesheets. Sadly, though, there seems to be opposition from the development team because of too many unforeseen variables in the process.

Therefore, if you’re dead-set on trying to write a dependent plug-in for WordPress, you’re going to have to try some workarounds. If you’re going to choose the second option I mentioned above, you’re going to have to first make sure you examine the plug-in you’re planning to extend. You need to understand its classes (if it uses PHP classes), its variables and its constants.

Then, you need to write some code that checks for the existence of one of those items (hoping that they aren’t removed from future versions of the plug-in) and stop execution of your plug-in if they don’t already exist.

I would also recommend using a WordPress action like admin_notices to output an error message for users to inform them that they need to activate the other plug-in in order for your plug-in to work. Although there is no real documentation on the admin_notices action, it is fairly simple to use. You can take a look at the WP Super Cache plug-in and the Google XML Sitemaps plug-in for examples of the admin_notices action being used.

To use the admin_notices action, simply write some code like:

function my_custom_error() {
    echo '<div id="My_Custom_Error" class="error fade">
        <h3>My Error Headline</h3>
        <p>This function should echo an error message that will appear
        at the top of the administrative dashboard. You can use some
        conditional code to check which admin page is currently being
        viewed if you want to make sure it only shows up on a specific
        page.</p></div>';
}

add_action('admin_notices','my_custom_error');

Once you’ve written your plug-in and are ready to test things out, you need to make sure your new plug-in’s name is alphabetically lower than the plug-in on which it depends. WordPress appears to activate and execute plug-ins in alphabetical order, so if your plug-in appears earlier in an alphabetical list than the plug-in on which it depends, it will always fail.

Start out by de-activating the original plug-in and activating your new plug-in. Then, check to make sure that your custom error message appears and is formatted the way you desire. Once you’ve done that, go ahead and activate the original plug-in and start testing your new plug-in’s functionality.

It’s far from perfect, but hopefully it will work for you until the WordPress team figures out a way to build in plug-in dependency checking.

One Response

  • Nice tutorial. Will be useful for the new plugin I am planning to build.