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

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.

(photo by hobvias sudoneighm, click for photo page)

Thanks to troubleshooting help from mommyknows and other users, I’ve been able to track down and fix an issue with posting to different kinds of pages.

Thanks to Brooke Dukes, we also now have a site for the plugin itself: wpbook.net – with instructions, blog posts about the plugin, and the like.

Grab 2.0.8.1 from the plugin repository and check it out!

(2.0.8 somehow incorporated a nasty syntax error – whitespace ahead of the opening PHP tag – so skip that and go straight to 2.0.8.1).

For a long time now WPBook has enabled users to cross-post excerpts from their blog posts to either the wall of their personal profile or the wall of a Facebook fan page.

However, in setting up WPBook many users were ending up with:

• Your WordPress blog outside Facebook. (Example: www.openparenthesis.org
• The Facebook application view of your blog. (Example: apps.facebook.com/openparenthesis)
• The Application Profile page for your new Facebook application.(Example: https://www.facebook.com/apps/application.php?id=12797741823)
• A Facebook Fan Page for the Blog, or other Fan Page on which the blog gets published. (Example: https://www.facebook.com/pages/WPBook/44062579871, which in this case isn’t a fan page specific to the blog but to the WPBook plugin itself).
• Facebook Tabs, which can be added to users’ personal profiles (including your own), or Facebook pages (either a Fan page or an Application Profile page). (Example: https://www.facebook.com/pages/WPBook/44062579871?v=app_12797741823).

Starting with 2.0.8.1, WPBook can instead post directly to the wall of the Application Profile page – which is a nice way of showing potential application users what kind of blog posts come through the application.

Of course, you can post to your own profile’s wall in addition to a second target, which can be any of these:

• A Fan Page wall
• Your Application’s Profile page
• The Wall of a Facebook group

If you post to a Fan Page wall or an Application Profile wall, the post will come from the Application; if you post to the wall of a Facebook group, the post will come from your personal profile.

Settings for Profile ID and Page ID

You should provide your personal Facebook Profile ID in the WPBook settings, and then in the field provided for “PageID,” you can provide:

• An actual Page ID, for a Fan Page. (To find this, click on “edit page” – the url will look something like this: https://www.facebook.com/pages/edit/?id=44062579871 – the Page ID is the part after id=)
• An application ID, for an Application Profile page. (To find your application ID, go to the Application profile page, the url of which will look something like this: https://www.facebook.com/developers/apps.php?app_id=12797741823 – the Application ID is the part following app_id=)
• A group ID, for the wall of a Facebook group. (To find your group ID, just visit your group page, the url of which will look something like this: https://www.facebook.com/group.php?gid=149948248362737 – the Group ID is the part following gid=)

As always, please post in the support forums with your experiences.

WPBook 2.0.2, released last night, is already superseded by 2.0.3, which I just tagged for release.

Bugs fixed:

• Extra whitespace in wpbook.php after the closing ?> tag
• Cleaned up includes to break on functions rather than midstream

I think that will solve the most immediate issue folks are having.

As always, let me know what you’re seeing here or in the support forums.

Test Boxes, photo by David Bleasdale, cc-by license

I’ve just tagged version 2.0.0 of WPBook for release, but haven’t yet changed the “stable” tag in the readme.

What that means is that if you’re using WPBook, you won’t seen any automated notification of a newer version being available. You’ll have to go to the WPBook download page and find 2.0.0 at the top of the “other versions” list.

Please do so, especially if you are willing to help test the new features.

What is there to test? Most importantly, a new feature which imports comments made by users on your Facebook wall (or the wall of a Facebook page) in response to excerpts posted by WPBook on those pages.

In other words, if you have “publish to Facebook Stream” enabled and working for your personal wall and/or the wall of a Fan Page, when you publish a new blog post, and that post gets published to the FB wall, and users make comments on that wall post, those same comments will get imported to your WordPress hosted blog.

A few notes:

• You’ve got to have stream publishing working in order for importing to work. For the last few versions, I’ve had the app request “stream_read” permissions as well as “stream_publish” – so it should have the right permissions. If it doesn’t, visit the “click here to grant permissions” page from the WPBook settings and try regranting them – it can’t hurt and it might help.
• Comment importing relies on wp_cron, WordPress’s built in pseudo-cron system, which basically lets timed events happen in the background. (It’s the same thing that makes scheduled posts work). In order to get WPBook’s necessary hooks added to wp_cron, you will need to deactivate and then reactivate the plugin.
• In case you weren’t listening above, you will need to deactivate and then reactivate the plugin for commenting importing to work. Comment importing is a task which fires off hourly, so don’t expect any comments for the first hour or two.
• Comment importing will only work for new posts, or more accurately, posts published to your Facebook wall AFTER installing 2.x. Posts you had previously posted to your Facebook wall will not have their comments imported.
• Comment importing also only works for posts published within the last 7 days (user configurable). Basically this is a potentially taxing operation, and it’s my experience that most comments on a Facebook wall are made within the first 24 or 48 hours of a post being made, so there isn’t much point in going back longer than 7 days.
• You can configure (in the expected places in WPBook settings) whether comments imported from Facebook should be automatically approved, and what email address should be affiliated with them. (This is different than comments made inside the Facebook Application version of your blog, where users can input their email adress. The comment form for wall posts doesn’t allow for email, and doesn’t grant the application permission to pull the users email). This is so that you can set a gravatar to be used for imported posts (just set the email address to one you control, then set a gravatar for that email address).
• There is a debug mode, enabled by changing define ('DEBUG', false); to define ('DEBUG', true); at line 37 of wpbook_cron.php. (If you’re not comfortable changing this, perhaps you shouldn’t beta test plugins.) This will create a wpbook_debug.txt file inside the plugin’s directory which captures information about every time cron runs.

Additionally, this version also includes the often requested “Promote External links” option – if checked, this will cause WPBook to use your external (WordPress) permalinks for new posts, both in the “Recent Posts” box in your profile and also in the Wall notifications, so users are sent to your WordPress blog, not to the Facebook Application view of your blog. In essence this lets you use WPBook without ever expecting users to go to your Facebook Application, which is now just used as a mechanism for connecting WordPress to Facebook for the publishing of new posts and the importing of comments.

If you are testing it, please let me know by commenting here or posting in the support forums for WPBook and thanks in advance!

I’m getting tired of Dopplr’s consistent FAIL on a common (for me) use case- a one day trip to NY on Delta.

Whenever I forward such a confirmation here’s what Dopplr does:

Thanks for sending us a message by email.

We automatically created a trip to Atlanta, GA, United States (from Newburyport, MA, United States) between February 10th and February 13th

We won’t share coincidences from this newly-created trip with your fellow travellers until February 18th. This is to give you a chance to check and correct any problems in interpretation.

If you’d like to check, go to [link removed]

Yours sincerely,
The Dopplr Team.

The problem is, I’m not going to or from Atlanta – that’s where Delta airlines headquarters is, sure, but it’s a long detour on the Boston->New York route.

I’m also not travelling Feb 10 to Feb 13, I’m leaving and returning on the 13th, and the trip was booked on the 10th.

I can (and do) go in and manually fix the trip in Dopplr, but in this type of case TripIt’s import feature just works.

Tripit’s mechanism for adding trips is superior. The ability to simply forward (or even set an automatic rule to forward) confirmation emails is a major step forward . . . Where TripIt seems better at pulling data in, Dopplr seems to be better so far at pushing their data out, or letting people pull it into other contexts.

Well, now Dopplr’s gone and added some new import mechanisms of their own. This post from the Dopplr blog (ok, it was posted back on July 8th, but it has been sitting in my queue to write about) lays out three new options: Twitter, SMS, and Email:

Today I’m really happy to say we’re taking the wraps off a number of new ways to get your future into Dopplr and share your travel information with those you trust: Dopplr by Twitter, SMS and… Email!

Although I love twitter as a notification service (a way of letting me know something relevant happened) I don’t see myself using it as a data input service. For those of you who would like to, just follow the dopplr user and send direct messages with your trips, like: d dopplr a trip to London July 28th to August 3rd. (Nicely, it also happily accepts @dopplr posts, in case you want to announce your trips as well as put them in dopplr). SMS is another option – you associate your SMS number with your Dopplr account and you can text message the same types of messages to Dopplr’s number.

Finally, they’ve got email working at trips@dopplr.com (wonder how many people will confuse plans@tripit.com with trips@dopplr.com – did they make plans@dopplr.com an alias?).

Interestingly, you can use the same kind of shorthand messages used for Twitter or SMS – “a trip to London July 28th to August 3rd” – or you can forward confirmation messages from booking services (which is how TripIt handles import). This is because Dopplr did not set out to parse all the complex formats used by different agencies, but took a simper approach, as explained by MattB:

There are an awful lot of ways to format a travel itinerary. When people asked us to extract trips from emails, we looked at our long history of e-tickets, confirmations and reservations, and scratched our heads.

Inspiration came in the shape of Apple’s last OS X release, Leopard, and an intriguing feature called “Data detectors“.

We realised that instead of creating a piece of code to decode every email format out there, we could look for patterns of dates and place names in the text (and later, other information too) and turn those into trips.

A happy side-effect of this approach is that as well as extracting information from automatic reservation emails, it works well with short text strings like “I’ll be in San Francisco from 3rd July to 7th July”. This means we can work with many hand-written emails, with Twitters, and with SMSes too.

Of course it won’t work with every variation under the sun (for example, it’s most reliable when an email contains just a return trip in a single hop), but we’ve had very satisfying results in our testing. And of course every email you send us will be added to our test suite so that our engine can get better and better over time.

In other words, rather than specifically targeting all the different potential formats, and parsing them in some structured way, Dopplr looks for some specific patterns in the text and tries to understand their meaning without knowing the format of the email in advance.

I wonder how different this is from what TripIt actually does behind the scenes – how much they plan for specific formats they know in advance – and how successful it will be “in the field.” For now it is enough to convince me to turn off my automated importing and give trips@dopplr.com a try on my next few confirm messages. Then, I can automate a rule in my email such that travel confirmations get auto-forwarded to both plans@tripit.com and trips@dopplr.com, and be sharing my travel plans painlessly.