Mike Lee

Thanks! If at all possible, I would love to see this in the next release 😉

In any case, I’ll mark this topic as resolved.

FYI, here is a simple change that does offer this functionality, though I really don’t want to be modifying this plugin’s code since it will cause update problems. But in case someone else has this problem, or the plugin author is reading this and is interested in suggestions, here is an option:

In file top-10.php, line 408, change it from:

$p_in_c = (in_array($cat->cat_ID, $exclude_categories)) ? true : false;

to:

$p_in_c = (in_array($cat->cat_ID, $exclude_categories) || in_array($cat->parent, $exclude_categories)) ? true : false;

Ah, thanks for the info, phord.

So the prevailing assumption is that this may be caused by a particular Apache configuration set by my host, which is not playing nice with my WordPress installation. I’ll send a note to my hosting provider to see if they have any insights.

Interesting. I wonder what it is that my host has doing that’s different than your host.

So I compared the response headers from my server to your server, and here’s what I found:

Mine:
404 OK

Yours:
404 Not Found

Another user just posted this thread a few hours ago with the same issue. I looked at his response headers and saw this:
404 OK

To do one more comparison, I went to http://wordpress.org/404 to throw a 404 error on this machine. Also received a:
404 Not Found

I see a bit of a pattern here. Seems that my server isn’t throwing a correct 404 header. That would explain why an ErrorDocument 404 isn’t working.

And furthermore, this is only the case when I have these rules in my .htaccess file:

RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php


When I remove these rules, my 404 header works as it should.

So why are these rules causing my 404 header to foul up? Hmmm…

Steps I’ve Taken So Far

1. First, I read all of the documentation on Creating an Error 404 Page and Using Permalinks, trying all of their suggestions. None of them worked for me.
2. Next, I took a look at my .htaccess file. It’s CHMOD access was 666 (which is correct, and what an omen, huh?). The contents of it were:

   
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php
</IfModule>
# END WordPress
ErrorDocument 404 /404.html


   This is what WordPress created for the custom permalinks, and it appears to be working as it should – except for the last line. The last line should be displaying the custom 404.php file. And for some reason, it wasn’t.

3. Next, I verified that my hosting provider has the Apache module mod_rewrite installed. They do.
4. Next, I read all of the above forum threads and even tried a search on Yahoo and Google. The thread WP 2.0 messed up my permalinks held some promise. One of our members, Ryan, posted some fixes to the functions-post.php and classes.php files. I promptly downloaded & installed them. Unfortunately, they didn’t resolve the bug.
5. Then I turned off my custom permalinks and found my custom 404 page working as it should. However, when I tried to point my 404 page to the custom one in my theme (using: ErrorDocument 404 /index.php?error=404 in my .htaccess file), I received the same error again. Hmmm.
6. Then I decided to dig into the .htaccess file some more, to understand exactly what it was doing. I read up on this Apache module mod_rewrite documentation. And here is what I understand to be going on:

   This turns on the mod_rewrite runtime engine:
   RewriteEngine On

   This sets the base URL for rewrites to my document root URL (for you, it could be different):
   RewriteBase /

   This sets a condition to detect whether or not the URL to your blog is a valid filename. If it’s NOT, then it returns true:
   RewriteCond %{REQUEST_FILENAME} !-f

   This sets a condition to detect whether or not the URL to your blog is a valid directory. If it’s NOT, then it returns true:
   RewriteCond %{REQUEST_FILENAME} !-d

   If both conditions are true (meaning if the URL to your blog is not an existing filename or directory, then go to your root index.php file:
   RewriteRule . /index.php

   Ah ha. That seems to be something. So essentially, these rewrite conditions are hijacking the errorDocument statement and pushing every request through index.php. That explains why my system has been seemingly ignoring my errorDocument statement.

7. Then I typed in this explicitly: blog_domain_name.com/index.php?error=404, since that’s what this documentation suggests. Instead of seeing my custom 404 page, I get my blog’s homepage. Ah. Now I think I’m getting closer to the problem. The issue seems to be in how WordPress handles the error querystring parameter.
8. Now I’m going to dig into WordPress’ code to find out exactly what it does with the error parameter. It seems to me that blog_domain_name.com/index.php?error=404 should work, and for some reason, it isn’t. Give me a few days to look into this. If I find any answers, I’ll post them right away. If you have any comments, please post them to this thread! Thanks!

My System’s Set-up:

FreeBSD 5.4
Apache 1.3.34
PHP 4.4.2
WordPress 2.0

Next, I’ll point to several related threads in this forum.