Software, Development, and WordPress

Handling The Fragmentation of WordPress Versions, Themes, and Plugins

For the past few weeks, I’ve been talking about the decision to migrate away from the WordPress Plugins Repository and move back to the premium model similar to what I once offered. The truth is, this is going to introduce a bit of WordPress fragmentation which may not be a good thing.

If you’re just catching up on this, here are a few articles about the migration:

I’ve enjoyed the discussion around all of this, but there’s one problem that is introduced when developers opt to move away from the central WordPress repository.

It introduces fragmentation into the market.

My Stance on Fragmentation


Fragmentation. It basically looks like this (but less blue :).

Before getting into the challenges that fragmentation introduces, I wanted to share my stance on it:

Simply put, it depends.

I think some are completely fine with fragmentation; others, not so much, but the truth of the matter is that fragmentation yields both positives and negatives.

Case in point:

  • In the Android marketplace, fragmentation introduces a significant challenge to users as well as developers because the average user isn’t really sure which version they’re using (all vendor customizations aside) yet all apps are listed in Google Play. Compatibility, upgrades, and features are major issues.
  • In contrast, the iOS marketplace isn’t nearly as fragmented because, generally, every iDevice is running the same operating system. This makes for a consistent experience for users, developers, and vendors.

If that sounds as if I’m pro iOS, I’m not. I’m trying to stay agnostic a simply share the facts about two marketplaces each of which are fragmented differently and demonstrate that fragmentation can yield different results.

Perhaps it’s unfair to try to draw an analogy to general case of fragmentation by looking at a single market, but I think there are principles that are represented in the mobile device market that are applicable elsewhere.

And here’s what it is: Fragmentation can yield innovation because newer versions provide developers with new tools which, in turn, introduce a set of new utilities to users.

Lack of fragmentation may stifle innovation, at least to a degree, because you’re waiting for the latest and greatest to come down the pipeline and it could be a significant amount of time before that happens.

Simply put, innovation may take longer.

WordPress Fragmentation: Versions

But how does all of this fragmentation come into play in the WordPress market and, more specifically, for theme and/or plugin developers or who looking to segment themselves away from the core repositories?

First, note that there’s a couple of ways to look at how WordPress is fragmented. It’s not just in the marketplaces.

WordPress Versions

Look at how many are still on 3.0 alone.

For the most part, this may not matter. Though I don’t think that you can force users to upgrade, there are obvious benefits for doing so for both users and developers.

First, you have to acknowledge that WordPress is fragmented in and of itself. According to the latest data, there’s a relatively wide variety of versions of WordPress being used.

Having multiple versions of WordPress available somewhat forces the hand of the developer when creating themes and plugins to decide which versions they are going to support because the API does change from version to version.

Now, Back To Plugins

Finally, the crux of the problem for plugins can be broken down into two areas – the user and the developer.

For The User


Tron fights for the user.

The WordPress Plugin Repository is a fantastic resource for users. It’s a centralized place that they can search, download, and install plugins to help introduce functionality into their blogs.

It has it’s obvious set of challenges for developers, but you have to admit that it’s an awesome place if you’re a user.

Developers, Developers, Developers!


Developers! So much obligation for this.

Introducing your own marketplace – whether you’re a larger company or a single developer – is making the end user’s experience more challenging because they no longer have a single place to go.

We’re faced with the challenge of making people aware of our site and our products, and users are forced to move from a centralized location not only to download the product, but to receive support.

This doesn’t necessarily mean that the experience is bad – we’ve obviously discussed the challenges of supporting free plugins – but we do have our work cut out for us: Aside from working to market ourselves and our work, we also need to make sure the user’s have the most pleasing experience that they can when interfacing with us or our teams rather than the WordPress plugin repository.

“And Your Point Is…?”

All that say that I definitely see the merits and advantages of having the centralized repository. And I’m not someone who is staunchly against the repository, either. Obviously, I think it’s great for the users.

But as someone who is attempting to provide products to other users via that channel, it has its shortcomings.

Ultimately, I urge anyone who is moving away from the marketplace to give some seriously deep thought into why you’re doing it, how you’re going to do it, and what kind of value you’re going to be bringing in doing so.

Truth be told, that’s why I’m taking my sweet time in doing so.


  1. Adam W. Warner

    Tom, you raise some very valid questions here and this has been a subject that our team has been focused on with the upcoming launch of our own plugin marketplace.

    We are laser focused on three things in order to mitigate fragmentation:
    1. High Quality and Tested Code –
    Whether it’s a free plugin in the repo, or a premium version, if it works across as many install configurations as possible, then we’re doing things right for the users and lessening our time spent on the two other points below.

    2. Documentation –
    Of course, we know it’s impossible to avoid issues with all uses-cases or expectations of the end user. We’ve found that a mix of written and visual (screencast) docs have done wonders to give the end users the answers their looking for straight away. Mix this with “requiring” that users check a box before submitting a support ticket that says “Yes, I’ve read the docs and FAQs”, serves at least as a reminder that they can help themselves.

    3. Fast Customer Support –
    When we launched our first premium plugin, we were immediately swamped with support requests and it quickly became apparent that we needed a larger team, and people dedicated to support exclusively.

    That said, we know that having repo and premium versions still present fragmentation in terms of support channels. It’s a rock and a hard place that we’re still trying to figure out definitively.

    • grappler

      Hi Adam,
      How do you do your documentation? Do you use a plugin or just simple post?

      @Tom A interesting discussion would be what the best way to create documentation is.

      • Adam W. Warner

        @grappler, we are currently using a mix of pages with written and video content for documentation. FAQs are being handled by the FAQ Manager plugin by @norcross.

        • grappler

          @adam I have a second question for you. I find that testing can be a chore. The testing data that Tom’s team created is great. How do you make sure you have tested for every scenario? Do you have a quality check list or something?

      • Tom McFarlin

        @Tom A interesting discussion would be what the best way to create documentation is.

        Oh, it’s coming :). I’ll even be sure to link back to this comment to make sure others know you guys are interested and that we’ve been discussing for it a while.

    • Tom McFarlin

      Thanks Adam – love hearing these points especially from someone who’s in a similar situation.

      Although I’m not looking to introduce a marketplace, per se (assuming a marketplace is defined where you guys are going to sell your own and others), I am looking to begin a place to sell and manage my own work.

      To your points:

      1. High Quality and Tested Code

      This is something that I wish people spent more time doing. My own team does an extensive amount of this, we’ve released some of our own test data, we undergo several cycles, and we’ve even done some user testing, but we still miss things.

      I can only imagine what it’d be like if we simply released stuff with doing very little.

      2. Documentation

      This is an area that I plan on discussing more in the future because I think it there are different personas (users and developers) and different learning styles (auditory, visual, reading) all of which factor into learning how to use a tool.

      3. Fast Customer Support

      Yes! This is something that cannot be underestimated. I don’t understand why so many companies fail to see this.

      The way I see it:

      A company provides a service to users
      The users pay the company for their product
      The company survives based on its user base
      The company should treat the user as a first class citizen

      For whatever reason, we’ve got this backwards.

  2. Kevin Marsden

    If the fragmentation of WordPress is this big, I can’t imagine what it’s like for premium themes and plugins. For a basic website, upgrading WordPress takes less than five minutes (assuming you already have a good backup). On the other hand, upgrading premium themes and plugins is a hassle. At a minimum, you have to do the following:

    – Keep track of versions
    – Research changes
    – Download new release
    – Test new release
    – Ensure any customizations or child themes aren’t affected
    – Upload the upgrade to your server

    Because of all of this, I’m assuming that the vast majority of the premium theme and plugin buyers never upgrade their products until something breaks.

    The bottom-line is that we’re a bit spoiled by the ease of centralized WordPress updates; it makes manual updates seem like a big hassle.

    • Adam W. Warner

      Good theme and plugin authors build in the auto-update feature;)

    • Tom McFarlin

      You’re not wrong, but perhaps I can provide a slightly different perspective.

      My team and I work on Standard and have for about three years.

      We generally try to make sure that we’re compatible with the most recent versions – that is, say the last two or three versions and the most current version – but are clear that that’s all.

      We have to set our customer’s expectations because we can’t leave legacy code rotting in our codebase. We also want users to have the most recent version of WordPress so they (and we :)) can take advantage of new features.

      To that end, we’re also very clear in our upgrade instructions, FAQ’s, blog posts, comments, etc., about what our stance on this.

      The bottom-line is that we’re a bit spoiled by the ease of centralized WordPress updates; it makes manual updates seem like a big hassle.

      This is true – and implementing it into your own plugin or theme is not an easy task. We’ve tried a couple of different strategies, but have yet to settle on one that we really like.

      As such, we’re overly communicative in our forums, Twitter, and blog about releases.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑