W-Shadow.com

Lets talk about that plugin-related code you have to put in your theme files when you want to add something nifty to your blog, like a “Related posts” feature or AdSense ads. It occurs to me that most plugin authors have been handling this the same way – you get a custom function that you need to call from somewhere in your theme. This works, but I believe it isn’t The Right Way. In this post I’ll discuss why custom hooks and do_action() are better both for the developer and the end user.

First, using the WordPress hook system automatically prevents problems with missing and undefined functions. If there is no plugin to handle a do_action call then, quite simply, nothing will happen. On the other hand, if you use a plugin-specific function in a theme file and the plugin happens to be unavailable (deactivated or deleted) you’ll get an error message and probably a broken page. This can be avoided by checking if the plugin’s function is defined before calling it, but many plugin authors forget to mention this crucial detail in their documentation. If they used custom WP hooks this problem simply wouldn’t exist. Also, do_action('func_name',arguments); is at least 11 bytes shorter than if(function_exists('func_name')func_name(arguments); 🙂

Another advantage of WP hooks is that they provide a unified API. If most plugins used hooks instead of custom functions then eventually it would become much easier to seamlessly test and replace plugins that do the same thing because, hopefully, a system of common plugin-related hooks would arise. For example, if all plugins that display related posts would hook “related_posts” instead of requiring their own special function calls then you could easily test various plugins without editing your theme every time. Theme designers would also be able to use this hook to ensure that related posts appear in the right place if the user decides to install a plugin like that (and the designer wouldn’t have to know which particular plugin will be used).

Finally, from the developer’s perspective, using hooks allows for better plugin architecture. And by “better” I of course mean “object-oriented”, though feel free to disagree – if you use a hook it doesn’t really matter what design paradigm your hook handler follows. The user doesn’t need to know if the feature they want should be invoked as a simple function, an object method, or a static call. You can implement it any way you like. And if you ever feel like renaming your functions or objects – because of conflicts with other plugins or just to make the code more readable – you can do it without forcing your users to edit their themes. It’s a win-win.

Of course, I’m not exactly a renowned WordPress guru with thousands of readers, so it’s unlikely that every plugin writer will immediately embrace my brilliant idea. So, if you think my suggestion has merit, I would appreciate it if you … ah, mentioned it on your blog and stuff 🙂 And even if you think this idea sucks, do let me know why by perusing the comment form below.