Making Developer-Friendly Themes and Plugins

Commercial Themes / Plugins

When I was a freelancer, I used to think commercial themes were the bomb. They had everything: sliders, tons of short-codes, page templates, page builders, the works… However, the more I learned about WordPress, I learned the first and major problem of commercial themes is their ability to be extended. The objective of a business is to retain it’s customers, and what’s the easiest way to do that? Do not make your theme developer friendly!

Nowadays when a developer sees a commercial theme, he’s going to do one of three things: make the theme his own so he can write the code to his specifications, make a child theme and risk spending tons of extra hours fixing the core theme anyhow, or spend hours on end reading the documentation (if any) on the theme to set it up how the client wants it, if that’s even possible.

I could go on and on about commercial themes, but in short, most of the time a theme from these top sellers are not extendable. There are usually very little to no filters/actions beyond what WordPress already offers. Sometimes it’s just an oversight on the developer’s part, other times it may be a business decision which I understand, but I believe in ALWAYS writing your code as if another developer will need to add to it or take away from it later.

I want to conclude this section in saying not all commercial themes are bad, just do your research before you decide “This has everything, I’m gonna buy it!”. Do you really need thirteen sliders?

The WordPress Way

WordPress has two very nifty methods, which I’m sure you’ve used their counterparts, add_action and add_filter, which are do_action and apply_filters. So many times when working with a theme have I wished a filter was used, but most of the time it’s not.

Most of the time, you can create a child theme, and overwrite the template you’re working on, adding in the filter you need. However, if the filter/action you want to add resides in the functions file (functions.php) you have to literally replace all functions with your own, and replace all calls to those functions everywhere they’re called, in turn bringing more files into your child theme. Before you know it, you’re in a spider web of function calls. I’ve been there. Plugins are double hard to muck with, it’s even harder to extend a plugin, and you’re absolutely limited to what the plugin developer has allowed you to modify.

 Hooks are provided by WordPress to allow your plugin to ‘hook into’ the rest of WordPress; that is, to call functions in your plugin at specific times, and thereby set your plugin in motion… – WordPress.org

You are usually using these hooks to edit the core functionality of WordPress in certain circumstances, but, these hooks aren’t just for hooking into things. They’re also available so other plugins can hook into your content.

What to use, and when to use it!

Always think of the future use of your plugin or theme. If it’s a form, maybe a user may want to add more fields later down the road or maybe some sort of authentication method that a developer will need to hook into. There’s absolutely no reason you cannot hook into it and provide data related to the function/display call.

I personally use the do_action method sparingly when I create themes or plugins (plugins mainly because I’m no designer). My rule is that if a user wants to output content that is displayed and shouldn’t need to edit content, arguments, or some other setting in the current context, then I use an action!

The apply_filters method, on the other hand, is always in my back pocket. This is really handy for allowing another developer to overwrite output, modify custom queries, and tons more things. My rule here is to filter all the things…not kidding. If I’m running a custom post type query somewhere on the site, it has a filter; if I’m outputting stuff to the front-end, it will have a filter. Though there are special cases that I don’t use filters such as option panels and other settings related pages. If you’re using CMB2 for this, that’s handled for you…you are using CMB2, right?

Conclusion

The above methods are not the be-all, end-all methods of extending plugins and themes. PHP itself has some very nifty things up its sleeve such as Class Extensions and Implementations, or, if you’re the stickler for formatting, but still want extendability, Abstract Classes is the way to go. (Thanks to Ben for that one!)

Bottom line: You have zero reasons for not making your plugin or theme developer friendly. Yeah, sure, we can extend your theme to no end, but if it’s a pain in the rear, we will more than likely fork your theme, and make it our own. And when it comes to plugins, please, I’m begging you, please make them developer friendly! Think of the future people, please?

If you have your own methods to make a theme or plugin is extendable please do share. I love knowledge–you can never have too much of it!