kevin_i_orourke

It’s not the front page that needs to be static. By the way, the Codex information about Creating a Static Front Pages declares itself to be obsolete.

I can’t use WordPress because for Pages to work I need to let WP rewrite my .htaccess, which in the past has messed up other parts of the site. Also, for security reasons I don’t want the web server process having write access to configuration files.

The page for the Static Page eXtended plugin gives a 404.

If you look in the source code for wp-include/classes.php at line 864 it has:
var $use_verbose_rules = false;

If you change the line to:
var $use_verbose_rules = true;

You get the old-style more specific rewrite rules. I’ve tried this on my site and it works, it may cause problems with plugins (such as Owen Winkler’s EzStatic) that depend on the less-specific rules but you can manually write rewrite rules to get around that.

I think the problem is that the ErrorDocument handler in .htaccess isn’t getting the chance to do anything because WordPress handles the problem.

Because WordPress is handling it Apache is not aware that there was a 404 error.

The root cause is that WordPress’s permalink lines in .htaccess are accepting too much, they should be more specific.

I’ve been having the same problem.

I already have ErrorDocument 404 /404.phtml in my root .htaccess, I prefer error pages to not be handled by WordPress.

I’m assuming I can revert to my old .htaccess setup, that only redirected specific bits of the site into WordPress? Specifically, anything that doesn’t begin with “/archives” is none of WordPress’s business.

Somebody else is having the same problem.