Why would you think that Layers is required for WordPress plugins? Layers is just one among many different frameworks available for WordPress, and if you make plugin for specific framework you need to make it clear in the item description.
There are no special WordPress plugins guidelines, just make good plugin, good documentation for it, make sure plugin doesn’t have some security issues. And, the rest is up to the reviewer to approve or not based on plugin functionality.
The only category with decent sales on CodeCanyon is WordPress, and WordPress plugins as a whole sell a lot more (10 to 20 times more) than PHP scripts category. Just compare top selling products in these categories to see the difference:http://codecanyon.net/popular_item/by_category?category=php-scripts http://codecanyon.net/popular_item/by_category?category=wordpress
You must have well written documentation, there is no way to avoid it. If your documentation is lacking, you will have a lot of support questions because users will not know how to use the plugin, and it is more than likely that reviewer will reject the plugin with bad documentation.
Gewora saidI thought so too originally, but at the moment it’s just the old API (plus search) on a new framework. The OAuth stuff does let them implement this in the future though, so it’s a big step in the right direction (see post above)
It looked like it is now possible to verify a purchase simply by authorizing the user with Envato
Current OAuth they made is not good. It requires to set return URL when adding new app. So, if you make a plugin for clients that will need to use OAuth, each client needs to register own app with own return URL for that too work. And that defeats the purpose of having new API and OAuth in the first place. Clients using plugins or applications based on API and OAuth need a simple solution where the plugin author has setup application, and not each client.
Right now the only solution is to have each client generate personal token and that is the same as having the old API key. Basically we need to rewrite all API code for nothing, maybe few new endpoints only. New API needs to be made as it should be done before it is ready for proper use. Until then, I plan to stick with old API for as long as possible.
I tried to post comment there, but Disqus decided that my comments are spam, and removed them….
Hi Milan, thanks for the questions and for the heads-up!Anything submitted requires approval unfortunately (to combat spam) so please be patient while we periodically check and approve all submitted messages. You’re completely right though – your messages were flagged as spam for some reason but I’ve located them and have approved them for you. Great questions and Giancarlo will get around to answering them as soon as he gets into the office today!
Thanks! I am looking forward to answers.
Hey guys! We’re running an AMA with Giancarlo this week on our blog so if you have API questions, ideas, or need help, I would encourage you to post any API questions via our AMA post to keep the conversation in one place and to get the fastest answers.
I tried to post comment there, but Disqus decided that my comments are spam, and removed them. I tried posting all my 5 questions from this thread at once, and one by one, but now all my comments are marked as spam. Can Giancarlo respond to my questions here, or read questions from this reply and respond in the blog post at least. My questions: http://codecanyon.net/forums/thread/introducing-the-new-envato-api/176182?page=1&message_id=1268553#1268553
I have few questions about new and old API:
1. Until when the old API will remain valid? My plugins are using it and switching to new one is not easy thing to do, so I need to know about old API status.
2. There is nothing mentioned about the API call limits. What are the limits and how they are applied: per IP/user or per app?
3. Can you write some tutorials or step by step instructions for plugin authors related to switching to new API? Can you write tutorial on creating the app for use with OAUTH?
4. When creating new app, there is one field that is a very big problem: Confirmation URL. In relation to my plugins that use API, this field is impossible to use. For instance: my plugin is made for WordPress to check user purchase codes and allow them to access forums. So, someone buys my plugin and installs it on its website. His website users enter purchase codes to access forum. How can I use new API to do this? Based on new API limited information, I need to create new APP for API, but how to create it, and what to use for confirmation URL? This URL needs to return users back to the website where plugin is installed, and I have no way of knowing where that is. We need a lot more information about how all this will work on the real use examples for API as we had them so far with old API. Based on the way API works, each buyer of my plugin has to register for own APP, and than insert that data into my plugin to be allowed to use it and to be able to set own confirmation URL.
5. Do you have and API libraries ready to use made? Most companies that have API have code libraries that can be used to avoid implementation problems. PHP library will be first one to have.
Can you please answer as soon as possible, especially in regard to question 4.
No, this is hard reject (it says: ‘cannot be resubmitted’).
New Google mobile search and mobile friendly results are not affecting whole websites but individual pages. So, if you have website where some pages are responsive and some pages are not responsive, they will only punish non responsive pages. As it stands now, only home pages for all Envato marketplaces are responsive, so they are the only pages that will be able to show in the search results, but no products will be visible on the Google search on mobile devices.
This is really, really bad news, and it is amazing how badly Envato handled responsive design changes knowing for a while now that Google will make this change. If Envato doesn’t switch to responsive design soon, all our items will be invisible when searched on mobile devices very soon.
Right now mobile search is still not penalizing the non responsive pages, but I expect every future search engine reindexing will use new information and remove all Envato items pages from search results on mobile devices.
The new pop out modal window for tags is far less usable than a list. it seems that changes are made just to look different rather than any actual usability improvements.
It is very doubtful that any usability study is done with new search other than “it looks cool”. Envato was suppose to make website responsive and this here is a huge step backwards, since any popup to select anything will look bad on small screen. The only way to make search on small screens is to have it as off-canvas panel and not to use popups anywhere.