Browse: Home / Development Blog / Page 2

Development Blog

WPBook & WPBook Lite Updates for Deprecated Offline Access

By John Eckman on May 19, 2012

Enable "deprecate offline_access" to get extended access token and be prepared for when Facebook permanently removes offline_access

Facebook’s developer roadmap is always changing. The latest change that impacts WPBook and WPBook Lite is the removal of the “offline_access” permission, coming in July:

The offline_access permission is deprecated and will be removed July 5, 2012. Until then, you can turn this change on or off using the “Remove offline_access permission” migration. On May 2, 2012, we will automatically turn the migration to “enabled” for all apps. If this breaks your app, you can turn the migration back to “disabled” until July 5, 2012 when it will be permanently “enabled” for all apps.

If that wasn’t confusing enough, check out the “Removal of offline access permission” page, which explains that:

While we are removing the use of the offline_access permission, through a migration setting in the Developer App, we are now allowing the option to use access_tokens with a long-lived expiration time that can be renewed each time the user revists your app (see exceptions below). For existing apps that are not using the offline_access permission, there are no changes required for your app, but you should consider using the new endpoint that allows the longer expiration time.

To translate a bit and summarize:

  • On May 2nd, 2012, Facebook changed the setting for all existing apps so that the “remove offline_access” permission was enabled – but allowed users to change it back to disabled if this broke their applications
  • As of July 5th 2012, the offline_access permission will disappear forever for everyone
  • At some other point (I don’t know when) Facebook changed the migration’s name from “remove offline_access” to “deprecate offline_access” and linked the setting to these “long-lived” tokens

Ultimately, as I read the docs, this means you have to make a choice: you can either keep “deprecate offline_access” disabled, and use offline_access tokens, OR you can set “deprecate offline_access” enabled, and use “long-lived” tokens.

Long Lived tokens live for two months (60 days) and then the user has to re-authorize the application to get a new long-lived token.

I’ve updated WPBook (2.5.2) and WPBook Lite (1.4) to work with long-lived tokens. The apps will no longer ask for offline_access, and will check for token validity, flagging in the admin when a token is invalid.

If you already have a Facebook application set up and working with either WPBook or WPBook lite, you don’t need to do anything. Your tokens, which were granted under the old “offline access” regime, will keep working, for now. Per Facebook:

After the offline_access removal date, currently set for 7/5/2012 (see roadmap for exact date), all existing offline_access access_tokens will have their expiration time truncated to 60 days. This truncation will be transparent to the user and your app will continue functioning normally; Facebook will send an updated message through the weekly developer round-up when this truncation will occur.

If you don’t yet have a Facebook application, and are setting up a new one, you should start with “deprecate offline_access” enabled, and WPBook / WPBook Lite will be fine, but you will need to re-authenticate every 60 days.

Ultimately everyone will end up having to re-authenticate every 60 days.

These implementations are just the first pass to ensure that WPBook and WPBook Lite keep working. Next step will be to actually store the expiration returned with the token and be able to inform the user before the token becomes invalid, not just let them know after the fact.

Posted in , , , , , , | Tagged

Testing Facebook PHP SDK 3.1.1

By John Eckman on January 4, 2012

OK, no more testing, no more publishing and unpublishing this page.

WPBook 2.3 is released. This uses the same Facebook SDK (3.1.1) as WPBook Lite which I just released last weekend – this will make it easier to manage both.

It will also let me start work on adding more features to the plugin- a more stable base to work from.

—-
Third test. Should publish just to WPBook page.
—-
Oops. That’s why we test. Typo in publish_to_facebook.php fixed.
—-
Sorry for the testing post. Just working on an update to WPBook 2.3, including an update to the Facebook SDK, and need to make sure in the process I haven’t busted anything.

This should post to personal profile and to page wall.
—-

Posted in , , , , , , , , , , | Tagged

Facebook Graph API – Post Versus Link

By John Eckman on January 3, 2012

Difficult Choices. (Photo by Beppie K, cc-by-nc-sa license)

Over in the WordPress Support forums for WPBook, WPBook user TheCitizen was asking about the absence of “share” links on Wall Excerpts posted via WPBook. I responded that in my experience posts made via the API (by an App, rather than by the user directly) don’t get “share” links inside Facebook.

He pointed to Facebook Page Publish, a WordPress plugin which also cross-posts to Facebook (though it does not import comments). Posts made via this plugin do get a share link.

Digging in a bit, I realized that Facebook Page Publish uses the Link object in the Facebook Graph API, whereas WPBook and WPBook Lite both use a Post object.

What’s the difference? That’s what I’m trying to determine now.

Links are posted with these fields (ref):

  • link
  • message

The rest of the values “are taken from the metadata of the page URL given in the ‘link’ prarameter.

Posts are created with these fields (ref):

  • message
  • link
  • picture
  • name
  • caption
  • description
  • actions
  • privacy
  • object_attachment

So Posts are more complex than Links, whereas Links rely on getting the Facebook metadata from the page returned by the link.

How does each appear, on the timeline and in the news feed?

Here’s the same link, posted twice, using the Facebook Graph API explorer – the first time (the lower box) is as a Link, the second time is as a Post:

That is how they look on the timeline – logging in as another FB user and looking at News Feed, I could not even see the Post type, only the Link type:

Though I’m certain that in the past I have seen items in the newsfeed which were posted as Posts. (Maybe it was that I’d just posted the same link as a link, so Facebook was hiding the second item as spam? I’ll retry with something different).

(Update: here’s what a Post type object looks like in the Newsfeed – the item for this blog post):

A few things to note:

  • The nicer excerpt – “We are an interactive agency . . . ” was pulled from the page being linked to by Facebook themselves, not entered by me. In the case of WPBook or WPBook Lite posts, we want to provide the full excerpt, not have it pulled from the link destination.
  • The image – again, this was pulled from the link destination. In the case of WPBook or WPBook lite posts, the image would be provided by the app (the featured image from the post) not grabbed from the destination link – but it looks the same in both.
  • In the case of the link type, the “via the Graph API Explorer” is next to the poster’s name, but in the Post type it is down at the bottom above the action links
  • The Link type gets a “share” action link, while the Post type only gets “Like” and Comment.”

Given all this, plus the fact that I found it hard to find the Post type in the newsfeed of an account I know follows me, I wonder if we shouldn’t switch to posting blog posts as the “Link” type.

The challenge is that the “link” type depends on the target blog having the right open graph metadata in place already (unless wpbook / wpbook lite try to actually provide that metadata).

When Facebook visits the link, it looks for Open Graph Metadata – which your blog’s theme may or may not provide.

Using the “Post” object allows WPBook / WPBook Lite to control the message being sent to Facebook more explicitly, rather than relying on metadata.

The part that worries me though is how frequently “Post” type objects get into News Feeds. Since Facebook controls the algorithm which decides what, out of the hundreds or thousands of possible posts in any given user’s feed, to show that user, I have no way of knowing whether object type (Post vs Link) has any impact.

Anyone have data on that to share?

Posted in , , , , , , , , , , , | Tagged

« PreviousNext »