Birnam Designs Blog -- sharing tips, resources, ideas, and more on web development and design

Wordpress 2.0 was released a couple of weeks ago with much huzzah, and once again the Wordpress team has managed to make their software even simpler and even more powerful to install and use than ever before. I don’t know how they pull it off. It took me, literally, about 25 minutes to learn that 2.0 was released, download the new version, read about the installation, update my old Wordpress installation, and reinstall all of the plugins I was using with 1.5 — all without a single hiccup. I was ecstatic!

A few days after the upgrade, I noticed a problem with my Feedburner statistics. They weren’t coming in anymore. I looked a little closer and realized that a very fundamental change had occurred in the way that Wordpress read URLs.

Background

Up until version 1.5, Wordpress relied on a long chain of mod_rewrite rules to turn pretty search-engine-friendly URLs like this:

http://www.myblog.com/2006/01/11/first-post

to URLs like this, which is what Wordpress actually needed in order to dish out the correct post:

http://www.myblog.com/archives.php?year=2006 &month=01&day=11&post-slug=first-post

It did this all behind-the-scenes, without even redirecting the browser. It just very politely gave you what you were looking for. In theory, this helps search engines find all of your material. In practice, it helps Grandma Josephine type in the URL you’re trying to read over the phone so she can see the picture of her great-grandson puking all over your wife’s foot.

(And that’s just the tip of the iceberg when it comes to mod_rewrite. Which is great, except it can be tricky to use. In the words of Brian Moore, “Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.”)

Then Wordpress 2.0 came out, and things changed. The Wordpress .htaccess file was simplified dramatically. Instead of processing the URL with mod_rewrite, everything was piped to index.php and the URL was deciphered using PHP code. From the end-user’s perspective, nothing has changed. From the Wordpress developer’s perspective, the new version was more powerful, more flexible, and they could control it better. From the blog developer’s perspective, though, this caused a headache or two. For me, the headache was dealing with my Feedburner statistics.

Feedburner

Feedburner, a statistics-gathering service for RSS feeds, sets up a special Feedburner address for users to read your feeds. The downside is that this means that users accessing your local feed URL instead of the Feedburner address won’t be noticed by your statistics. So any subscribers that read your blog feed before you setup your Feedburner account come in under the radar. Can mod_rewrite help? (spoiler alert: yes, it can)

The old way

With Wordpress 1.5, the basic trick was to make a mod_rewrite rule that directed requests for your local feed to the Feedburner address, then setup Feedburner with a different, dummy feed URL, and then setup a new mod_rewrite rule that redirects that dummy URL to the actual local feed. It’s a terrific technique I got from David Seah.

The new way

When Wordpress 2.0 started piping everything into the index.php file, that dummy URL that was given to Feedburner suddenly stopped working and started generating 404 File Not Found errors, because the PHP-based URL parsing didn’t recognize it. But if you gave Feedburner the real feed address, you lose the ability to redirects users visiting that URL to the Feedburner page (unless you happen to like infinite loops on your server).

Unless, of course, you use Conditional rules! Using conditions in mod_rewrite, the server can determine if the viewer is a Feedburner script or a live user. Here’s what the code looks like after added to the standard WP2 .htaccess rules.

# BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /journal/

RewriteCond %{HTTP_REFERER} ^.*FeedBurner.*$ [NC,OR] RewriteCond %{HTTP_USER_AGENT} ^.*FeedBurner.*$ [NC] RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php [L]
RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ http://feeds.feedburner.com/(feedburner account) [L] RewriteRule ^(wp-)?(feed|rdf|rss|rss2|atom)(\.php)?/?$ http://feeds.feedburner.com/(feedburner account) [L]

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php </IfModule> # END WordPress

Of course, you will want to alter where it says “(feedburner account)” with your actual feedburner account.

The way this works is simple. Before your page gets auto-piped to index.php, .htaccess looks for feed readers. In the first block, the conditional rules determine if the user is a Feedburner script using HTTP_USER_AGENT (and HTTP_REFERER for good measure). The NC means “case-insensitive” and the OR is a logical ‘or’ statement to join the conditions. The rule directs a feed request to index.php like normal. The [L] means that if this rule is matched, it is the last rule that should be followed, and mod_rewrite stops processing. NOTE: The Conditional statements will only effect the first rule after the condition.

The second block looks for users. If they are trying to access your feed, these redirect them to your feedburner account. Again the [L] will stop processing if there is a match. Because the conditions in the first block stopped after the first rule, these rules act like an “else” clause.

The rest of the .htaccess file is normal.

Conclusion

Feedburner and your users can look for a feed in the same place! We can read the HTTP_USER_AGENT server variable to look for a Feedburner signature. If that signature is found, the blog will redirect to the standard feed. If not, the user is directed to Feedburner. Simple!

This entry was posted on Wednesday, January 18th, 2006 at 1:04 am and is filed under wordpress, statistics, htaccess / mod_rewrite. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.