Ikiru Design

I think the quip, which I most often see attributed to Thomas Fuller, that “All things are difficult before they are easy” is so clearly borne out by debugging that the truth of it cannot be doubted. You can easily spend minutes, hours, even days bashing your head against a metaphorical wall only to notice that a misplaced colon — which you of course, didn’t realize was misplaced — was the cause of reams of unnecessary pain.

The Problem: Incompatible Rules

During my work on Kaleidoscope, that’s the theme this site is running, I decided that a random post link in the footer would be nice. A quick search yeilded Matt’s Random Redirect Plugin, which was more than up to the job. Without a need to reinvent the wheel, I just borrowed the core functionality of Matt’s plugin function and dropped it into my theme’s functions.php file.

And on my personal test server, it worked well. And when I put it on the Ikiru Demo Blog, there too it worked fine. But I found problems on Ikiru Design. More frustratingly, those problems would sometimes seem to suddenly disappear. (It was only later that I realized that it was whether or not I’d logged in that was the cause of that disparity.)

As you may suspect from what I’ve said so far, Ikiru Design has the WP Super Cache plugin running (though it has rarely needed it). Looking desperately to figure out why my redirect link in the footer worked on the demo blog but not on the main one, I decided to look through their directories.

Solution One: Changing .htaccess

Mercifully, I noticed that the .htaccess files were drastically different sizes. And I remembered that SuperCache depends on your making changes to that file. And indeed, comparing the two showed these lines added to Ikiru’s .htaccess file:

# BEGIN WPSuperCache

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{QUERY_STRING} !.*s=.*
RewriteCond %{HTTP_COOKIE} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

I now understand what this does, but at first I didn’t. It looked like a mash of random characters. But I know enough about programming conventions to guess that an “!” means not. And I also know enough about this modern world to know to Google things I don’t understand. “RewriteRule” seemed a reasonable phrase to start with.

I’ll spare you the full narrative of the search, but I’ll explain what I learned. RewriteCond provides the conditions that determine whether or not a RewriteRule is used by the server. Essentially, if a user trying to access a given file on the server gets through all the conditions in the RewriteCond stack, they’ll be made to follow the RewriteRule.

In this case, that means that if their query string — that’s the ?s or ?p=187 or ?random that tells the server what dynamic features are wanted — doesn’t start with ?s, and if the user doesn’t have a cookie specifying that they’ve either logged in or commented, and if the proper static file has been generated, send them that static file. (You see essentially the same rules there twice, the top one is for if you’re using compression, the other for if you’re not.) This is exactly how Super Cache is advertised to work.

But it means that the server will ignore the query string ?random that Matt’s Random Redirect function relies on. So the user will get, as I was, the cached version of the index page. And they’ll get it before Matt’s plugin has had a chance to well, redirect them.

Having figured that this was what was probably happening, I felt reasonably hopeful that I could finally fix this week-old problem. After all, the random link was working when I was logged in — thus not making me follow the RewriteRule — but it was failing when I wasn’t.

So I added was this line to the RewriteCond stacks:

RewriteCond %{QUERY_STRING} !.*random*

This adds an exclusion, which says that if the url looks something like “http://www.ikirudesign.com/?random”, exclude the user from the RewriteRule. Uploading the modified file and opening the link from every conceivable page I could find showed that it was finally working.

Solution Two: Changing the Function

But this can’t be packaged into a theme. Fortunately, a usable but imperfect solution can be. The basic problem is that redirects break with WP Super Cache. The solution is to do this same thing without a redirect.

Essentially, all this take is simplifying Matt’s Random Redirect Plugin even further. The result was this function:

function sc_safe_random() {
	global $wpdb;
	$query = "SELECT ID FROM $wpdb->posts WHERE post_type = 'post' AND post_password = '' AND post_status = 'publish' ORDER BY RAND() LIMIT 1";
	$random_id = $wpdb->get_var( $query );
	return get_permalink($random_id);
}

This is essentially the first three lines of Matt’s function — which picks a random post from among those eligible on your blog — and adds a line that just tells it to pass the permalink for that post to the place where the function is called. Then you simply call the function for your random link, like:

<a href="<?php echo sc_safe_random() ?>">a random post</a>

This solution works, but it’s got a problem. If I were to click the redirect version into five new tabs from a single page, I’d receive five tabs each with a different random post in it. If I do the same with this version, I get the same post each time.

The likelihood of someone doing this is obviously questionable, but it’s a feature that I’d rather not lose. For that reason, I’m planning on making sure that I allow a user who doesn’t have WP Super Cache enabled, or who have implemented Solution One, to use the redirect version. Those who have Super Cache enabled, or who don’t mind the limitations of this second solution, would be able to continue to use it.

I recently redesigned my non-design blog, Frozen Toothpaste, and did it with a variation of the BWO_one theme. At first I was very hesitant to go with a BWO_one variant because it meant that I’d lose the sidebar which the theme I had been using, Chris Pearson’s Copyblogger had had. It was some of the arguments that I’ll present here that convinced me that that would be OK.

Now, I should be clear that this is not an argument that no blog (or other website) should have a sidebar. I think they’re incredibly useful in a lot of cases. When I surf the blogosphere, I tend to favor the sidebar as a way to get around.

But the sidebar’s usefulness gives way to one of it’s biggest flaws: the clutter problem. Bloggers — who tend to be novice designers — tend to dump anything and everything into the sidebar. Most people probably have seen this problem before, but if you doubt me go spend a little time looking though blogspot.com or wordpress.com, you’ll notice what I’m talking about.

The problem starts benignly when a new blogger will say: “I want a little note to be easily visible,” and they’ll dump it into the sidebar. They’ll say “I want a RSS subscription button (or perhaps one for every feedreader known to man)” and that’ll go in the sidebar. They’ll create multiple blogrolls, and then a few images and maybe some links to their own content. And they’ll ad a last.fm widget, and a flickr widget, and a translations widget, and the “awards” they got from other bloggers. And it’ll all go into the sidebar. By the time they’re done no one wants to see, let alone click on the cluttered mess that resides where a simple sidebar used to.

I’ll readily admit that this story is a slight exaggeration. Many sidebars are manageable while they contain all the desired content. But that doesn’t change the fact that sidebars have latent tendency to become ugly and unmanaged clutter magnets.

Another strong argument for banishing the sidebar is that, especially but no exclusively when weighted down with moving widgets, they’re a hideous distraction from your writing. This may not be a concern for some bloggers, but I’d bet that the vast majority of people who blog do it as a way to practice, polish, and improve their writing. You want readers to look at and comment on what you’re writing, not be whisked off to yet another blog.

It not that a sidebar is an unavoidably bad, or that it shouldn’t be used. The issue is primarily that one must consider if they really need a sidebar. If you don’t it’s far better to use a design without a sidebar than to persist in having one that offers no function you desire.

There are risks in eliminating it certainly. But for every visitor that’ll be turned off by your lack of a sidebar, at least one more will be interested enough to try to see why you’ve eliminated it. It’s not that ever site should either have or not have have one, but every person designing for blogs should think about their merits and problems before making more of them.