38 posts
  • Australia
  • Envato Developer
  • Envato Staff
  • Exclusive Author
  • Has been a member for 3-4 years
stevehodgkiss Dev says

This change has been reverted, the API method will now return all items as it used to. This method is one of the only ways to easily get all items for a user and we’ll look at improving performance in other ways.

We’d much rather you use the API than scrape the site.

If we revisit this again in the future we’ll be sure to provide an alternative way to get the same functionality. As @aaranmcguire suggests pagination may be the way to go.

973 posts
  • United Kingdom
  • Attended a Community Meetup
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
  • Sold between 5 000 and 10 000 dollars
  • Has been a member for 3-4 years
  • Envato Studio (Microlancer) Beta Tester
  • Bought between 100 and 499 items
  • Referred between 10 and 49 users
  • Exclusive Author
aaranmcguire says

Thanks, I was thinking of what would be the best way to do large info like this,

I think if you have a cache file would be best, then when a new item is approved from that user, delete the cache and remake it when there is a API call. I know it requires a bit of work but I think its the best way, unless you have memcache servers.

290 posts
  • Sold between 10 000 and 50 000 dollars
  • Exclusive Author
  • Author had a File in an Envato Bundle
  • Bought between 10 and 49 items
  • Referred between 50 and 99 users
  • Has been a member for 2-3 years
  • United States
SchwartzSound says

We’d much rather you use the API than scrape the site.

On that, is there a reason certain data fields aren’t included in the API ? For instance, some of the queries that contain items, don’t provide a date for the item, where others do. Also useful info (for AJ items) such as BPM and Looped Audio aren’t included. Would love to have access to these without pagescraping, since they must already be in the database somewhere. Also, as far as I’m aware there’s no other way to get anything out of the item description without pagescraping. I’d love to not pagescrape as the API is much neater and faster—any possibility of including a mini description, or even an separate item blurb/summary as part of the API in the future?

Thanks for all your hard work on this great tool!

2964 posts
  • Football Contest Participant/Runner-up
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
+11 more
dtbaker Volunteer moderator says

Here’s two examples of the scrape script:

http://dtbaker.com.au/premium-php-applications/index.html
http://dtbaker.com.au/premium-website-templates/index.html

This script does a simple html scrape of the item pages once and caches the results forever for processing.

Unfortunately getting this information via API is not possible at this stage.

629 posts
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 4-5 years
  • Sold between 100 and 1 000 dollars
Thecodingdude says

This change has been reverted, the API method will now return all items as it used to. This method is one of the only ways to easily get all items for a user and we’ll look at improving performance in other ways.

We’d much rather you use the API than scrape the site.

If we revisit this again in the future we’ll be sure to provide an alternative way to get the same functionality. As @aaranmcguire suggests pagination may be the way to go.

Why do you never ask the community before you do changes like this only to revert it once you know it’s not very popular…Seems crazy to me…

If you want people to use the API , provide the tools and functionality. For what you don’t have, scraping is the next best option.

3716 posts Community Moderator
  • Author had a File in an Envato Bundle
  • Grew a moustache for the Envato Movember competition
  • Community Moderator
  • Referred more than 2000 users
  • Has been a member for 5-6 years
  • United Kingdom
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
  • Contributed a Blog Post
+4 more
quickandeasy Volunteer moderator says

@Thecodingdude,

As originally said, this untapped method of pulling all items from a user was causing back-end performance issues.

Whilst I can agree with you that it would have been nice to inform us prior to the change so we had time to update our websites and apps, Envato must make their decisions based on the masses of data they have have on the impact, costs and returns of certain features, not simply the opinion of users.

2964 posts
  • Football Contest Participant/Runner-up
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
+11 more
dtbaker Volunteer moderator says

@thecodingdude – it has always been documented as returning limited items, they were just making improvements to site speed (praise? never!) by adjusting the API to reflect the documentation.

isn’t it good that they reverted back to showing all items to support the community? now that they know people were using that feature?

meh

167 posts
  • Australia
  • Sold between 10 000 and 50 000 dollars
  • Bought between 10 and 49 items
  • Exclusive Author
  • Has been a member for 3-4 years
  • Referred between 10 and 49 users
michaeldale says

How about they just fix the SQL query so that it isn’t slow?

565 posts
  • Exclusive Author
  • Netherlands
  • Has been a member for 1-2 years
  • Sold between 100 and 1 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
Coriiander says

Hey hey,

Even though this thread is a year old, I found it to be fitting to reply here instead of creating a new thread. Here goes:

It would be really, really convenient to have an API-call to simply return the total number of files for a given user (discussably on a given site). A fast one. It should simply return an integral value, thus without any further metadata. Right now if we want to know whether our local db is up to date for a given user, we need to either scrape the user profile to get the number of files value (subject to getting broken due to stylechanges etc), or call the still rather slow new-files-from-user function. Seeing author profiles load pretty fast and represent #-sales pretty fast (loadssss faster than new-files-from-user anyway) I’m pretty sure that the author records contain a number_of_files-alike field. An API returning the value of that field would be really great. Not just for us, but also for lowering the serverload.

Hah, even better would be (and yes, I know it will probably never happen) if we could get an API like: “get-user-filecount(string site)”, which then returns a JSON-object array with the total number of files for each user on that site (integral numbers, no metadata, just the numbers). Oh, that would be so great.

565 posts
  • Exclusive Author
  • Netherlands
  • Has been a member for 1-2 years
  • Sold between 100 and 1 000 dollars
  • Bought between 1 and 9 items
  • Referred between 1 and 9 users
Coriiander says

Good god, I’m sorry, never mind. I somehow missed the “user-items-by-site” API. I already implemented it in my API-wrapper class a while ago, but never came across it again seeing it was accidentally set as a private member. But ohhhh, oh how lovely it is!

by
by
by
by
by
by