Home » Problems with themes on ThemeForest, are problems with themes

Problems with themes on ThemeForest, are problems with themes

Japh —  September 6, 2012 — 38 Comments

This morning I got up at 5:30am to attend the WordPress Dev Chat, as I do every Thursday. I had a bunch of notifications from Twitter, which usually means people are excited about something. Here’s the tweet from @carlhancock that got the discussion started:

It went on from there, mainly with Carl, @pippinsplugins, and @michael_silva talking about ThemeForest themes including bad code that breaks plugins (Pippin specifically trying to make it clear that not all ThemeForest developers write bad code).

The problem is essentially WordPress theme developers include code that removes or overrides core WordPress functionality that WordPress plugins may rely on.

Specifically, things like removing wpautop and wptexturize with a shortcode, which is a strange thing for a theme to be doing in the first place. It seems to have been promoted in Step 3 of a tutorial on adding a column layout with shortcodes.

Because quite a number of ThemeForest authors are including this code in their WordPress themes, it’s causing big problems for plugin developers like Carl (founder at Gravity Forms). Having this code in a theme breaks plugins.

So what can we do about it? If this is a problem with themes on ThemeForest, then really that means it’s a problem for themes anywhere. There is already a great plugin called Theme-Check that theme developers can use to check their themes for issues or bad practices, so I’m hoping we can create a ruleset for Theme-Check to stop these issues in any theme, including on ThemeForest.

I spoke on Skype briefly with @iandstewart, who seems to think it’s a good plan, and will be getting some discussion happening on the Theme Review mailing list to make sure it’s a good idea and to get help making it happen.

So that’s been my eventful morning, and it’s only just hit 9:00am!

This post is mainly to get my thoughts out, but if you have any thoughts of your own t contribute, please feel free to leave a comment.

[Update:] To clarify, as my wording above is a little ambiguous, the ThemeForest review team do currently use the Theme-Check plugin. However, it doesn’t currently cover the specific issues being discussed.

Japh

Posts Twitter

Web developer, technologist, innovator. Wptuts+ Editor and WordPress Evangelist @ Envato. I love the internet.

38 responses to Problems with themes on ThemeForest, are problems with themes

  1. One of the things I think would make a huge difference (for future) themes is requiring that every single theme that gets submitted to Theme Forest pass the theme check plugin, and require that the submitter give proof of it. Even if the author has 15-30 themes already approved they should still required. I can think of 3-5 authors off the top of my head whose themes wouldn’t even get close to passing a theme check, and they’re all elite authors and all get their submissions approved without question.

    To me that’s part of the major problem: there are certain authors will produce tons of shitty themes, but because they are elite and have sold so many, their submissions are automatically approved. I’ll name the authors if you want me to.

    The problem also needs to be worked on for existing themes, and it needs to be worked on NOW. As Carl has pointed out, plugin developers are faced with fixing problems in bad themes every single day. I spend at least 2 hours per day on support tickets, and most of it is due to bad themes (not all of them from Theme Forest, but a lot of them).

    The way that I would address it is to setup some sort of scan that can go through every theme on the marketplace and check for instances of known issues (like the one Carl mentioned). Every theme sold on the marketplace exists on Envato servers with zip files, so I know it’s possible to automate the checks.

    Another way that would at least help to alleviate the issue is to review every single theme that has greater than 500 sales. Once that’s done, review all with 100 or greater. Honestly it is the themes with the most sales that cause the most problems. I very rarely come across a problem in themes that have a low number of sales, simply because there aren’t as many installs running them out there. So get the “big boys” taken care of first.

    • Great feedback, Pippin, thanks!

      Firstly, I’ll have to look into the issue of elite authors getting themes submitted without going through the Theme-Check plugin. The ThemeForest review team do use Theme-Check, so that shouldn’t happen. I don’t think naming the authors here would serve much purpose, but I’d certainly appreciate an email so I can investigate further.

      Reviewing existing themes is certainly the biggest issue. There are a lot of them, and significant portion wouldn’t have been through the review standards we have in place now. While we obviously have the ZIP file with themes, they’re stored on Amazon S3 servers, so I’m not sure if that adds complexity to an automated scan. That’s just logistics though, really. This is one of the good reasons for ThemeForest adding a theme-only ZIP file to uploads too. Easier to scan that than a package that could contain a theme anywhere.

      “Big boys” first makes sense to me too.

    • requiring that every single theme that gets submitted to Theme Forest pass the theme check plugin, and require that the submitter give proof of it

      That’s easy. They should run theme check upon theme upload, like WordPress.org does, and if there’s at least one required-level error, it should just never make it to the review queue, like on WordPress.org.

      I also think it needs rules that triggers errors for: more than one call to add_shortcode, at least one call to register_post_type and at least one call to add_menu_page, and wp_add_dashboard_widget :)

      K

      • At the moment it’s a manual run through of Theme-Check, but good point. No reason to do a manual check if a “required” test fails!

        I definitely think we should at least also add automated checks for loading bundled JavaScripts from external sources. Even though we might want to add the triggers for shortcodes, post types, menu pages, and dashboard widgets ;)

  2. I absolutely agree that something should be done… whether theme check or manual based off a set of hard rules (although I don’t see much of a reason to deviate off those rules) resulting in a suspension of the theme until the issues are resolved.

    It may sound harsh, but it’s for the betterment of the community. 3 years ago I would probably disagree, but now there are standards in place and really no excuse to be coding themes that way.

    Ultimately its up to you and TF leadership, as well as other marketplaces to determine how you want to handle it. Going forward any new themes obviously, but how do you handle a theme that’s 3 years old? Some leniency or a time period to update? Either way a theme that’s 3 years old probably has other issues like depreciated functions that should be addressed, but like I said, it’s up to you do decide exactly how to handle it.

    • Exactly. ThemeForest does have a process for exactly that. In fact, we recently suspended a theme for including an out-of-date version of TimThumb until the author could resubmit with an updated version.

      There was a cull on ThemeForest after WordPress 3.0 was released where all authors were notified that those themes not updated within a certain time period would be suspended from the marketplace. I also like the idea of maybe something like the plugin directory uses for plugins older than 2 years.

      • Yes, I meant to mention the plugin repo… some themes are still making money which is nice for the author… but when it hasn’t been updated in 2 years it hurts everyone else.

        Just some things to think about in the big picture.

  3. I just wanted to preface my eloquent tweet that is quoted above by saying I tweeted that after spending 4 hours providing support to 9 Gravity Forms users who had either installed or upgraded to the latest version of Gravity Forms only to encounter problems with the plugin due to the RAW shortcode issue.

    I was extremely frustrated at the time and unfortunately pretty much the remainder of my entire day was spent assisting these users, working with our development team to review the issue and implement a workaround and then release an update of Gravity Forms to workaround the issue. It’s frustrating to have to include workarounds for issues that shouldn’t have to be worked around.

    It’s not an exaggeration that ThemeForest themes account for 90+% of the theme conflicts we encounter and a significant number of support hours assisting users with issues that are directly caused by poorly coded themes and NOT a problem with the Gravity Forms code. It costs us money, the man hours that have been involved to date are not insignificant.

    ThemeForest needs to do more to address the issue. I know that you (Japh) are proactive and always reach out when you are made aware of an issue, but I think Envato as a whole needs to be more proactive.

    I was under the assumption that when issues were pointed out that made it into the ThemeForest theme standards that these standards were being retroactively applied to existing themes and not just new themes.

    After reading the post above, I see that this was an incorrect assumption… and a major problem that is detrimental to the community as a whole.

    Some of these “standards” aren’t just best practices, they are things that theme devleopers simply shouldn’t do because they break WordPress. Ex. the RAW shortcode.

    Only applying standards to new themes going forward means you are still selling numerous themes where major problem still exists. That doesn’t solve the problem.

    What you guys need to do is in situations where a significant issue exists, the RAW shortcode being a great example, you need to find a way to retroactively review all existing themes to make sure NO themes are being sold that introduce this problem.

    In situations where a theme isn’t caught, as soon as it’s reported that the problem exists… PULL THE THEME FROM THE MARKETPLACE immediately and require the developer to update it before it will be permitted to be sold again.

    It shouldn’t matter if it’s a theme that has sold 400 copies or a theme that is a best seller. If it’s got bad code in it, it should be fixed ASAP or pulled from the marketplace. Allowing sales of that theme to continue with the problem still in place does a disservice to the WordPress community and the customers you serve.

    You guys seriously need to extend your standards and theme development requirements and reviews to ALL themes. New and existing.

    • I think your initial tweet really shows just how frustrating this is.

      I completely agree with you that as standards are improved, they should be retroactively applied to existing things too. We’re very aware that this needs to be done correctly too, and with over 2,000 WordPress themes on ThemeForest now, it’s a non-trivial task.

      We’re doing more than it may sometimes look like we’re doing. With over 2,000,000 items across all the marketplaces now, it may look like we’re focussed on everything but WordPress themes, but it takes time to implement a good solution that works for everyone involved.

  4. Dig that you shared all of this, Japh.

    I’m not necessarily entering into the ThemeForest part of all of this, but I did want to offer my thoughts as someone who builds themes, plugins, and applications on top of WordPress, and as someone who has had a theme audited my Automattic for sale in the premium marketplace

    There’s a handful of things that I always do whenever I’m working on themes and plugins and it’s something I recommend to fellow developers:

    Install the Developer Plugin by Automattic. It’s a bundle of several of the most powerful plugins.
    Install Theme Check like you’ve mentioned above.
    Use the WordPress Theme Unit Test and load it into the theme to make sure all aspects of themes are covered (formatting, comments, pings, post types, menus, galleries, etc, etc, etc).
    Have the Coding Standards open to make sure they’re being followed throughout development
    Install the RTL Tester for internationalization testing
    Learn the database schema. This is something I’m still doing, but it will change the way that you write your code – you’ll know when something should be a taxonomy, post or user meta data, custom post type, custom meta data, etc, etc.

    Additionally, there are other rules like making sure the parent theme does not include any !important in the CSS (because it makes it difficult to the child theme), that calls to get_template_directory_uri() are used rather than get_stylesheet_directory_uri(), and so on. The list of requires gets quite long.

    These are a must. For themes being added to the WordPress.com Premium Marketplace, if any of the above fail, then it’s likely that the theme will not be approved for sale and will be returned to the developer until the issues are addressed.

    The problem with having such a vibrant community of developers – and I use that term loosely – is that people are getting away with churning out poorly architected “products” and being rewarded for them through payment.

    This gives them incentive to continue creating something even if its at the expense of building a quality product. The customer is none-the-wiser. If the theme looks good, nothing else matters.

    But as programmers and people who care deeply about the WordPress platform and the code behind the products built on top of it, I believe that we’ve got to hold ourselves to a higher standard than simply “getting it to work.” This rings true for both plugins and themes.

    The thing is, this is a beast to tackle and I’m not certain it can be done completely, but we can improve vetting of plugins, themes, and products if we adhere to much stricter standards.

    Anyway, a bit of a rant and this is definitely not targeted at any area in particular. Just offering my thoughts and observations on what I’ve seen for the last couple of years.

    • Thanks, Tom! Well put too, I wrote a post for Wptuts+ late last year to encourage theme developers to do just the things you’ve mentioned.

      Using the Developer Plugin is really a must, and now that it includes Theme-Check too, you might as well.

      I believe the ThemeForest standards are very good these days, and constantly getting better. It’s the existing themes that really need revisiting.

      Also, I really appreciate everything I see you doing around the Internet for WordPress development. You’re the kind of WordPress developer that others should aspire to be like. So, thanks :)

      • Of course!

        And you know that one of my goals at WPTuts+ is exactly that – to help evangelize the absolute best practices in order to get the word out to more budding developers.

        Personally, I can’t speak to ThemeForest (which is why I didn’t mention it much in my previous post) because I’ve not really sold or bought anything through it, but I do applaud higher standards and more critical reviews.

        And likewise to you, as well. It’s because of posts and discussions like that this that can ultimately help better the WordPress community.

    • The !important thing is tricky. I’m guilty of putting that in my themes’ stylesheets to overwrite !importants that plugins include in their stylesheets. Drives me crazy.

  5. Coming from a non-theme-developer, but someone who uses WordPress a lot and has mucked around a time or two with making themes, I have a question. If removing wpautop and wptexturize is such a problem for other plugins, then how do you deal with the problems that wpautop cause? What’s the better solution for those situations where automatically inserting paragraph tags is an issue? Instead of just saying don’t do it, what’s the preferred solution?

    • “Don’t do it” doesn’t apply to everything. We’re specifically referring themes not doing it. You can create or install a plugin that removes or even changes up how paragraphs are formatted (there’s probably even some out there). It’s simply not the place of a theme to be mucking around with this sort of thing. They should be leaving this to developers who know what they’re doing.

      So, in terms of themes, “don’t do it” is the solution.

      If you have a specific issue with those two filters, I’m sure there are any number of developers who can create a solution based on your needs.

    • I wrap the (usually form code like Aweber’s) code which WordPress messes up with [raw] and [/raw].

      See http://www.wprecipes.com/disable-wordpress-automatic-formatting-on-posts-using-a-shortcode

  6. If you guys do come up with anything for consideration with Theme Check, then my email address is always open, and I’d be happy to take a look and work with you on improving Theme Check to catch just these sorts of things.

    • Hey Otto, thanks for replying here. I recently emailed the Theme Reviewer’s mailing list with a suggestion specific to wpautop(), and there was some good discussion about it. Not sure what came of it though, if anything. I’ll give it a bump :)

  7. TheOtherJaybles October 4, 2012 at 9:56 am

    Propaganda perhaps…? I’ll fuel that machine, hell, if I could build themes using Mr. Tadlock’s Hybrid, then sell them on ThemeForest, I would! ‘Cause that sh*t just works. But seriously, set the standard, then enforce it. Good job Japh, Pippin, Justin, you guys are setting standards just by “reminding” devs how to do what they do. And now specifically to you Japh, keep posting posts like this, maybe, just maybe, some of the authors on ThemeForest will pay attention, yes, even the so called “Elite” authors, and start doing things differently. Best practices are what’s important to the WordPress community as a whole. Green theme devs start by reading posts like this, they go on to produce their own themes, they keep in mind all the ideas that have been shared, and in turn end up releasing some good themes. Plugin devs are happy, less support crap to deal with.

  8. So refreshing to see this kind of conversation happen in public and I must say, Japh, you would have to be one of the most diplomatic operators around. I hope Envato know how lucky they are to have you working the WP community for them.

    Well done and keep up the great work.

    • Thanks, Troy! I’m really pleased with the reception this has had, and I feel like the community is more understanding these days that we know we’re not perfect. We do want to be though, and are trying to make it happen!

  9. A little late to that party, but I still want to leave my two cents here.

    The thing that most annoys me with TF themes isn’t that much that tons of stuff is included that shouldn’t be (from post types to shortcodes and even worse things), as I can move those later into plugins.

    The really annoying thing is that I haven’t encountered a single theme so far, that I could throw in my local dev environment, turn it on and just start working. The default is ~200 notices for undefined indexes. How the heck should one find his own errors in between this mess? One author told me that he will “fix” this with one of the next releases (his themes have been up for more than one year). The end of the discussion was me telling him how to do the basic things in PHP. The thing I’d really, really want to see from TF themes is the requirement for clean code without errors/warnings/notices – force them to set an error level and error display. If it throws out something: Please reject it.

    Thanks.

    • I agree, and I’ve had that happen myself with ThemeForest themes. Again, these are issues with existing plugins more so than newer ones coming in, which are checked more thoroughly.

      We’re overdue for a re-review of the whole library to ensure everything is up to our current standards. But this shouldn’t be too far off.

Trackbacks and Pingbacks:

  1. The Problems with WordPress Themes - Tom McFarlin - September 7, 2012

    [...] Japh – a fellow tweep and WordPress evangelist at Envato – recently shared a post on his blog titled “The Problems with themes on ThemeForest are problems with Themes.” [...]

  2. The Ecology of WordPress Plugin Development | Pippins Plugins - September 8, 2012

    [...] into your own plugin without understanding exactly how it works. Blindly copying code is one of the biggest problems currently facing the commercial WordPress theme market; please do not be a perpetuator of this [...]

  3. The Week in WordPress: 2nd Week of September, 2012 - WPLover - September 8, 2012

    [...] “Problems with themes on ThemeForest, are problems with themes“. Japh Thomson, WordPress Evangelist at Envato, addresses the problem us developers often find when working with themes bought from ThemeForest. The discussion in the comment section is especially worth reading. [...]

  4. WP Late Night #25: "Lean forward and choke yourself" | WPCandy - September 14, 2012

    [...] http://blog.japh.com.au/2012/09/06/problems-with-themes-on-themeforest-are-problems-with-themes/ [...]

  5. Justin Tadlock hopes to improve ThemeForest from within | WPCandy - September 20, 2012

    [...] heels of a fresh round of ThemeForest criticism. Just a little earlier this month Envato employee Japheth Thomson responded to strongly tweeted words from Carl Hancock of [...]

Share Your Thoughts