Change to the new-files-from-user API method

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.

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.

stevehodgkiss said
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!

Here’s two examples of the scrape script:

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.

stevehodgkiss said
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.

@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.

@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

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