not yours

because I say so

Previous Entry Share Next Entry
Putting the Headache Trauma in HTaccess
WordPress is really starting to get on my tits. For the past week and a bit I've been trying to battle a problem whereby WordPress intercepts requests for a URI - say, /music/ - and returns a 404, instead of avoiding it entirely and letting Apache serve the enclosed index.php.

Accessing /forums/ returns /forums/index.php no problem.

I thought the problem might have been caused by the fact that the /music/ URI was used as a stub for a WordPress-created page in the past, even though I'd since deleted it. So I renamed the now real directory to /musiczzz/: no change.

I followed someone's advice to stick the all-encompassing WordPress directives at the end of .htaccess, not the start: no change.

I can't wrap my head around the .htaccess directives, despite the fact they don't deviate from the supposedly docile default, but still they seem to be hijacking Apache to distraction.

I'll upgrade to version 2.1 of WordPress, but I don't think that'll make any difference either.


  • 1
Oh god, I had the same issue. I figured I'd just fucked up my install of 1.*, but it was really annoying, and I never figured out how to make it work within 1.*. I deleted it all a couple of weeks ago, made a new subdir, put WP 2.0.7 in, and finally my 404s/403s/500s are behaving again. At least in terms of WP staying corralled in the /wp/ directory and children, not the damned parents.

Is that .htaccess in /music/?
What's in it? (sanitize as necessary)
Is there one in / too? (well, in the docroot of your virtual server)
Does either/any have an Options -Inherit? (IIRC)
Any URL rewriting going on?
Which version of Apache (and any applicable modules) are you running?

Yes, and I think that's the one causing the problem - current code at http://sh.nu/p/8642.
Lots, most of it handled by the default code at the end.
Server: Apache/1.3.37 (Unix) mod_fastcgi/2.4.2 mod_gzip/ mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/ mod_ssl/2.8.28 OpenSSL/0.9.7a PHP-CGI/0.1b

The rewrite directives at the top are rewriting /music/ into /index.php?.... stuff. Remove music from those regexes and you should be golden.

That was the original plan - I wanted /music/ to rewrite to http://www.freshair.org.uk/index.php?category_name=music (that direct URL works), and when that rule resulted in a 404 I originally removed that from the regex and tried the real index.php-calling-wp_blog_header() thing instead. /music/index.php works, but /music/ doesn't, even with the new htaccess syntax you provided.

Ah, I see. I didn't realize that.

You might try simplifying the regexes. You'll notice that the WP ones don't have anchors (^$). You also might be able to turn up the log level and see what they're all being rewritten to, which should help you determine what's going on.

Another suggestion would be to comment out the entire .htaccess, and re-add line-by-line until you figure out what's doing it.

So I'm now thinking this is a problem within WordPress, as the rewrite appears to be working...

Went into my 404.php file and added the following code:

When I go to /music/ and see the source code of the 404, this is what it tells me:
<!-- /home/freshair/public_html/index.php : category_name=music -->

At least I can comfort myself with the fact that I'm not wrong here. *sigh*

Oh, and my /knowledge/ rewrite ain't working no more since the server migration either. I know mod_rewrite is on, but it doesn't seem to be doing much for me besides working with WordPress's virtual pages...

  • 1

Log in

No account? Create an account