When it comes to selling a theme for both WordPress.com and for self-hosted installations, one of the questions that I find myself asking is:

“Is it worth maintaining two repositories for the same theme?”

And I wonder this because when it comes to maintaining a codebase of a theme on WordPress.com and a version for the self-hosted version of WordPress, you can make the case that there’s no need to have a difference in the version of the themes.

But for anyone who has worked in both variants of WordPress, then you know there’s actually little bit in variation.

Two Versions of WordPress Themes

First, I’m always of the mindset that if you’re going to be selling a copy of your theme – or any software, really – in a marketplace (such as the App Store, even), then you have to play by the rules of that environment.

If they’re bringing the market, and you’re bringing the product, then they set the rules. Easy as that.

When it comes to WordPress.com, there are a number of different things that dictate how you build features into your themes. Some of these include how the options are organized in the Theme Customizer, what options can be made available so not to interfere with other paid options in the WordPress.com marketplace, and so on.

Of course, this isn’t a criticism WordPress.com, either – it’s a fact of the marketplace. This could just as easily be ThemeForest, Creative Market, Mojo Themes, and so on.

On one hand, there’s a strong case to want to maintain a single copy of the same theme to sell for both hosted and self-hosted installations.

Think about it:

  • A single repository for the source code
  • One place to manage issues
  • One place to maintain pull requests or commits
  • A single way to manage tags and releases
  • …and so on.

But as nice as that sounds, it comes at a major expense: you lose the flexibility that comes with self-hosted installations.

Just as we have to play by the rules of the marketplaces in which we sell our work, those restrictions don’t exist for self-hosted installations. To that end, we’re able to offer our own set of unique features (or even potential upsells), how we organize the features, and other ways in which we architect the product.

In fact, some may say that the versions of the theme that are offered in marketplaces are “lite” or “lighter” versions of themes that are offered for self-hosted installations.

But, again, this comes with having to:

  • Have a second place to keep the source code
  • Track multiple support forums
  • Juggle different sets of bugs and issues
  • Multiple ways to tag releases
  • …and so on

And, coming from experience, I know that this can eventually reach a point where the code bases diverge to the point where they feel like different products.

Perhaps they are, perhaps they aren’t – I guess it depends how you look at it, but I digress.

But it gets to be significantly more work to manage two versions of the same product the longer they exist, and the more mature they become over time. No, it doesn’t necessarily have to be that way, but I think the case – more often than not – is that it is.

So should the extra work that comes with maintaining separate code bases for market-based products and self-hosted installations dissuade us from maintaining two variations of the project?

Personally, I think in the direction of no, but I think those who are looking to do so need to know what it is they are getting into as it relates to managing multiple variations of WordPress themes.


Join the conversation! 11 Comments

  1. I sell themes on wordpress.com as well (under pro theme design). When I first started I had two versions of each theme – but it got more and more frustrating keeping them in sync – so eventually I retired the non wordpress.com version and transitioned everything to a single code base.

    If I want to add additional functionality that can’t be done on wordpress.com then I would use a plugin – but so far I’ve not found a need. If you make sure you integrate all of the jetpack functionality then you get all sorts of things like featured content, infinite scroll, and social links integrated in a standard way. And they’re working on adding additional custom post formats to Jetpack. All of that combined mean I don’t need to worry about 2 versions. There’s enough there to keep me busy without adding a second version into the mix :)

    • In keeping with the plugin idea, I think that it’s not a bad idea, but then it does raise the question of if you should bundle the plugin with the theme and activate it (and deactivate it) when the theme is activated or deactivated, or offer the users the ability to download or even purchase the additional functionality.

      Then you’re getting into the realm of should the plugin then support multiple themes or just a single theme?

      Personally, I’m of the mindset that it’s absolutely fine to have a plugins made for a single theme, but that’s a whole other post :).

      • Since I want to stick to one version of the theme I would not do any auto enabling or anything like that. For me it’s important to keep things as simple as possible so I would simply have an optional plugin – that only works for that theme – that the user can install if they want the additional functionality.

  2. Well it depends on what your goals are. You’ll have to ask yourself if the required additional work of maintaining two code bases, the additional support that this requires and everything else is worth it for you because you’re getting more exposure, maybe more direct revenue or anything else. I think when someone’s only starting out, they should have a presence on all marketplaces so they can establish their brand(s). Then once you have enough customers, you can go the Array way ;)

    • For the most part, I agree with you, but this point has some difficulties to it:

      I think when someone’s only starting out, they should have a presence on all marketplaces so they can establish their brand(s). Then once you have enough customers, you can go the Array way ;)

      Obviously I’m a use fan of Mike (and the work at Okay Array), but going into every marketplace can be difficult mainly because many of them are either selective about who they take in, have rules of their own about which each developer has to abide, and fragments the customer base so support is spread out across a number of forums (which makes it difficult for both the developer and the user :).

  3. About the only solution other than having two versions, that I could see, would be to have the base functionality in the ‘lite’ version of the theme and then provide the ‘extra’ functionality via plugins.

    The downside being that a user of your theme would also need to install the plugins to get the full functionality.

  4. At Automattic, we face the same challenge. ;) Outside of WordPress.com, we also have themes at the WordPress.org Theme Repository, Creative Market, and other external market places.

    Like Ben described above, we also maintain themes in one place and use a small amount of compat files (like for Jetpack) to add support for .com features on self-hosted installs. We then use the “deployment” step (read: creating a zip and uploading it) to bundle the correct files.

    There’s also the possibility to do it the other way around, with a WordPress.com compat file. If we find a inc/wpcom.php or includes/wpcom.php file in a theme folder, that file will be loaded automatically (and does not have to be included from functions.php).

    • It’s good to know about inc/wpcom.php or includes/wpcom.php files. Thanks.

    • There’s also the possibility to do it the other way around, with a WordPress.com compat file. If we find a inc/wpcom.php or includes/wpcom.php file in a theme folder, that file will be loaded automatically (and does not have to be included from functions.php).

      This is exactly how I have things setup in Mayer (by that, I mean inc/wpcom.php) which makes it really easy to keep stuff centralized.

      It’s nice to know you guys at Automattic are think about this stuff as well, and I dig hearing you guys chime in if for no other reason to see how it’s happening on the other side of the fence :).

  5. In ideal world you’d have only one theme codebase and use it on WP.com and WP.org. I agree with Ben and those are the direction I’m moving also. I also blogged about how I became WP.com theme author.

    But there are lot’s of cases we still need two different code bases or little different themes. For example if you want to support plugins like EDD, bbPress or Restaurant you still need to rip that code of before sending it to WP.com.

    • I’m with you – it’s a tough spot to introduce a variation of a theme that has support for great third-party plugins while also maintaining the same code base.

      At this point, I honestly think it’s a bit inevitable that we’ll be able to get away with a single code base; however, this raises the question then as to if keeping the theme name the same is clear for our customers.

      For example, can the average blog / WordPress / CMS customer distinguish between “hosted” and “self-hosted?”

      In my experience, it’s actually kinda tough because the terminology used to describe the two are different, so when I’ve tried to break it down for my friends they end up getting confused.

      Of course, I’m not above admitting that it could be my fault at doing a poor job explaining :).

Leave a Reply