Practical WordPress Development

Not Everything Can Be a WordPress Plugin

One of the things that I – and most developers, designers, and implementors – love about WordPress is how easy to is to implement new functionality through the use of plugins.

Yes, I’ve shared at length my thoughts on the plugin economy and it’s not coming from a point of disdain. Of course not. It’s coming from a place of appreciating something, wanting to see it being made better, and simply sharing gaps in experience.

But a second thing that I’ve begun to notice is that people want plugins for everything – even things that I believe should remain core business logic.

Why Not Everything Can Be a WordPress Plugin

I – as I’m sure many developers and designers in the WordPress space – have received emails, comments, tweets, or some form of communication as to why any given piece of functionality can be made into a WordPress plugin.

For example: Let’s say that I provide some instructions on how to enforce a Single Widget in a WordPress sidebar. Now, this isn’t to say that something can’t be made into a plugin – the truth is, many things can be – but not everything should be a plugin.

With last year’s State of the Word about WordPress becoming an application framework, with my own perspective on the matter, and with the recent developments on WordPress in 3.7 and 3.8, it’s further proof that WordPress is continuing to evolve to into a platform on which web applications are built.

On one hand, this is fantastic because it’s going to allow us to build more mature applications that are typically relegated to other libraries, frameworks, and foundations that are currently available.

However, this is also going to either “separate the men from the boys” (which is a cliche I tend to hate because I feel like I’m likely right around the pimply adolescent with braces), or, rather, it’s going to result is people creating some incredibly creative solutions to problems built on top of the platform that was once designated for publishing.

What’s The Point of This Diatribe?

So here’s the thing: If WordPress is moving into more of an application foundation or even application framework, then there are going to be something things that continue to work well as plugins, extensions, or whatever you want to call them.

However, there are also going to be certain things that simply aren’t deserving to be a plugin for two reasons:

  1. It’s not general enough that it warrants being developed as something outside of the core business logic.
  2. The specificity of a given requirement on how to achieve something may make a great tutorial, blog post, or guide, but doesn’t necessary quality itself as a plug-and-chug solution.

The reason I bring this up is simply this: I’m beginning to see more and more people see code snippets, tutorials, and how-to’s, and basically say “hey this great, can you make this a plugin?” Or something such as “Can you make this into a plugin?”

And the short answer is “No.” Honestly, if I could make it a plugin, I would, you know?

But if you’re looking to be a developer and you’re looking to build things for others, then you’ve got to draw a line at some point and learn how to think creatively about solving problems, and craft the necessary pieces by hand in order to satisfy your customers.

Anything less than that is going to provide them with a generalized solution that is either going to be too general for their needs, or it’s going to fall short of what they need.

Stay Hungry

I know that many people out there love WordPress and there’s even a bit of a gold rush going on right now. I urge you guys not to stop learning.

Stay hungry for that insatiable desire to get better at what you do – at building things for WordPress. Rather than looking at the band-aid solutions or the quick turn around, realize that not everything can be a WordPress plugin.

Build your clients specific, well-designed, focused solutions.

In the end, both you and they will be better for it.


  1. Eric Dye

    You’re always thinking ahead.

    Great thoughts, Tom. Thanks for sharing.

  2. W

    What a racist, offensive illustration accompanying this post.

    • Tom McFarlin

      Apologies and removed. No offense meant – just an internet meme by a comedian.

      • John Saddington

        I don’t see a need to apologize. If the image was the only thing this person “got” from the point then he/she/it’s doing it wrong.

  3. Chris Howard

    Heheh. Guilty. Do find having to reign in my enthusiasm to pluginify everything.

    On a similar note, and something I’m also guilty of, your plugin doesn’t have to do everything.

    Encountered that yesterday. Needed a function on a client site that I new I could add to one of my own plugins and was going to, but then thought – it will need more options which will that then just add to the end-user complexity?

    So, I bit the bullet and just wrote the necessary function for the client site only.

    Likewise I think I’m too willing to accommodate too many customer’s feature requests.

    Again, thanks Tom, another great post remind us on smart practices.

    • Chris Howard

      *knew! Dang.

    • Tom McFarlin

      On a similar note, and something I’m also guilty of, your plugin doesn’t have to do everything.

      Exactly! At least not at first. Aim for that strong 1.0, lay that foundation, then build on top of it.

      We’re all guilty of getting excited and adding this and that and this and that until all of the sudden this neat idea we had has morphed into something greatly different than we originally envisioned :).

      Anyway – thanks for the comment. Love hearing from people working through the same things.

  4. Myke Bates

    Just some food for thought: I think we should be careful in making some of the claims in this article. Don’t get me wrong, I agree with the main point here but to blanket it by saying domain specific logic should not be turned into a plugin would be incorrect. Most times it SHOULD be a plugin but a plugin that is only to be consumed by the specific site as opposed to the plug and chug (repurposed for the masses) type plugin, as you mentioned.

    Great write up!

    • Tom McFarlin

      I really like what you’ve said and agree with it. Especially this:

      but to blanket it by saying domain specific logic should not be turned into a plugin would be incorrect.

      Your point on relegating the domain specific logic into a plugin is correct, but I do feel as if the term has been polluted in the context of the wider WordPress economy.

      For example: When a person says they are writing a plugin for WordPress, most consumers would assume that it will work for their site; whereas, you can have site (or application)-specific plugins.

      Whenever I’m working with a client, I’m very explicit in saying that something will show up in the plugins menu but it’s really just tooling or a tool for their specific site.

      At any rate, thanks for the comment – I think you’re spot on and appreciate what you’ve said here.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑