Retweet Shirt Photo by Deb Hanson - http://www.flickr.com/photos/debspace/3766841512/

Just released an update to ReTweeter (1.1), which now uses the Twitter API for Retweeting. This means that instead of the traditional “RT: @username” syntax, the retweeted tweets will now show Twitter’s little retweet icon and the link to the original tweet (where it says “about 4 hrs ago”) preserved, and the retweeting user’s name at the bottom, like so:

Screencap by Jeronimo Palacios - http://www.flickr.com/photos/jeronimo_palacios/4093181811/

Instead of what Retweeter used to produce, which looked more like this (rt: @username):

Or this (username: tweet):

Thanks to Cody Wilson at QC Co-Lab (@qccoloab) for the patch for this. Of course, if you’d like to keep the old format, you can just set ‘USE_OLD_FORMAT’ to true in the configuration section, and retweeter will keep using the older format.

I’ve also started storing the md5 hash (required for OAuth) in the database instead of recalculating it each time retweeter gets called. (If you ever need to change your md5 hash, say because you’ve regenerated your OAuth token at Twitter, just delete the row in the ‘conf’ table and retweeter will create a new hash the next time it runs).

Note that you will have to alter database tables if you’ve previously used a version of ReTweeter from 1.0 or before – but I’ve included the necessary SQL statements in the README included with the download.

First, ReTweeter has been updated to 0.9.4. The fix here was primarily to deal with tweets which, when retweeted with the username prepended, were longer than 140 characters.

Second, WPBook has been updated to 1.5.3. This includes a new option to enable publishing to the wall of a Fan Page independent of publishing to the author’s personal wall. (1.5, 1.5.1, and 1.5.2 all could publish to Fan Page walls, but also published to the author’s wall, which in many cases results in duplication for many of your friends and fans.)

Also in 1.5.3 is some improved error checking (fixed the “activation on PHP 4 hosts” bug and added more Try/Catch pairs around Facebook client calls) and the ability to support old school permalink urls with query string parameters.

Good to be home on the weekend . . .

(Updated 1/5 – it’s actually 1.4.1 now, as there was a typo in the theme/index.php file – get_exteral_url should be get_external_url).

Last night I packaged and released version 1.4 of WPBook, the plugin I maintain which creates a view of your WordPress blog as a Facebook application.

(For example, see Open Parenthesis as a blog, and then Open Parenthesis as a Facebook app).

Highlights of this release

• Fixed bug which made invite friends link only work on the home page
• Fixed bug in setting for custom/header footer which included a permalink
  (WordPress support topic 306263)
• Added Gravatar support
• Added (experimentally) a list of “pages” as well – this means you should able to use WPBook even if you have a static homepage set in WordPress – just use the url of your home page as the “Canvas Callback URL”
• Removed hard coded references to wp-content and plugins directories
  (See http://willnorris.com/2009/05/wordpress-plugin-pet-peeve-hardcoding-wp-content)
• Removed hard coded reference to config.php, routing Facebook comment submission through WordPress’ built in query parser instead
  (See http://willnorris.com/2009/06/wordpress-plugin-pet-peeve-2-direct-calls-to-plugin-files)

As you can see, this was really more of a bug-fix and code cleanup release, with one experimental functional addition (pages). The one feature I didn’t get to but wanted to was threaded comment support (as in WordPress 2.7 and later). Would users want to be able to set threading differently inside Facebook than outside it? (I’m thinking that WPBook should just follow the settings in the blog it is installed to, with respect to threading – and perhaps gravatars as well, given how integrated with WordPress gravatars have become).

The next version will be more of a “feature set” release, and will also be the first version to require PHP 5. Although Facebook only officially supports a PHP 5 client library, I’ve been supporting PHP 4 by relying on an open source PHP 4 Facebook client.

The problem is that many of the operations most requested by users rely on Facebook API calls which sometimes fail. The PHP 5 client handles this by throwing exceptions, which WPBook needs to catch – something PHP 4 can’t do.

What’s coming in 1.5

Here’s my tentative roadmap:

• Threaded Comments – which may mean upping the minimum WordPress to 2.7 for simplicity’s sake. Given that we’re at 2.9 now I think that’s ok.
• More work on Pages. Need to be able to list pages not to show inside Facebook, enable user to set page depth, maybe even show the top level pages as Facebook style tabs across the top of the application? (tricky inside an iFrame app)
• PHP 5 required – this will allow me to trap “uncaught exceptions” which sometimes occur when users submit new blog posts. It’s a cosmetic error but a really ugly one which it happens, and as I use more and more Facebook calls it may happen more often.
• Publish to Facebook’s Stream.publish API when a new blog post is published – this is the most commonly requested feature. (Is it fair to assume the blog author is also the owner of the Facebook application? I had assumed so but that may not be the case – may require the user to enter his/her Facebook UID in WPBook for publishing to the stream)
• Enable publishing to the wall of a Facebook “page” as well as a userwhen a new blog post is published.
• Enable users leaving comments to also publish to the Facebook stream- has to be at the user’s discretion, but WPBook could offer to publish comments both to the stream of the user publishing the comment and to the blog author’s stream.

What else would you like to see in WPBook 1.5? (Not that these aren’t enough).

I’ve also got to start thinking about WordPress 3.0 and the merge with the WPMU codebase, and what impact that has, but I’m hoping that can wait for WPBook 1.6.

Photo by Uncle Bartelby

Adina Levin wrote earlier this month (Twitter, Facebook, and the unselfish API about the differences between Twitter and Facebook not in terms of how they treat their users but in terms of how they treat external developers.

In short:

Twitter’s API is unselfish. Using the straightforward REST API, developers can and do write clients, search tools, mapping tools, recommendation tools, analytics, personal organizing – a wide range of extensions. Twitter doesn’t do anything to constrain developers other than a rate limit.

Whereas:

Facebook’s API is build to serve Facebook more than developers.

She goes on to discuss the shift towards Facebook Connect, away from the emphasis on the application platform, but notes that even then:

The problem is that when sites use Facebook Connect, they have minimal connection to their user base. An an application or community site wants to create the policies whereby the site communicates to the community, and the community talks to each other. With Facebook Connect, those rules belong to FaceBook. . . . With FB Connect, all your member database are belong to them.

One could argue, of course, that it isn’t a fair comparison. Twitter’s platform is more narrow than Facebook’s, with a much simpler privacy model (protected or not, versus groups, networks, friends, and per-application settings), and much less potential for exposure (photos, videos, and detailed personal info being in Facebook’s direct control versus external services like TwitPic). Facebook would argue, I imagine, that they’re trying to create a high standard for privacy for their users, rather than allow every third party app to set it’s own rules, and that this requires them to maintain more control.

Still, I can’t help but feel that the “Open API” approach – impose as few controls as necessary – is ultimately more web-native and will succeed, while the “Controlled API” approach – only release the functionality absolutely necessary and control use with strict Terms of Service (ever read the FB Connect terms?) – calls to mind the old days of walled gardens like Compuserve, Prodigy, and AOL, before they joined the real web.

Photo by Andrea Mercado

Thanks to Karen Huffman (@slakm) who raised some issues she was having with an installation of ReTweeter, I’ve tracked down the bug and uploaded and released 0.9.1.

Turns out that in late December of 2008, the Twitter API servers started sending a 417 Status Code response to many clients, including ReTweeter. (See Alex Payne’s announcement on the Twitter API Google Group and this message from Tom Morris which identified the necessary fix for CURL based clients).

In addition to squashing that bug, this update also better handles error responses from the Twitter API in general, which is to say it actually identifies to the user what status code was returned to enable better troubleshooting.

Remember to copy your settings from your old version before overwriting with the new.

Went better than the WordPress talk yesterday, in terms of time – easier to describe Twitter (which everyone already knows) than to try to cover the WordPress plugin API, the Facebook API, and the plugin I wrote to connect the two all in less than 30 minutes.

Xefer has created an intriguing mashup using data from the Twitter API, a Yahoo! Pipe to some basic transformation, and the Google Chart API to display results:

To get your own, just replace with your twitter username to the end of this url: blog post describing the project:

The most interesting aspect of this project is that, other than the static files being served up by xefer.com itself, no other server-side processing is being done here; all the processing is being handled by Yahoo Pipes and Google, and of course Twitter itself which is ultimately hosting the raw data.

Who knew I tweeted so much on Sundays?

Note that the data seems to be, as per the comment on the blog post, in GMT, so you’ll need to do offsets in your head for your local timezone.

Here’s mine (click to see full size):

I wonder how much this changes over time, or how far back they are able to grab tweets.

The same is true when you use SMS or IM to interact with Twitter.

However, if you use a Twitter client, what happens?

On Twitterific, nothing. The message appears to be sent, nothing shows up your timeline, no error occurs.

Is this a limitation of the API, or of the application’s handling of it?

Update:

@Twhirl tells me (via Twitter) that:

twhirl should display an error message informing you about it.

Maybe time to change? I sent the twitterific developers a note letting them know of the bug.

What does your twitter client do? Tell me in the comments, please.

WorkBook is apparently part of the WorkLight platform, and pricing starts at $10/user/month.

Some coverage:

• WorkLight secures Facebook for enterprises (Dan Farber on ZDNet blog – with a photo)
• WorkLight enters the Enterprise Facebook Market (Bill Ives at Fast Forward Blog)
• WorkBook: Getting Facebook Ready for Work (Andrew McAfee)
• WorkBook Brings Facebook Inside the Firewall (Web Worker Daily)

McAfee, who was able to see a demo, has the best details on the workings of the app:

In a quick demo, Lavenda opened up his standard public Facebook profile, then launched WorkBook (Worklight’s offering) just like he’d launch any other Facebook application. After he logged in, a separate section opened up within the profile. This section was devoted to the user’s employer— let’s call it Lavendaco. Inside this section were a number of standard Facebook features— friends, groups, Q&A, profiles, etc.—presented using the standard Facebook UI. But the data populating each of these were specific to Lavendaco, came from the Worklight server installed at Lavendaco, were encrypted as they travelled across the Internet, and did not pass through Facebook servers.

But I have to confess my own reaction is closer to Bill Ives, which is, wouldn’t this be pretty easy to build yourself, on top of Facebook APIs?

Maybe a good candidate for our next ONE (Optaros New Employee) training class, wherein the team does a quick project. Our Intranet is Drupal 6 based, and shouldn’t be too hard to pull that in to Facebook. I know there is already a Facebook Module for Drupal 5.x