You can clone with
HTTPS or Subversion.
In users.rb, I'm wondering why in the user_recent_media method you chose to return response["data"] and not simply response like all other calls that return collections of media?
This makes paginating through a user's recent feed difficult, as you won't easily know what to pass in for the max_id parameter as there's not next_max_id returned.
Was there a particular reason for this choice?
working on the same issue.
I might patch this, @rapsli have you got anywhere with this yet?
ok, I'll have a look today.
@rapsli @jonbuda @shayne
Hi Guys, I've been looking at this today, and as far as I can see, changing the return to response instead response["data"] is good enough, however, this would obviously break anything using the current response.
I'm just patching my local gem code for now.
The same issue exists with #user_follows so it isn't possible to paginate through results without modifying the code.
I think we should just patch these changes in, @shayne is probably busy as hell right now.
If you just add issues for each instance where the pagination doesn't get sent, I can patch them in my fork and then send over a pull request when they're all done.
Up to individuals how you handle the shortfall but I'd recommend replacing/patching the gem rb files until you know the issue is fixed.
I'm also going to post a more built out example app (using Sinatra) that uses the paging patches. I'll probably announce it here when the thing is in a github repo.
Submitting a patch for this.
Hey. I am facing the same issue. Any update on this? I realize the pull request was requested almost 2 months ago. Is the issue going to be rectified? Any info will be appreciated.
@gurrinder for the moment I'm just using mine, in my Gemfile
# Custom instagram gem
gem "instagram", :git => 'https://github.com/jasonm23/instagram-ruby-gem.git'
I expect @shayne is busy with other stuff for the moment.
thanks @jasonm23 . Hope it gets merged in soon.
@jasonm23 want to attach a pull-request to this issue?
@shayne sure, it's this one, #28
However, it doesn't properly address all the issues with response[:data] just the ones that have been an issue for me.
Notably, user_follows, as mentioned above hasn't been addressed.
I submitted pull #41 last week to route around all of the truncating-of-meaningful-data issue.
@yaauie Looks pretty good. Would you mind adding tests and perhaps a pagination example to the readme (if not I can later this week), before we cut a new gem? This change would probably warrant a 1.0 release.
@shayne before tagging v.1.0 I think there's some work to do on exception management. (i.e. from Faraday when the IG servers fail.)
@shayne I can definitely do that. This change definitely warrants a 0.9.x since it breaks the API, but if you want to go all the way to a 1.0, that's up to you.
Ok– let's plan on better exception handling + API changes for 1.0
Great, I should probably scan my logs for some examples of where IG has responded badly. Mostly they seem to be faraday related, I'll open up some specific issues for them. it's 3am so I'm turning in for the night, I'll have a look tomorrow.
I just remember getting a lot of BadRequest exceptions occurring randomly when the IG servers were up but not responding all the time.
We also get JSON (or YAJL or whatever MultiJson adapter we're using) parse errors when the API decides to return an HTML error page (e.g., 502 Bad Gateway or a 404 for a malformed request like https://api.instagram.com/users/USERNAME_INSTEAD_OF_ID?access_token=fubar )
502 Bad Gateway
I've opened up a couple of new http status related issues
Seems like this was all given up on…any chance of getting some attention again?