On WordPress Plugins and Extensions

From a consumer perspective, WordPress is as attractive as it is because of the number of plugins that exist for it. From a developer perspective, WordPress is as attractive as it is because of how easy it is to extend the core application through the APIs.

They’re a hot topic, too – anyone (including me and probably you, as well) who’s worked with WordPress in any capacity has their opinions on some plugins, on certain plugins, on all plugins, on the plugin directory, and so on.

But one thing that we don’t talk about very much – at least right now – is the idea of extensions. But why? They’re something that are becoming more common with various plugins and with various themes.

Plugins and Extensions

I think plugins are easy to define:

Plugins are meant to introduce functionality to WordPress core that [should] play nicely with each theme.

Yeah, there are some operative words in there, but the general idea stands true. When it comes to extensions, though, I think different people may have different definitions.

At a high-level, I think that extensions can be defined as the following:

Extensions may be thought of as plugins for plugins or theme-specific plugins – or some extensions are plugins, but not all plugins are extensions.

You can probably come up with a better definition, but the main point is that extensions can come in two flavors:

  1. Those that introduce functionality into specific plugins
  2. Those that introduce functionality into specific themes

Though there are plenty of examples of each of these; two examples that quickly come to mind are the Easy Digital Downloads extension library and the Make Plus plugin for Make by The Theme Foundry.

If you’re someone who wants to create extendable plugins and themes, then you’ll need to place proper hooks (and do_action calls) throughout your codebase, but that’s not the point of this post.

Instead, the main point is simply to bring up the question is to if this is something we, as developers, should be thinking more about when working on our projects? That is, should we be making our plugins more extendable? Is there value in creating theme extensions beyond what the standard child-theme functionality offers?

This – like so many other things – doesn’t have a definitive answer. There are going to be those who absolutely agree and those who absolutely don’t (and that’s fine), but for those who are interested in considering it from a business standpoint, does it not make sense to follow this model in order to create a lean core product and create a mini-ecosystem around your work?

No, not all plugins and themes need to offer extensions. Offering pure functionality into WordPress core and/or focusing solely on the presentation of data in the form of a theme works fine (and has worked fine) for years.

Perhaps we’re just beginning to see something become more and more common throughout WordPress. Maybe not.

Personally, I think that it’s something that’s catching on and that will become more common for a number of WordPress-based businesses. Given the right project, I think it’s something that’d be fun to try. In the meantime, though, I’m enjoying seeing how others are working with this model and seeing how it works out for them.

12 Replies to “On WordPress Plugins and Extensions”

  1. Even if you don’t plan to do the whole base/addon model for your plugin, you should still build hooks into your product all over the place. First, by its nature, building extensibility into your plugin will help you separate concerns and speed up future development. Second, it will totally cut down on the difficulty of providing support while increasing what you’re able to provide with that support.

    I have a few plugins which are pursuing this model (roughly speaking). I can not count the number of times I’ve had somone say “can X be done” and I nearly tell them no before remembering that I built a hook for that and yes, it can be done, and it can be done in a couple lines of code. That’s made a big difference in the quality of support I can offer (and therefore my base plugins’ ratings, and therefore the overall use of the plugin).

    I have also had a few occasions where people have contracted me to write small extensions. Building a product with plenty of hooks makes such extensions affordable for potential clients, and allows me to build them on top of the base code (so that the client doesn’t lose access to updates).

    So yes, I am a member of the “filter all the things” club. Because of the Child Theme system, this may be less important for themes than plugins. But I still think there are plenty of good use-cases for this too.

    1. Even if you don’t plan to do the whole base/addon model for your plugin, you should still build hooks into your product all over the place.

      I think this is true IIF you want others to be able to extend it. Sometimes, a theme or a plugin should just function out of the box as is, you know?

      That’s made a big difference in the quality of support I can offer (and therefore my base plugins’ ratings, and therefore the overall use of the plugin).

      That’s really neat to hear, too. I think that does present a really strong case as to why hooks should be built in.

      So yes, I am a member of the “filter all the things” club. Because of the Child Theme system, this may be less important for themes than plugins. But I still think there are plenty of good use-cases for this too.

      Good thoughts, Nate – thanks for sharing them. Definitely stuff to consider.

      1. I think this is true IIF you want others to be able to extend it. Sometimes, a theme or a plugin should just function out of the box as is, you know?

        Hmm, maybe I misunderstand you, but I’m not sure how a plugin built to be extended wouldn’t function out of the box as is. If you mean that the base plugin shouldn’t be crippled (as a business tactic) — well, yes, I certainly agree with you there! But there’s nothing that would prevent you from building a complete, decisions-not-options plugin that is nevertheless extensible through hooks. In fact, I think hooks are actually more useful with the decisions-not-options approach.

        I have made all kinds of decisions in one of my plugins to reduce the number of options in the settings page. Having these things filtered makes it really easy to say, “You can only set these things, because 90% of people don’t need an option for that. But if you’re the 10%, you can change it by writing your own micro-extension.”

        My gist account is full of these micro-plugins that allow for something to work dead simply out of the box with very little setup, but still allow for flexibility in edge cases.

        1.  Hmm, maybe I misunderstand you, but I’m not sure how a plugin built to be extended wouldn’t function out of the box as is.

          Oh, it would. I didn’t mean to imply otherwise. I just meant that it wouldn’t have any room to be extended or customized via other source code :).

          Based on what you said, I think we’re in complete agreement. 

           I have made all kinds of decisions in one of my plugins to reduce the number of options in the settings page. 

          Love this. I try preaching this every chance I get.

           My gist account is full of these micro-plugins that allow for something to work dead simply out of the box with very little setup, but still allow for flexibility in edge cases.

          I’ve got a ton of gists, but they’re all marked as private because I don’t want to field the comments and requests that come into them. 99% of them are shared on this blog anyway, so I use the comment field to handle them :).

  2. The extenion or “addon” is how we approached extending our plugin.

    Like anything else, there’s a fine balance between what should go in core versus the extension. We’re very aware of this, as we could possibly have a dozen plugins per site. It’s not a performance issue, but more so a setup issue.

    Forcing our end-user to install as many plugins as there are punch-hole doors on an advent calendar, isn’t nesccearily enjoyable.

    We’ve been moving to extending our themes through a plugin over the last 8 months and should have that all rolled out fairly soon.

    1. Like anything else, there’s a fine balance between what should go in core versus the extension.

      Amen.

      We’re very aware of this, as we could possibly have a dozen plugins per site. It’s not a performance issue, but more so a setup issue.

      As is the case with all well-written plugins, IMHO.

      Forcing our end-user to install as many plugins as there are punch-hole doors on an advent calendar, isn’t nesccearily enjoyable.

      That analogy … LOL.

      We’ve been moving to extending our themes through a plugin over the last 8 months and should have that all rolled out fairly soon.

      This is something I’m looking to consider with a couple of plugin rewrites and maybe even some potential themes I’ve in the pipeline for 2015.

  3. It’s hard to see how extensible plugins and themes wouldn’t be a good thing.

    I’ve wished more than a few times that there was a simple indentifier in the plugin manager for plugins that extend a specific theme or plugin. Probably some good naming and clear documentation is in order — drop-ins come to mind as another way of extending WP (with plugins that are not plugins?) that has never been very clear in name or description.

    Maybe “Theme extensions” for plugins that extend themes, and “Plugin extensions” for plugins that extend plugins? Using “extension” by itself seems too generic and non-descriptive since it’s really just a synonym for “plugin.” Textpattern had “extensions,” and WordPress called them “plugins.”

    1. It’s hard to see how extensible plugins and themes wouldn’t be a good thing.

      Right? Except for if someone comes along and does some type of extension that causes weird functionality and then they come to you for support for something you didn’t even write.

      drop-ins come to mind as another way of extending WP (with plugins that are not plugins?) that has never been very clear in name or description.

      Ah, good point. Didn’t even cross my mind while working on this post.

      Maybe “Theme extensions” for plugins that extend themes, and “Plugin extensions” for plugins that extend plugins? Using “extension” by itself seems too generic and non-descriptive since it’s really just a synonym for “plugin.” Textpattern had “extensions,” and WordPress called them “plugins.”

      I generally agree. I think the term extension is kind of taking on a definition of its own in WordPress in that an extension is a plugin-for-a-plugin or a theme-specific-plugin.

      But maybe the jury’s still out.

  4. re: “This – like so many other things – doesn’t have a definitive answer.”

    And thus the WP plugin repo is littered with a never ending list of left for dead plugins. Think about as things typically are now, even the tweak of some basic view / presentation element leads to a fork (and not a simple add-on / extension).

    Architecting and coding for “growth” – even if no one else goes there – forces the original dev to do better things; to be more mindful.

    Put another way, the best way to start a company is to put serious thought into the exit strategy. An extension based approach saves time and effort. It’s 2015, let’s stop pretending is 2005. Please? :)

    1. Architecting and coding for “growth” – even if no one else goes there – forces the original dev to do better things; to be more mindful.

      I think this is a fantastic statement.

      An extension based approach saves time and effort. It’s 2015, let’s stop pretending is 2005. Please? :)

      You’re asking to turn a huge corner with this. It can be done, of course, but it won’t be quick and it probably won’t necessarily be clean ;).

Leave a Reply

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