Hey in /search/comment I can see
author_comment come back, is it possible to have something similar for verified buyer? like
buyer_comment so we can see if they have purchased the item or not.
edit: also a note for anyone playing with the comment API, to get a direct link to the comment (e.g. it could be on page 2 or 3, not the latest “comments” page) just append the Comment ID to the end of the URL, and it will redirect to the correct page and hash. e.g. themeforest.net/item/item-name/12345678/comments/54321
edit again: I was just trying to figure this one out too,
buyer_and_author ? Is it true if the author has replied to the message? Kind of like an unanswered flag?
For instance a new user can not simply use the verify item unless you use the oauth which is more work for the same result.
2 curl requests, rather than just 1 which was done before.
Just 1, no OAuth, same as before, see my code snippet http://codecanyon.net/forums/thread/introducing-the-new-envato-api/176182?page=2&message_id=1269051#1269051And here’s another previous post with more detail on 1 click verif http://codecanyon.net/forums/thread/introducing-the-new-envato-api/176182?page=7&message_id=1271995#1271995
edit: LSVRthemes beat me!
Please see this help article https://help.market.envato.com/hc/en-us/articles/204013780-The-Item-Is-Not-Working
I think this would be much clearer if the support definition was available first.
If the definition of support is very clear then it will certainly cut down on majority of support abuse, and I really don’t think we will get buyers abusing the system (asking for feature requests, customisations, incompatibilities between themes and plugins, etc..).
So if someone pays for extra support and then starts complaining that they need a new feature, too bad, it will be clearly defined they are not allowed to ask about this. So we will have an official ruling to fall back on.
This is good!
They all use decent caching and reverse proxies like nginx. You’re basically getting a static copy of WordPress without going through the hassle of manually making a static copy
(i.e. nginx will look for a cached html file that was automatically generated by WordPress, if it finds it, that gets sent to the client, if it doesn’t find it, it hits Apache/WordPress/PHP and generates the static cached files automatically for next time. And if there are login cookies present or certain “shopping cart” ajax calls are made, those are not cached, so you can have a fully static html cached WordPress theme but still have things like shopping cart quantity updated via ajax just fine, and you can still login to WP and make changes, it’s all rreally good ).