I have a Facebook aplication on my site with multi friend selector which posts to selected friends.
When I test it on local host all works fine, but when I upload it to live server on the last step of sending when I click post to my selected friends, there is a pop-up warning saying :
Sorry, you have run out of requests to sent with this application.
Please try again tomorrow
But it was my first post on the live server... What options or something else should I change to avoid this warning?
Added from comments
<fb:serverfbml width= "740" height="407" >
<script type="text/fbml">
<fb:request-form action="%%POSTCARD_ACTION_URL%%?at=send_postcard" method="POST" type="POSTCARD" content='Click the View button to see the Postcard sent to you. <fb:req-choice url="%%FACEBOOK_ACTION_URL%%?view=%%hash%%" label="View">' invite="false">
<input type="hidden" name="mail_hash" id ="mail_hash" value="%%hash%%">
<fb:multi-friend-selector style="width:80%;" showborder="false" actiontext="Select the friends you want send postcard." rows="3" bypass="cancel" email_invite="false" />
</fb:request-form>
</script>
</fb:serverfbml>
I am using a multi-friend-selector wraped into serverfbml
If you were testing your application's invite feature, and deleted the requests when the application was not in sand box mode, then all the request rejections were calculated into the "user feedback" of your application....
Once facebook's systems have decided that your application has received enough negative feedback,they will start limiting your application's features. One such feature that they can limit is requests...
All limitations enforced on your application can be viewed in the Insights >> Diagnostics tab in your application's settings.
With regard to initial invite limitations, when you start developing your application, AFAIK, you have a limit of 50 requests per user, per day as shown below :
UPDATE
After some further discussion and updating the original question, It seems that you are using the old method of inviting friends - FBML. As you can see from the documentation pages of FBML, they are in the process of (and nearly finished) removing their support for it.
We are deprecating FBML. On Jan 1, 2012: FBML will no longer be
supported on Platform. June 1, 2012: FBML apps will no longer work.
All FBML endpoints are removed. If you are building a new application
on Facebook.com, please implement your application using HTML,
JavaScript and CSS. You can use our JavaScript SDK and Social Plugins
to embedded many of the same social features available in FBML.
You should seriously consider migrating to use the newer Requests Dialog. All the information you need is in link.
https://developers.facebook.com/docs/reference/dialogs/requests/
You'll need to use the Facebook JavaScript SDK and after setting it up and calling the FB.init() function, you'll want to make a call to the FB.ui() function and tell it to open the Requests Dialog.
Further Update
After filing a bug report to do with the incorrect displaying of Request 1.0 when the application from which the screenshot was taken was set to use Request 2.0, Facebook replied to the bug first by "confirming and assigning" (see older responses in the bug report) and then stating that this "by design" will be removed as soon as FBML is totally deprecated. Facebook also stated :
Request 2.0 does not have limits as 1.0 did.
Good to know :P
Related
I have integrated Facebook with my application to post content. It was working until version 1.2 of the application, but now I am getting a security warning just after login as bellow.
The weird thing about this security warning is that it works for one of my Facebook accounts properly without any warning as previously, but I get this warning with my other account. I have attached a screen shot of the issue:
Disabling the secure browsing is not worth , as we cant make all the users to disable secure browsing.
I do have resolved.Check my answer here. Escape from Facebook security Warning
After a long time spend on Internet to search this issue. Finally I got the answer about it.
Login to Facebook account > Go to Privacy Setting > Click on Security tag on left side of Page > then Disable Secure browsing
Now Reset your simulator and and then Run application and again login it will work for sure
Short answer is that the problem can be solved if you use your own redirect_uri rather than the standard facebook one. When the access token is returned, the standard www.facebook.com/connect/login_success.html page has a timer which will change the URL possibly before your app can retrieve the access token.
This problem can occur related to internet latency. We had two customers report issues with this one in Myanmar and one in the UK. No issues for anyone else. Assuming you are authorizing like this:
https://www.facebook.com/v2.10/dialog/oauth?client_id=999999999999999&redirect_uri=https://www.facebook.com/connect/login_success.html&response_type=token&scope=user_photos,user_events&display=popup
For the default redirect_uri (https://www.facebook.com/connect/login_success.html), facebook returns the access_token in the parameters of the URL, but the html body for that page contains two timers:
Success <br/>
<b id="warning" style="display: none; color:red">
SECURITY WARNING: Please treat the URL above as you would your password and do not share it with anyone.
See the Facebook Help Center for more information.
</b>
<script type="text/javascript">
document.domain = 'facebook.com';
if (window == top) {
setTimeout(function () { document.getElementById("warning").style.display = "block"; }, 2000);
}
setTimeout(function () { if (window.history.replaceState) { window.history.replaceState({}, "", "\/connect\/blank.html#_=_"); } }, 2000);
</script>
When either timer fires, it will change the URL which removes the access_token. So as long as you catch that before it changes, everything works. In our case, we were using an embedded browser control under Windows and monitoring the navigated links. As long as the code can receive a navigation event containing the access_token before this timeout occurs, then everything worked. We were never able to determine how latency of the internet connection and possibly some combination of a user's slow computer caused this problem, but this solved it.
In the Facebook Login settings for your facebook app, add your own URIs to the list of Valid OAuth redirect URIs. If you redirect to your own html page, then you can avoid the facebook timeout.
When going to the set up pages for all the Social Plugins, they now provide example code using an APP ID.
http://developers.facebook.com/docs/plugins/
Is an APP ID now required for the Like Button and other plugins? What happens if an APP ID is not included when using the plugins?
I've checked the Facebook developer blog and read about the Like Button Migration. I haven't been able to find a straight answer for this either there or in the FB Like Reference.
Notice:
This is an old dated information, the official facebook's behaviors are changed.
Simply, the answer is No, just look at the following official Facebook resource.
Notice: To do it without need to the app id, you have to visit the above page when you are signed out from Facebook. Look at the following screen shot.
As semsem said, the simple answer is "no it is not required"... there are ways to get around having an appId associated with the "like" button. Here's my experience working with this. I'm not a Facebook or Open Graph expert, so YMMV.
Why we avoided using the appId on the button:
We're providing an service where we have one website (the engine, as it were) that provides a service distributing online courses to students (customers). Instructors (also customers) who what to use our service to disseminate courses to students can brand the site how they wish, and map their domain to their section of our website that serves those course(s).
As a simplified example: we serve from http://courses.example.com/instructor_name, but we want students to access the content through http://www.instructors-domain.com/. Any courses would be sub-directories off the base URL.
Associating the "like" button with our Facebook App disallows any cross domain shenanigans. While there are valid reasons for doing so, it doesn't work for where we're at in our company and product evolution. So we needed to find a workaround.
We wanted to allow folks to "like" a course, have the "story" point to the appropriate places on the net, as well as get some customization (e.g. "NAME likes an online course on FBAppName"). We basically achieved this. We lost some functionality which we deemed acceptable at this point in our evolution.
The short of it
I used the iframe version of the Facebook "like" button as dictated by the appropriate Facebook developer's page (for the link see semesm's answer for the link, I got no rep). I took their code snippet and manually removed the appId query string in the iframe's src.
In the "liked" page itself (which was the same page that had the "like" button) I used the Open Graph meta tags including specifying the appId. (These tags were specified: fb:app_id, og:type, og:url, og:site_name, og:title, og:description, og:image.)
The og:type was our custom type of the form 'namespace:app_custom_object_name'.
A failed approach
My first attempt was to use what I understand as the preferred method, the "HTML5" tab in the "Get Code" section of the developer's "like-button" page. I tried their method stripping the appId from the appropriate places. This method proved ineffectual.
If the domain doesn't match that in the Facebook App, there will be no "like" button.
If the domain does match, the "like" button will appear. However, it takes 3 clicks to actually "like" something. The first click changes the "thumbs-up Like" icon to a normal anchor with one word that didn't make obvious sense (I forgot what the word was). The second click will brings up the login/authorization window for using our app. The third actually bring up the modern fancy "like" box where you can type in a comment. I didn't find a way around this behavior.
Note that when I specified the appId in this approach on the appropriate domain, it worked as one would expect (though inconsistent with our desired behavior).
I did not try the other two options in the "Get Code" section of the "like-button" page.
Informed speculation and rumor
In my research around this, my overall impression is that requiring an appId is the way of the future for Facebook. Who knows if the old way will be depreciated, probably never, though I didn't find anything in the docs talking about this "legacy" behavior. This makes sense to me with their newer offerings and the advanced tracking that becomes available with this method.
I've seen suggestions that the "likes" used in this manner are akin to second-class citizens... treated as inferior in some respects. In my own experimentation I found the behavior of the fully specified appId (in the "like" button itself) to be different and more accessible and predictable (in terms of Open Graph queries and visibility on my limited Facebook tests) than the partially specified appId. (Again, I've found no solid documentation on this, and did not endeavor to full grok the differences.)
May this info help someone else along. Good luck!
So, I just tried the sємsєм method, as comments say: Facebook want you to login to get the code, and if you have an app, you have to choose one.
But if you don't, it gives you a code without any app reference.
So when you get a code – no matter any app you choose –, you just need to remove the appId parameter in the .js URL (&appId=##############), and you got (for the latest HTML5 code, 6th line):
js.src = "//connect.facebook.net/en_US/all.js#xfbml=1";
The code for the div element does not change.
I simply use the URL code inside an iframe tag without an appID and it seams to work,
here is an example:
<iframe src="http://www.facebook.com/plugins/like.php?href=<%=request.original_url%>&width&layout=button_count&action=like&show_faces=false&share=false&height=35&appId=" frameBorder="0" width="150" height="25">
</iframe>
According to Facebook's Social Plugins FAQ
Web: If you are using Social Plugins on the web, you do not need to create a Facebook app for integrating a Social Plugin.
iOS/Android: If you are using Social Plugins within a iOS or Android app, you need to create a Facebook app and tie it to your app identifier.
It seems that the official answer is that they are only required for iOS/Android.
I'm going to add the ability to comments the products trought the "Facebook comments plugin" on a dynamic web marketplace based on Yii framework .
So, today I created a new facebook app, I included the facebook sdk js file and I added this html code to the view that render a single product:
<div class="fb-comments" data-href="<?=$this->createAbsoluteUrl('site/courseDetail',array('id'=>$model->course_profile_id))?>" data-num-posts="10" data-width="470"></div>.
The comment is linked to the URL!!
Well, what happens if the domain change or if I decide to add an url rewrite engine to my web application?
I suppose that I loose all the comments....weird....it is a big limitation...
I read the documentation: https://developers.facebook.com/docs/reference/plugins/comments/
and I saw that now is strongly recommended to use the html5 code because the FBML has been deprecated. Starting June 1, 2012 FBML apps will no longer work as all FBML endpoints will be removed.
So, I can't use the xid parameter such as on <fb:comments...>
right?
I am using Facebook Comments plugin in my website:
http://developers.facebook.com/docs/reference/plugins/comments/
by add this to my web :
<div class="fb-comments" data-href="http://example.com" data-num-posts="2" data-width="470"></div>
And i want to use it also in my android app, Can i use Facebook API or something else that i can make a comment on a URL without using the Comment plug-in.
Its impossible but comment plugin will show mobile version automatically for mobile devices
The mobile version will automatically show up when a mobile device
user agent is detected. You can turn this behavior off by setting the
mobile parameter to false. Please note: the mobile version ignores the
width parameter, and instead has a fluid width of 100% in order to
resize well in portrait/landscape switching situations. You may need
to adjust your CSS for your mobile site to take advantage of this
behavior. If preferred, you can still control the width via a
container element.
You can use the Graph API with stream_publish permission from the user in order to publish comments on their behalf. You can read the following docs to see how that works:
https://developers.facebook.com/docs/reference/api/post/#comments
In my application I am displaying custom invite dialog. This is achived by using FB.XFBML.parse method which parses FBML fb:serverFbml with other content that is responsible for displaying multi-user list.
On the side of app all looks good, invites are delivered.
But users that switched already to timeline have problem with accepting requests done this way. They cannot click on it and enter the app or even remove it. Users that are not using timeline yet can use this method to access app.
Below screen with not working example and part of edited code I am using:
Link to image
This is code copied from browser:
<form method="POST" target="" action="http://application_link/index.php/player/invitedfriend" content="Some content <fb:req-choice label='Example label' url='http://apps.facebook.com/app_name/' /> " type="closer" invite="true" id="req_form_4f840...">
I know that FBML is deprecated and won't be supported starting June 1 but based documents facebook provides I should be able to use fb:serverFbml without any problems thanks to FB.XFBML.parse. Any idea what might be wrong / solution to this? I would rather not want to use standard facebook dialogs.
Thanks
You should enable Requests 2.0 for your application (if not already enabled) and use the new approach to send invites. The Requests Dialogs page can help you out. The code to use the new method is quite simple too:
FB.ui({method: 'apprequests',
message: 'My Great Request'
}, requestCallback);
The new approach has more advantages than the old FBML version. XFBML is the website version of FBML. Both will be removed in June so you should switch to the above method ASAP.