For now, since the Google+ API is read-only, I’m borrowing inspiration from Luka Puši?’s GPlus Bot and Dmitry Sandalov’s Twitter 2 Google Plus script.

This means emulating the Google+ mobile web experience using Curl.

WPGPlus adds a box to the post edit screen where you can choose yes/no for publishing to Google+, as well as a place for a message to be used in the body.

(If you provide a Google+ message it is used; if you provide a post excerpt it is used; otherwise post content is used).

Anyway, check it out and let me know what you think!

Photo by Peter Wood, cc-by-nc-nd license.

This last weekend I finally got drafted and posted Closing the Books on WordCamp Boston 2011 over on WCBOS site.

Planning WordCamp Boston the last two years has been quite an experience: challenging, at times high-stress-inducing, but well worth the effort. It’s only really been possible, of course, because of the first class team of organizers and volunteers, many of whom worked quietly behind the scenes getting all the hard tasks done, especially in the weeks leading up to the camp.

Thanks are due (much overdue) to my fellow organizers and all the volunteers, speakers, sponsors, and attendees who made WordCamp Boston 2011 a great success!

Now, on to 2012.

• WordPress 3 Ultimate Security
• WordPress 3 Cookbook
• WordPress 3 for Business Bloggers

All three have now been published and are worth checking out. Details of each below.

The earliest of the three to be published was Olly Connelly‘s WordPress 3 Ultimate Security.

Connelly covers a broad swath of general web security while honing in on WordPress: everything from securing your home wifi to setting up ssh on a remote linux server. Though the advice is most deep for people on dedicated servers or VPS’s where they control the whole stack, there’s a lot of useful info here for folks on shared hosting as well.

He also covers troubleshooting, recovery, backing up (sometimes necessary for recovery!), and many of the plugins available aimed at making WordPress more secure.

The second (in publish order) was WordPress 3 Cookbook by Ric Shreves and Jean-Baptiste Jung.

This one takes the familiar form of a cookbook, presenting a series of “recipes” for how to accomplish specific tasks using the WordPress platform.

The recipes range in complexity from very simple tasks requiring no plugins or code editing (just using WordPress’ built in settings) to complex theme development and plugin configuration.

The current sample chapter on the Packt site is Chapter 5, “Building Interactivity and Community” which gives a good sense of the style of the book. (Though I found Packt’s free chapter function non-functional in Chrome – try Firefox instead).

I won’t even hold it against them that they chose to suggest Simple Facebook Connect over my own WPBook as a way of doing WordPress Facebook integration. ;)

The third was WordPress 3 for Business Bloggers by Paul Thewlis, which, as the blurb has it:

shows you how to use WordPress to run your business blog. It covers everything you need to develop a custom look for your blog, use analytics to understand your visitors, market your blog online, and foster connections with other bloggers to increase your traffic and the value of your blog.

It’s got a case-study format, based on a kind of individual-consultant-professional style blogger using his blog to show his professional knowledge and spread a personal brand – but the lessons are applicable to a wide variety of different kinds of bloggers.

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?

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.

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.

This year’s camp promises to be even bigger than last years, with content from 30+ speakers spread out over one and half days at the Boston University student union. We’ve even got a pre-conference workshop the Friday before and a reception Saturday evening at the Microsoft NERD center.

If you haven’t already got tickets, you’ve missed regular registration, but you can still get in on late registration (which just means you’re in line after the regular registration folks for lunch and T-Shirts) for just $40.

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.

Try Again (Photo by Samantha Marx, cc-by license, http://www.flickr.com/photos/spam/3355834452/)

Spent some quality time this weekend with WPBook. As a result, I just released version 2.2.1. (There was briefly a 2.2 release, but something was corrupted in that version of the SVN repo, so use 2.2.1 instead).

Included in 2.2.1:

• Read More is back. Re-enabled the “Read More” action link. Unfortunately, because of a Facebook API bug wpbook can’t add more than one action link to a post, so no “share” button on wall posts until that is fixed. (Facebook doesn’t add the Share link automatically to posts from the Graph API and there’s currently no way to make that happen other than manually adding it as a link, but I think the “Read More” link is more important.)
• Post to Group Walls. Added posting options for Group walls, and comment import form Group walls. Because of the way the Facebook API has changed, posting to a Group feed is distinct from posting to a Page’s feed, and requires different syntax.
• Controlled debugging. Limit the size of debug files created to 500k, so that users who enable debugging and then forget won’t have an unlimited file growing every hour. Also made the debug constant more specific to WPBook so as not to interfere with other plugins potentially using DEBUG as a constant
• Fopen errors. Clean up DEBUG for cases where permissions fail or file is not writeable
• Facebook::$CURL_OPTS . Made “disable ssl verification” an option so that only users who need it will have it and others won’t get conflict
• Required fields are required. Cleanup to the admin screens in general, more clarity around what is required and better language on the admin screens about what is being checked. (Thanks BandonRandon for patches)
• Better check permissions. Improved “Check permissions” page, to show what options mean and enable links to view profiles, pages, links to validate IDs are correct.
• Added wpbook logo which had been missing
• Fix for get_themes() issues with WordPress 3.0.1 through 3.0.5

I realize from the activity in the forums that many users are having trouble with the 2.1 and later WPBook – but I believe all the known errors have been fixed, and most are due to misconfiguration.

A few configuration notes that might help:

1. Your application ID, secret, canvas URL, and Profile ID must be correct or nothing else is going to work. If you load your application canvas page and you don’t see the WPBook theme, but see just your blog in an iframe (unchanged), then something is wrong in your Facebook Application setup, your WPBook setup, or in a plugin conflict.
2. Your personal FB profile is absolutely required, even if you don’t plan to publish to your profile’s wall. It is through the FB profile that the access_token for publishing to pages is retrieved. If your FB profile ID is wrong, nothing else is going to work.
3. Any time you change the Profile ID, the Page ID, or the Group ID to which you are trying to publish, you must visit the Check Permissions page and will most likely need to regrant permissions. Again, if permissions aren’t working, nothing else is going to work.

If you’re stuck, please open a new thread in the wordpress forums and provide the following debugging info:

• The URLs of your Facebook Application and your blog outside FB
• The contents of your check permissions page – verbatim
• What you are trying to publish to – profile, page, group – by ID and by URL
• What error messages you are seeing, in the WordPress interface and/or in the PHP error log

With the right information, we will be able to get it working.

Thanks

Code Bug (Photo by Guilherme Tavares, cc-by license, http://www.flickr.com/photos/guitavares/1703252007/)

Just released WPBook 2.1.4.

Two key bugfixes in this release:

1. Comment Imports. In changing to the Graph API I needed to add an access_token to the FQL calls I’m using to retrieve comments from non-public streams.
2. Facebook Avatars for Pages. Given that you can now comment on wall posts as a page (by using the “use Facebook as page” option if you are the admin of a page) some of your comment authors in FB might be pages themselves. This fix will get the right FB avatar for them, eliminating what was otherwise a broken link image.

There should not be any need to regrant permissions or change any Facebook settings in this release.

Thanks to all the users who’ve provided feedback (and debug files!) in the forums.

Note that if you’ve already made the changes described in upgrading from 2.0.x to 2.1 you do not have to redo them, though you will have to regrant permissions (in order to fix #s 1 and 2 below).

Three significant bug fixes:

1. Access Token storage. In 2.1 and 2.1.1 I had been storing the access_token Facebook returns after granting permissions in the user_meta table, which worked, but only if you were always publishing in WordPress as the same user who granted permissions. (The same WordPress user_id). Now this gets stored in the options table and works regardless of who is logged in, which makes more sense for the publish action in the first place.
2. Publish as a page. This required getting the “manage_pages” permission, so you will need to regrant permissions (visit the WPBook options page, click on the “Check Permissions” link inside the Stream/Wall options section, and then click on “regrant permissions” on the resulting page inside Facebook). Basically once you’ve granted “manage_pages” permissions, WPBook looks for the page you’ve identified as a target, and fetches and stores a new access_token that is specific to acting as that page. This access token is then used to publish to the page’s wall, so that they appear to come from the page, not from your FB user id.
3. Post Thumbnails. This was more badly broken than I thought – not sure how it worked in my testing. (My guess is that FB grabs an image even when you don’t provide one, and may have accidentally grabbed the right one when I test-posted). But it works now, provided you have actually indicated a post-thumbnail (or “featured image” as it is now called in the WordPress admin).

What may still be outstanding is support for WordPress 3.0.1 and potentially other versions between 2.9 and 3.1. Please do open a thread in the forums if you are using an older version of WordPress or having other issues.

Note to self, by S@Z, creative commons license

Just tagged a 2.1 beta 2 release of WPBook, which adds to the earlier release 2.1 beta 1 some new tricks:

1. Post as Note in Facebook. Based on a patch supplied by sebaxtian in the forums, this option changes the posting type in Facebook from a regular story (an entry in your news feed) to a Note, using the Facebook Notes application.
2. Custom Themes. Based on a patch from BandonRandon, this functionality looks first for an installed theme named ‘WPBook’ and if it finds that uses that theme over the default supplied theme. This way, advanced users can change the appearance of their WPBook powered blogs inside Facebook and not have those changes overwritten with each new release. I will be sure to note in future releases when any new functions are introduced or significant changes made to the theme files.

I haven’t, unfortunately, gotten much feedback on the beta. I say unfortunately because I think that’s a result of few people testing it – I suppose it’s possible it is just working for everyone but I think it has seen few downloads. (There’s one reported error in the forums, but I can’t isolate what’s causing it).

So please do test this one – remember that if you are upgrading from 2.0.x you will need to make the same changes to your settings as described in the release blog post for 2.1 beta 1 .

Report on your success or failure in the forums – thanks.

I’ve just tagged earlier today a 2.1b1 (beta 1) release of WPBook. Please download it and test it, and report back what you find here or (preferably) in the forums.

Make changes to your Facebook Application settings described below after installing WPBook 2.1 but before trying to visit application pages!. We’ll update the official WPBook documentation once we’ve got a few folks testing the new version and can move to a 2.1 release.

This release is the first to use Facebook’s OAuth-based authentication protocol, Graph API, and new PHP SDK. I know that’s a whole lot of acronyms, but let’s just say it means we’ll stay current as Facebook makes obsolete some of the older ways of integrating to Facebook.

New features:

• Facebook Like button on posts, rather than Share button. The like button now works in a very similar fashion to the older share button (it posts into the users news feed when he/she likes something). It also resolves to the external url, so if you’re using a Facebook Like button on your blog outside Facebook, likes inside Facebook will get counted as well.
• iFrame based tabs. Unlike the old FBML based tags, iFrame based tabs (which you can use on “new” page profiles) can include videos and other full html objects.
• WPBook now uses post_thumbnails (“featured image” set in the post edit screen) for wall posts, which should yield more consistent results
• WPBook now requires WordPress 2.9 or later

In other words, this is really mostly a back-end cleanup release.

When you install, you’ll need to make a number of changes:

1. In WPBook Settings, there’s now a box for “App ID” rather than “API-key.” You’ll need to change this as if you had WPBook before 2.1, it will be set to your API Key – you’ll need to change it to your App ID
2. In WPBook Settings, go into the Stream/Wall section, make sure your Profile ID and Page ID are set correctly, and click on the Check Permissions link. Even if you previously had permissions set correctly, you’ll need to re-grant them in order to store successfully an access token that will give WPBook the ability to connect to Facebook even when you are offline. The Check Permissions page itself (shown inside Facebook, see below) now tries to give an indication of the current status of all permissions and necessary steps.
3. Update your Facebook Application settings – go to your Facebook application and change the Advanced Tab settings to match the below – enabling OAuth 2.0 and Post for iFrames Canvas urls
4. Update your Facebook Application settings for Page Tabs. If the page you want to add the tab to is using the old page style, leave tabs set to FBML and ?app_tab=true&fb_force_mode=fbml (as before). But if the page to which you want to add the tab is using the new profile layout, change tabs to iframe, and change the tab url to ?app_tab=true, leaving out the &fb_force_mode=fbml bit.

Here’s what the new “Check Permissions” page looks like:

And here’s what the “Advanced” tab of your Facebook Application settings should look like for 2.1 or later:

I’ve validated that it is working for me on two different WordPress blogs (with different Facebook Applications):

• Posting to individual profile Wall on post publish, including featured image
• Posting to Application Profile Wall, Page Wall, and Group Wall, including featured image. (One type of wall at a time – is there interest in posting to multiples at once?)
• Importing comments from individual profiles and from page walls – based on wp-cron, running hourly
• Showing canvas pages with new OAuth based permissions
• Showing iFrame based tabs or FBML based tabs, depending on the string entered in the url box of the Facebook settings for Tabs – iFrame based tabs only work on new style profiles

Ours Goes to 11

Just tagged and checked in another maintenance release of WPBook, 2.0.11. This will be the last (hopefully) release in the 2.0 series – next up is 2.1, with OAuth 2.0 for authentication. (Facebook is migrating in this direction, which means eliminating by March 2011 some of the calls I’m relying on now).

This release also incorporates all the 2.0.10 changes, but it marked stable – so many of you will jump right from 2.0.9.2 to 2.0.11.

Changes in 2.0.11:

1. Removed “add to profile” tab options. (Facebook no longer allows these for individual profiles, only for Facebook Pages, and the button itself is not necessary).
2. README updates – link to instructions
3. Conditional checking for fb_page_target to avoid ‘premature end of FQL query”
4. README updates on profile tabs
5. Add pending_to_publish state. (This should pick up posts written by other authors but now approved by an editor).
6. Filter JS out of FB share link
7. Added more debugging info

Changes which were in 2.0.10 (and thus incorporated into 2.0.11):

1. (Changes by bandonrandon, see http://bandonrandon.wordpress.com/2010/10/10/wpbook-2-0-10-beta-release/)
2. Move includes into their own directory
3. Incorporate FB avatar in comments imported
4. New Admin Layout, images
5. Bug fix: default for ‘post to facebook’ is set to true
6. Links in permissions page point to wpbook.net
7. FB tabs view moved to its own file in theme directory

I’ve also updated a few of the directions pages on WPBook.net to reflect more accurately what WPBook can do and what settings are necessary – that work will be ongoing this week to bring the directions up to speed with both Facebook changes and WPBook changes.

In the meanwhile, post in the forums in you’re having difficulty.

B2B Buzz - New Community for Small Businesses from Hoovers Online

(Via MediaPost) Hoovers and several business cosponsors have launched a new “social community” for small business users called B2B Buzz. The site’s focus is primarily content:

The voice of the social community will guide the direction for a portal and business consortium that Hoover’s and contributors Outsell, Selling Power, and Shore Communications plan to launch Tuesday. For the first six months the group will focus on building and sharing its collective expertise on marketing and sales, along with a variety of business topics for entrepreneurs.

In essence there’s a “self-assessment” and a blog (the site is on WordPress) for each of their three primary audiences: Sales, Marketing, and Small Business. The assessments walk you through 10 questions designed to determine how effectively your business is leveraging information – and end with an “enter your email address to get your results” style capture form (which gives no indication as to what happens to the email address you provide – shouldn’t a best practices site do a better job of explaining the privacy policy at the point of email capture?).

The Assessment ends in email address capture form

The site also links to a Twitter account (@b2bbuzz) and a LinkedIn Group though these links aren’t specific to the sub-audience but cross the three user types.

So is it a community? (Nevermind a “social community” which was MediaPost’s redundant term – the site merely bills itself as “a community of business information experts”).

Users can comment on blog posts, of course, and interact with the site authors via Twitter. According to the contributors page, “Experts from across the industry are invited to join our contributor ranks,” though the site’s beginning with five (including 2 from Hoovers and 1 from co-sponsor SellingPower). There isn’t, however, anything to register for – no user profiles, discussion forums, or call for user-contributed ideas and stories. Even the comments form is a simple name, email, and (optional) website link.

Given the recent Forrester report on the “plateau” of content creation, is this a smart strategic move to focus on where the companies involved can add value, or is it just the first step in the direction of a more robust community to come? (Or, I suppose, both?). Or has “community” become the new default generic term for “site,” displacing “portal,” “destination,” and “blog” itself?

Photo by Jason Permenter - http://www.flickr.com/photos/volcanologist/3334093782/in/photostream/

(Via Chris Brogan)
Editorial Calendar is an excellent new plugin for WordPress which shows your blog posts (already published as well as scheduled for future publishing) in a calendar view and lets you drag posts around to different days. Simple, clean, and just works (at least on the two 3.0.1 WordPress blogs I’ve tried it on – haven’t dealt with multiple authors, etc yet).

Here’s a walkthrough video from one of the plugin’s authors, Zach Grossbart:

The WordPress Editorial Calendar Screen Cast from Zack Grossbart on Vimeo.

See a walk through of the WordPress Editorial Calendar, a new plugin that gives you a simple drag and drop interface for managing your blog.

(Only for self-hosted WordPress blogs, though I imagine the folks at Automattic will love this and want to make some version of it available for WordPress.com users as well)

Photo by Daniel Morrison - http://www.flickr.com/photos/danielmorrison/4106439044/

So in this new theme for Open Parenthesis, I really wanted a lightbox / thickbox type effect on local images. This means that when the user clicks on the smaller images used inside blog posts, the “view larger” version is presented in a nice javascript modal dialogue box, with the rest of the page darkened. It’s a common effect you’ve likely seen on many blogs, and there are some plugins which do this, but I wanted it built in to the theme.

I found this post – Create Thickbox in WordPress With Just 3 Lines of Code – which seemed (and was) promising, but had to customize a bit for how I use images – basically to avoid applying the thickbox effect on images which are linked to external sites.

The steps are simple. First, add these three lines to your theme’s header file:

<?php wp_enqueue_style('thickbox'); ?> <!-- inserting style sheet for Thickbox. -->
<?php wp_enqueue_script('jquery'); ?> <!-- including jquery. -->
<?php wp_enqueue_script('thickbox'); ?> <!-- including Thickbox javascript. -->

I suppose one really could also add these to the themes Functions file, but I went for just adding them directly to the header. From this point on, smaller images that are wrapped inside an anchor link (pointing to the full size image) with a class of ‘thickbox’ will automagically be treated with the right behavior.

But who wants to have to add class=’thickbox’ for every image you upload? In the comments thread Remiz pointed out that jQuery can easily do this for you:

$(".post-content a img").parent("a").addClass("thickbox");

(You have to change the “.post-content” bit to match whatever class your posts are wrapped in). The problem is that this selector is too greedy – it adds the class to any image inside a link. I often use images to link directly to third party sites, so the href points not to a larger version of the image but to someone else’s website. In that case thickbox won’t know what to do. I changed the selector to limit it to only images which are linked to something local:

$(".entry a img").parent("a[href*=openparenthesis]").addClass("thickbox");

This says find every image which is inside a link which is inside a div marked with class “entry” (which all my posts are), and then if and only if the href attribute of the enclosing link contains “openparenthesis”, add a class of thickbox to that link. This way when I link an image to an external site (I figure it will be rare to link to an external site that also includes the words openparenthesis) the lightbox effect doesn’t get applied.

Additionally, to add the “gallery” style effect, in which the thickbox treated images include a “X of Y” notation and a link to the previous or next image, you have to add a rel="gallery" or some other string to each anchor link. Again jQuery handles this easily:

$(".entry a img").parent("a[href*=openparenthesis]").attr('rel', 'gallery');

Finally, to make sure jQuery is loaded before your javascript fires, wrap it like this:

jQuery(function ($) {
/* You can safely use $ in this code block to reference jQuery */
$(".entry a img").parent("a[href*=openparenthesis]").addClass("thickbox");
$(".entry a img").parent("a[href*=openparenthesis]").attr('rel','gallery');
});

You can see the effect in this post. The first image (above) and the next image (below) are both smaller sizes linked to a local, larger size. The third and fourth images are linked to jQuery and WordPress sites, and thus don’t get the thickbox effect.

This image is linked to a larger view and will get thickbox treatment as it is local

Linked to WordPress.org, thus it doesn't get thickbox treatment

Linked to jQuery.com, also no thickbox effect

Photo by Brian Arnold - http://www.flickr.com/photos/brianarn/265152959/

SixApart recently announced that they will be closing Vox, their hosted blog service, at the end of September. Earlier this year, Ning announced it would be moving to a “paid users only” model, leaving many communities looking for new homes online. What’s a site owner to do when free (as in beer) services disappear? Look for open source replacements, of course!

WordPress and Drupal

The good news is that this doesn’t even have to mean running a server anymore. WordPress.com, the hosted, free (as in beer) version of the free (as in speech and beer) and open source WordPress blog software, can import your Vox blog. To replicate your Ning site, consider Drupal Gardens (if you want to avoid running a server), or Drupal Commons (if you’re up for managing a server). Migrating from Ning to Drupal is not as simple as Vox to WordPress, but some have done it:

• Migrate from Ning to Drupal via WordPress->BuddyPress->Drupal (!)
• Migrating from Ning to Drupal (Not a tutorial but pointer to User Import, Feeds, Table Wizard, and Migrate modules – which one could use together to import a Ning site)

Unfortunately I don’t think there is yet a straightforward way to get from Ning to Drupal Gardens. Gardens exports sites but doesn’t (currently) import them.

The key is that in either case, you’ve got long term flexibility. You can always export your WordPress.com blog when you’re ready to move to self-hosted (giving you more flexibility with plugins and customizations but necessitating a hosting account or server space somewhere). Drupal Gardens gives you the same option, allowing you to export your Gardens site (users, content, and all) when you’re ready to move to managing your own Drupal install.

Photo by Leo Lapworth - http://www.flickr.com/photos/ranguard/2616141325/

One Week | One Tool is a project of the Center for History and New Media at George Mason University. Held earlier this summer (July 25th through July 31st), the project brought together a diverse set of 12 participants with backgrounds in the Humanities (History, Literature, Linguistics, Library Science), New Media, and Software Development, with the express focus on designing and building an actual useful tool in one week. As they put it:

A short course of training in principles of open source software development will be followed by an intense five days of doing and a year of continued remote engagement, development, testing, dissemination, and evaluation. Comprising designers and developers as well as scholars, project managers, outreach specialists, and other non-technical participants, the group will conceive a tool, outline a roadmap, develop and disseminate an initial prototype, lay the ground work for building an open source community, and make first steps toward securing the project’s long-term sustainability.

The tool they produced, which is currently in a self-described 0.4 alpha version, is Anthologize – a WordPress plugin for gathering, organizing, and outputting in anthology formats (digital formats as well as formats destined for physical print) blog content.

Once installed and activated, Anthologize works on the concept of projects, broken up into parts (using the new custom post types in WordPress 3.0). You can assign various blog posts (from the blog to which you installed Anthologize, or imported from external feed urls) to parts, drag and drop them to re-arrange the parts, and merge posts together (using the “append” button) within a part:

The edit projects screen, showing posts, parts, and projects

One nice touch I appreciate is that the export project screen allows you to set not just traditional copyright on the collection but also creative commons licensing options:

Exporting a project, with Creative Commons options

The exported project can also have a dedication and acknowledgements, and can be output in PDF, RTF, ePub, or TEI formats, suitable for sending to printers or many eReader style devices:

Export Options, including dedication and acknowledgements

Unfortunately, in my initial trial, the plugin was unable to handle shortcodes, which WordPress uses for photo captions and various kinds of embedding – a significant blocker for this blog but not necessarily for more text-heavy blogs. Granted, the plugin is in an early alpha stage, but I guess the real test will be whether this kind of focused effort can sustain the long-term development, debugging, and support that a truly useful tool always requires. Who’s going to take care of the tool once the week is over?

(The project lives on at github and Google Group for developers and users).

That said, I’m intrigued by the sense of experimentation and innovation that the project clearly created, and how constraints enable creativity. What if more corporate project teams kicked off new projects in a similar way? Put some stakeholders from different roles in a conference room for 1 week with the focus on delivering a real functional tool at the end of that week.

I think we’d be amazed and what we can create.

(Footnote: the project was “Generously funded by the National Endowment for the Humanities.”)

Photo by Stephen Burch - http://www.flickr.com/photos/stephenburch/3334570347/

Sometimes you just want to use WordPress as a simple content management system, and the site owners don’t plan to blog or have any content for which feeds really make sense. Its easy to not add subscription options to sidebars or footers, but don’t forget the autodiscovery links in the header, which look like this:

<link rel="alternate" type="application/rss+xml" title="Open Parenthesis RSS Feed" href="http://www.openparenthesis.org/feed" />

These links are what browsers like Firefox use to “autodiscover” the feeds and add the feed icon to the address bar. But what if you don’t want any feeds? Just add this line to your theme’s functions.php:

remove_theme_support('automatic-feed-links');

And voila, no more autodiscovery feed links.

There’s no codex page for remove_them_support(); but my guess is this requires WordPress 3.0 or later as that’s when 'menus', 'automatic-feed-links', 'custom-header', 'custom-background' and 'editor-style' were added to add_theme_support();.

Old Theme

It’s served me well, but over the years it’s come to feel a bit cluttered. Too many sidebars (more accurately perhaps too many widgets in the sidebars), too many colors, too many rounded corners (ah, the enthusiasm of Web 2.0), fonts too small, contrast too weak between text and background. The new theme is brighter (more white space!), lighter (less brown, blue, and orange – more red), and all around easier to read.

The new theme is based on one called Nameless by a German designer named Karsten Kuhnen:

Nameless Theme

I’ve made a few alterations, especially to the sidebar on the right, to better fit with the content here – but the design is very simple, clean, and modern. Hopefully less to distract you from the content.

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

We are also moving toward IFrames instead of FBML for both canvas applications and Page tabs. As a part of this process, we will be standardizing on a small set of core FBML tags that will work with both applications on Facebook and external Web pages via our JavaScript SDK, effectively eliminating the technical difference between developing an application on and off Facebook.com.

We will begin supporting IFrames for Page tabs in the next few months. Developers building canvas applications should start using IFrames immediately. By the end of this year, we will no longer allow new FBML applications to be created, so all new canvas applications and Page tabs will have to be based on IFrames and our JavaScript SDK. We will, however, continue to support existing implementations of the older authentication mechanism as well as FBML on Page tabs and applications.

Finally, due to low usage rates, we will remove application tabs from user profiles in the next couple months. Application tabs will continue to be supported on Facebook Pages.

Good thing I finally got around to updating WPBook to support FBML-based tabs, just in time for them to be discontinued. ;)

Oh well, once they allow iFrames on tabs we’ll get the ability to do things like embedded videos. But then they’ll take tabs away from individual profiles? So individual profiles won’t have boxes or tabs?

I guess that will just encourage anyone really using WordPress as a platform for promoting their blog will end up creating a page, and then using the tab in the page?

You can see a timeline of some of the updates here: Developer Roadmap

They also changed the developer app again:

We’ve also spent some time cleaning up some of our developer tools and documentation. We’ve simplified the Developer application by removing obsolete settings and tabs

So the instructions for WPBook which I just updated last weekend will need updating again to match the new settings look & feel. Ah the joys of depending on a third party platform . . .

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.