The WordPress plugin API is vast and powerful. It allows developers to essentially hook code into almost any area of the WordPress system without modifying the core files at all. It also allows for the creation of standalone plugins that work within the WordPress system but do not hook into the core modules.

Over the last few weeks, WordPress plugin development has become one of my favourite things to do. I find it exciting to be able to create functionality, incorporate it seemlessly into the WordPress system and see it work smoothly with the other modules. While plugin development for WordPress is incredibly powerful, it also carries with it a few areas where people commonly stumble over and potentially lose interest in their code… which could be the next big thing. Here are a few guidelines I’ve picked up in order to step over the stumbling blocks.

1. Understand actions, filters and hooks, where to use which action and their limitations.

Actions, filters and hooks are what allow developers to insert their code into virtually any part of the WordPress system. While there are only almost 400 hooks documented, there are in fact around 800 hooks in the WordPress system. The WordPress codex has a great reference for actions, filters, hooks and how to use them.

2. register_activation_hook() does not function the same way as add_action().

While looking through the WordPress forums, the register_activation_hook() function (runs the function you pass to it when the plugin is activated) has come up as a regular topic of conversation. Users are attempting to display text on activation, using it as if it were the add_action() function. register_activation_hook() does not function the same way. The function, the way I understand it, works in an almost overall scope, not having access to variables within your plugin for display purposes. In short, don’t try to echo or print variables with this function. It won’t work. The function is best used for doing common setup such as installing database tables, setting default options, etc.

3. Use dbDelta instead of mysql_query or $wpdb->query() when installing database tables.

The dbDelta function (which you pass your database query to) is used when installing tables into your WordPress database. It is also used as an upgrade script in the same area. Don’t forget to include the WordPress upgrade script before running dbDelta(). The include looks like this:

require_once(ABSPATH . 'wp-admin/includes/upgrade.php');

4. Understand the scope of your plugin and work within it.

As mentioned above, WordPress plugins can be used to hook into essentially any area of the WordPress system. This includes standalone menus, as well as running actions when a post or page is saved, for example. Understanding the objective/s and scope of one’s WordPress plugin is essential to choosing the correct approach for the plugin. If it’s a short plugin with specific objective, there’s no need, in my opinion, for more than one or two files. Keep it simple. On the other hand, if the plugin is a large, standalone module, I don’t believe there’s any reason to have cluttered files of hundreds of lines of code, where an Object Oriented approach would ultimately serve as a much cleaner and more extendable solution.

5. Plan, plan, plan.

Planning on paper, drafting a code map on screen, talking it through with other developers. Planning a plugin can never be done too much. It helps with all of the above steps as well as helping to see where you need to be at the end of the development and planning a solid roadmap for the journey to get there. Also, other users may have ideas that could streamline your plugin even further.

These are just a few things I’ve picked up on my WordPress plugin development journey. I’ll post more if and when they come up. I hope these tips are useful and help in overcoming the potential stumbling blocks when getting started with WordPress plugin development.