wopethemes saidYour order must have set off their fraud filters for some reason. I would give them time to get back to you and sort this out. Linode is another unmanaged VPS provider that I personally recommend.
Digital Ocean look suck. tried and paied $10 and the account get locked with waiting ticket and no chat support. sound very suck services and I’m trying new one.
+1 – They’re worth giving them a chance to sort it out with you in my opinion.
Interestingly since the last time I posted in this thread, I’ve switched to Digital Ocean and have loved them so far. (ServInt was great, but Digital Ocean better suited my needs going forward.) It takes a little more awareness of server management, but it was easy enough to pick up in a few days. I also combine mine with ServerPilot to handle security updates and stuff like that, which really simplifies the setup and management aspects of my droplets.
Oops! Looks like the discussed update for this thread wasn’t able to be posted in time. Sorry about that!
In regards to future plans, we currently have projects in dev taking into account demands for larger file sizes but this work is still some time out from being finished. Until then, the VideoHive review team is making exceptions when appropriate (when you’ve done your best to limit file size). If you feel you need to go over 1 GB for your uploaded item, please include additional information as to why in your message to the review team.
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