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.
—-

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?

A few months ago I discussed the Future of WPBook in this space, specifically what to do about Facebook’s new requirement that all applications providing canvas pages or page tabs had to be accessible via SSL. As I outlined it then, I saw the options as:

1. Eliminate the canvas page and tab altogether – make WPBook just focus on cross-posting and comment import, thus potentially eliminating the SSL requirement?
2. Make it optional – keep the canvas page and tab, but make them optional – only for users who want them and have the necessary SSL certificate
3. Fork the plugin – make a version of the plugin which works like the current model, but also a second (WPBook Lite?) that only does cross posting and comment import? That way we could have separate directions for each to simplify setup confusion
4. Stop developing WPBook – There are a number of other plugins which do Facebook posting, and at least one which does Facebook comment importing (probably more). Is it worth continuing to develop WPBook if better alternatives exist?

Ultimately, I settled on Option 3: Fork the plugin, and create a lighter-weight version which did not include the canvas page or tab. The result is WPBook Lite, available now in the WordPress Plugin Repository.

Should I use WPBook, or WPBook Lite?

I suspect this will be the main question folks will face, so here’s a quick comparison table:

Basically, if you are able to access your blog via HTTPS, and you WANT the view of the blog inside Facebook as a canvas application, or you want the page tab feature, you should use WPBook.

If your blog is not accessible via HTTPS, or you don’t want the view of the blog inside Facebook / page tab, then you should be happier with WPBook lite.

I’ll be updating the instructions over at WPBook.net shortly to reflect Facebook’s new look for developer settings shortly, and will also differentiate between WPBook and WPBook Lite. In theory, configuring WPBook Lite should be significantly simpler for most users.

If you’re already using WPBook and shift to WPBook Lite, you will need to regrant permissions.

Migrating from WPBook to WPBook Lite:

1. View your WPBook settings page, and write down your profile ID as well as the IDs of any pages/groups to which you want to cross publish.
2. Deactivate WPBook (but don’t delete it yet)
3. Install and Activate WPBook Lite
4. Set up a new Application for WPBook Lite – this time you should only need the “Website” settings under Integration, not any of the “App on Facebook” section settings
5. Visit the WPBook Lite settings page in WordPress, fill out the required fields (APP ID, Secret, your profile ID), and save the form
6. Re-visit the WPBook Lite settings page, where you should now see an opportunity to grant appropriate permissions

If done correctly, WPBook Lite should pick up right where WPBook left off.

If you run into problems, please comment in the appropriate WordPress Support Forums: WPBook or WPBook Lite.

I’ve been doing a lot of thinking about the future of WPBook, and wanted to give a quick update. There are two key factors making me rethink the whole approach.

Pittsfield in the Near Future (from Cameo Wood on flickr, cc-by-nc license)

The first is a change Facebook has made, requiring SSL certificates for “all Canvas and Page tab applications.” (They announced this change earlier this summer, as part of the bizarrely Orwellian “Operation Developer Love” but it went into effect as of October 1st).

This is a problem because many WPBook users’ blogs are not available via https connections (including my own), and with this new Facebook change their WPBook implementation will fail, though how exactly that will be manifest isn’t clear to me yet (see below). Getting an SSL certificate for your blog isn’t an insurmountable task, but if you run your blog on cheap shared hosting, the costs of an SSL certificate (and the dedicated IP it requires) can be nearly as much as you’re paying for hosting! It’s also a task that the non-technical user will find horribly confusing.

The second is a recent report showing that:

Using a 3rd party API to update your Facebook Page decreases your likelihood of engagement per fan (on average) by about 80%

The study results suggest that one of WPBook’s core functions – posting automatically to your wall (or the wall of a fan page, group, or application) whenever new blog posts are published – might not even be a good idea to begin with.

Facebook posts direct versus via 3rd party APIs (Edgeranker study)

If third-party automated postings get de-prioritized by Facebook, you might be better off using a Facebook share button and manually cross posting to Facebook each time you publish. On the other hand, maybe the reason third-party automated postings get less attention is because people post more crap weak content that way. (If what the 10 most popular third-party apps post is lots of nonsense about games, thinly veiled ads, and self-promotion, maybe that is what the study results show people are ignoring – not that good relevant content posted by automated applications gets ignored).

So, what’s the way forward?

The scenario I’m imaging is to split apart the functions of the current WPBook and make some portions optional.

WPBook currently does four main things:

1. Expose a view of your blog as a Facebook application (a canvas page or set of pages). Basically this is an iframe inside Facebook containing your blog content, drawn by WordPress in a theme supplied by WPBook, to make it look more like other Facebook pages.
2. Expose a view of your blog as a “tab” for use on Facebook pages. This is also iframe based, but a bit different in terms of what is allowed in that tab.
3. Cross-post to Facebook whenever a new blog post is published. (To your personal profile wall, or to the wall of a Fan Page, Group, or Application, or some combination thereof).
4. Import comments made against those wall posts, and make them WordPress comments

I believe that the Facebook requirement of SSL only affects numbers 1 and 2 of this list. Even in the current WPBook, if you set “use external permalinks” then users never need know your application canvas page exists – they will just click on the links in wall posts and be taken to your (external) blog. Users without SSL certificate capability (or interest) could still get the benefits of 3 and 4 without having to worry about 1 and 2.

(It’s not clear to me right now how this would impact setup of WPBook-based applications. Facebook’s developer blog clearly indicates that canvas and page-tab applications will require SSL, but that would seem to imply other kinds of applications will not. Is it just a question of choosing a different application type during setup in Facebook? The whole app creation flow has changed so many times it is hard to keep track – maybe it is a question of unchecking some of the boxes in the dialog below?)

New Facebook App Creation Options

So the question becomes, is it worth it to keep WPBook trying to do 1 & 2 above?

Originally this was all WPBook did, and it seemed to me quite useful and distinct from any other Facebook related plugin. In essence you could use WPBook this way to drive a whole in-Facebook experience and never require (or even let!) users go to the blog outside of Facebook (though preventing them from accessing the blog outside Facebook would require some extra work on your part).

Open Parenthesis, as seen outside Facebook (left) and inside Facebook (right) - click for full size

But most users, it seems to me, were confused by this “Facebook view of my blog” approach. They wanted cross posting, and comments import, but didn’t like the application view of the blog (which required all users viewing blog content to consent to application permissions) or worried about it taking traffic away from their external blog.

Should I:

1. Eliminate the canvas page and tab altogether – make WPBook just focus on cross-posting and comment import, thus potentially eliminating the SSL requirement?
2. Make it optional – keep the canvas page and tab, but make them optional – only for users who want them and have the necessary SSL certificate
3. Fork the plugin – make a version of the plugin which works like the current model, but also a second (WPBook Lite?) that only does cross posting and comment import? That way we could have separate directions for each to simplify setup confusion
4. Stop developing WPBook – There are a number of other plugins which do Facebook posting, and at least one which does Facebook comment importing (probably more). Is it worth continuing to develop WPBook if better alternatives exist?

My concern with option 2 (“make it optional”) is just that configuring WPBook is already too complex for many users, given the variety of ways Facebook can be used and the variety of ways WPBook can be configured. Adding yet another set of variants (which would change not just what you have to set inside WordPress but also what choices you make when setting up the corresponding Facebook application) will only increase complexity and therefore support requests, which I honestly just don’t have the time to answer as quickly or extensively as I’d like.

My concern with option 3 (“fork the plugin”) is similar – more work for me, when I’ve had difficulty keeping up with plugin maintenance and maintenance of the instructions as Facebook constantly changes their application settings pages. If maintaining one plugin is difficult, maintaining two will be more so, even if they share some segment of the code base.

So option 1 (“eliminate”) is perhaps the simplest. (I say “perhaps” because I haven’t looked into it in depth yet – how hard will it be to untangle all the permission setting and checking logic, which is currently using a canvas page to display the current permissions? How will that change existing applications built using WPBook?).

But once that’s gone, what distinguishes WPBook from all the other Facebook posting plugins?

The fourth option would be to just declare WPBook obsolete. Existing WPBook installations work, if the user’s blog supports SSL. Currently if users browse Facebook in https mode, my own WPBook-powered applications just don’t work, because I don’t have SSL certificates for any of my blogs – just not worth the effort. But I’m ok with that.

It may be seems that new WPBook users will find they can’t set up a Facebook application (necessary to use WPBook) without an SSL certificate, and if they want to have cross-posting and comment import they’ll need to use an alternative approach, but a quick search of the plugin repository suggests other options are plentiful.

I’d love to hear from you all – especially if you are WPBook users (it’s had over 100,000 downloads, but I’ve no idea how many are in active use).

• Are you using the “Canvas Page” or “Tab Page” views inside Facebook? If so, do you have an SSL certificate for your blog? Would you miss these views if WPBook were revised to eliminate them?
• Have you evaluated other WordPress plugins for accomplishing the same thing? Did they work, or what issues did you run into?

As always, comments (and patches!) welcome.

Road to nowhere (Photo by Matthew Connor, cc-by-nc license)

Back in January, I got an unexpected flurry of WPBook support requests, and ultimately discovered they were the result of Facebook’s decision to allow people to browse Facebook in HTTPS mode.

As part of that change, Facebook introduced some new settings: “Secure Canvas URL” and “Secure Tab URL,” which would enable https connections throughout your Facebook application.

WPBook mostly worked with these two variables properly set (thanks to cshiflet for this patch).

Now, however, Facebook has announced they will require ALL apps to support https:

Today, we are announcing an update to our Developer Roadmap that outlines a plan requiring all sites and apps to migrate to OAuth 2.0, process the signed_request parameter, and obtain an SSL certificate by October 1.

What will this mean for WPBook users?

Unfortunately, my guess is that many WPBook users are not prepared to install an SSL certificate and accept https traffic on their blogs. (SSL certificates typically require that your blog have a unique IP address and cost extra at shared hosting facilities).

If you are unable to install an SSL certificate for your blog, and enable https based browsing of it, you may be unable to use WPBook after October 1, 2011 (or whenever Facebook decides to actually enforce this migration step).

More to come as we get closer to that date.