1. Hi Sarah,

    thanks so much for mentioning us in the article, which btw, is a great read and full of interesting points that I am sure will spark some discussion. I agree also with Justin that we don’t always realize we have done something wrong, but if we eventually realize, and work towards correcting things, everyone wins in the end.


    1. Bold decisions. It’s a lot of work but will be worth it in the end.

      Would you consider the Church Theme Content plugin for your church themes? http://wordpress.org/plugins/church-theme-content/

      We use it at churchthemes.com, Justin Scheetz uses it with his latest on ThemeForest, UpThemes is working on one with it, ChurchSites.co uses it and hopefully more.


    2. I think we’re in the middle of a lot of theme developers and commercial theme shop owners realizing they have doing something wrong and are working towards correcting it.


  2. Cracking article. I’ve recently started using ACF quite a bit in a theme I have been developing, well mainly child themes if it. As a result I now have a range of ‘plugin-esqué’ thingamybobs like sliders and options tabs based solely on ACF. I can export them as XML and import them on any project I use ACF with. I think the way I’m doing this almost falls into the same arena but falls short as the theme files need to call ACF specific functions, such as: get_field().

    It’s a shame as ultimately I think I’ll have to change towards creating plugins that use shortcodes to add the bits and bobs in the content.



  3. This is a great article. As I was reading, I thought about whether theme authors use data portability as a feature. Something to the effect of a badge that immediately informs customers that they don’t have to worry about being locked into the theme.

    Right now, it seems like that is an excellent point of difference that some of the smarter theme authors could take advantage of. As long as their claim were true, it would be a win win situation.


  4. This is great news. Themes are presentational and theme functionality should be directly related to presentational elements. When themes ship with custom post types and other odds and ends they lock the user into that theme for perpetuity lest they lose the custom content they’ve created. We have helped a lot of people untangle themselves from premium themes that added custom functionality on top of WordPress’ own functionality and it is a serious problem for the longevity of the ecosystem. To see theme foundries moving away from this practice is long awaited good news.


  5. Thanks Sarai, I got convinced about the saying of Justin Tadlock and just to satisfy my curiosity went to the forest to pick a theme and the fire in me died when I’m about to use the theme however, Divi elegantthemes proves to be another breed outta the whole lot because it made me wanna create more WP site while learning the codex of themeing :).


  6. I’ve been thinking about this a lot recently and agree with the premise that plugins should handle the functionality and themes should handle the beauty, which is why I’ve started really diving into plugin development and trying to move all of the things I normally utilize for client projects into plugin format.

    This way they’re not tied down to my theme + it’s been a great learning tool on the different things I am able to do as a theme developer who may or may not be creating themes to sell soon.

    Really well written article Sarah, I hope the more things like this are discussed, the more the average WordPress user will become educated.


    1. And you get the benefit of reusing your plugins for other projects. You’re not reinventing the wheel. I think a contributing reason to why we’ve ended up in this situation is that themes can pretty much do everything a plugin can do. There is no real inherit separation of functionality. Because of this, I think a lot of theme authors just built in functionality into the theme.

      Glad to see such a reversal in practices and getting back to the separation of the presentation of content and functionality.


      1. Yes, I’ve already noticed a speed up in development time since I am able to just activate plugins rather than have to copy/paste the code into each theme functions file and then change up names to ensure it’s unique to the website I’m using it on.

        I used to just throw everything I could into the functions file since it seemed like the cool thing to do when building a theme, but the more I work with plugins, the more I see the benefits of having the code outside of the theme, especially when an update is done, since it goes to all client projects who used the older version of code.

        Timthumb comes to mind, and I’m sure you remember how big of an issue that was when the vulnerabilities hit with it, and updating that code on every client site was an absolute pain.


        1. Oh, TimThumb. Remember that like it was yesterday. Sites are still being hit by scanners looking for themes using the vulnerable script. Lots of sites have a lot of installed themes but are only have one activated. Those other themes could be ticking time bombs. But that’s all beside the point.

          Modular code is better than eggs all in one basket.


  7. The thing about themes doing what plugins should do…

    Let’s take tweets, many themes include being able to add option of showing your tweets.

    What if I don’t like how the theme is handling the showing of my tweets?

    If I were to use a plugin and I don’t like it, I deactive+delete and find another one.

    Replace tweet with whatever else you want.

    The more things a theme does, the bigger it is. Fat ladies are for opera not WordPress.


  8. This is a discussion well worth having. Unfortunately bloated themes are very much a market driven thing. The X theme in the article has over $600K in sales in what looks like 4 months.

    I’m all about keeping a differentiation between look and layout of themes and the functionality of plugins. At the same time, as long as people keep buying swiss army knife do everything themes, folks will keep producing them to get those sales.

    Most people don’t want to learn. They just want to do.


    1. Excellent point Chris and it’s something we’ve been hammering away here at the Tavern. Trying to educate theme authors that this is not the way to make a buck. Acknowledging the fact that it’s not all their fault, they are just creating products to meet consumer demand.

      Unfortunately, this is a trend that will be hard to slow down considering the momentum it has. But Jonathan and others are shining examples that a buck can be made without putting the customer into a locked box.


  9. So over the Avada, Udesign and X theme bloat after having built many sites around them. As they keep updating and expanding their feature sets they always introduce new bugs that have to be dealt with- not to mention the massively expanding html that keeps getting bigger and bigger. I have since switched to Genesis and couldnt be happier since I now never have problems with Cache, minify and CDN optimisations.

  10. cp

    Methinks that there should be a demarcation imposed within the WP owned theme repositories to differentiate between themes that ‘have functionality built in, that should be in plugins’ and those that ‘have functionality from accompanying plugins’. And a visual badge applied as ‘branding’ to show which camp themes fall into. And a way to view, say, only the latter.

    External repositories could use the same badges should they choose to, but I accept that a ‘false flag’ culture could then arise at the more disreputable end of the market.

    If WP doesn’t help itself to encourage good coding and standards then the market will dictate the move away. Sort of like the tail wagging the dog?


    1. Interestingly, the Theme Review Guidelines that are used to review and approve Themes to be included in the official WordPress Theme Directory already require Themes to respect the presentation-vs-content/functionality differentiation. Directory-hosted Themes are not permitted to include “Plugin territory” functionality.

      In fact, the Theme Review Team was somewhat ahead of the curve for this trend, and initially took quite a bit of heat for defining and enforcing a “bright line” differentiation between Theme and Plugin functionality; but it has been worth the effort, and then some.


  11. We chose to adopt this philosophy some time ago at WooThemes. It’s been a mammoth task given our extensive catalog of themes but we’re now really starting to bear the fruit of this transition.

    It can be a tough sell though. From the consumers perspective the ThemeForest theme with 5000 features represents better face value – despite the drawbacks that to us as developers are all too apparent.

    I just wanted to say major kudos to any ThemeForest authors who are bucking that trend. It’s also great to see articles like this posted on wptavern. Openly discussing this topic can only help more folks understand the benefits of building themes more sensibly.

    My only emerging concern is the lack of unity with regards to the plugins authors choose to integrate with. Separating functionality into plugins is great, but saturating the plugin space with 20-30 plugins which all essentially do the same thing does seem a waste of resources.


    1. Exactly, we don’t need multiple content plugins that meet similar needs. We just need a couple that do the job really well. Many developers should work on a few shared plugins instead of many developers working on their own plugins.

      The problem might be getting developers to agree on how things should be done. In reality that might mean ceding control to a competitor. Ideally, developers would join a project instead of creating a new one. This assumes the plugin maintainer is willing to work with others and that they’ll not brand the thing to death.

      Then there’s the idea of establishing common post types, taxonomies and custom fields for a niche that multiple developers can use in their projects. Is there any reason this wouldn’t reduce the lock-in effect just as well?


  12. I completely agree, the theme marketplace has become something of an arms race with everyone racing to have the most features. As a WordPress web design agency, we’re constantly struggling with bloated, slow-to-load and difficult-to-maintain ThemeForest themes. Yes, themes need the flexibility to adapt to different people’s content, but that doesn’t mean that you have to pack in every feature under the sun at the expense of performance etc. I’d love to see more themes that go against this trend and combine flexibility with simplicity, performance, standards-compliance etc. And as you say, a major part of this is separating things out so that the theme is for the design, and the plugins are for the functionality.


  13. Interesting article and as mentioned in other comments, this may also derivate on a plugin universe with tons of similar plugins. Why not just using/including other projects like PODs and Piklist to create those extras? Maybe some day instead of reinveinting the wheel, developers could help projects like PODs to become more awesome and interchange components no matter what theme you are using :)

  14. karlogaga

    Theme X sucks big time! On the “Live Preview” on Themeforest it shows a menu with smooth scrolling to sections which the theme actually doesnt have and the developers are too lame to implement it.
    Dozens of people are complaining about it in their support forums, but themeco couldnt care less about that. I asked for a refund but they dont feel responsible.


Leave a Reply