Extending the Third-Party Identifier Deadline
In November, we outlined our technical solution to address the use of UIDs on Facebook Platform. Since that time, we have worked closely with the developer community to ensure broad adoption of this solution across the several million applications and web sites using Facebook. While many developers have moved to third-party identifiers, we are extending the deadline mandating this mechanism to January 31st, 2011. This will give everyone in the developer community the time they need to make a thoughtful move, minimizing impact to applications and mostly importantly, Facebook users.
Making Third-Party Identifiers Indexable
In order to help with the adoption of third-party identifiers, you can now retrieve a UID for a given user using their third_party_id in FQL (e.g. we have made third_party_id an indexable field in the user FQL table). This feature was requested by a number of developers that did not what to store a third_party_id/uid mapping or wanted to create such a mapping in bulk. You must use your applications access token to retrieve this information:
https://graph.facebook.com/oauth/access_token? client_id=[App ID]&client_secret=[App Secret]& grant_type=client_credentialsThis will return your application’s access token. With that in hand, you can query for a uid using a given third_party_id:
https://api.facebook.com/method/fql.query? query=select uid from user where third_party_id="[third_party_id]"& access_token=[App Access Token]
After we launched the new Insights dashboards for Pages, Applications and Domains, we received a lot of feedback and have been working on fixing key issues and reliability. This week, we introduced a date selector to let you specify a date range for all the metrics on the page. This was a popularly requested feature, and we hope you find it useful. Please let us know in the comments below if there are other features from the old Insights that are important to you.
Ad networks (including offer companies) that operate on Facebook Platform are required to sign terms that govern their use of data. In order to ensure that developers are clear what ad providers have signed these terms and may be used within Facebook applications, we have made an ad providers list available. This list is continually updated as more ad providers sign these terms.
Migration Setting for Time Zones and Deprecations
Facebook events do not support time zones. Events are intended to be created with start and end times that are specific to the location of the event. This has been a source of confusion within our developer community and exacerbated by numerous bugs. We have already made changes to our event creation code to fix these issues. We now have a migration to disable event start_time and end_time from being returned from the Graph API with a time zone (Timezone-less events). Many thanks to Drew Hoskins for his work fixing these issues.
We also now offer migration settings for developers looking to test the impact of the removal of the old API methods that we deprecated in August. These settings will be automatically enabled on January 3rd, but developers can manually re-enable the settings on the Advanced tab in the Developer app until they’re removed altogether on January 7th.
As we announced last week, we now make a change log available when we update beta.facebook.com prior to our weekly push. Moving forward, we will announce these changes on the Developer Updates section of Platform Live Status with the historical log available on the change log page. This addresses a common request for email notification and/or an RSS feed for this information.
Bugzilla activity for the past 7 days:
Developer Forum activity for the past 7 days: