Sandbox Status

From Facebook Developers Wiki

Jump to: navigation, search

This article keeps a running list of changes to the sandbox for the new profile design, as well as any current known issues. Also check out the developer blog and Bugzilla for more information.

Contents

[edit] Downloading the API Client Library

You can download the client library for the new profile design from http://svn.facebook.com/svnroot/platform/clients/php/branches/redesign-changes/.

[edit] Where to Make API Calls

When you're testing applications in the sandbox, you should make all your calls to the sandbox's API tier, api.new.facebook.com.

We now pass the fb_sig_in_new_facebook parameter to all pages on the site. Use this to determine whether a given user is using the new profile (true) (=1) or the old one (false) (=0).


[edit] Changes to the Sandbox as of 5 August, 2008

  • Currently 100% of our user base (except for those using Internet Explorer 6) can opt in to try out the new profile.


[edit] Changes to the Sandbox as of 5 August, 2008

  • With the new automatic authentication model, we now pass an fb_sig_canvas_user parameter, which sends you the user's public search listing data (like name, profile picture, friend IDs) when the user interacts with your application for the first time, before the user agrees to your application's Terms of Use.
  • Currently 60% of our user base can opt in to try out the new profile.


[edit] Changes to the Sandbox as of 1 August, 2008

  • When a user first interacts with your application, you can call users.getInfo and get a subset of user data (name, profile picture, and so forth). users.getInfo also no longer requires a session key, and if you don't pass one, you can get the same subset of information.
  • users.getStandardInfo returns more user information (like gender and birthday), and you can use the information from this call to return data for your analytics, for example. You shouldn't use this call to return information that you want to display to other users.


[edit] Changes to the Sandbox as of 31 July, 2008

  • Currently 15% of our user base can opt in to try out the new profile.
  • We rolled out version 0.4 of the Facebook JavaScript Client Library on www.new.facebook.com. To improve performance, we made changes that caused the cross domain communication protocol in the new version to be incompatible with the previous version. We realize that this change makes it more difficult for developers who utilize the iframe resizing feature to transition their applications to new.facebook.com, and we apologize for the inconvenience.


[edit] Changes to the Sandbox as of 30 July, 2008

  • For notifications.send, the user_to_user type parameter replaces the general type parameter. The app_to_user type parameter replaces the announcement type parameter.
  • The authorization dialog is now labeled Allow Access. If the user agrees to allow your application to access his or her information, you can continue to do so until the user removes access.
  • The iframe Feed form demo should now be working with our sample application, MySmiley. In addition, there's an example of the FBJS Feed form.
  • All the multi-friend-input issues should be cleared up. Check out the test case.
  • The new version of the FBJS bridge is now working in the sandbox. This version works on profile pages, Publisher, and large Feed stories. Soon it will also allow for Flash links from of short stories (navigateToURL). Check out http://apps.new.facebook.com/truncated/flash/test_fbjs.php for a super cryptic demo.
  • Currently 5% of our user base can opt in to try out the new profile. We're considering increasing the limit to 15% of users. It will happen pretty gradually, but be aware.


[edit] Changes to the Sandbox as of 14 July, 2008

  • The api.new.facebook.com domain points to a larger tier so you should have less trouble setting information for your apps. All new API calls should call api.new.facebook.com during the user preview period.
  • You can determine whether a user has authorized your application.
  • You can return a list of standard user information, including user ID, first name, last name, full name, time zone, birthday, sex, and affiliations (regional type only).
  • You can provide some content to encourage your users to add a box or info section to their profiles using the fb:if-section-not-added tag.
  • When a user interacts with Publisher we're now sending the fb_sig_profile_user parameter so you know the user whose Publisher is being interacted with.
  • We're now sending the following parameters to canvas pages:
    • fb_sig_in_profile_tab -- This parameter indicates whether the current request is for a user's tab content. We're sending this parameter instead of is_tab now.
    • fb_sig_profile_user -- This parameter specifies the ID of the user whose profile is being published to. This is in addition to fb_sig_user, which specifies the ID of a user who is interacting with the Publisher.


[edit] Changes to the Sandbox as of 10 July, 2008

  • Notifications: With the new profile, there will be two types of notifications: general and announcement notifications. General notifications require active user sessions, which use the sending user's active session (with the same allocation amounts as today).

    Announcement notifications are sent on an application's behalf. An application can send 7 announcement notifications per user per week when the new profile goes live. This number will fluctuate as allocations change, based on user feedback, like today.

    To account for these changes, we've added a type parameter to Notifications.send, which can be set to general or to announcement (the default is general).


  • Old vs. New Profile: Determining Which Site a User Is Using. We will pass in the fb_sig_in_new_facebook parameter on all pages on the site. Use this to determine whether a given user is using the new profile (true) or the old one (false).


  • Feed Stories. During the user preview period, Feed stories submitted through the APIs will appear on both old and new profiles. The old Feed API calls (feed.publishStoryToUser, feed.publishActionOfUser, and feed.publishTemplatizedAction) will render the appropriate Feed story on the old profile, and render one line stories on the new profile. The new Feed API call (feed.publishUserAction) will work as expected on the new profile, and will render one line Feed stories on the old profile. All Feed stories will be aggregated and shared in News Feed as they are today.

    Note: When the new profile launches in full, only feed.publishUserAction will work to publish Feed stories. So we recommend you create and register your Feed story templates now and start testing and using that method.


  • Changing require_add to require_login: During the user preview period, require_add will continue to work on the old profile only. When calls are made to require_add on the new site, the user will get redirected to login.php instead. There will be a simplified authorization screen (a much friendlier version of login.php) that will be available on the sandbox soon.

    Going forward, you should start using require_login instead. If you use this method, it will open a simple Ajax authorization window instead of requiring a redirect to another page at all. We plan to deprecate require_add entirely in the future.


  • User Sessions: During the user preview period, we will still grant infinite sessions to your Web applications for users on the old profile. However, we'll grant temporary sessions to your Web applications for users on the new profile. Temporary sessions last 24 hours, or until the user logs out, whichever comes first. After we launch the profile to all users, we will grant temporary sessions to all Web applications.


  • API Calls: For many calls, session keys are now optional. If you continue to pass valid session keys, we'll ignore them. We recommend you remove session keys from the appropriate calls now.


[edit] Changes to the Sandbox as of 5 June, 2008

  • Parameter name changes for tabs. In the request for the FBML content of a tab, the parameters 'fb_sig_user' and 'fb_sig_session_key' are now named 'fb_sig_profile_user' and 'fb_sig_profile_session_key' to distinguish them from other request contexts, where fb_sig_user always represents the logged in user. On a tab, fb_sig_profile_user is the id of the user whose tab is being viewed, and fb_sig_profile_session_key is a special read-only session key on behalf of the tab owner, given so that you can request data for constructing the tab contents.


[edit] Changes to the Sandbox as of 23 May, 2008

The following items were not documented in the New Design Integration Guide originally, so we're announcing them here. The documentation will be updated, too.

  • To use the wide layout (760 pixels) for your canvas pages, you have to enable it in the Facebook Developer application. Edit your application's settings, then check the Use full canvas width option.
  • We changed the permissions for profile boxes, tabs, and Publisher so they work with require_login as opposed to require_add, since they all have separate confirmations.


[edit] Known Issues as of 25 May, 2008

  • You must be logged in before navigating to the sandbox -- it doesn't support logging in or out of Facebook (you can log in to Facebook on the regular site first, then go to the sandbox URL)
  • The sandbox is currently limited to the profile, Developer application, and application canvas pages only
  • The top level navigation in the Applications menu and home page/News Feed are not available -- so test your Feed stories on your Feed tab
  • The interaction between the Feed and Wall tabs is subject to change
  • Some Facebook applications, such as Video or Notes, are not integrated into the Publisher at this time
  • There are issues with some versions of Internet Explorer that should be resolved shortly
  • When posting a wall post in new profile on the profile of a less active user, wall post is originally and until page reload listed under the last date of activity rather than "Today"