In the “old days” (or in a lot of big corporates today), those support cases would have been handled behind a corporate “veil of secrecy”, tucked in a back end system somewhere, responded to by anonymous “Customer Service Representatives” via a generic email account like “support@intensedebate.com”. While we’re also making use of a generic email address, the similarities between our approach and that of big corporates ends there. End to end, the differences are pretty stark.

Plugin Release

Previously, companies may have tried to encode their plugins, or released them as some sort of binary so that they could control access to them and avoid people modifying them. When we released the 2.1 version of our plugin, we “checked it in” to a public-readable Subversion repository which then publishes to the WordPress Plugin Directory. That code (and all other code in the Plugin Directory) is GPL licensed and available for re-use/hacking/modification. People are welcome to read the code and see what we’re doing, point out where we could do things better, and ideally improve upon it themselves.

After we’ve uploaded the code, people will start getting notifications in their WordPress admin panel that there’s a new version available. To help explain what’s going on, we published a blog post announcing the new version, the new features etc.

Comment Support

Not that it’s a recommended channel for receiving support, but this is where we start really differing. People have posted a number of issues and questions about the plugin right there on the announcement post. We could moderate and remove those comments (or not allow them in the first place); instead, we work with our customers and try to address their problems right there an then. Michael and I have been bouncing around on that post answering questions and finding out more information from people so that we could fix some problems and get to 2.1.1. With email notifications coming in every time someone commented on that post, we’re able to quickly respond to people and help work out any issues they’re having.

Seeking Satisfaction

If people aren’t commenting on that post directly, they’re often over at the Intense Debate Get Satisfaction forum, a community-powered support system where a number of people are contributing. Again, this is a very public way of supporting users, and puts us out there in the limelight, warts n’ all. We answer what we can, assure people that we’re still working on things and that we’re making progress (which we are, a lot of it) and that we’ll get back to them as soon as there’s something to report. When there are updates, or when we need more information for troubleshooting, we post another message and get a stack of responses from eager users, hoping to have their problems solved. This is very real and very connected, and I truly believe that being open and transparent about problems that people are having and the way that we’re working with them helps not just that user, but others who may have similar problems.

Late-night Tweeting

For real-time feedback and almost-instant-messaging-immediacy, there’s Twitter. I know, with Oprah getting in on it now Twitter will probably implode soon, but in the meantime, I’ve found myself providing support direct to people via Twitter as well. One user wanted to use IntenseDebate, but found the comment importer wasn’t working. I replied that we were about to release a fix, and that user was then able to get up and running. This all happened, asynchronously, within about 4 hours of his first tweet.

In Your Facebook

Then for one that I really wasn’t expecting, someone contacted me through Facebook to try to sort out a problem. A user spotted me providing support via Get Satisfaction and other methods, and tracked me down on Facebook. In this case, it was someone that we were already working on a fix for, but it demonstrates just another way that people have been able to get in touch with us.

Better for Customers, Better for Us?

I guess the big question (or 2 questions really) this all poses is: Is this new way of providing support better for our customers? Is it better for us (as the company providing support)? Could it be better for everyone still?

The biggest problem I have (as someone providing support) is just trying to keep track of all these different “vectors”. I’ve identified 4 different support vectors above, and that’s not even including our normal support email/form, official Facebook group or VIP support channels. That makes at least 7 different vectors through which we might be providing support. It can get messy trying to keep up to date with them all and ensuring that you’ve replied to people where they’ve contacted you and in a timely fashion. Perhaps there’s an argument for traditional, centralized systems after all

As it turns out, it’s been quite a project. LiveJournal’s API is, shall we say, “challenging” to work with, and the sheer size of Guav’s journal (over 3,700 posts and nearly 200,000 comments) meant that I kept running into time, memory and database limits that would crash the importer. After a lot of back and forth with Guav though, I’m happy to present the new importer (find it under Tools > Import > LiveJournal), sporting the following features:

• Just enter your LiveJournal username and password and you’re ready to go
• Via the API, it connects directly to LiveJournal and imports all of your posts,
  • Posts marked as “Friends Only” are assigned a password within WordPress,
  • Posts marked as “Private (you only)” are marked as Private within WordPress, which means that only authors on your new blog can read them,
  • lj-cut tags are converted to the WordPress equivalent, the <! — more — > tag,
  • lj-user tags are converted to normal links, and have class=”lj-user” attached to them to make it easier to style them if you like,
  • Tags are imported properly,
  • If you closed the comments on a post in LiveJournal, then they’ll be closed in WordPress as well,
  • Lots of the “meta” information related to posts is also imported using WordPress’ Custom Fields feature. You could then use these values to reproduce some of LiveJournal’s functionality within your new theme if you like. The fields imported are:
    • If your post contains adult content (lj_adult_content),
    • Your current co-ordinates and location (lj_current_coords and lj_current_location),
    • Your current mood (lj_current_mood),
    • Current music (lj_current_music),
    • Your userpic keyword (lj_picture_keyword)
• Next up, all of your comments are also imported,
  • Threading is preserved, so replies to other comments show up successfully (provided you enable that feature in WordPress),
  • The “subject” of each comment is included as the first line of the comment itself, because WordPress doesn’t have a comment title/subject value,
  • LiveJournal users get links back to their LiveJournals,
  • Your own comments are linked to your WordPress account, and are linked back to your new WordPress blog,
  • Anonymous users are labeled as “Anonymous”,
  • “Screened” comments on LiveJournal are imported as “Unapproved” within WordPress, so you can decide what to do with them

So there you have it, a brand new, shiny LiveJournal importer. This should be bundled with the 2.8 release of WordPress (it’s available right now on WordPress.com), and will be available for everyone. As I mentioned, it’s been tested with one single, very large blog (and a few smaller test ones), but if you find anything wrong with it, please file a bug on the WordPress Trac!

Huge thanks again to Guav for helping with the testing of this thing (maybe now he can migrate over to WordPress as well)!

2008-12-26: Fixed a bug that caused the JS to overwrite details on a non-FB Connect comment as well. Also changed the fake email address that’s stored to include the user’s FB user ID.

In case you’ve been living under a no-technology-news rock for the last few weeks, you’ll know that Facebook Connect was released recently. I had been seeing/hearing a lot about it, including this video at Mashable, showing how to implement FB Connect in 8 minutes. So when my friend Morgan from BlownMortgage asked me if I’d be able to help him implement it on his new resume-editing site ResumeDonkey.com, I figured “how hard could it be” and said yes. Although it definitely didn’t take 8 minutes, I got it done, so I thought I’d post some details on the specific approach I used for ResumeDonkey.com.

Before I rolled my own solution, I took a good look at a few of the existing WordPress options including:

• The WP-FBConnect plugin, made by Facebook,
• Another WordPress plugin made by Sociable, and
• The Community Facebook Connect Plugin, by Jesse Stay

None of these worked quite how Morgan and I had discussed, so I decided to make my own, lightweight solution. Before editing any actual theme files, there’s some prep-work to be done, so:

1. Log into Facebook and then go and add the Facebook Developers Application
2. Click the big button at the top right to Set Up a New Application
3. Enter a name and agree to the terms (you read them all, right?)
4. On the next page, enter the base URL of your website in the “Callback URL” field. MAKE SURE you use the correct preference for your website as far as www. or no www. is concerned, and preferably enforce that on your website using a plugin or something. If you enter http://www.domain.com here, and someone accesses your site as http://domain.com, then your FB Connect integration will break and throw a warning about being on the wrong URL.
5. You can also set some sexy icons/logos to appear in the News Feed of people who comment on your blog, but I’ll let you handle that.
6. Get a copy of the “API Key” at the top of this page, you’ll need that later.

OK, now we need to register a “template bundle”, which will be used to post updates to the News Feed of people who comment on your blog.

1. Go to the list of your Facebook Apps and click on the app we just created on the left
2. Click “Create Feed Template” in the list of links on the right
3. Make sure your correct App is selected in the box, then click Next
4. In the “One Line Template” box, paste this exact text

   {*actor*} commented on the {*blog*} post {*post*}.

5. In the “Sample Template Data” box, paste this (make sure quote marks are still  quotes and not fancy curly-quotes)

   {"blog":"<a href='http://test.domain.com'>My Blog Name</a>", "post":"<a href='http://test.domain.com/post-url/'>Test Post Title</a>"}

6. Click Update Preview and make sure that you’re happy with the News Feed format (if not, change the One Line Template string)
7. Click Next
8. Now click Skip (and ignore/Okay any errors) until you get to the final page and then click “Register Template Bundle”
9. It will give you a Template Bundle ID, and you’ll want to get a copy of that, because we’ll need it later as well.

OK. Now you’ve got a registered and configured (roughly) App on Facebook, time to get dirty on your own blog. Create a file in the root of your domain and call it “xd_receiver.htm”, then copy the following code into it:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Cross-Domain Receiver Page</title>
</head>
<body>
<script src="http://static.ak.facebook.com/js/api_lib/v0.4/XdCommReceiver.js" type="text/javascript"></script>
</body>
</html>

Add the “fb” XML namespace to the header.php file in your theme. Mine ended up looking like this (in PHP):

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml" <?php language_attributes(); ?>>

And also drop in a reference to jQuery if you don’t already use it in your theme. It’s bundled with WordPress so you can reference it like this (anywhere before the call to “wp_head()” in your header.php):

<?php wp_enqueue_script('jquery'); ?>

Then you’ll want to edit comments.php (assuming you’re using a relatively normal theme), and make some changes to add the FB Connect button. Find the part where a user would normally enter their name/email/URL and change it to look something like this:

<div id="comment-user-details">
<fb:login-button length="long" onlogin="update_user_details();"></fb:login-button>

<p style="clear:left;"><strong>Or enter your details below:</strong></p>

<p><label for="name">Name <?php if ($req) echo "(required)"; ?></label><br />
<input type="text" name="author" id="name" value="<?php echo $comment_author; ?>" size="50" tabindex="1" /></p>

<p><label for="email">Email Address <?php if ($req) echo "(required)"; ?></label><br />
<input type="text" name="email" id="email" value="<?php echo $comment_author_email; ?>" size="50" tabindex="2" /></p>

<p><label for="url">Website</label><br />
<input type="text" name="url" id="url" value="<?php echo $comment_author_url; ?>" size="50" tabindex="3" /></p>
</div>

Just above this block, you should also find the start of the <form> tag for posting a comment, you want to add the “onsubmit” attribute to it so that it looks something like this:

<form action="<?php echo get_option('siteurl'); ?>/wp-comments-post.php" method="post" id="commentform" onsubmit="update_form_values();">

The important parts there are that it’s all wrapped in a DIV or SPAN with id=”comment-user-details” and then obviously the <fb:login-button> stuff. Now further down (I went right down to the bottom of the comments.php file actually), add this code:

<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
<style type="text/css">
#fb-user { border: 1px dotted #C0C0C0; padding: 5px; display: block; height: 48px; }
#fb-msg { float:left; }
.fb_profile_pic_rendered { margin-right: 5px; }
a.FB_Link img { float: left; }
</style>

<script type="text/javascript">
var fb_connect_user = false;
function update_user_details() {
fb_connect_user = true;
// Show their FB details
if (!jQuery('#fb-user').length) {
jQuery('#comment-user-details').hide().after("<span id='fb-user'>" +
"<fb:profile-pic uid='loggedinuser' facebook-logo='true'></fb:profile-pic>" +
"<span id='fb-msg'><strong>Hi <fb:name uid='loggedinuser' useyou='false'></fb:name>!</strong><br />You are logged in with your Facebook account. " +
"<a href='#' onclick='FB.Connect.logoutAndRedirect(\"<?php the_permalink() ?>\"); return false;'>Logout</a>" +
"</span></span>");
}

// Refresh the DOM
FB.XFBML.Host.parseDomTree();
}

function update_form_values() {
if (fb_connect_user) {
profile = jQuery('#fb-user').find('.FB_ElementReady .FB_Link')[1]['href'];
user_id = profile.substring(profile.indexOf('?id=')+4);
jQuery('#url').val(profile); // FB profile URL
jQuery('#email').val(user_id+'@facebook.com'); // Can't get a real one from FB unfortunately. This saves their user id @facebook.com
jQuery('#fb-user').find('.FB_ElementReady .FB_Link').each(function(i){ if (i==1) { jQuery('#name').val(jQuery(this).text()); } }); // Gets their name from the DOM
setCookie('fb_connect', 'yes');
}
}

function setCookie(c_name,value,expiredays) {
var exdate=new Date();
exdate.setDate(exdate.getDate()+expiredays);
document.cookie=c_name+ "=" +escape(value)+((expiredays==null) ? "" : ";expires="+exdate.toGMTString());
}

function getCookie(c_name) {
if (document.cookie.length>0) {
c_start=document.cookie.indexOf(c_name + "=");
if (c_start!=-1) {
c_start=c_start + c_name.length+1;
c_end=document.cookie.indexOf(";",c_start);
if (c_end==-1) c_end=document.cookie.length;
return unescape(document.cookie.substring(c_start,c_end));
}
}
return "";
}

FB.init("YOUR-FACEBOOK-API-KEY", "/xd_receiver.htm");
FB.Connect.ifUserConnected(update_user_details);
if (getCookie('fb_connect') == 'yes') {
setCookie('fb_connect', null);
FB.Connect.showFeedDialog(YOUR-TEMPLATE-BUNDLE-ID, {'blog':'<a href="<?php bloginfo('home') ?>"><?php addslashes(bloginfo('name')) ?></a>', 'post':'<a href="<?php the_permalink() ?>"><?php addslashes(the_title()) ?></a>'}, null, null, null, FB.RequireConnect.promptConnect);
}
</script>

For those of you paying any attention to what you’re copy-pasting, you would have noticed that there are 2 important things you need to replace in that last block of code. Go back now and replace “YOUR-FACEBOOK-API-KEY” and “YOUR-TEMPLATE-BUNDLE-ID” with the appropriate values from the beginning of this process. YOUR-FACEBOOK-API-KEY should be replaced with the 32-character string from the Facebook App config, and should include double-quotes around it in the code above. The YOUR-TEMPLATE-BUNDLE-ID should not have quotes around it.

Save everything and upload it (if you were working offline). If all has gone well, you should now get a FB Connect button on your comments (you need to log out of WordPress to see it), and when you click it, you should connect to FB, then be able to post a comment.

When a Facebook user comments on your blog now, their name will be loaded from Facebook, their profile URL will be used as their URL, and the email address will be recorded as “user@facebook.com” (their API doesn’t allow you to actually get it, to avoid spam I assume).

Enjoy.

This validator may be used in conjunction with sfValidatorAnd() or other constructs, and just allows you to quickly and easily ensure that a field does not contain a value (or an array of values).

/**
 * validatorNot verifies that an input value is NOT some other value.
 *
 * @author     Beau Lebens <beau@dentedreality.com.au>
 */
class validatorNot extends sfValidatorBase {
  protected $not;

  /**
	 * Configures the validator
	 *
	 * Available Options:
	 *
	 *  * not: The value or array of values that the input value should NOT be.
	 *
	 * Available Error Codes:
	 *
	 *  * not
	 *
	 * @param $options Array of options
	 * @param $messages Array of error messages
	 *
	 * @see sfValidatorBase
	 *
	 */
  protected function configure($options = array(), $messages = array()) {
    parent::configure($options, $messages);
  	$this->addRequiredOption('not');
    $this->addMessage('not', '\'%not%\' is not allowed.');
    $this->not = $options['not'];
  }

  /**
   * Compares $value to the restricted/denied value
   *
   * @param  mixed $value  The input value
   *
   * @return mixed The cleaned value
   *
   * @throws sfValidatorError
   */
	protected function doClean($value) {
		if (!is_array($this->not)) {
      $not = array($this->not);
		} else {
			$not = $this->not;
		}
		foreach ($not as $n) {
			if ($value == $n) {
				throw new sfValidatorError($this, 'not', array('not'=>$n));
			}
		}
		return $value;
	}

	/**
	 * Access the "not" value
	 *
	 * @return mixed value this field may not equal
	 */
	public function getNot() {
		return $this->not;
	}
}

The Configuration

Everything here is happening on a completely (and very) custom theme, which is hosted on a WP 2.6.1 blog. It’s powered by 2 frontend web servers, which are transparently accessed via an LVS. The database is hosted on 2 servers, which are configured in a multiple-master configuration and are also accessed via the LVS. I’ve configued WP-Cache and WP-Super-Cache before so I’m confident I haven’t messed anything “basic” up with the configuration of the plugin.

The Problem

Let’s make sure we’re solving the same problem here. I was seeing my pages load just fine, and they even included the appended comment:

<!-- Dynamic Page Served (once) in 0.928 seconds -->

I saw that files were created in wp-content/cache/*.html but there were no files created in wp-content/cache/meta/*.meta (for WP-Super-Cache). Apparently without the meta files (which contain appropriate headers etc), the caching system assumes it can’t send the cached version, so it re-processes everything and sends the dynamic version (thus the comment).

The Solution(s)

I tried all sorts of things to get this to work, including:

• Moving the define(‘WP_CACHE’, true) to the top of wp-config.php, just in case
• Deleting and manually re-creating the symlink for advanced-cache.php
• Turning on $use_flock in wp-cache-config.php
• Modifying $sem_id in wp-cache-config.php (you never know!)
• Banging my head repeatedly on the keyboard.

Needless to say, none of these things worked. Eventually, I came across a thread where Donncha (the author of WP-Super-Cache, and really nice guy to boot) mentions that a plugin doesn’t have an ob_end_flush() where it should. That reminded me of a post about Anarchy Media Player not working with WP-Cache that I’d seen, so I tried it out by changing the end of my footer.php theme file to look like this:

</html><?php while (ob_end_flush()) {} ?>

That seems to have fixed it! I’m now getting the beloved comment that I was looking for in my source files:

<!-- Cached page served by WP-Cache -->

and performance is way up. High-fives all around. The moral of the story is make sure you close/flush buffers in your themes and plugins. This is a bit of a hack fix for when someone doesn’t do that, but it works.

I had to turn them down, because I am now working at AdultShop.com, which is taking up nearly all of my time, and I simply wouldn’t have had time to dedicate to the job. I asked them what they were doing anyway, and apparently they wanted me to work on the information architecture of their entire suite of websites and online applications – bugger!