our software relies on the ref parameter passed to likes and custom actions to track attribution. Since this morning the fb_ref parameter has stopped appearing on like links on the timeline and is appearing embedded in a different parameter in custom action links on the timeline. Examples below...
This is a timeline link for a Like made 18 hours ago. It has the fb_ref parameter:
http://prod.demo.smartsaasp.techlightenment.com/ecommerce/product/?id=1407109375&fb_ref=1002100600__I8RH9f_yxWiH4DJKIMuhm_1407109375&fb_source=timeline
This is a timeline link for a Like made today. It is missing an fb_ref parameter. Also note that fb_source=aggregation, even though the link is appearing in the same style as the previous example (fb_source=timeline):
http://prod.demo.smartsaasp.techlightenment.com/ecommerce/product/?id=184537892X&fb_action_ids=10151115280129669&fb_action_types=og.likes&fb_source=aggregation&fb_aggregation_id=288381481237582
This is a link from the recent activity panel in the timeline for a Like made today. It is missing an fb_ref parameter:
prod.demo.smartsaasp.techlightenment.com/ecommerce/product/?id=184537892X&fb_action_ids=10151115280129669&fb_source=timeline_og&action_object_map=%7B%2210151115280129669%22%3A10151068797314544%7D&action_type_map=%7B%2210151115280129669%22%3A%22og.likes%22%7D&action_ref_map=%5B%5D
Finally, this is a link from the recent activity panel in the timeline for custom edge (view) made today. It actually has our trackcode embedded within the action_object_map parameter, but does not contain an fb_ref parameter.
prod.demo.smartsaasp.techlightenment.com/ecommerce/product/?id=184537892X&fb_action_ids=10151115279759669&fb_source=timeline_og&action_object_map=%7B%2210151115279759669%22%3A10151068797314544%7D&action_type_map=%7B%2210151115279759669%22%3A%22scrm-ecommerce-prd%3Aview%22%7D&action_ref_map=%7B%2210151115279759669%22%3A%221002F00400_E6a0_zsqF3j4e3vInVUiN184537892X%22%7D
I assure you that the ref parameter is being correctly sent when we do likes and custom edges.
Can anyone help?
Related
Posting links via Graph to my feed, i am noticing that new "story" and "story_tags" fields are being implicitly added (without my intention). this is new behavior as of on our around 07/20/12, as if i look at links prior to that in my feed, they did not include these extra 2 fields.
one of the issues i have with this is that the "story" and/or "story_tags" field appears to be triggering something new that has unexpectedly altered the display of the link on my feed, as the new posts no longer resemble those i made 07/19 and earlier, IF the link is to a page on Facebook. specifically, my "picture," "caption" and "description" values seem to be getting overwritten by content pulled from the FB page i am linking to. if however i link to an external page then this does not occur (although curiously the "caption" field seems to now be overwritten with the link in this case, or simply ignored altogether).
furthermore, i have an Xbox 360 game that posts links to my page (it links to a page on Facebook for the game). i just did one now. when i look at it in my feed in Graph it does not contain a "story" or "story_tags" field. thus, their caption, description and picture fields are not being overwritten like mine are when i set my link to a Facebook page. how are they getting around this? is there some way i can do the same through Graph?
I am not sure what you mean exactly, but since I've started working with Graph i've noticed the story and story_tags.
As far as I could see a message is posted by a person itself, and a story is something like [user] is tagged in picture, or [user] liked a story.
And indeed the Story and story_tags do not contain a whole lot of info. But you should check for picture caption en description anyway because as I've noticed they aren't always there.
I am writing an application that needs to retrieve all posts on any given facebook page. For the McDonald's page, I would use this url:
https://graph.facebook.com/McDonalds/posts?access_token=xxx&limit=5000
The problem is that first, I do not receive any posts older than 2011-11-01 and the number of posts shown is much less than 5000. This means that the limit parameter isn't working properly. I looked this up and found that it was a known bug.
Then I tried to follow the next and previous paging information provided in the end and even using that I can't get past 2011-01-24. After following the next link 2 times, an empty page comes up. The McDonalds page is much older and contains more posts. So the question is, how on earth am I supposed to retrieve older posts. Is there any workaround at all?
There is a limit on the limit. Try using since & until to extend the date params
https://graph.facebook.com/McDonalds/posts?access_token=xxx&limit=5000&since=2+years+ago&until=now
&limit=5000&since=2+years+ago&until=now
&limit=5000&since=3+years+ago&until=now
I use the JavaScript SDK for Facebook Connect.
Yesterday I loaded all the friends of a logged in user like this:
https://graph.facebook.com/me/friends?fields=name,first_name,picture&access_token=MYACCESSTOKEN&callback=?
Using this code I got the id, name, first name and picture of all the friends that the logged in user has. This was called using AJAX/jsonp. As I said, it worked yesterday and no modifications have been done to the code since then.
Today I get the id, name and the first name - no picture(!) Could this be a glitch in Facebook Graph, has there been any updates that I could have missed or is the above call to the graph API invalid?
Is this a correct way to get the picture of all friends?
You're right, the picture field is not being returned anymore. However it is very easy to get the picture URL. http://graph.facebook.com/{friendId}/picture you can either call that to get it programmatically, or even have that graph call as the src attribute of the image tag <img src="http://graph.facebook.com/{friendId}/picture" />.
Update: Bug seems to be fixed now.
Once again, Facebook proves themselves. Why would anyone just remove something from an API without at least notifying people they are going to do it?
Fyi, I filed this bug report:
https://developers.facebook.com/bugs/269804093087242
My guess is that it gets ignored or closed as either a duplicate or wontfix and there won't be any recourse.
The issue with the workaround above is that img src url ends up being a http redirect instead of the absolute url like before. That just slows things down.
The button share (like) doesn't want to update the information on page. The first time deduces the information correctly, but then, at update of page and button click the old information is deduced. I used different browsers, in them the old information is deduced.
Only after I interpose url in Object Debugger after that the page is transferred correctly. How to make so that it happened without Object Debugger ?
Example:
enter link description here
But this is how it's supposed to work. Your page is not expected to change often. You are responsible for updating Facebook when you change your page.
Looks like an issue was closed related to the question I'm about to ask, so I wonder if I'm going to be skating on thin ice, but here goes. I feel like even though this is kind of localized by nature, it could be a useful example for other developers dealing with the Like button.
I seem to be having issues regarding the Facebook like button. The infuriating part is that I'm pretty confident I have everything setup properly, and even though the linter says "hey, this all looks kosher!" the like button fails to get the correct content and uses cached info from a different page.
Here's the case: referlocal.com. We serve daily deals, and list them right off the homepage. There can be one of many deals listed on that homepage, so obviously Facebook is seeing just one when it goes to take a peek at the root directory. Now, on the homepage, whatever deal your viewing has a FB Like XFBML tag with href and ref attributes set. Every page that displays a deal also has OG tags pointing directly to the offer view page. Deals can also be viewed on user pages. So, on these three paths:
/
/{username}
/offers/{city}/{title-url-alias}
a like button is included as well as OG tags that point to /offers/{city}/{title-url-alias}. For about 3 weeks, the button worked like a champ. But recently, it's been performing strangely. For any deal, regardless of the 3 locations, it always uses the information cached from the previous days "/" deal. Regardless of the OG tags or origination.
Here's the wildly confusing part. The Facebook Linter is supposed to recache the information on the page, right? Well, it sort of does. It picks up on all of the appropriate information set in the OG tags, but when you click the Like button at the bottom of the page, no dice, still uses the deal FB saw on the homepage from the day before.
I know this is probably killing my argument for localization, but check this out:
http://developers.facebook.com/tools/lint/?url=http%3A%2F%2Freferlocal.com%2Foffers%2Fdallas%2Fget-20-of-authentic-italian-american-cuisine-for-only-10-at-leggios-italian-ristorante-dallas
Regardless of the fact that the linter finds all the appropriate information, the like button at the bottom still is liking a deal FB cached from the previous day.
Any ideas?
I had this problem too. The linter caches things in a very weird manner - seems like the best thing to do is either to add a query string and change it every time, or just rename the file every time you're checking.