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

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

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 found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.