Cancel

Sarah Gooding

WordPress Theme Shops Move Toward Preserving Data Portability

photo credit: kthread - cc
photo credit: kthread – cc

In the old days, WordPress theme developers used to build loads of specific functionality into their themes, i.e. recipes, portfolios, testimonials, analytics, fundraising capabilities, custom post types etc. Commercial theme providers competed fiercely with one another to see who could pack the most functionality into their offerings. Many companies sought to become a one-stop-shop for everything an individual or business might need in order to launch an online presence.

The practice of locking users into using a theme by tying their content/data to the use of the theme is now highly discouraged. WordPress theme shops have slowly started to separate function from design in favor of preserving data portability.

restaurantThis past week we’ve seen more evidence of this trend as two major theme providers have released plugins for functionality that users might previously have expected to find within themes. Justin Tadlock, who has long been a vocal advocate of data portability in themes, released a new free Restaurant plugin. The plugin allows restaurants to manage a food and beverage menu and works as a companion to themes.

WooThemes released Projects this week, a new plugin to handle portfolio capabilities. They said that preserving data portability is one of the main reasons behind this decision:

You’ve probably already noticed that our product strategy has deviated to separating features and code wherever possible, shifting our functionality into plugins, rather than bundling into each theme…It also ensures your data is portable, which aligns with a core WordPress philosophy.

UpThemes’ recent open letter to the WordPress Community is further demonstration that the tides are turning in favor of data portability. In it, they openly admit that it was impossible for them to continue to support all of the extra stuff that they had been building into themes:

Gone are the days of locking custom post types in a theme. No longer do we build pluginesque functionality into the core of a theme. We now build themes that rely on existing, awesome plugins that offer features that can be used with other themes, should you choose to update your design or build your own theme.

UpThemes is starting fresh and making use of plugins such as Church Theme Content and Recipe Schema to add extra functionality, instead of packing it all into themes.

We’re witnessing the end of an era in WordPress theme development. Bloat is no longer acceptable. Theme authors are creating leaner products with a stronger focus on designing for specific use cases. Anything extra is plugin territory.

This should be quite liberating for theme authors who no longer bear the pressure of having to pack all kinds of complex functionality and options into their products. Themes and plugins will no longer overlap as heavily as they have in the past but will act as compliments to one another.

Tips For Consumers

photo credit: Leo Reynolds - cc
photo credit: Leo Reynolds – cc

If you’re looking at this issue from a consumer standpoint, the most important thing to remember is that you are the guardian of your own data. If you choose a theme that locks you in, you are the one who will suffer the inconvenience of trying to transfer data when you change to a new theme.

Before installing a new theme, whether its free or commercial, ask yourself if you’ll be able to take all of your data with you, if and when you decide to stop using that theme. If the theme advertises dozens of capabilities, examine each of them to make sure that they don’t tie you down.

Last year we discussed this issue in a post about why you should never add analytics code to your WordPress theme. This is because analytics have nothing to do with the design of the theme. It’s a function that you’ll need to maintain throughout years of using WordPress with many different themes. You don’t want to have to transfer that data every time. Store it in a plugin and be done with it.

The same goes for portfolios, testimonials, recipes and custom post types. You’re likely to want this data on your website for years to come. Make sure that the theme you choose will give you that freedom. Find plugin substitutes for any data-driven functionality that is built into your theme. It’s not as convenient, but ultimately you’ll be glad that you kept your data separate from the design.

Category: ,
Tags: ,
15

15 responses to “WordPress Theme Shops Move Toward Preserving Data Portability”

  1. I know I don’t have Justin’s stature in the community, but I hope developers will consider taking a look at the Food and Drink Menu plugin for restaurants that I released a couple months ago. It’s also designed as a framework around which theme authors can build their sites, with a simple templating system, tons of hooks to filter and extend it with your own data, and support for multiple menus, shortcodes, widgets, etc.

    Food and Drink Menu:
    http://wordpress.org/plugins/food-and-drink-menu/

    On GitHub:
    https://github.com/NateWr/food-and-drink-menu

    An introduction to the template system for theme authors:
    http://themeofthecrop.com/2014/01/28/customize-restaurant-menu-templates/

    In the long-term, I hope to build a suite of companion plugins that will work as a comprehensive framework for theme authors to build restaurant sites, with support for table booking and other useful features for restaurants.

  2. This presentation-vs-functionality separation has been a struggle at times with the Theme Review Team, so I’m glad to see some of the bigger players making moves in the same direction.

    I believe that this approach will actually result in *more* innovation in Theme development.

  3. I really like this new direction that theme companies are taking. Personally what I think would be good is if the products are not “branded” i.e Projects by WooThemes. This will hinder other theme companies from using it because in the end they’re promoting their competitor’s plugin.

    A solution which I fear would happen is a bunch of forks of the same plugin with different branding. Now what is ideal is what Justin is doing with his plugins.

    A group of theme companies or developers need to join forces and collaborate on standalone projects rather than branding these simple but useful plugins. I think that way the entire community will benefit from it. Just my 2 cents.

    • I was looking at Projects on WordPress.org and had the very same thought. I personally would not develop a theme with it for this reason. Even if it is only ever used for themes made by WooThemes, it’s still a useful thing, but if the idea is to make things easier for as many users as possible, multiple theme developers need to be using it.

  4. We talk a lot about data portability, but both Chip and Syed hit on some points that are truly at the heart of this for me. On the one hand, it’s about the users. On the other, it’s about designers having the tools they need at hand for creating cool themes.

    At some point in the past few years, theme designers also became plugin developers, mostly because we wanted to build themes that were beyond the standard blog design. So, instead of focusing efforts on actual design, more focus was put on development of features. This shifted the market toward big theme packages. Even though much of the code was open source, it started a dangerous trend toward a closed-source system where everyone had their own scripts that varied wildly. I don’t want to get into the economics of it all, but a lot of extremely good designers couldn’t compete with features.

    What I don’t want to see is a trend of everyone having their own plugin with their own branding. While I think competition is good, we need collaboration around a central project. If we have too many in-house plugins developed, it weakens the concept that many of us have been preaching.

    My ultimate goal is to see growing communities around specific plugins for things like forums (bbPress), e-commerce (Jigoshop, WooCommerce), portfolios, restaurants, and much more. When we have a major plugin or two to handle specific uses, it allows for much more innovation in the theme space. Theme designers can quit worrying about plugin dev and start designing awesome stuff.

    • I’ve been itching to get a look at your plugin for a while. Great to see you’ve finally released it! I really wish you had responded when I contacted you last year asking to get involved. I was in the middle of writing my own solution, but would have happily jumped on your bandwagon. Without any communication from you regarding what kind of hooks you were planning, the template system you envisioned, long-term development plans, etc, I had to push forward with my own solution.

      I appreciate that the plugin may have been too early in development to bring in contributors/collaborators you don’t know, and fully understand your position. But to help me decide whether to push forward with my platform now or join forces with yours, can you provide some information regarding your plans for the following:

      1. How do you plan to handle the sorting and display demands of a restaurant menu?

      One of the reasons I was dissatisfied with existing solutions is that they all handled menus like any other custom post types — posts with archives. But restaurant managers typically want their online menus to mimic real-world menus, which means precise control over sorting order, categorization, multiple menus (I recently had a client with 3 menus for each of their 8 locations), etc.

      I can see that you plan to add taxonomies for meal times and courses, but from my experience the jump from data structure to presentation is incredibly difficult for lay-users (ie – customers). Have you considered any kind of layout manager? I know you want to keep the base plugin simple. I’m wondering how much of the sorting and display logic you plan to bake into the plugin or whether all of this will need to be handled with separate addons.

      2. Do you have any plans for integrating an addon shop into the plugin, or providing a centralized location for plugin authors to promote and sell their addons? EDD, for instance, provides strong sales opportunities for third-party authors. But not everyone is as welcoming. What are your plans in this regards?

      • Sorry if I missed a comment you made or anything. I often miss things if they’re left on the blog, which is one reason I’ve moved to GitHub in the past year (for the collaboration aspect). The 95%-finished Restaurant plugin has been up there for several months.

        1) I plan on allowing add-on plugins to handle the more complex items. I’ve actually found the opposite of what you’re seeing. Most of the people I’ve talked to with small mom-and-pop shops and cafes tend to only need a single menu of items. So, that’s the base we started with. We wanted to shoot for the smallest of businesses with the initial plugin. Anything beyond that can be handled with additional plugins.

        For display and layout in general, that’s being left to theme authors. But, actual use cases help in this type of conversation.

        2) Theme Hybrid is already set up to allow third-party users to promote their stuff. Currently, we’re just doing this with themes. But, it’d be easy enough to open this up for plugin authors. However, as of right now, I don’t allow people to sell commercially through the site. Theme Hybrid has always been about $free plugins and themes.

        If we had enough developers on board, I could see the potential of having paid add-ons handled on a separate site. One thing I’d like to avoid is nickle-and-diming users for every feature though. I’d much rather see a healthy community around the free plugin and free add-ons. But, I certainly know that some advanced add-on stuff (reservation system, for example) might be better developed and supported commercially.

        • Thanks for replying, Justin. I sent a message through the contact form on your site ages ago, so I guess it just went down some rabbit hole for spam. I probably should have followed it up more. Wish I’d found that GitHub repository earlier. Must not have looked properly.

          1) I guess with the display and layout issues, I was referring more to the backend interface a user would interact with. I’m sceptical that the default taxonomy interface is intuitive and easy for an end-user wishing to construct a menu. But this is a broader issue. I’ll spend some more time digging into your setup to see how easy it is to manage the menu.

          2) I certainly appreciate the need to have a robust free solution. And I don’t think restaurants are a large enough niche for there to be much profit in the nickle-and-dime approach to addons. For me, it’s just a question of market access. If I invest time into a plugin, I want to be sure that that plugin is discoverable for its target audience. Otherwise it’s useless for me. (We don’t all have profitable theme clubs. ;) ).

          Unless there’s anything you want to reply to here, I’ll move any future questions/comments to the GitHub tracker.

          • 1) With the one and only taxonomy included, the WP meta box works. With the other taxonomies I have in mind, they’d probably work better with a custom meta box.

    • I wonder if developers are concerned that making a free functionality plugin would be helping their competitors too much.

      – You help your competitor save time
      – You make it easier for your users to switch to your competitor

      Maybe these things motivate heavy branding?

      I think the issue of helping a competitor save time is unimportant. Building a theme is a piece of work whether or not a plugin is used.

      It is true that it will be easier for customers to switch to a competitor. I don’t see a big issue though because the competitors users can switch away just as easily. Equally easy is better than equally hard, which is mostly how it has been. Frankly, it will mean more sales all around, because it also means easier switching to a provider’s newer theme from an old.

      Then there are other added bonuses like increased awareness of your brand (even if it’s modest, it’s something), free code contributions from competitors, and the possibility of selling addon plugins to one’s own customers as well as competitors.

      Justin, I like that with Restaurants you say it is basic on purpose and that developers should make addon plugins for more sophisticated features. This completely parallels WordPress as core tool with an ecosystem of free and paid plugins for additional functionality.

      • I wonder if developers are concerned that making a free functionality plugin would be helping their competitors too much.

        – You help your competitor save time
        – You make it easier for your users to switch to your competitor

        I think that’s short-sided thinking. Not only is the developer saving time for himself, but he’s also making it easier for his competitor’s customers switch to him. And, as you say: he’s also facilitating a larger overall userbase, by driving the underlying data scheme toward a standard.

        Besides: in a GPL environment, it’s not like a competitor can’t already see the developer’s code, and write a conversion/import script anyway. You’re never going to lock in customers by using a proprietary data scheme.

      • I’m pretty much in agreement with Chip. Every time a competitor integrates his theme with one of my plugins, that’s one more potential customer that I didn’t have before. I can only see that as a good thing.

    • So I was thinking about this today. There are plenty of theme frameworks and developers that use them. Why can’t there be the same type of effort involved with plugin frameworks? Church Content AudioTheme, and others are the plugin frameworks. They just need developers to be aware of them and use them instead of baking those features into the theme. I think the reality of the situation is that developers won’t stick to using one, two, or three plugins that handle a set of features for themes. Instead, I can see developers creating more and more of these plugin frameworks and now, we all end up in a similar but different rabbit hole.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: