Upgrading WordPress and wp-recaptcha to their latest versions (3.3.1 and 3.1.4 respectively) seems to have solved the problem.

I try to blog as much as I can, not because I think that each post is a piece of poetry that needs to be enjoyed by as many as possible, but because each post represents a train of thought that I need to get rid of. The sooner, the better. Noise is not a problem. The Internet is filled with noise, but nevertheless we only read what we want to read and we still find what we need. We filter. If you don’t, good luck surviving the digital age.

There is a convergence movement towards media integration. Eventually, this will lead to the collapse of all these media, meaning that the need for distinct, specific media will be less and less. This is good. We need to be truly press-less before the original promise of the press can be fulfilled: information liberation.

What I mean by this is that, when we publish, we don’t need to make a clear distinction between the weighty and the weightless. After all, God Google defines the weight of our publications not by means of what we say about it, but by means of incoming link frequency and the relative weight of these links.

When I say something worthwhile, I first have to convince others that I did, but before I can do that, I have to convince them to come look. Then, after visiting me and having been convinced by my great content, they might decide to link to me. Only as soon as that happens, do I gain weight. (According to Technorati, the weight of this blog is pathetic.)

Not every post I write resembles even an essay. Most postst don’t even come close. That’s because blog posts don’t need a point. I’ve made this point before, but I can’t repeat it often enough, because every time that I’m thinking “Shit, what did I do then and what was I thinking?” I’m reminded of it. I’ll stop reiterating this no sooner than I stop forgetting to write these things down.

When a blog post does attempt to make a point, there are even stronger arguments for quantity over quality, because publishing—really publishing—something makes it possible for others to respond, be this in comments or in their own blog. There’s something concrete for them to cite and to reference. This process gives me valuable feedback and I can simply republish my thoughts (which have matured not only through time, but also through argument) in a new post. Voila! And maybe the old post is so shitty that nobody is interested… Who cares?! Obviously, they don’t! So go on and do something else with the time that you’ve freed by not having to polish a turd.

Remember that blog posts are not naturally organized into some sort of reading hierarchy. There’s no reason that the same subject can’t be treated twice. Just hit that “Publish” button, get it out of your head and get on with your life!

Fireworks reflect off the waters of Pickering Wharf in Salem, MA while the Friendship takes it all in. Photograph by Flickr user snowriderguy.

I just published the 100th post here on blog.bigsmoke.us. Who would have thought that when I published my first post?

(Actually, that first post, although the first post to have been published through this blog, is no longer chronologically the first, not since I started backposting my older regular website content on this blog.)

Hopefully, the 1000th post will be a bit sooner than the 100th post; I still keep stumbling upon issues that I wish I had blogged about so that I don’t have to solve them twice. Also, there’s a lot of content that got stuck in the feeling of formality that was induced by having to give it a permanent place on a static website. That feeling made me want to elaborate beyond what was actually in my head at any given moment. This blog induces less and less of such inhibitions, which in turn generated more and more content.

Most of the time I still don’t think about blogging my thoughts because I associate writing with making a point and supporting that point well. That association is a mistake. Instead, I would like to cultivate the following reasons to blog:

1. Writing is fun because sharing is fun.
2. Writing is fun because reiterating an experience is liberating.
3. Redoing my research and problem-solving is not fun.
4. Receiving comments to your writing is fun.
5. The very act of writing down an unsolved problem often reveals the solution.
6. If it doesn’t, some visitor will.
7. Often a problem is really not a problem at all. Trying to formulate such a problem will make this painfully obvious.

Blog posts don’t need a point, blogging is the point.

Dan Peverill’s GeSHI plugin sucks for two reasons:

1. It’s no longer being maintained. It doesn’t even seem to justify a page on Dan’s website anymore (for which reason I’m not going to give him any link-juice).
2. It breaks HTML. With the plugin enabled I can no longer use the <code> tag to mark in-line elements as being code. Frankly, this is annoying and I find myself typing <tt> often when I mean <code>.

A search for WordPress plugins tagged GeSHi reveals a number of results: Sniplets, CodeColorer, Developer Formatter, and WP-SynHighlight. WP-Syntax is a plugin that is missing from the tag search.

Sniplets seems much too generic to my taste. I just want a GeSHi highlighter, period.

CodeColorer says it does what I want, but if I ever want to use the TinyMCE editor again, I won’t be able to with this plugin. Shouldn’t be too much of a problem, but still…

Developer Formatter is very thoroughly written and even sports a TinyMCE plug-in for copying/pasting the code. It is pretty big, though, and, as a rule, I tend to avoid plug-ins that complicate the database schema. I also don’t really see how these extra tables are an advantage feature-wise.

WP-SynHighlight uses a custom BBCode-style tag, [codesyntax] I like this (if you’re going to use pointy brackets, at least keep out of the HTML namespace), though I don’t like the attempt at a generic name; what’s wrong with calling the tag [geshi]? Seriously… I’m sure I’m going to forget this name billions of times if I’ll use this plug-in.

WP-Syntax uses the <pre> tag with a few custom attributes. This at least is better than the officially inline <code> tag that my current plugin uses, because most of the time that I’d use a <pre> tag I really do want syntax highlighting. Just wondering: will it also allow my to use it normally for that other rare occasion? Sadly, the plugin will doubtlessly wreak havoc with the visual (TinyMCE) editor.

So, which plugin will I choose? I am somehow inclined to want a plugin that can play nice with the visual editor because I keep telling myself how much nicer it would be to switch to the visual editor for all my posting. (That this will be difficult because I disabled WP’s ‘wpautop‘ filter to rid myself of its eagerness is a story for some later time.) This requirement rules out CodeColorer and WP-Syntax.

That leaves Developer Formatter and WP-SynHighlight. Both seem to fit my purpose. Developer Formatter sports a nice TinyMCE plugin for inserting code, but I don’t think that switching to TinyMCE will suddenly and unexpectedly make me afraid of typing. Besides, I really don’t want the extra tables in my database without a very good reason, so, for now, I will try WP-SynHighlight.

If, in the pre-2.6 days, you wanted to fetch your WordPress updates through SVN, the docs would advice you to do an svn checkout from the official WP SVN repo in your working dir and then do an svn update whenever you want to update WordPress. This works because svn update leaves local modifcations alone. However, this means that you’ll be unable to commit your local changes (configuration, themes, plugins, etc.) if you choose this route.

I used my own subversion repository for my blogs and thus had to upgrade the old fashioned way with each release (although I prefer diff/patch over rm/cp). (I could have used vendor branches, but, clearly, I hadn’t thought about that at the time.) This was pretty much a royal pain in the ass, so I was glad when I could move WordPress into a separate directory with its 2.6 release.

This process consisted of removing everything except wp-content/, wp-config.php, .htaccess. (I also kept robots.txt, favicon.ico and some other personal files.) Then, I added the current WordPress release as an svn:external.

svn propset svn:externals 'wp-factory http://svn.automattic.com/wordpress/tags/2.6.1' .

.htaccess changes

In the WordPress codex, it is then suggested to copy index.php to the root dir and to change it to require wp-factory/wp-blog-header.php instead of ./wp-blog-header.php. I preferred adding some mod_rewrite voodoo of my own to .htaccess, so I did:

<IfModule mod_rewrite.c>
# This way I don't need directory indices
RewriteRule ^$ /wp-factory/index.php [L]
 
# This way WordPress can manage its own block without doing any harm
RewriteRule ^index.php /wp-factory/index.php [L]
 
# Allow easier access to /wp-factory/wp-admin/
RewriteRule ^wp-admin http://%{HTTP_HOST}/wp-factory/wp-admin/ [L,R=301]
</IfModule>

The middle rule performs most of the magic. It redirects all the requests to /index.php to the factory default index.php. This means that I can let WordPress pretend that index.php does live in the root, so I don’t have to modify the rewrite rules that are managed by WordPress itself:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress 

wp-config.php changes

In Giving WordPress Its Own Directory in the WordPress Codex, it is suggested to change the “siteurl” and “home” options through the administration panel. In my case they would have to be changed to “http://blog.bigsmoke.us/wp-factory/” and http://blog.bigsmoke.us“. I couldn’t do this because I override these with WP_SITEURL and WP_HOME in my wp-config.php. This is because I configured WordPress to support a development environment separate from the live production environment.

Ignoring the customizations for my development environment, these are the relevant settings in wp-config.php:

define('WP_HOME', 'http://blog.bigsmoke.us');
define('WP_SITEURL', WP_HOME . '/wp-factory');
 
define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
define('WP_CONTENT_URL', WP_HOME . '/wp-content');

BTW: I really like it how WordPress disables the form controls for siteurl and home when you override these settings in wp-config.php. Kudos for that, devs!

Next time: git

In the end, this is all quite a bit of pain to compensate for what is essentially a version management problem. That’s why, on my newer projects, I’m now using git which makes forking and tracking an upstream repo absolutely trivial.

A few references

• Editing wp-config.php in the WordPress Codex
• Giving WordPress its Own Directory While Leaving Your Blog in the Root Directory in the WordPress Codex
• Vendor branches in the Subversion Redbook

I think one of the advantages of a blog is that it’s quite clear what gets published when. You can add this information to the pages of a good old fashioned static website, but it’s just not quite the same. One of the reasons is that, on my blog, my guideline is that posts are not edited anymore after hitting the “Publish” button.

Why blog posts shouldn’t change what they say

Once a post is published, it can be commented on below the post or from within elsewhere on the world wide web. If, after publication, a post changes significantly, it becomes very unclear what is being cited / commented on. Of course, simple formatting changes or grammar/spelling corrections are not considered significant changes, but changing the meaning of what is being said is.

(Because blog posts are so temporal it is habitual that if you do have to commit corrections which change the meaning of the text, you notify the readers of your post of this by adding an Update notification at the top or the bottom of your post. Examples of this are abound on the web. Here’s one example.)

Vertical navigation

Ever since the first time that I saw a blog which featured vertical navigation instead of the typical columns, I’ve wanted to implement this for myself. Well, finally…

Site-wide elements use the complete width of the page. The page content is centered in the middle at 87.5%. The identity stuff in the header and the navigation in the footer sits against a back blackground while the content area has the proven black on white for easy reading. I hope that the strong color-contrast as well as the clear difference in with between site-wide elements and page content makes it easy to keep focused on either reading or navigating without distractions.

… and a talkative footer

With this theme, I didn’t want another footer which consist of the odd logo and some loose copyright statements. I wanted a footer which you can actually read, even understand. And who cares if it takes up a little space? It’s at the bottom of the page.

Related posts

I’ve written an (unpublished, unpolished) plug-in which can generate a list of posts that are chronologically related. Traditionally, most blogs have a next/previous post link at the top and bottom of each post. This works very well if you limit your blog to one subject (which is really a very good idea anyway), but if, like mine, your blog is a little bit messy, you could say that someone who stumbled here searching for an article about Subversion is not necessarily interested in the next post if this is a photo of my baby niece.

Hence the chronologically related posts plugin. With this plugin I can say wether I want a link to the first, previous and next post in the blog, within the same category, or matching a given number of tags. (The tag matching isn’t implemented yet, though. Also, matching on meta fields would be a kick-ass ass way to support explicit sequences.)

I put the list generated by this plug-in on top of a blue background besides the various context links of the post.

Issues left

I hope to have the first major revision of my theme ready soon. Here’s a list of some issues that I might address:

• The CSS renders a bit psychedelically in MSIE 6 (only version I tested) at the moment. Sigh… Let’s just hope that IE 7 will give better results. Then I’ll gladly drop the IE 6 support.
• When viewing a category, the tag cloud in the navigation panel at the bottom only shows tags for that category. This has to do with the use with me calling the st_tag_cloud() from within the category template.
• Some of the elements that I just showed to you don’t really look that good and most elements that I didn’t can be said to be … hideously ugly. Some highlights: the header (should really be a few cool images), the comment form, and the Next/Previous Page links.

Comment!

I’d almost forget all about the clean, new look of the comment list. And, if you register a Gravatar, your comments will be accompanied by your avatar. Try it. Please!

How cool is it then that I can just Control+K to my Google search box and enter: bypassing smart completion to get my own page on the top of the result list?

Since my blog is literally a log that I mostly use to keep track of what I think and do while problem-solving, it’s great that I can rely on Google to find my way through memory lane.

Importing the tags from Ultimate Tag Warrior worked fine. Before upgrading and importing, I quickly patched my local version of WP with a little help from Subversion:

$ svn diff http://svn.automattic.com/wordpress/tags/2.1/ http://svn.automattic.com/wordpress/tags/2.3.1/ > wp.diff
$ cd blog.bigsmoke.us
$ patch --remove-empty-files -p0 < ../wp.diff
$ svn revert wp-config.php
$ svn add `svn status|grep '^?'|sed -e 's/\?//'`
$ svn rm `svn status|grep '^!'|sed -e 's/!//'`

Then, after a few changes to my template files to play nice with WP’s new built-in tagging system, everything was running again.