Last week we announced our newly published and recently updated WordPress theme submission requirements, which raised lots of valuable discussion over in the forum post. The insight everyone provided was valuable and greatly appreciated. It also reminded us that we need to be including more community input, from a wider group, from much earlier stages! Where you provided feedback and it was not taken on board, we also really apologise and hope the clarifications below address your concerns better this time.
The process also made it obvious that we hadn’t been communicating clearly enough at the launch of these submission requirements, which we’ll provide further clarification on here. We will continue working harder at improving our communications, especially from within the Review team and covering all other aspects of review.
What were we trying to do?
We’ve spent quite a lot of time discussing and thinking about our WordPress theme requirements and feel they are a great start but will obviously need tweaks along the way. Overall, the requirements, while not perfect, are a fantastic (and long awaited) step forward for our community of authors and buyers.
The goals for these submission requirements were:
- To [finally!] publish our current requirements.
- To update our currently used requirements to be more inline with current development standards.
- To begin using an iterative approach to update requirements based on your feedback and evolving industry standards.
While we should have done a better job communicating these goals, we still feel that we’re on the right track to improving things for ThemeForest and our awesome community of WordPress theme authors.
Why are we doing this?
Overall, making our review standards both more up to date and more public is an important step towards improvements that are to the benefit of the community as a whole—always our most important focus. Here’s why we think this is so important for both Marketplace authors and the general community:
- Improving ThemeForest’s library quality which will improve the experience and satisfaction buyers have and, ultimately, lead to more sales for authors and fewer support requests.
- Making the authoring process easier and more transparent, which has long been a frustrating and often mysterious area and shouldn’t be. A clearer authoring process and path to getting themes accepted leading to fewer rejections, happier authors and buyers, more sales and a bigger and better theme library!
- Increasing the involvement our community has in the review process will help improve the system overall and ensure that we’re all working towards the same goals. We don’t want the review process to be an unnecessary roadblock and we want your help towards improving it. Making our requirements public means that we’re making it easier for you to be involved in updating and refining these standards.
Revised Timelines & Requirements
We have made some tweaks and corrections to the submission requirements, although much of the requirements are still there. From feedback you’ve given us, however, it’s clear we need to allow more time for some of these requirements to go into effect and to ensure everyone is clear on the new requirements. So we’re splitting the introduction into two phases, extending the timelines and we will be listening to and adjusting the requirements based on the feedback we get.
Please note that this launch plan is only for new themes being submitted, and will not affect existing themes. We have no immediate plans for the next six months to apply these requirements to ThemeForest’s existing library.
In the future, we will be actively working towards library re-reviews to bring the library up to these new standards. When the time comes, library re-reviews will be in steps and we will work in advance with authors to minimize negative affects on authors’ production of themes and ongoing sales. This will be an important phase, as maintenance is a part of selling themes. Over time, they need to be updated.
The goal with re-reviews is to improve ThemeForest’s library quality for the betterment of buyers (which in turn is better for authors!), but these will be carefully thought out, there will be long lead times and plenty of communication.
Phase One – taking effect for new items on September 9th, 2013
This first phase of the submission requirements includes only the general standards that are widely supported by the community. According to your feedback these requirements can be comfortably adopted and the community supports these clear standards. (Don’t worry guys, we’ve dropped jshint as a requirement in favor of strict mode.)
The majority of these requirements are already operating in the Review team but they have not previously been made available in one permanent, public location. We are setting an eight week timeline (from the original launch post) to gather any additional feedback and will adjust the requirements as necessary.
Phase Two – Tentatively taking effect for new items November, 2013
While we lay the groundwork by introducing the basic Phase One standards, we’ll begin to look at the requirements that raised a lot of discussion and that are far more time-consuming for authors to implement.
We’re going to aim for November of this year to have this phase of the requirements be applied to new items during the review process, but we’ll be working with the community to ensure authors are ready, the impacts are minimal and everyone has had a chance to provide us with their feedback. This will also give us an opportunity to improve and refine these more difficult requirements to best fit the community.
The main requirement in Phase Two is cleaner separation between a theme’s design and the features it provides. For more specifics, please see the updated submission requirements section of the revised knowledgebase article. We welcome your feedback.
Q & A on Phase Two
Here’s some further clarification on the hot questions in Phase Two of the requirements launch, being asked following last week’s launch of the WordPress submission requirements. There’s sure to be more questions, so please ask them in the forum thread here and we’ll clarify as soon as possible.
Why move functionality into plugins instead of themes?
This is about separation of concerns. Themes should be responsible for the look and feel of a website, while plugins take care of the functionality. This is precisely why the two exist.
Moving functionality from the theme to a plugin allows for modularity and portability, which has advantages for both customers and authors:
- For the customer, by using a plugin, it’s simpler to enable and disable functionality as needed while still using the same theme. They can also switch themes without fear that the data they’ve spent hours entering into a custom post type is going to vanish from sight.
- For the author, it’s simpler to use the same piece of functionality across multiple themes. Building functionality for a particular niche is no easy task, and this makes using that functionality with multiple designs easier.
Are shortcodes permitted?
Shortcodes will be permitted in plugins, but not integrated into the theme itself. Among other things, this makes life easier for customers if they ever need to swap themes, their content isn’t suddenly littered with unhandled shortcodes.
Why should I make all my custom functionality available in a free plugin?
We’re actually not at all asking you to do this. You’re welcome to release your plugin on the WordPress.org repository if you’d like, or you can include it with the theme as a zipped package. You can also provide updates via a private server (a good article on that here), or even sell your plugins via CodeCanyon as an upsell.
Where should styling for plugins live?
Your plugin can have default styling if required, and your theme can override it. Think of this in terms of re-purposing your plugin. For example, if you have several themes that all use the plugin, it should have the base styling that all those themes would use, then each individual theme sets and overrides styles for that theme’s needs.
Won’t having a number of plugins and themes mean lots of CSS and JS files?
While there may be a couple more CSS and JS files doing things this way, it will be negligible. Even then, it’s easily fixed with caching plugins that provide concatenation and minification of a site’s CSS and JS files.
Who supports my theme and my plugins?
Nothing changes here. You support your theme and plugins, at your discretion, as always. It’s been asked, “Who supports my plugin if it’s being used with someone else’s theme?” You do, but of course, you needn’t guarantee that it will work with any and every theme.
A good example of this is the ZillaShortcodes plugin. This plugin states clearly in the description that it’s “compatible with any theme, but use ours and we’ll style it to match.” It’s really up to you how you manage support for both your themes and plugins.
If I provide custom plugins with my themes, what license are they under?
They will be under the same license as everything in the main download file of that item. Whether that’s our Regular License, Extended License, or 100% GPL, the same license applies to the plugins as the themes (unless the plugins are already under another license of their own, which will then apply).
Thanks, everyone, for your patience and valuable feedback while we roll out these WordPress submission requirements. We hope this adds clarity to the many important questions you’ve had! Please be sure to let us know if you have more questions via the forum thread covering this update and we’ll continue clarifying and working with everyone to get these requirements in tip-top shape!