rewrite rules

How WordPress Taxonomy Query URLs Could Be More Awesomer

(Updated, see below) WordPress 3.1 introduced some awesome new taxonomy query features, and the URL parsing allows some rudimentary syntax to query multiple terms and choose if the query is OR’d or AND’d. The URL syntax is as follows: A comma (,) between terms will return posts containing either term (logical OR), like this,mysql/ . A […] » about 300 words

WordPress, Permalinks, Mod_Rewrite, and Avoiding 404s

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 […] » about 400 words

Where’d All My Rewrite Rules Go?

Between WordPress 1.x and 2.x there was a big change to the way rewrite rules are handled.

In the old days, everything got written out to a <a href="">.htaccess</a> file. Every condition, every form of permalink could be found there, and I had some comfort knowing I could see and mess with it all. I was a bit surprised to find that with 2.0.2, WP writes out a sparse file that has only one significant rule. Something that looks like this:

RewriteRule . /blog/index.php [L]

That one line takes everything in your request URL and passes it through to index.php for processing. The beauty of this is that WP doesn’t need to write to the file system with every change to the permalink structure (which used to include every new “page” added or renamed).

The only downside to this is that you can no longer expect a $_REQUEST array full of all the query terms your plugin might use. Instead you’ll have to use the <a href="">$wp_query</a> object. All of this was probably mentioned in the API docs before I built a bunch of dependancies on $_REQUEST, but it was easy enough to fix.