I understand you are allowing “upgrading” of files but not “downgrading”, however is there a list of what constitutes a sufficient alteration to a file?
The variations policy states “It has been rebuilt to primarily serve the purpose of the extended functionality (eg. eCommerce) ok so the judge of this is down to the reviewers knowledge and opinion? I think it would be wise to have a slightly more definitive explanation or criteria of change (unless I have been stupid and missed it)
We agree! The policy needs more definition and examples, which we will work on providing in the coming weeks.
A forum thread was recently started in which some members of the community wanted to discuss “lite” versions of themes being sold along side the full featured version.
This was a great question to ask as it has been a point of confusion for quite some time now.
But first, some history…Originally our undocumented policy around this was a strict No. However, over time, things have changed and the benefit to both authors and buyers, if done correctly, makes sense. Just like in every other major marketplace, versions of a core product or “upgrades” are commonly available. As the demand for eCommerce grew, so did the demand to sell a standard theme and an eCommerce version, separately.
Once the pricing for these features was reconsidered, we also eventually reconsidered allowing an eCommerce version to be sold separately as the work involved was often significant and justified a price increase. These themes commonly had an eCommerce focus rather than being an all-in-one like we see frequently today. eCommerce support is also much easier to add to a theme than it used to be.
As the marketplace landscape continues to change, there’s an increasing demand for theme variations and themes that focus on a certain purpose. To better accomodate this demand for both authors and buyers, a limited degree of theme variations would need to be allowed (ie. not strictly limited to eCommerce). However, as we had no documented policy for this, we have worked towards getting things like this both clarified and documented publicly.
The Updated WordPress Variations PolicyYou can read the recently published variations policy here.
Our goals for this were to:
- Document the existing policy publicly
- Clarify where the “line” is which justifies a new version
- Adjust the policy according to community feedback and demand
We have completed the first and are working on the second and third. We are listening to community feedback and discussing the future of the policy.
What is the policy?In short, “lite” theme versions are not permitted. However, multiple theme versions are permitted.
What we’re trying to be careful of here is the confusion around what a “lite” theme is. There has been many instances where a “disabled” version (most often called “lite”) of a theme has been requested to be sold (either separately or on its own) in which the buyer could then “unlock” the full set of features via subsequent purchase. We do not feel this approach is appropriate for ThemeForest and have not allowed it. So the term “lite” had become associated with “not fully functioning.”
We want to make clear that the minimum requirement for ThemeForest items is fully functional products (a “standard” product).
Beyond this, however, a theme can have significant additions in functionality and purpose that justify a new version being sold (just adding a plugin and a few extra styles will not cut it). If a new version of a theme is permitted, it does not mean it can be sold elsewhere when you are an exclusive author. The core product is still viewed as being the same and we feel this would breach your exclusivity with Envato. The only exception to this is when the theme has been rebuilt for another platform (eg. WordPress vs Drupal).
Questions that need to be answered…
- What is a “standard” WordPress theme?
- Won’t this flood the marketplace with versions of everyone’s themes?
- Are there future improvements planned for this policy? If so, what are they?
We will be working to answer these questions and clarify the policy documentation in the coming weeks. Please let me know if there’s any questions I’ve missed or clarifications you’re looking for in the policy documentation. Thanks, everyone!
Unfortunately I’ve not been able to respond to this thread as quickly or as often as I’d have liked. As you can imagine I’ve been very busy working on various projects for ThemeForest and, most importantly, discussing the feedback everyone has provided here with the different teams. This tends to take a little time, thus the delay in followup to this thread.
I realize this policy comes as a surprise to some of you, although it has actually been in practice for some time now (though without official clarification or documentation). This is an area the team is working hard at improving (documenting and improving submission requirements, policies, etc).
Tomorrow morning I will be clarifying the concerns in this thread via a new thread where the discussion can more appropriately continue, which will be easier for me to compile and discuss with the team so we can make the necessary appropriate changes.
Thanks for understanding, everyone!
Bwt just currious if there is any plan/possibility to dispay “Last two weeks processing time” chart (days from submited to approved) for any selected marketplace/category ? So authors would know about what to expect. Best Regards, Andrey
This is not planned for the near future, though it is something we’ve thought about in various implementations. If something similar to this becomes a reality, we will update the community.
How in this situation we should plan exact time of our releases? Progress bar have helped us at least to plan it. New system is destructing this process. Please do not implement it.
Planning for an exact time of release has been a guessing game of sorts with or without the progress bar. A better solution for this would be providing information somewhere on average review turnaround times over a period of time. However, a solution like that isn’t currently in the works at this time and likely wouldn’t be an ideal solution to solve the “release timing” issue. Functionality allowing authors to publish at a specific time (once approved) would make more sense, which is an idea I hope to investigate further soon.
One of my items still on the queue for the 6th day and the progress bar still on the same position (80%) from Wednesday but items on the home page getting in. So it is not improvement.
The change hasn’t been deployed yet. This thread was advanced notification that this would be happening soon.
I wonder if it’s possible to display a numerical review status for each item, based on how many items are going to be reviewed before it.
For example, I post a sound effect and at first, it begins with:
Reviews to go: 238
Every time an item is reviewed, the number will count downwards until it is the very next item to be reviewed. Once it has been reviewed, it will leave the queue.
There could be separate queues based on what kind of submission the item is, whether it be New, an Update, or a Resubmission.I think it would be a lot more satisfying to see where you stand in the queue, based on a number, than a “pending” status.
The current version (the “progress bar”) functions pretty much like that. However, we have improved the functionality of the review queues to be more dynamic in considering various information about an item or author. This improves how efficiently we’re working through the queues but makes it much more difficult to indicate exactly when an item will be reviewed.
I personally don’t see how this is an improvement, but let’s see where this goes.
It’s certainly not ideal vs indicating approximately when an item will be reviewed, so in that sense I would agree that it’s not an improvement. However, the current implementation of indicating when an item will be reviewed is not accurate and gives authors an expectation that will not be met due to the way the system functions. We would rather provide a solution that is accurate until we are able to implement something more ideal. We have a list of ideas I hope to explore further soon.
I also like to see how long has it actually been since I uploaded.
Don’t worry, you’ll still see the elapsed time since the item was uploaded.
Some time ago a few changes were implemented in review queue functionality that increased their complexity in favor of more efficient queue management. Unfortunately this affected the item review “progress bar” (displayed on the Author Dashboard sidebar) and gave an inaccurate and misleading indication of when submitted items might be reviewed.
As the complexity of the review queue functionality is expected to increase, it becomes significantly more difficult to indicate when submitted items will be reviewed. So we’ve decided that until we’re able to provide a more ideal solution, we would change the information provided to be more relevant and accurate.
What are we changing?
- The “progress bar” shown when an item moves through the review queues will be removed.
- In place of the “progress bar” we will show the state of the submitted item and the state of that item in the review queues.
We will also be publishing what these states are and what they mean in the Knowledgebase once the change is about to be deployed. I don’t yet have an exact ETA for deployment of the change but once I do, I will post an update in this thread.A few examples of how this new information might read is:
- Example Item Title – New, currently Pending
- Example Item Title – Update, currently Pending
- Example Item Title – Resubmission, currently Held
- Example Item Title – New, currently in Standby
Quick update here.
1) This is a policy clarification, not a new policy.
2) You can see the published policy here: http://support.envato.com/index.php?/Knowledgebase/Article/View/528 Please keep in mind that we’re just clarifying an existing policy and, as stated before, will adjust appropriately according to feedback we receive.
3) I’ve read through this thread and the feedback everyone has provided. I will be discussing it with the team.
Thanks for your input, everyone! Please be patient while we work to ensure the policy best fits the needs of the community.
I understand it may not sound like it makes sense, but there’s actually been many authors and buyers in favor of it, though it’s important for it to be properly managed. For example, if a buyer is looking for a standard WordPress theme, why should they be forced to purchase a more expensive version (which is only more expensive because it is built with advanced features the buyer doesn’t want or need).
Conversely, an author that has built a tremendously advanced theme may lose sales from buyers seeking a simpler version in a lower price bracket.
The obvious tradeoff to this is that a single theme design could potentially have several variations in the library; something we must carefully monitor and further evolve the marketplaces to best accomodate the library and community needs.
We feel that authors should be enabled to build products buyers are seeking and buyers should be able to find the level and type of product they’re seeking, which is why we feel this should be allowed but for it’s intended purpose. That means if an author wishes to build a variation of a theme, it needs to justify being sold as a separate theme. And that won’t be permitted with only minor additions or changes. The Review team will be evaluating these themes to ensure they provide appropriate levels of added functionality and value.
Hopefully that sheds some extra light on our thoughts for this. We’ll soon have a published policy that we can further work from.
This piece of work has now hit the Operations Team sprint (in the Review Team) and I’m following up to update on a few things.
1) The policy has been further discussed among the team and we’ve agreed on what the current policy should be for the time being. However, we do recognize the situation is not ideal and improvements will need to be made along the way.
2) We will publish the policy on this (covering theme variations) into the Knowledgebase soon and will update this thread once we’ve done so. Our target is before the end of February.
3) Please be mindful that the policy won’t cover every situation and there’s likely to be many questions to be answered. As these questions come up, we will work to answer them and further clarify the policy, with examples if necessary.
4) An item that was recently removed due to the lack of clarity on this policy will likely be coming back soon, so don’t worry, this isn’t a mistake.