One thing I’ve struggled with in the past when creating WordPress sites, is where to draw the line between the code that should be added to a WordPress theme and what should go into WordPress plugins. It’s usually not an issue on a smaller sites such as my own site, but when you start developing larger and more complex sites, things can get a bit hairy.

I’ve worked on projects where we built everything into the theme. I’ve also worked on the complete opposite where almost the entire site was created using plugins. Naturally, the majority of the projects that I’ve worked on have gone for a hybrid approach of using both.

The hybrid approach is the one that causes the most confusion, because the line between what goes where doesn’t really exist and constantly changes.

Although all approaches have their merits, these days I feel quite strongly about creating modular plugins rather than sticking everything in the theme or going hybrid. There are a number of reasons for this that we will get in to shortly. Again, this doesn’t really apply to smaller sites but bigger feature rich websites.

The relationship between features and functionality

Traditionally when we think of WordPress plugins, we think of them as enablers which add additional functionality to WordPress. They extend WordPress. These plugins usually serve a purpose behind the scenes. This added functionality in turn can become features if it’s integrated into your theme.

I mostly like to think of plugins (especially the majority of plugins in the repository) as how you are able to do things (i.e. your functionality) where as features are the result of implementing that functionality and are what the user is able to do.

So, it’s quite clear that when building something that is going to extend WordPress, it should always be created in a plugin. The grey area here is the code that does not extend WordPress, but rather turns the available functionality provided by WordPress and 3rd party plugins in to features that your users love.

WordPress plugins as features

Now that we’ve cleared up what features are (the what and not the how), how should we implement them? Plugins, themes, hybrid? Like I mentioned above, I feel after working on many different WordPress projects, that plugins are the way to go. Why?

  • Your website/application becomes modular. Every little piece of your site is broken down in to features which you can easily turn on and off. You simply just activate or deactivate the plugin.
  • It forces decoupling of your code. Coupled code is usually bad. By writing your site features as individual modular plugins, it forces you to write code that is independent of any other feature that you’ve built out in it’s own plugin. While it’s possible to couple two modular plugins, it’s far more difficult than if you where to have all your code in a single theme or plugin.
  • It’s much easier to maintain features. Because each plugin usually serves around 1 or 2 features there is far less code to look through when debugging. It’s also easy to find something that you’re looking for in your codebase because you will know which feature it is part of. Refactoring is a breeze!
  • Another unusual side benefit is that I’ve found that it helps me define my classes in my code. Because each plugin has laser focus on it’s purpose, it’s usually quite easy to apply meaningful names to your classes and methods.

What could go wrong?

While all the above sounds great, there are some drawbacks to the approach too.

  • If you’re not careful and you get too granular with your feature plugins, you could end up with hundreds of plugins. This becomes a bit of a headache to manage. There is a fine balance between too much and too little modularity. It takes time to get a feel for the right amount.
  • Since your theme basically becomes your controller, it can end up with a lot of if/else to check if a plugin is enabled or not. Wherever possible try to make sure modular plugins use actions and filters. You should be doing this already in any case.

The purpose of the theme

So now that everything is built into nice and neat modular plugins, where does that leave the actual theme. Again my thoughts on this are strong. The theme should only contain “view code” i.e. theme files and styling. Your functions.php is going to be quite bare as all the heavy lifting is done using plugins.

By adopting the above approach to building websites on WordPress, I’ve definitely found that they’ve been far more manageable and maintainable.


Join the Conversation


  1. Interesting article. I generally write a couple of plugins to make my code reusable. A plugin that define a library that all others plugin may use, classes and helper functions ( what your thought about helper function ? ). The theme at least use only the plugin functions to get the data and show that on front end. I write a starter theme that define only a base structure of the site pages and everything else are hooks. I agree with you that focusing on hooks is the way to make your code reusable and maintenable.

    Recently the WordPress plugin review team decided that every plugin must include all libraries that it use rather than classes like Tgm. What’s your opinion about that?

    1. Thanks for the comment Guido!

      For helper functions, I usually make them static functions within a plugin. I don’t really make them globally accessible or use them in a global context as that would couple the plugin to another plugin. The downside is of course you may have some duplicated functionality. I think it’s a fair trade off though. I would rather have some duplicated code than coupled plugins. It goes without saying that we should leverage as much core WordPress functionality as possible.

      I’m not too familiar with Tgm, but I think the decision that they took is exactly inline with my thinking. If you’re installing a plugin, it should extend WordPress and not just enable you to extend WordPress in an easier way. Modular plugins that function independently from anything else are what I advocate.

      I’ve never been a big fan of plugins which do a developers work for them using an interface.


  2. Completely agree with your approach, and your reasoning. If there was one thing I could improve about the WordPress community, it would be more education around this very concept.

    I do think more theme developers are moving in this direction, though. Which I think benefits the entire community (devs and end users).

    Great piece, Matt.

    1. Agreed Dave!

      I definitely plan on doing more in-depth articles on this topic with some video examples.

  3. I’ve been thinking about this a lot lately. Do you use the mu-plugins directory? I’ve been using this area more and more.

    Some rules of thumb I use when deciding where to put custom code for a specific site:

    * Plugins should be easily removed or replaced. The site should not break if any plugin is deactivated.
    * Themes should not diddle with content management. Any custom content types, widgets, shortcodes, user roles, or workflows that are absolutely core to the way content is organized on the back-end should be defined in the mu-plugins directory.
    * If some functionality could be re-used on other sites without much configuration and no dependencies then I would consider creating a regular plugin out of it which could be published on This is quite rare though.

    1. Great thoughts Cornelius! I definitely agree.

      To be honest I don’t use mu-plugins much for a single, simple reason. It really bothers me what the main plugin file has to be in the root of the mu-plugin directory. I know you can just use an include path, but I still find it messy and silly.


Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.