August Statistics

Yes, more meta-blogging. Hey, at least I’m posting. And it’s been ages since I posted the old browser stats. Here’s the top of the browser breakdown for jclark.org for August:

1.  FireFox                 46.0 %
2.  MSIE                    25.8 %
3.  Unknown                 12.6 %
4.  Safari                   6.7 %
5.  NetNewsWire              2.1 %
6.  Mozilla                  1.8 %
7.  Opera                    1.8 %
8.  Konqueror                1.6 %
9.  Camino                   0.6 %
10. Netscape                 0.3 %

Item 3, Unknown, is largely composed of feed readers. Lots of feed reeders. Yea for Firefox at number one, but 25%+ of you are still using IE? Have you learned nothing?

And now, stealing shamelessly from Effika, here are the top ten searches for August.

                                     #hits
1.  jason clark              2.4 %     62
2.  firefox printing         1.3 %     36
3.  odd/even number rule 
    of star trek movies      1.3 %     35
4.  open source flickr       1.2 %     33
5.  flickr open source       0.9 %     24
6.  perl module version      0.8 %     21
7.  markdown vs textile      0.7 %     19
8.  feed autodiscovery       0.5 %     14
9.  ubuntu mount hard drive  0.5 %     13
10. firefox print            0.5 %     13

Nothing too unexpected here. Not even item 3. Judging by the fact that I haven’t been flooded with email from long-lost friends, I’m guessing item 1 isn’t people looking for me… so who are you looking for?

Odds and Ends

It’s been a busy week, but I’ve managed to find time for a little recreational computing here and there. Here’s the latest on some of my recent entries.

  • My WordPress conversion is largely completed. I still need to get a comments Atom feed set up, and I’d still like to tag some of my pre-conversion posts, but I’m otherwise nearly done.

  • I still haven’t quite gotten tag pages working as I want, but I’ve got it working with redirects, for now.

  • I’m still making little tweaks to Tranquility, the WordPress theme I created for the site, as well as some of the meta parts of the site. I haven’t finished the About or Colophon pages yet, but I did get the Licence page finished, and a number of minor display tweaks made.

  • I replaced my lousy V5 WRT54G with a $30 refurbished V1.1 and a copy of OpenWRT White Russian RC5, which rocks.

  • The one thing I’ve always wanted from my router has been DNS resolution of my DHCP host names; none of the Linksys firmwares across two models of router have done it, and neither did the last version of Sveasoft I tried (the last before the subscription fiasco). Works perfectly with OpenWRT; with a quick edit to the device’s /etc/hosts file, my static IP machines (my server, and the router itsself) also now have DNS-resolvable names.

  • Less than a week after I fixed my page titles, Google has reindexed most of them, so now my search hits have titles again.

  • Technorati is still showing lots of bad links from my test site, which is 410 Gone.

  • I still need to write up my Blosxom to WordPress conversion method, which I promised to do. Hopefully by next weeked.

The Permalink Problem

The conversion from Blosxom to WordPress began (in my head, at least), over a year ago, when I began to consider switching from categories to tags as a way to reduce the “friction” of writing. Blosxom is good at many things, but its filesystem based storage isn’t well suited for tagging. After exploring several possiblilites, I decided I’d move away from Blosxom; eventually I settled on WordPress.

The biggest hurdle I faced was dealing with permalinks. Blosxom supports two styles of permalinks: date-based and category based. I decided to go with category style permalinks (e.g., /weblog/Apple/macbook.html) when I first started using Blosxom because the URIs are “hackable”; you can whack the end (filename) off the URI and you’ve got the URI for the category. This worked fine when the site was category based, but fails with tags. For this reason, I’ve configured WordPress to use date based URIs (e.g., /weblog/2006/01/01/macbook/); I also decided to drop the “.html” bit since its not necessary.

However, Cool URIs Don’t Change. There are plenty of old links to my site out around the Internets, which use category based-permalinks, that I don’t want to break. Even the internal links within existing posts on this site will continue to use the old URIs, at least until I can get around to cleaning them up. I wanted to keep supporting these existing URIs, so I needed to make sure I can support the old permalinks.

WordPress supports category based permalinks, but with some caveats. If I configure the whole site to use category permalinks, then date-based URIs don’t work. If I configure the site to use date-based permalinks, category-based URIs don’t work. After searching for a plugin to help without success, I tried the WordPress forums. When that failed to turn up a solution, I poked around the code looking for a solution.

(A brief aside. If you want to explore the WordPress codebase, I recomment this excellent online cross-reference.)

I ended up creating a simple plugin that uses the “generate_rewrite_rules” action hook to add additional URI rewriting rules to the internal set used by WordPress to resolve each URI. I hope to make it available as a plugin someday when I have time to make it more generic; currently its hardcoded to solve my problem. Here’s the heart of the code, if you want to build your own version:

function add_permalink_style($rewriteobj) {
    $extra_rewrite = $rewriteobj->generate_rewrite_rules('/%category%/%postname%.html', EP_PERMALINK);
    $extra_rewrite = apply_filters('post_rewrite_rules', $extra_rewrite);

    $rewriteobj->rules = array_merge($rewriteobj->rules, $extra_rewrite);
}

add_action('generate_rewrite_rules', 'add_permalink_style');

To help me test everything, I tossed together a quick and dirty test suite, a simple list of links to test from my browser. The code above allows them all to pass.

Because my old permalinks all included .html at the end, I can use the rewrite rule above to strip it out. I originally was doing that with a mod_rewrite rule in my .htaccess file, but that caused problems for old permalinks to my category archives. Since the mod_rewrite rule was stripping the .html suffix before wordpress could see the URI, category URIs (e.g. /weblog/Apple/OSX/) and category-style post permalinks (e.g. /weblog/Apple/OSX/howto-install-carbon-emacs/) matched the same pattern, and WordPress thought the first example was for a post named “OSX” in the Apple category. I believe this is the same thing thats causing my tag URIs (e.g., /weblog/tag/wordpress/) to fail at the moment; the only workaround I’ve found requires a mod_rewrite RewriteRule, but only works with a browser redirect. I’m still working on this problem, as I really don’t want to use redirects. Also, for reasons I haven’t quite figured out, the above makes category permalinks work (and without a category URI prefix, see below), even though the rule expects a post name (slug) with .html appended- but I’m not going to argue with success.

Another issue I ran into was WordPress always wanting a prefix in front of category archive links. For example, my Apple category’s archive link (by default) was /weblog/category/Apple/. Even though my plugin’s extra rewrite rule seems to make URIs like /weblog/Apple/ work, I wanted the catgeory links on my Archive page to omit the extra prefix, for consistancy. WordPress allows you to change, but not omit, this prefix. I came up with a cheap hack for that problem; since I could already handle the URIs without the prefix, I only needed to change the URIs generated on the archive page via WordPress’ wp_list_cats() function. I was able to do this in my plugin by hooking into the list_cats filter:

function fix_category_links($content) {
    $content = str_replace('/category/', '/', $content);
    return $content;
}

add_filter('list_cats', 'fix_category_links');

It’s a hack, but it’s a hack that works.

At this time, I believe all the old permalinks from my Blosxom blog (both posts and categories) should work, as well as the new date-based permalinks. A key part of all of this was to import my existing Blosxom content while preserving the filename (slug in WordPress parlance), I’ll cover this and rest of the import process in a subsequent post. If you should find any links that don’t work, especially from external sources, please let me know. Now if I can just fix those tag URIs….

Converted

Well, I’ve (mostly) finished my converstion to WordPress. If you’re viewing this site in your browser, the theme you’re seeing is called Tranquility, and I created it about 6 months ago, when I first started trying to convert to WordPress. After a 6 month hiatus, it’s nice to finally show it off. Please leave a comment and let me know what you think.

If you’re reading this in your feed reader of choice, then you’ve successfully been redirected from the old rss feed, or the old Atom 0.3 feed, to my shiny new Atom 1.0 feed. Please come have a look at the website as well.

I’ve done my best to ensure that everything’s still here and still working, including old permalinks. I’ll have another post in the near future discussing the issues I had (and some solutions) with my existing permalinks; for now, please let me know by dropping a comment or an email (see the About page for my email info).

I’ve switched from hierarchical categories to tags; this is the first tagged post, but I hope to tag the older posts as well. You can still browse the old categories in the Archives.

I’ll have more to say about the conversion in the near future. For now, it’s late, and I’m done for the night.

Update: First bug- the tag links below don’t seem to be working. Oops.