Here are all the posts from the Developer Blog in the last week.
 | Friday, September 30 at 8:00pm |
f8 Videos Available
We had an awesome f8 conference in San Francisco last week. Thanks for everyone who attended or participated via one of the many viewing parties. Videos of all of the f8 sessions are now available online at https://f8.facebook.com/.
Scraping OG Objects
We’re already hard at work improving the Open Graph since last week’s announcement. This week, to make updating Open Graph objects easier, we’ve released the ability to scrape objects at the same time as you publish actions. Just add scrape=true to the POST parameters when publishing the action:
https://graph.facebook.com/me/recipebox:cook? scrape=true& method=POST& recipe=http://www.example.com/pumpkinpie.html& access_token=YOUR_ACCESS_TOKEN
Note that you only need to scrape an object if the meta tags have changed. If we ever encounter an URL that we've never scraped, we will scrape it regardless of the absence (or presence) of the scrape parameter. We also automatically scrape objects approximately every seven days, though we will respect Expires: headers. See the Open Graph documentation on Creating and Using Actions for the full details.
Reminder: Breaking Changes coming on Oct 1st
The following breaking changes are slated to go into effect on the 1st of October:
-
OAuth 2.0 Migration
All apps must migrate to OAuth 2.0 for authentication. The old SDKs, including the old JavaScript SDK (FeatureLoader.js) and old iOS SDK (facebook-iphone-sdk) will no longer work.
-
Apps on Facebook authentication and security migration
All Canvas and Page tab apps must convert to process signed_request (fb_sig will be removed) and obtain an SSL certificate for use in Secure Canvas URL and Secure Page Tab URL (unless you are in Sandbox mode).
-
Auth 1.0 deprecation
Auth.promotesession, auth.createtoken, auth.expiresession, auth.getsession will be removed on Oct 1st. Details on support for OAuth 2.0.
-
manage_pages permission required to access user accounts (/me/accounts)
We are modifying access to the FQL page_admin table and the graph.facebook.com/me/accounts endpoint. Previously, with basic permissions granted, an app could go to this endpoint or the FQL table to access the list of a users’ apps and Pages. We are going to require that apps have the manage_pages permission in order to obtain access to this information.
We will post an update on the rollout plan on Monday, Oct 3rd (the changes themselves will proceed as planned).
Canvas Ticker Flyouts
Last week, we launched flyouts for the Canvas ticker. These flyouts appear when a user hovers over or clicks on a ticker story. They provide richer information to users about what's going on with their friends, and often allow users to like and comment on the story.
For games, we have also launched “passing stories” in the Canvas ticker. These are stories in which gamers are informed when one friend gets a new high score which exceeds another friend's high score. This is most appropriate for arcade-style games where you get a score each time you play. To have these stories appear for your app, make sure to use the scores method in the Graph API each time your user gets a new high score.
One important side effect of this change, for apps using Adobe Flash, is that it is more important than ever that your app use "opaque" mode for any flash objects occurring within the iframe. If you don't, your game will be hidden when a popup occurs. Please see Special Considerations For Flash Developers for more information.
Support for Multiple Domains in the Developer App
We have heard from developers that only being able to set one App Domain in the Developer App is sometimes not enough. For example, if you are redirecting users for geographic distribution of load, you may want to redirect some users to a URL in the myapp.com domain, while redirecting others to a URL in the myapp.co.jp domain. Now, you can do this in the Developer App. Simply set multiple domains in the App Domain field:
Now, you can specify a redirect_uri in either domain. Your App’s URL (Website and/or Mobile Web URL) must be derived from one of the domains listed in the App Domain field.
Resources from “Making Fast Social Apps” talk at f8
After last week’s f8 conference, several people asked for references to the resources mentioned during this talk. Here are the links mentioned in the presentation:
Bugs
A couple of weeks ago, we introduced a new bugs tool. In the past week in the new bugs tools there were:
- 381 bugs reported
- 22 bugs accepted
- 7 bugs fixed
Although no new bugs can be filed in Bugzilla, we will continue working on closing out the remaining open bugs in Bugzilla. The total number of open bugs in Bugzilla is now 1,381 (up 56 from last week, due to re-opened bugs).
Facebook Stack Overflow activity
Activity on facebook.stackoverflow.com this week:
- 574 questions asked
- 178 answered, 31% answered rate
- 316 replied, 55% reply rate
 | Thursday, September 29 at 7:30pm |
Requests are an important Social Channel for users to communicate with their friends from within apps. Coupled with the Open Graph updates announced at f8 last week, Requests continue to be a core part of how people share app activity with friends.
As part of the FBML deprecation, we will stop supporting our old request model and will no longer fix bugs on January 1, 2012. We highly encourage all developers to move to Requests 2.0 by this date. Today we're announcing several new features to Requests 2.0 to make the process of sending and receiving requests even more efficient for users and developers.
New features for Requests 2.0
We have heard repeated feedback from developers and users that requiring users to click ‘Send Request’ every time they wish to send requests to the same friends interferes with game play and limits sharing. To reduce this friction, we’re introducing frictionless Requests, which improves the experience for both users and developers.
Frictionless Requests enable users to send requests to specific friends from within an app without having to click on a pop-up confirmation dialog. Upon first sending a request to a friend from within an app, a user may authorize the app to send subsequent requests to the same friend without prompting for his permission. By default, the check box is checked. This removes a dialog from the flow and streamlines the process of sharing with friends.
To enable frictionless Requests you must initialize the JavaScript SDK with ‘frictionlessRequests:true’. You’ll send requests to users via the Requests Dialog just as before. As users share with friends, they may authorize the app to send future requests to specific friends on their behalf.
You can specify an array of user_ids in the ‘to’ field of the request dialog. Only if all of the user_ids are frictionless, the confirmation dialog will not display and the users will be notified of the request. If even one of the recipients is not frictionless, the confirmation dialog will be displayed and the user must press ‘Send Request’ for the requests to be sent.
Here’s a full JavaScript example for how to use frictionless requests.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="https://www.facebook.com/2008/fbml"> <head> <title>Frictionless Request Example</title> </head> <body> <div id="fb-root"></div> <script src="http://connect.facebook.net/en_US/all.js"></script> <p> <input type="button" onclick="sendRequestToOneRecipient(); return false;" value="Send Request to One User" /> <input type="text" value="User ID" name="user_id" size=”50” /> </p> <p> <input type="button" onclick="sendRequestToManyRecipients(); return false;" value="Send Request to Many Users" /> <input type="text" value="Comma Delimited List of Multiple User IDs" name="user_ids" size=”50” /> </p> <script> FB.init({ appId : 'YOUR_APP_ID', status : true, cookie : true, frictionlessRequests : true, oauth: true }); function sendRequestToOneRecipient() { var user_id = document.getElementsByName("user_id")[0].value; FB.ui({method: 'apprequests', message: 'My Great Request', to: user_id, }, requestCallback); } function sendRequestToManyRecipients() { var user_ids = document.getElementsByName("user_ids")[0].value; FB.ui({method: 'apprequests', message: 'My Great Request', to: user_ids, }, requestCallback); } function requestCallback(response) { // Handle callback here console.log(response); } </script> </body> </html> Performance improvements
We have spent the past few months on rewriting the back-end for requests to make them faster to ensure users have the best experience with Requests 2.0. However in doing so, we ran into issues which require a breaking change to Requests 2.0 to make them more efficient.
To opt-into higher performance Requests 2.0 enable the migration “Requests 2.0 Efficient” in the developer app. This setting is available in the Advanced section of your app settings.
Setting the ‘Request 2.0 Efficient” in the app migration changes the format for request IDs in the JavaScript requests callback method.
Previously the response param that looked like:
{ request_ids: ‘request_id1, request_id2, …’ } With the “Requests 2.0 Efficient” migration, the JavaScript request callback method now receives a response param like below to represent the changes to the request ids explained above:
{ request: ‘request_id’ to:[array of user_ids] } 
A request now has a single ID representing the actual request object and is then concatenated with the user_id to create the full request ID which represents the request for the specific recipient.
This prevents a developer from having to make a second GET request back to the Graph API to identify the recipients once a request has been sent. To construct the request ID for a user you concatenate as follows: ‘<request_object_id>_<user_id>’. Thus the request IDs from the example above would be:
150785095008591_499802820 180646335344553_499802852
To delete a request, the developer must issue an HTTP DELETE request to:
DELETE https://graph.facebook.com/[<request_id>_<user_id>]?access_token=[USER or APP ACCESS TOKEN] Note: You can concatenate the request_id and user_id without doing the migration so that you can verify everything works before actually migrating.
Here is a full PHP sample which shows you how to concatenate the request_id and user_id in order to delete the outstanding requests for a user.
<?php require_once('php-sdk/facebook.php'); $config = array( 'appId' => 'YOUR_APP_ID', 'secret' => 'YOUR_APP_SECRET', ); $facebook = new Facebook($config); ?> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="https://www.facebook.com/2008/fbml"> <head> <title>Deleting Requests Example</title> </head> <body> <?php $user_id = $facebook->getUser(); if ($user_id) { //Get the Request Ids $request_ids = explode(',', $_REQUEST['request_ids']); //Construct full Request_Id function build_full_request_id($request_id, $user_id) { return $request_id . '_' . $user_id; } //For each Request construct full Request_id and Delete foreach ($request_ids as $request_id) { echo ("reqeust_id=".$request_id."<br>"); $full_request_id = build_full_request_id($request_id,$user_id); echo ("full_reqeust_id=".$full_request_id."<br>"); try { $delete_success = $facebook->api("/$full_request_id",'DELETE'); if ($delete_success) { echo "Successfully deleted " . $full_request_id; } else { echo "Delete failed".$full_request_id; } } catch (FacebookApiException $e) { echo "error"; } } } //User TOS if user has not authenticated your App else if (!isset($_REQUEST['error'])){ $params = array( 'redirect_uri' => 'http://localhost/~namitag/requests.php' ); $loginUrl = $facebook->getLoginUrl($params); echo '<script>window.top.location.href="'.$loginUrl.'";</script>'; } else { echo ("user denied permission"); } ?> </body> </html> Migrations and breaking changes
Starting today new apps will automatically be opted into “Upgrade to Requests 2.0” and “Requests 2.0 Efficient" and these migrations will no longer be available in the app settings for new apps. This requires developers to use the new request_id format as detailed above. In addition when a user is directed to your app, by clicking a Request from the app, the games dashboard, or from a Request notification, you must delete the request after it has been accepted. These are not automatically deleted once they have been clicked, thus it is the developer’s responsibility to clear them once they have been consumed. See sample above for how you can delete these requests.
In 90 days - on January 1, 2012- existing apps will be opted into “Requests 2.0 Efficient” and "Upgrade to Requests 2.0" migrations and all developers must ensure that they are using the correct request_id format and deleting requests appropriately.
We look forward to improved requests experience with frictionless Requests and our performance improvements. For more information reference our documentation here. Please provide feedback and thoughts in the comments below.
 | Thursday, September 29 at 7:00pm |
When Platform launched in 2007, FBML was a key component for developers building on Facebook, with millions of apps successfully built using this technology. Over time, as Platform matured and embraced open standards, such as OAuth 2.0, HTML, and Javascript, the need for FBML has decreased. Last August, we announced our intent to move away from FBML. In March, we removed the ability to create new FBML apps. Today, we are announcing the FBML deprecation schedule:
- January 1, 2012: FBML will no longer be supported. We will not fix FBML bugs after this date with the exception of security and privacy issues
- June 1, 2012: FBML apps will no longer work on Facebook. All FBML endpoints will be removed.
We realize that some of you may still be relying on FBML for your apps. We want to make sure that you have all the resources you need for an easy and speedy migration. Over the past few months, we’ve been working with developers to understand the remaining use cases for FBML. Based on these conversations, we identified two primary use cases remaining: Requests and Static FBML tabs on Pages.
Requests
We have already announced the new and improved Request 2.0 which should make migrating from FBML Request much simpler. To upgrade to Requests 2.0, apps should send requests by using the Request Dialog. To learn more about Requests 2.0 and how to migrate from FBML Requests, see our documentation on Requests.
Static FBML
Custom tabs on Pages are an important aspect of Facebook Platform. Many developers and Page admins rely on Static FBML for hosting this content. With the deprecation of FBML, this content must be moved to an iFrame based solution. There are several free iFrame solutions available that allow easy migrate Static FBML content to HTML. The Preferred Developer Consultant Finder on Facebook is a great tool to find PDCs to help guide you through the upgrade process. In addition, we have worked with WildFire, one of these PDCs, to create a step by step tutorial to guide your migration. The tutorial is available here.
We are excited to move into a modern, standards based Platform. Please provide feedback and thoughts in the comments below.
| Please Note: Our deprecation of FBML does not impact XFBML (eXtended Facebook Markup Language). XFBML is a set of XML elements that can be included in your HTML pages to display Social Plugins. When your page is loaded, any XFBML elements found in the document are processed by the JavaScript SDK, resulting in the appropriate plugin being rendered on your page. The JavaScript SDK will continue to support XFBML after the deprecation of FBML (save for the fb:serverFbml element which is used to execute FBML on our servers). |
