Themeforest Updates WordPress Theme Guidelines for Developers

Themeforest, the super successful WordPress theme marketplace run by Envato, has recently set out new guidelines for theme developers. The changes, which are fairly major, have some cheering and others booing. (See the discussion on their forum here.)

As mentioned in the announcement of the changes, theme developers will have eight weeks to get their themes into line with the new standards.

Themeforest lays down the law for theme developers.

Of course some of those booing the new requirements are developers who have a lot of work ahead of them. Others who may not be so happy, however, are simply people who don’t like some of the restrictions.

For example, here is a list of the types of shortcodes that are NOT permitted in the new guidelines:

maps

accordions and toggles

boxed contents

column

contact forms

charts

Those cheering the changes are people who believe these new standards will clean up a lot of the messiness that can be found in some Themeforest themes.

What do you think? Are these new guidelines a good thing, or do they go too far?

140+ Plugins & Themes

35 Responses

Bob

Cleaning it up makes sense, and perhaps can upgrade the lousy reputation (mostly earned) that Envato’s ThemeForest has. But the concept of avoiding the dreaded Lock-in to a theme is a bit off the mark. These are premium themes and are purchased often precisely because of the built in short-codes precluding the need for the buyer, generally a newbie from having to then go and get a plugin, hope it’s the right one, hope it’s compatible, and hope that developer sticks around to support it.

Hi Bob, we’re not telling our authors that they can’t provide this functionality at all, just that they need to move it into a plugin instead. Which they can still bundle with the theme. So no need for customers to go searching :) (They can also put a notice in the admin prompting installation of any required plugins).

Complex shortcode functionality really should reside in a plugin, not a theme. It also just makes sense when you consider most of our authors have multiple themes.

Lock-in is also an issue with custom post types. Switching themes and your data vanishes! Not a good feeling. While moving custom post types to a plugin won’t mean they work with every theme on the front end, at least the data is accessible on the back end. If the theme does support it though, that’s even better.

Conceptually I agree. And of course, that’s why I kept Justin’s post for 2 years and provide it as a source. But in practice, this may preclude some developers with fantastic ideas and little resources from completing and proffering their themes. And of course, it then begs the question – a complete theme, including the short-codes just has to work or it won’t sell, but as separate components, is Envato going to vet every plugin to ensure that it is fully compatible with not the companion theme, but with other themes, as is the premise of the new move?

Actually, I believe this makes the completing and proffering of themes even more approachable for authors with ideas but few resources. It sets precedent for good practices, and the ability to be able to compete by using existing plugins rather than having to build all functionality from scratch integrated within the theme. The problem we have, is that functionality in these themes should always have been in plugins instead.

Of course we will be vetting these plugins to ensure they’re of an acceptable quality and that they work with the companion theme. However, the fact is, themes need to support plugins, not the other way around. Any plugin you install is going to look relatively generic unless your theme supports it.

I like the idea, and hope it works. My only concern is that this is only going to represent yet another “update” to worry about. And for the preponderance of WordPress users, more is not necessarily better. :)

I hope so too, Bob. I think yet another update isn’t necessarily a bad thing either. Making it easier for authors to provide updates in a modular way will hopefully mean they provide them more often, and that any security issues that may arise are fixed more quickly, etc.

I don’t see what the problem is with shortcodes like toggles and accordions. Is the idea that these should be done with a plugin instead? Having basic design elements that help break up content (like toggless, tabs, etc) is incredibly convenient when it’s built right into the theme. I can’t seem to figure out why it would be looked down upon.

Thanks @Bob for the link. The “locked in” effect makes sense, and I can definitely see the disadvantage. This new change definitely makes sense for Theme Forest too. “Locked In” users won’t buy more themes! Couldn’t WordPress build into core shortcodes for all the common elements (buttons, tabs, toggles, notes, etc)? I feel like this would solve a lot of problems, and then the theme’s CSS would define the styling of those basic elements that are built into core. This way changing themes won’t leave behind “empty shortcode clutter” but will simply change the styling to match the new theme. This seems like a no brainer to me. Am I missing something here, or I’m assuming there must be a reason why WordPress hasn’t done this yet?

Hey JJ_D, actually the plugin should pick up precisely where the theme left off in this case, so it won’t be an issue. In fact, by moving the shortcode to a plugin, we avoid the issue you mentioned.

If shortcodes are built into your theme and you switch, you end up with literal shortcodes through all your content. If the shortcodes are in their own plugin though, then that won’t happen even if you switch themes.

Thanks for the post, Joe! It’s a pretty big announcement, and we have a few tweaks to make based on feedback from our authors, but we’re hoping that in the long run this will be a big win for customers, our authors, and the WordPress community as a whole.

Sorry if this comes off as being a tad snarky, but I’m still trying to figure out how Themeforest has the right to demand anything of authors when they, themselves, seem to be skirting the licensing requirements clearly stated by WordPress? Is there some kind of Envato carve out in the rules that I haven’t seen? If so, I would love a link.

On top of what I have stated above, it appears to me as if this is a blurring of the line between a freelancer, and an employee. That said, each marketplace has their own requirements. This just seems ultra restrictive.

I have no horse in this race so I guess it doesn’t matter much to me in the end. I’ll buy the occasional plugin, or graphic – but I steer far away from the themes. It isn’t because of *author* ‘lock-in’s’ either.

Firstly, Envato aren’t “skirting the licensing requirements” at all. All WordPress themes and plugins sold on ThemeForest and CodeCanyon comply with the GPL, whether they be sold under a split license or 100% GPL.

Also, as operators of ThemeForest, it makes sense that we set the requirements for themes that are to be sold there. We want to ensure that themes sold on ThemeForest meet a minimum standard.

I would actually prefer the plugin approach. I am a TF customer, and have purchased quite a few themes. There’s one that I happen to really like, and the developer has already broken out the additional functionalities into plugins.

This allows me to use/load only those which I need for a particular site. And makes troubleshooting easier if I need to switch off one or two plugins at a time.

The developer makes all of the plugins available through the WP Codex, so it’s really easy to get them.

Big headache, but necessary evil. Envato will lose some large scale sellers in the short term who are too busy to comply -OR- who have sold enough themes to survive off of the “lock-in” contacts they already have in place by dealing from their personal site’s support systems. This will be their justification for separation. Long term this definitely opens the door to others who don’t have the option not to comply because they rely on TF for exposure/traffic. By far it’s best for the Buyers in the future.

Nobody should be too upset though… either the theme developers will comply, and consumers will get updates on TF from them – OR – they won’t and most developers will continue to provide solutions from their personal sites (which TF should facilitate for a year or so with links so we’re not left in wind when looking for updates. Would be the classy move anyways other than the “sorry this product is no longer here” message) So, as a Buyer… not too concerned unless WordPress releases some crucial update in the short term forcing us Buyers to jump through these hoops so our sites stay secure.

What would be really nice is if TF provided their developers with a support forum solution on TF. Then monitor it occasionally to make sure the developers maintain/service products when stating they will under terms of sale. Seems like that would be a wise “lock-in” of their own that would benefit all.

Also, I don’t think we’ll lose any large sellers over this. I think the vast majority of our authors can see the good in this, and we’re making some tweaks from their feedback already too to ensure the requirements do all make sense for them.

Don’t underestimate the arrogance/greed of successful people ;-) Although, I guess they do have a pretty nice split after they get to a certain level. So, you’re probably right. Just don’t cave to their requests or threats too hard though.

DREAMS… The comment threads not being searchable and having to jump to the developer sites for support is chaos. If that were under control a Buyer would never have to leave the TF site for anything.

@Japh – imho you are doing the right thing – clean segmented code – themes where theme should be and plugins where plugins should be. I use Themeforest themes and build my own themes but I pretty much don’t bother with an other third party seller of themes because your business model favours all parties involved…more than I can say for some…mentioning no names… (cough cough).

I am happy about it. A lot of the built in “bells and whistles” that these themes offer seem many times to not play nice with other 3rd party plugins…without some tweaking (including many of the WPMU DEV plugins). As stated earlier, being able to turn functionality on and off is going to help with trouble shooting. Especially when trying to mix and match plugins and themes between developers. Good luck Envato!

That said, clearly the genie is out of the bottle. The only way forward is to stop using the term “theme” (in the true sense of the Automattic ideal) and instead start using (when appropriate) “application” or “WordPress application”.

The difference being applications have much of key functionality baked in. A theme on the other hand is universal, agnostic, and supplemented with plugins and/or a child theme, as theme were meant to be.