WordPress 2.5.1 added a really powerful feature to register_taxonomy(): automatic registration of permalinks and query vars to match the taxonomy. Well, theoretically it added that feature. It wasn’t working in practice. After some searching yesterday and today, I finally found the bug and worked up a fix. I made a diff and set off to open a ticket in Trac.

On the one hand I’m glad I searched first, because it turns out that a ticket on the very same issue was opened on May 16th and it already has a fix. On the other hand, it’s kind of a kicker to have lost my chance at reporting the bug and submitting a fix by only a few days.

The fix is committed for WordPress 2.6, but I’ve done a workaround for 2.5.1 (workarounds are easier to manage than core code changes). I’d say I wish I searched Trac first, but I wouldn’t have known what to search for if I didn’t figure out how to fix the bug first. And I guess I really can’t complain about a community that quickly finds and fixes bugs.

After reporting weirdness last week I finally sat down with a completely clean and virgin install of WordPress 2.3.2 and traced what happens when you make a permalink request for a non-existent URL.

Here are two sets of URLs to use as examples and context:

• These are valid URLs:
  • http://site.org/archives/101
  • http://site.org/page-name
• These are _not_ valid URLs:
  • http://site.org/archivezorz/101
  • http://site.org/favicon.ico

Valid URLs get parsed, the expected MySQL queries get executed, and the results are processed and returned to the browser. Normal. The problem is that invalid URLs that get sent through WordPress still result in a query like the following being executed on the database. What?

SELECT SQL_CALC_FOUND_ROWS  test_posts.* FROM test_posts  WHERE 1=1  AND post_type = 'post' AND (post_status = 'pub
lish' OR post_status = 'private')  ORDER BY post_date DESC LIMIT 0, 10

That is, even after a URL is sent through WP->parse_request() and found to be invalid/404, WordPress marches on to WP->query_posts() and hits the database with a generic request for the X most recent posts. And because this is executed for every 404, it actually results in a lot of database activity.

In most cases MySQL has cached the result, and so it poses a minimal load on the server. And even if the cache is stale, for most sites it’s not a particularly resource intensive query.

But, if you’ve got 350,000 rows in the posts table, it’s incredibly resource intensive to order all those posts on the post_date (datetime) column. I’ve seen hundreds of them pile up and take forever to complete after writes to the table. It’s sufferable if write activity on the posts table is very low, but that’s not something I want to hope for.

So my question to the wp-hackers community is: Do we actually want to execute that query for every 404 under normal circumstances? If not, is the following (or something like it) the stupidest solution?

In wp-includes/classes.php:

	function query_posts() {
		global $wp_the_query;
		$this->build_query_string();
 
		// return if the request URI is a 404
		if( $this->did_permalink && $this->query_vars['error'] == '404' )
			return;
 
		$wp_the_query->query($this->query_vars);
	}

The above works, but there’s probably a better way to write it.

I made a mistake in changing my WordPress permalinks, but by the time I’d discovered it my blog had already been indexed. Fixing the permalinks meant breaking those indexed URLs, leading to a bad user experience, but leaving them as is wasn’t really an option.

Last night, after getting 404′d while using Google to search my own blog, I realized I had to do something.

First I looked at Apache mod_rewrite and the URL rewriting guide (as well as this cheat sheet from ilovejackdaniels), Then, frustrated, I found some items in the WordPress Codex, including this one about conflicts between .htaccess files/rules and this about problems with subdirectories inside the WordPress root.

The suggestions in both boil down to creating a specific error document:

Create a file on your website. Call it onerror.html. It can be empty or have just <html></html> in it for all that it matters.

In Wordpress’s .htaccess file, add this to the top of the file:
ErrorDocument 401 /path/to/onerror.html
ErrorDocument 403 /path/to/onerror.html

The explanation, though even the poster doesn’t claim to know that it’s the correct explanation, is that the rules are additive, and WordPress is greedy with trying to get requests directed to its own URL parsing routines. The ErrorDocument is supposed to keep more of the processing in mod_rewrite.

But after all that, and only limited success achieving what I wanted, I realized that what I really wanted was not to parse requests before WordPress had a chance at them (as would happen with rewrite rules), but to handle requests that WordPress’ internal rules couldn’t match.

What I ended up doing is writing a tiny plugin that hooked into the template_redirect hook. The short of it is that if WordPress thinks it’s 404′d, and I can divine some meaning from the requested URL, then I redirect to browser (including a HTTP/1.1 301 Moved Permanently statement). Voila, it works.

wordpress, rewrite, mod_rewrite, rewrite rules, apache rewrite, permalinks, redirect, 404