WordPress Hijacks non-wp mod_rewrite rules

Hi there

I hope someone can help confirm this is a major bug in WP2.0.

It appears as soon as you include the wp-blog-header.php file into any non-Wordpress file, WordPress will hijack the mod_rewrite rules and cause the non-Wordpress rules to be completely ignored.

Let me demonstrate.

I’ve got a calendar on my site which is simply a php (calendar.php) file that simply includes the appropriate static html file depending on the year and month passed to it.

In it’s simplest form, the code looks as follows:


<?php
require_once('../blog/wp-blog-header.php');
get_header();
include "$_GET[y]-$_GET[m].html";
get_footer();
?>

(The actual file has more error checking etc in it).

I’ve included require_once('../blog/wp-blog-header.php'); so that I can use the get_header() and get_footer() functions to ensure a uniform look.

Now calling https://www.example.com/cal-data/calendar.php?m=3&y=2006 will cause the 2006-3.html file to be included in the output. This works a treat.

Now to keep things uniform, I’ve add a mod_rewrite rule manually to my .htaccess file as follows:


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^calendar/?([0-9]{4})?/?([0-9]+)?/?$ /cal-data/calendar.php?m=$2&y=$1 [QSA,L]
</IfModule>

(The RewriteRule line is one line in my file).

I added the rewrite rule to the top of my .htaccess file above the WordPress section.

Now at face value, everything should work based on the fact the .htaccess is read from top to bottom, with each rule being matched one at a time, thus my rule should be found before any of the WordPress rules. This is exactly how it worked in WP 1.5.2.

In practice, when viewing the page in Firefox, it appears there are no problems, that is until you view the HTTP headers (using the Live HTTP Headers plugin). It becomes very clear that a 404 status code is sent. IE/wget/curl just barf at the first hurdle and stop at the 404 error.

This shouldn’t be happening. The .htaccess file is read top to bottom and each rule is read one at a time until a match is found. As my calendar rule is the first in the file, it should be found and as I’ve got “L” flag set, processing should stop there and the rest of the file ignored.

However, after a bit of testing, I discovered that merely including the require_once('../blog/wp-blog-header.php'); line in my file causes the 404 errors to occur. I don’t even have to call any WordPress functions. If I don’t attempt to integrate my calendar into WordPress using this method, then I no longer get the 404 error.

This looks like a major bug to me as it stops people from “embedding” their own pages with their own rewrite rules into WP without actually creating a plugin.

As I said before, this all used to work without any problems in WP 1.5.2