• I just sent this in an email to Ryan, but I thought I should probably post it here too, just in case anyone else is seeing it.

    https://www.randomthink.net/dump_env.html is a sample of my problem output. My issue is notably different from the others I’ve seen on the boards, in that not only do my permalinks work fine, but now WP is catching odd random other requests, even when the files/folders exist.

    Examples:
    https://www.randomthink.net/archives/2005/12/30/wordpress-20/ – works fine, comments are fine too. There is a /wordpress folder under randomthink.net where I house the files, so I’m a little surprised that a slug with wordpress in it was working okay. I did update to those two files that Ryan posted – the functions-post and classes, I believe, including rev 3396 of classes, so that might be fixing that.

    https://www.randomthink.net/tests/ – this isn’t a WP page or anything, but simply a directory with some html files and whatnot, and it loads fine.

    https://www.randomthink.net/gallery/ – my G2 install, works fine.

    https://www.randomthink.net/awstats/ – my awstats install. This one doesn’t work right. WP intercepts the request and gives me a pretty WP 404. I’ve tried adding index.php to the request (shown in the dump_env above), and it doesn’t work then either. It works fine if I turn on verbose rewrites with Ryan’s plugin.

    https://www.randomthink.net/awstats/icon/clock/hr1.png – a file deep within my awstats install path. Doesn’t work, is caught by WP. Technically, the icon folder under there is a symlink, but that option is on in Apache, and it works fine if I’m using verbose rewrites.

    https://www.randomthink.net/misc/ – a directory that’s closed to open viewing, with no index file. It gets intercepted by WP. However, if I put an index file in there (be it .html or .php), I get that file, so it’s a half-works.

    https://www.randomthink.net/misc/wow/ – a directory that’s explicitly open to everyone. Works fine, regardless of index existing there or not.

    It’s seems like a random crapshoot as to whether or not folders that are at the same level as my WP index.php file (which is now the root of my site) work or not.

    I’m fairly certain that this is due to the .htaccess file handing everything off to WP that fails the -f and -d tests. However, some of those things shouldn’t be failing that test, but seem to be, since WP gets the request.

    I’m a DreamHost customer, and they’ve asked that we run PHP as a CGI. I’ve even noticed comments in some of the WP code mentioning adjustments put in place for that. I’m not sure if that could be causing some of the problems.

    Any insight you could offer would be most appreciated. I’m really comfortable in and around a shell, as well as with PHP, so if there’s anything that needs to be altered or adjusted, let me know and I’ll get it in rather quickly.

    For now, if I turn on Ryan’s rewrite.php plugin, it just writes out the verbose rewrites and all is well. However, I’m going to keep that off for the moment so you can go poke at things, should you so desire.

    As an aside, I’ve noticed that sometimes I can turn on the verbose rewrites, pull up my awstats page, then turn the verbose rewrites back off and continue to look at my stats, including a full refresh, so long as I don’t close my browser. That one could be that my awstats are guarded with basic auth, and something about being authenticated might be making the request go through past the -f and -d checks. That doesn’t make sense, but not much else has made sense with this issue so far, so I’m not surprised.

    Thanks again for any help and/or insight you can offer.

Viewing 10 replies - 16 through 25 (of 25 total)
  • Nurse Wizzle

    (@glenncoco)

    This seems to be the same problem my friend is having, except instead of Awstats, it is his osCommerce admin directory. The problem is referenced here: https://www.ads-software.com/support/topic/60605?replies=7#post-324096

    I’m a bit of a dummy when it comes to all of this though, so I’m not exactly sure how to fix it.

    Nurse Wizzle

    (@glenncoco)

    Can anyone help?

    redchickadee

    (@redchickadee)

    Running WP2 on Dreamhost, but can’t access my stats (https://www.crimgirl.com/stats/). I just read this thread and I can’t figure out if someone found a fix or not? I tried a couple of the suggestions and get nowhere. Any other ideas?

    elohin

    (@elohin)

    Updated link to help info on dreamhost:
    https://wiki.dreamhost.com/index.php/Making_stats_accessible_with_htaccess

    It worked for me, however, that’s just for the stats directory. Guess I will have to remember to edit .htaccess again if I make other non-wordpress directories or files.

    Thanks elohin. I’ve tried that twice but it didn’t work. Then I tried switching themes (from Hemingway Bright), and everything worked fine. Maybe certain themes have issues with Dreamhost? I don’t know. =)

    I have the same problem of password protected directory redirected to WP 404 error page. Here’s the fix I deviced:

    https://www.ju-ju.com/2006/03/17/wordpress-404-error/

    Brianarn’s solution worked perfectly for me as a DH user. I **am** using /%category%/%author%/%postname%/ in my custom permalinks and am able to access the stats now without issue.

    WP2.0.2

    1) edit the .htaccess file via the Manage>Files admin page (no direct editing or ftp)
    2) use this fix:

    # WP Fix
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
    RewriteCond %{REQUEST_URI} ^/failed_auth.html$
    RewriteRule ^.*$ - [L]
    </IfModule>
    # END WP fix

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

    3. note, I believe if you use FAlbum, that set of rules should remain at the top. I placed the above code below the rules for FAlbum

    HTH, AND THANKS! to Brianarn

    PS. I posted this solution over at the DH forums, too, so that others don’t spend the hour I did, pulling out hair, etc

    I had the same problem to enter in /cgi-bin/scripts…now i’ve solved using:

    # WP Fix
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_URI} ^/cgi-bin/scripts/(.*)$ [OR]
    RewriteCond %{REQUEST_URI} ^/failed_auth.html$
    RewriteRule ^.*$ – [L]
    </IfModule>
    # END WP fix

    But someone could me explain what is the second line:
    RewriteCond %{REQUEST_URI} ^/failed_auth.html$

    This is probably too late too help you guys, but I found that simply placing the Auth code before the WP section in the .htaccess file worked just fine. Also, it helps not to add the order or allow/deny bits, as those just seem to confuse Apache on DH. The auth bit works just fine without those statements.

    All real subdirectories and password protected subdirectories, and even redirected password protected subdirectories showed up fine. All non-existent pages pointed to the WP 404 page. All permalinks survived.

    Edit: Also, changing the Permalinks from within WP doesn’t affect the Auth code, which is outside of the area that WP modifies.

Viewing 10 replies - 16 through 25 (of 25 total)
  • The topic ‘WP 2.0 – htaccess overly aggressive? 404’s galore’ is closed to new replies.