Ikiru Design

Over the weekend, I decided to finally install a copy of the WordPress trunk — that’s the currently-being-worked-on version for those not familiar with the term. For need of something to write on that new installation, I noted my first impressions of it. It seems relevant to share as the WordPress team is now soliciting advice about its menu structures.

It worth noting that I did this Saturday. Things have changed since. If you’re interested, popularly relevant information about development is at the WordPress Blog. More abbreviated notes, and up-to-the-day changes are tracked here.

Because some of my impressions make little sense without visuals, I’ve included a gallery of the most notable changes that have so far been made in the progress toward 2.7. (Sidenote: first time I’ve used the gallery in WordPress.)

And now my impressions, as originally noted:

I don’t really like how the new version smashes out the horizontal space. Though I doubt the change is nearly as big as it currently seems to me, it’s undeniable that the compose area fits fewer words per line than did previous (2.6-) versions.

The left side navigation has its pluses and minuses. I like that you can get to any page at all from it, but it’s also there even when you aren’t wanting to go to any page.

I think the term Utilities in the sidebar is misguided. “Manage” seemed to make more sense, and still does.

The built-in browse and install feature for plugins is pretty unquestionably cool.

The built-in upgrade to WordPress itself seemed to have failed on my one and only attempt. (It has since worked for me, the failure may have been a fluke.)

I think the ability to drag anything on the write page the sidebar is good, but it’s not as much customizability as I’d like. Will I ever be able to put a custom field on a post, without having to name that field every time? And be able to put that field right under the title field if I so choose? Until then any changes or not to the Write page will seem rather superficial to me.

There appears to have been few or no changes made to the Themes area thus far.

The dashboard has changed, but right now the utility of the “Inbox” and Quick Post sections, both sitting above the news boxes of 2.5+, are open questions.

Clearly there’s no small amount of work left before 2.7 “ships” in November (by current plans). That said, I’m amazed by all the great features slated for inclusion, and I feel so lucky to blog on such a constantly-improving platform.

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.

If there’s one big problem with WordPress (and blogs in general) it’s that posts come and go very quickly. This is great for people who are embarrassed by what they’re writing, but for the average person this can be a great disappointment.

It also doesn’t help the case that WordPress’s default Archives page is ugly and hard to use. Nor that most free themes that contain an Archives page aren’t much better.

Since you may be a little confused, dear reader, some visuals. The default WordPress archives page (that’s archives.php for those keeping score at home) is pictured at right (click for bigger).

Anyone who’s ever used it will know that they’re taken from the monthly link to pages that simply show all entries from that month in full form (this time we’re talking about archive.php sportsfans). The format and contents of those pages doesn’t concern us now, as it’s a long-standing — even if unwise — tradition that clicking “February 2007” on the blog of anyone mildly prolific is a dangerous idea.

If you look very hard at improving the Archives page in WordPress, you’ll quickly come to understand why they tend to be so sub-par. WordPress’s native function to create archives (wp_get_archives) is frighteningly limited in it’s abilities. I’ll spare you the details, but suffice it to say that nothing it outputs is much better than what we’ve seen.

Since WordPress itself fails, a different application is needed. Having already found Justin Blanton’s Smart Archives plugin — which I used to make my archives at Frozen Toothpaste more presentable — I decided that was a good place to start.

As the Frozen Toothpaste archive shows (see left), the Smart Archive plugin allows you to cleanly display all the your writings from a given month listed chronologically. This, I decided, was the Archives page I wanted my themes to have.

But requiring plugins for a theme to work is fraught with problems. It requires more work than the average WordPress user can or wants to commit to. So however I made my archive, it had to be inside the theme. The easiest way to do that: include the plugin on the page that creates the archives — archives.php.

Though I’m neither a PHP or server-load “pro,” I couldn’t find much of a downside to to putting the code from the plug-in on the page (if you are such a person and can tell me that there is a problem, please do). And, better still, doing so would make the creation of a nice monthly archive as easy as the creation of a default poor one.

So essentially, that’s what I did. I did do a great deal of shrinking and modifying of Mr. Blanton’s plugin, but it meat of it is still intact. Most of my cuts were becuase I required it to do far less than the plugin can. I wanted the code as lean as it could be while still providing the necessary function, which I think it does. To see my archives.php page it in action, just head over to the Ikiru Demo Blog and look at it on any of my themes. (You can also see the Archives page on WordPress’s default theme for comparison.)

And if you’re looking for something even more fancy than the Archives pages provided by Smart Archives (in or outside of) my themes, I’d suggest that the best place to look is Clean Archives which is both flashier and larger than the Smart Archives plug-in. Though these characteristic were detrimental to my need here, they may be exactly what you’re looking for.