Note: I found an even better solution. Please see my comment below.
Ever since upgrading this blog from WordPress 1.5 to 2.0, files inside a password protected directory no longer works. Any attempt to load file in the directory will be redirected to WordPress and get a 404 error. After some research and debugging, I find the rewrite section WordPress put in my main .htaccess file is causing the problem. The rules reads like this:
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
What it does is check to see if the requested filename is a regular file or a real directory. If it’s neither of the two then redirect to /index.php, which is WordPress entry.
Supposedly, any existing directory or file in it will fail the test. So Apache will load the file/directory instead of WordPress index.php. However, the fact that the requested directory is password protected with its own per-directory .htaccess file seems to cause Apache to think it’s not really a directory/file, thus satisfying the 2 tests and invoke WordPress index.php.
I tried to change my main .htaccess file to fix that. But couldn’t. And I am not alone. I find many people with similar problem in WordPress support forum. For example: WP 2.0 - htaccess overly aggressive? 404’s galore
Now I finally deviced a fix to it and it’s to change the index.php file WordPress is using. Since my WordPress install is inside a subdirectory in my web root, I have a copy of the index.php in my root directory while loads WordPress files from the subdirectory. So changing it is fine for updating WordPress won’t overwrite it.
Here’s the fix:
<?php
/* Short and sweet */
$request_filename = $_SERVER['DOCUMENT_ROOT'].$_SERVER['REQUEST_URI'];
$this_dir = dirname(__FILE__).’/';
if($request_filename!=$this_dir && $request_filename!=__FILE__ && (is_file($request_filename) || is_dir($request_filename))) {
// we are not supposed be here!
die;
}
// load WordPress in /wp
define(’WP_USE_THEMES’, true);
require(’./wp/wp-blog-header.php’);
?>
What it does is first make sure the request is not for the home directory or index.php itself. We want WordPress to handle these, right?
Then it tests if the request is a regular file or a real directory. And die if that’s the case. Basically we are doing what the two RewriteCond lines in .htaccess supposed to do. Magically, this works!
Now, my password protected directory correctly asks for password instead of showing WordPress 404 error page. All WordPress permalinks work. All non-protected directories work. Direct URLs to my Gallery2 work. It all works. That’s a rare thing to say about anything I did. Really! Just ask my wife about the house… Err, wait. No, don’t do that.
I don’t know if this would work with other setup, like WordPress is installed right in the web root. But I guess it should. So if you have the same problem, give it a try and let me know if it helps. Good luck.
Found a even better solution at Textpattern:
http://textpattern.com/faq/173/password-protected-directories-with-htaccess
Basically, the problems is partly caused by incomplete error document set up. Specifying error documents in .htaccess file fixed my problem. But the hack in the original post might still be of use in other situations.
So scrap the above exercise. Or just pick your poison.