Behind The Blog

Last week when I put up my request for readers to dial into some sample voice applications, I received the feedback (ironically via Twitter) that my “skype:” and “sip:” URLs weren’t working. They appeared in the text correctly:

skype:+990009369996076704
sip:9996076704@sip.voxeo.net

but they weren’t “clickable”. Instead of launching your Skype or SIP client, they went instead to:

http://blogs.voxeo.com/voiplab/2008/06/03/got-a-minute-to-make-a-couple-of-phone-calls-to-generate-some-traffic-for-screencasts/+990009369996076704

http://blogs.voxeo.com/voiplab/2008/06/03/got-a-minute-to-make-a-couple-of-phone-calls-to-generate-some-traffic-for-screencasts/9996076704@sip.voxeo.ne

Neither of which worked, of course, so people got the good old 404 screen. (Some of you may know where this is going…) A quick look at the code showed the problem:

<a href=”+990009369996076704″>skype:+990009369996076704&t;/a> or <a href=”sip:9996076704@sip.voxeo.net”>9996076704@sip.voxeo.net</a>

The “skype:” and “sip:” URL prefixes were being helpfully stripped out when the post was being published! The links were then relative URLs which were of course bogus.

The solution turned out to be similar to what I could do to solve my embedding XML problem… modify the kses.php file. There at line 338 was this:

function wp_kses($string, $allowed_html, $allowed_protocols = array (’http’, ‘https’, ‘ftp’, ‘ftps’, ‘mailto’, ‘news’, ‘irc’, ‘gopher’, ‘nntp’, ‘feed’, ‘telnet’)) {

And so a simple change of adding ’skype’ and ’sip’ to the end of the list like this:

function wp_kses($string, $allowed_html, $allowed_protocols = array (’http’, ‘https’, ‘ftp’, ‘ftps’, ‘mailto’, ‘news’, ‘irc’, ‘gopher’, ‘nntp’, ‘feed’, ‘telnet’, ’skype’, ’sip’)) {

seems to have fixed the problem. I had to re-enter the URL prefixes on the original post, but now the “skype:” and “sip:” URLs do work in the edited post.

Fun, fun, fun…

Technorati Tags:
wordpress, wordpress mu, wpmu, skype, sip

Tonight I successfully upgraded blogs.voxeo.com to WordPress MU 1.5.1, the latest version. I’ve been wanting to do this since the release a month ago but I’ve held off to monitor the WPMU Forums to see what upgrade issues there were. The other challenge is, of course, that doing a site-wide upgrade requires setting aside a block of time in case anything goes wrong (and it did… see below). However, in light of reports of mass hacking of WordPress sites (see also here), I decided to make the upgrade tonight.

Following some of the links off of this forum post, I did successfully complete the upgrade, but I thought I’d record several lessons I learned in case they help others:

1. BACKUPS ARE YOUR FRIEND - Before doing anything, I had done the good old

tar -cvzf wpmu-backup-20080612.tgz wpmu

command in the directory above my WPMU installation to have a nice little tar file sitting there. This turned out to be critical as I did in fact need to restore it all to how it originally was after messing it up with #2 below. I also performed a MySQL backup to be safe although that turned out not be needed.

2. DISABLE ALL PLUGINS - This was mentioned in a few posts but for whatever reason I didn’t do it. Bad move. There was something about the OpenID plugins I was using that did not like the upgrade. It was somewhat bizarre in that the plugin to accept OpenID logins actually seemed to start working, which it hadn’t done before! However, it was causing a host of errors - bizarrely even when I reverted to a backup… so I wound up going into mu-plugins and blowing away the OpenID plugins from the directory (thanks to having the backup in #1).

3. YOU DO HAVE TO ADD THE SECRET KEY AND SALT - Just as detailed on Donncha’s blog post, on my first login to the admin interface I was given the warning that I needed to add two lines to my wp-config.php file. This was a very simple copy/paste into a shell window I had open.

4. USE ‘UPGRADE’ FROM SITEADMIN - Once you’ve copied the WPMU 1.5.1 files into your WPMU directory, the upgrade process for the individual blogs is a simple matter of choosing ‘Upgrade’ from the Site Admin menu.

5. THE ‘DEFAULT’ THEME GETS OVERWRITTEN! - After the upgrade, our home page was perfectly fine, but each of the individual blogs looked horrible. After a forced browser refresh it became clear that they had reverted to the default Kubrick theme. The issue became clear - the ‘default’ WP theme gets overwritten by the upgrade. In retrospect, this makes sense, but here’s the problem - we replaced the ‘default’ theme with our own that is visible on any of our blogs. The reason is simple… on this site, the only blogs that will be created will be with this theme. It will be the default for all blogs. Rather than create a separate theme directory and require blogs to be changed to that separate theme, it seemed to make sense to just replace the ‘default’ theme.

Oops.

Thankfully because of the backup from #1, restoring our ‘default’ theme was a trivial matter.

In a nutshell, those were my lessons from tonight. We’ll see if there are any further issues as we use it, but so far everything seems fine (outside of the fact that I have to go back and add the OpenID plugins back in - which will be for another day).

Technorati Tags:
wordpress, wordpressmu, wordpress mu, wpmu

If you look down in the comments area of this - or any other blog post - you’ll now see a link that says you can add a video comment:

What’s going on? Well, I’ve added a new video plugin for Wordpress from the folks at Seesmic. Here’s brief video intro from me:

Adding Seesmic’s WP plugin to our WPMU site 

The plugin was announced yesterday on Techcrunch and also on (Seesmic founder) Loic LeMeur’s blog. The folks at Seesmic even nicely created a little YouTube tutorial about the plugin:

Adding the plugin to WordPress MU was very straightforward. I downloaded the code, unzipped it and copied the directory into the “plugins” directory (NOT mu-plugins). I then went into Site Administration -> Plugin Commander and clicked on the “Allow” link to allow individual blogs to have this capability. Next I went into the admin dashboard for this blog and enabled the plugin for this blog. Ta da… video comments and embeds into posts are now enabled.

Why didn’t I just enable it across all blogs? Well, I like the granularity of being able to enable or disable it on a per-blog basis. The reality is that I’ll probably enable it for all the blogs on this site that I primarily run. But we may have other blogs here that others run (as Chris does with the Voxeo Labs blog) where they don’t want to use video.

One note I should make. In the Seesmic plugin configuration (for each blog), I have opted to allow “anonymous” video comments, meaning that someone does not need to have a Seesmic account in order to leave a video comment. There’s a checkbox there that enables that kind of posting:

Now, the one down-side I’ve already discovered is that in order to use it to embed a video in a post like this, I have to use the WordPress web editor to write my post. However, I almost never use this web editor because I’ve gotten very addicted to doing all my blogging offline using MarsEdit. However, I think odds are that when I want to embed a video, I probably won’t want to write as much text, so I probably won’t need all the shortcuts that I’ve gotten used to in MarsEdit. (I may also be able to go into the web editor, record and embed the video, save it as a draft, and then pull it down into MarsEdit and do further editing there - I’ll have to try it.)

Outside of that, it seems like a cool way to add video into the blogging platform. Let me know what you think. Hey… if you have a webcam, you can leave me a video comment!

Technorati Tags:
video, seesmic, wordpress, wordpressmu, wpmu, blogging

As I’ve had now several requests for more info about what we did on our main page to list the most recent posts across all blogs, I just thought I’d put up a note to say that I will be posting the plugin script and writing more about that soon. I just need to clean it up a bit more and create a page with more info. It’s almost there…. sometime in the next week or two, hopefully.

Technorati Tags:
wordpress, wordpress mu, wpmu

With WordPress 2.5 now out, we’ll be watching to see when WordPress MU gets updated. Of the long list of WP 2.5 features, the one that is honestly of most interest to me as the one running a blog site is of all things the improved editor:

Friendlier visual post editor — I’m not sure how to articulate this improvement except to say “it doesn’t mess with your code anymore.” We’re now using version 3.0 of TinyMCE, which means better compatibility with Safari, and we’ve paid particular attention this release to its integration and interaction with complex HTML. It also now has a “no-distractions” mode which is like Writeroom for your browser.

I don’t use the visual post editor myself - I do all my posting through the MarsEdit offline blog editor - but as I’ve been helping others post to this site, I’ve seen the existing editor as one of the things that sometimes causes challenges. So I’m looking forward to the new editor.

All the other features look good, too, so it should be an interesting release to get into place. Per a thread on the WordPress MU forums, though, it may be a little bit before WPMU comes out with a new release in sync with WP 2.5. As noted in that thread, WordPress.com needs to be updated first. We’ll see. This will be the first WordPress MU upgrade we’ll have done to this site, so it will be an interesting learning experience for us. Will the “upgrade” features of WPMU work as well as we would hope they will?

Technorati Tags:
wordpress, wordpress mu, wpmu

Given that we work with XML, we naturally want to include XML inside of our blog posts. However, that turns out to be a bit of a major headache. Over on our Voxeo Developer’s Corner blog, you can see what we are trying to do with posts like this one. We want to include snippets of XML code, complete with angle brackets, etc.

Obviously this can be done through good, old “HTML character entity substitution. In order to get:

<prompt>

we simply enter it into WordPress MU as:

&lt;prompt&gt;

We can do that - and certainly any number of text editors make it now easy to go through and swap all symbols over to their corresponding HTML character entities. But this is rather a pain in the neck. You have to bring the code into one of those editors, select the entire text, and then execute whatever script you use to to the character conversion. It takes a little bit of time and when you are trying to get folks like our busy support team to also contribute blog entries, you want to reduce anything that adds time to the posting process.

What I was ideally trying to do for our authors was make it so that they could do something like this:

<code>
… XML code…
</code>

With something like this, they could simply copy/paste their XML code directly into the WPMU editor and… ta da… publish the post. In trying to make this ideal a reality, I worked my way through installing a number of different “code markup” plugins for WordPress:

• Code Markup

• Code Autoescape
• Preserve Code Formatting

I also looked at Code Viewer but really did not want to store the XML code in separate files.

I installed each of these (in some cases multiple times), read and re-read the instructions, added the appropriate markup (usually <code>) around the block of code, published the entries and…

Nothing.

All the posts looked horrible and didn’t display any of my XML code. This was all incredibly frustrating and after spending a sizable chunk of my time trying to make this work, I finally posted my problem on the WPMU Forum and soon received my answer.

It turns out that WordPress has a file called “kses.php” which lists all of the tags that are allowed inside my post. Any tags not in the allowed list get stripped out! This obviously occurs before the code markup plugins step in and do whatever conversion they do of the code into HTML character entities. So… all my XML code appears to WPMU as regular tags, which, because they aren’t listed in kses.php get stripped out.

Oops.

The end result is that it appears that I have two options:

1. Enter all the relevant VoiceXML, CCXML and CallXML tags into kses.php so that they are allowed; or
2. Keep on doing it the text editor massive replace route.

Given everything else on my plate, we’re going to reluctantly have to stick with #2 and just keep on replacing the symbols with HTML character entities before copying/pasting into WordPress’ editor. It’s a pain - but I don’t see an option until either I find another solution or get the time myself to update kses.php.

If anyone reading this knows of another option, I’d love to hear it.

Technorati Tags:
wordpress, wordpress mu, xml, wpmu, blogging, HTML

Given that over the past year Twitter has emerged as one of the new communication tools within social media, one of my natural reactions was to figure out how to connect this blog site to Twitter so that a post/tweet would appear in twitter.com/voxeo whenever we posted a new article. (If you are not aware of Twitter, my external “The 10 ways I learned to use Twitter in 2007” should give you an overview.) My main reason for wanting to do this was to provide another way for people to stay up on what we post here. For some people, myself included, it’s easier to follow someone on Twitter than even to subscribe to their RSS feeds. So I wanted to make it easy for someone to “follow” the posts we create here on blogs.voxeo.com.

My first instinct was to simply go over to Twitterfeed.com and set up a link between our RSS feed for all posts and our new Twitter account. This undoubtedly would have been the simplest path to go - and one I’d probably recommend for others. There were however, several problems/challenges/concerns:

1. Twitterfeed.com requires the use of OpenID to login, which, as an OpenID advocate, I delight in. However, I wanted to create the feed using a Voxeo-related OpenID versus one of my own, so first I needed to go and turn this blog site into an OpenID provider.

2. My second concern was just that Twitterfeed.com seemed somewhat inefficient in that it has to poll to find out if you had new posts to tweet. There’s naturally the potential time delay from posting… and also just the general inefficiency. We are not posting here all that often and don’t need the feeds checked all that much.

3. My third concern was the issue of introducing yet another site in between this site and Twitter. Given Twitter’s API, it seemed logical that we could connect directly.

4. By the time I got the site set up to provide OpenID, Twitter was experiencing some performance problems last Friday and the Twitterfeed.com site was also offline.

This last issue caused me to decide I had to solve the problem on our own server so that we aren’t dependent on another site.

A Google search brought me to the “Twitter Updater” plugin for WordPress which, on first glance, seemed to provide exactly what I was seeking. I followed the instructions, activated it for one of the blogs, filled in the credentials, posted a test post and……. nothing. No Twitter post. In further reading down the page, it became clear that the developer stopped further work on this plugin and in fact moved her blog from WordPress over to Drupal and so had no real interest in the plugin anymore. I tried a hack by another user, but it, too did not work.

Meanwhile a friend had recommended that I use Alex King’s great “Twitter Tools” plugin. I actually had it installed, but hadn’t really thought about it for purely posting to Twitter. The strength of the Twitter Tools plugin is really about taking your updates from Twitter and posting it to your blog (which the README clearly shows). However, in our case, we’re not going to be (or don’t expect to be, anyway) posting independently to twitter.com/voxeo. It’s just another publishing medium for us - a one-way publish out to the world of Twitter. So we don’t need to publish our tweets here because there won’t be any.

This is, however, the solution I ultimately used. I activated the plugin for one of the blogs on this site, configured it with our Twitter username and password and then changed the settings so that it was only publishing outbound to Twitter.

There was one change I did make to the PHP code. By default, every new blog post appears in your Twitter stream with the prefix “New blog post: “. However, since our Twitter stream is only new blog posts, this prefix is redundant and wastes some of our precious 140 characters! So I modified line 75 and 76 of “twitter-tools.php” from this:

$this->tweet_prefix = 'New blog post';
$this->tweet_format = $this->tweet_prefix.': %s %s';

to this:

$this->tweet_prefix = '';
$this->tweet_format = $this->tweet_prefix.'%s %s';

You can see the result now over on twitter.com/voxeo.

A couple of notes about this implementation:

1. The good news is that this posts to Twitter as soon as we publish an article to a blog. No polling. No waiting. No reliance on a site in the middle (Twitterfeed). Just direct from our site to Twitter via the Twitter API.

2. The good or bad news, depending upon your perspective, is that the plugin needs to be activated separately for each of your WPMU blogs. If you have a lot of WPMU blogs and all you want to do is take all the blog posts and post them to Twitter, you are probably far better off taking the Twitterfeed.com route and simply linking a site-wide RSS feed to a Twitter account. In our case, we don’t have a large number of blogs and while we anticipate adding a few more, we don’t expect to add a huge number. Activating/configuring this plugin is now something I’ll just add to my “provisioning checklist” when rolling out a new blog.

   Note that on the good news side, we do now have a much higher degree of control over precisely which blogs post to the Twitter.com/voxeo account. Because we have to manually configure it, we wind up having the flexibility to not configure certain blogs, so that their postings do not appear in the Twitter.com/voxeo stream. We also have the flexibility to configure a certain blog to post to a different Twitter account. That’s not something I see us doing, but we do now have the option, which we wouldn’t if we simply connected our “all blogs” RSS feed to a Twitter account.

3. Do note that since we are using WordPress MU, after dropping the Twitter Tools plugin code into the “plugins” directory, I did need to go into the Site Admin page for the site and “allow” the use of the plugin for blogs on the site. After that, I could go into each individual blog, activate the plugin and then configure the settings.

4. I have the plugin activated currently in four blogs and all are configured to post to the same Twitter account. Everything seems to be working fine.

So there it is… how I linked our WordPress MU blogs to Twitter to publish notifications to the Twitter account when we post new blog entries. Hopefully some of you out there will find this helpful.

Technorati Tags:
plugins, twitter, wordpress, wordpress mu, wpmu, twitter tools, alex king, twitterfeed

I am a big fan of OpenID for a range of reasons, some of which I articulated here, “Why bloggers should learn about OpenID“, and others I have outlined in my other blogging about identity issues and discussed in a Security Round Table podcast about OpenID (the show notes for this podcast, by the way, provide a very large compilation of links to learn all about OpenID). So an objective I have is to make this blog support OpenID.

There are really two different aspects to “supporting” OpenID. First, a blog, or any other website, can be an OpenID provider in that it can be the source URL used as an “OpenID URL” to login to a site that supports OpenID. Second, a blog can support logins using OpenID.

The first part is the easiest and I’ve done this now using the “OpenID Provider for WordPress MU” plugin. Extremely simple to use. Just download, unzip, and drop the one PHP script and a subdirectory into your “mu-plugins” directory. Ta da. It is activated by default and now you can login to other sites with the URL of your blog (and, naturally, having logged into your own blog with a valid username and password).

How does this work in practice? Well, over on my LiveJournal blog I replied to a comment using OpenID to login. Here’s how the result looked:

You can see the OpenID logo next to my name and then the URL for the main blog site. I chose to login with the OpenID of “http://blogs.voxeo.com/” but could have equally logged in with any of the actual blogs. (As far as WPMU is concerned, the portal page is one of the blogs… we’re just not using it in that way, i.e. there will never be posts to the “blog” that is our portal page.) What I am not showing in a screenshot is the intermediary step where I was presented with a page on my WPMU site where I had to authorize www.livejournal.com to obtain my identity information. I’m just showing the end result.

There are a couple of advantages to this. First, I can now have a work identity that is associated with my employer. Second, from a marketing point-of-view, I’m leaving the URL of my blog there in the comments for the post. Other readers can then click on the link to come back and visit this site. Third, as a user, I didn’t have to re-enter all this information to leave a comment. I just entered my OpenID URL, authorized the requesting site to use my identity and… ta da… there it was.

So that’s the “easy” part of turning your site into an OpenID provider. How about having this site support OpenID for comment logins? Welllll… that’s turning out to be a bit more challenging. In researching the matter, it looks like most folks are using the plugin “WP-OpenID“. I’ve downloaded and installed it, but because we do not have PHP 5 installed, I am experiencing the problems outlined in this support forum post: “Fatal Error / Parse error in Yaris.php when WP-OpenID activated“. I’ve modified the script as noted in the comments but am getting the “implode” error identified at the end by “ericabiz”. Once I either: upgrade to PHP5; wait for the authors to come out with a new rev; or find another solution; I will then write “Part 2″ about OpenID.

Technorati Tags:
wordpress, wordpress mu, wpmu, openid, identity, plugins

When I started the WordPress MU installation, I was very careful to step through the installation process outlined in the README file. I made sure MySQL was working. I made sure PHP was working. I stepped through the installation web page that you get. It seemed like I was doing everything exactly as I was supposed to do.

However, I was getting a completely blank page! Nothing at all. A 0-sized HTML page. And no PHP error logs. Nothing. I was completely and utterly confused and after spending the better part of a day trying to figure this all out was about ready to give up completely on WordPress MU. I posted to forums. I went on the #wmpu IRC channel. I bothered friends…. I believe it was ultimately someone in one of the Skype public groupchats I monitor that helped me out… I communicated with a ton of people that day!

In the end, it turned out to be one little command that was all that was needed:

# yum install php-mysql

You see, I was using a stock Fedora Linux installation and it had both PHP and MySQL installed, but did not have the package that glues them together installed. Oops.

One ‘yum’ command later and everything was working fine. The installation went ahead just as the README file said it should. All was good.

The good news out of all of this was that I learned an incredible amount about PHP and MySQL, both of which I had not really used in any serious way for a few years. I also became very good at doing a WPMU installation! (since I kept blowing away my installation to try it again!)

UPDATE 25 January 2008: In the comments to this post, Garth Roxburgh-Kidd has indicated that the command to do this update on Red Hat Enterprise Linux 4 (RHEL) is this:

# up2date php-mysql

Thanks, Garth!