.htaccess being overridden

MY .htaccess rules seem to be ignored (they worked on another a couple other servers)

I read at this site fastcgi could be the cause:


Other than describing the cause, it doesn’t offer really a solution to get it to work with fastcgi… Is there a way to disable the fastcgi through the virtualmin control panel?

Better yet, does anyone here have a solution to get the .htaccess to work?

Here’s whats happening…

I goto http://mysite.tld/directory/

it automatically executes http://msite.tld/directory.php if a directory.php exists… But I DON’T want it to! I’m rewriting the rules in my .htaccess to goto index.php?somevariable=something…

Again my htaccess works, its worked on several other sites. Just not on my server that has virtualmin running. The configuration is pretty much a stock site created from virtualmin, no uber special configurations in the site apache2 configuration file.

Anyhelp, definetely welcomed!


Well, lots of folks here use FCGID and .htaccess files, I’d be surprised if that were your issue.

The things I’d suggest looking into are –

  • Verify that the owner of your .htaccess file is your Virtual Server owner’s account, You may also want to make the permissions “755”.

  • Look in Services -> Configure Website -> Edit Directives… you’d want to make sure that “AllowOverride” is set to “All”.

You may also want to look in the error log to make sure no errors are showing up there, that’s in $HOME/logs/error_log.

If none of that helps, I’d be curious to see the contents of your .htaccess file, as well as the output of “ls -l .htaccess”.


Here’s the last log entry when I tried to goto mysite.tld/about/

[Tue Aug 02 22:06:39 2011] [debug] mod_deflate.c(615): [client] Zlib: Compressed 3917 to 1482 : URL /about.php/

(I've since removed the rules from the .htaccess that do the compression..)

ls -la .hatches
sh-4.1$ ls -la .htaccess  -rwxr-xr-x 1 elead elead 1850 Aug  1 20:33 .htaccess

elead is the virtual server owner account.

.htaccess contents..   This is an edit from my original post, because I wanted to remove a lot of unnecessary stuff.. I broke it down the bare minimum, of the functionality I'm trying to get work right.

ErrorDocument 404 /notfound.html

AddDefaultCharset utf-8

RewriteEngine on

rewriteCond %{REQUEST_URI} !/admin/
rewriteCond %{REQUEST_URI} !/generator/
rewriteCond %{REQUEST_URI} !/data/
rewriteCond %{REQUEST_URI} !/pages/
rewriteCond %{REQUEST_URI} !/artificial-turf/admin/
rewriteCond %{REQUEST_URI} !/artificial-turf/
rewriteCond %{REQUEST_URI} !/artificial-turf/product/

RewriteRule ^([^/\.]+)/?$ /index.php?page=$1 [L]

RewriteRule ^([^/\.]+)/([^/\.]+)/?$ /index.php?page=$1&state=$2 [L]

RewriteRule ^([^/\.]+)/([^/\.]+)/?$ /index.php?page=$1&product_id=$2 [L]

RewriteRule ^([^/\.]+)/([^/\.]+)/([^/\.]+)/?$ /index.php?page=$1&state=$2&city=$3 [L]

RewriteRule ^([^/\.]+)/([^/\.]+)/([^/\.]+)/([^/\.]+)/?$ /index.php?page=$1&state=$2&city=$3&quote=turf [L]

RewriteRule rss/(.*)\.rss$ rss/$1.php [L]

Yeah, your ownership and permissions look good.

Were you able to verify that your Apache config has the “AllowOverride All” in it? Without that, Apache won’t look for a .htaccess file.

Also, just to be super sure that we’re dealing with an issue of Apache not trying to load your file – can you make the first line of your .htaccess file a bunch of gibberish… just pound on the keyboard for a few seconds.

Then, save that, and try browsing to your site… in theory, you should see your site still. But, if you get an error message, that means the .htaccess was indeed read.


Its definitely loading the .htaccess. I verified that by changing some other rules… And now just verified by your method. :slight_smile: It pukes when gibberish is put in the top.

Here’s my part of the apache2 config file pertaining to… the allow override & stuff…

<Directory /home/elead/public_html>
Options -Indexes +IncludesNOEXEC +FollowSymLinks +ExecCGI
allow from all
AllowOverride All
AddHandler fcgid-script .php
AddHandler fcgid-script .php5
FCGIWrapper /home/elead/fcgi-bin/php5.fcgi .php
FCGIWrapper /home/elead/fcgi-bin/php5.fcgi .php5

If you’re suspecting FCGId to be the culprit, as a first quick test I’d switch the site to using mod_php and see if the .htaccess is read correctly then. If so, you know it has indeed to to with FCGI and you can dig there further. If not, well, you know. :slight_smile:

This won’t solve your problem of course, but will narrow down possible causes for it. Maybe you have some directives in your .htaccess that for some reason can’t be processed or interfere with FCGId. Though it is not a general issue, I’m using .htaccess with FCGId just fine here.

Its definitely loading the .htaccess. I verified that by changing some other rules… And now just verified by your method. :slight_smile: It pukes when gibberish is put in the top.

Ah, so you’re not saying that Apache is ignoring the htaccess file altogether, you’re saying that FCGID is the cause of some rules in your htaccess not working.

Well, I hadn’t heard of that happening before, but if you want to rule that out as a possibility, you can go into Server Configuration -> Website Options, and change the PHP Execution mode from FCGID to CGI.


@Eric: Didn’t I just say that, in slightly different but logically identical wording? :slight_smile:

Didn’t I just say that, in slightly different but logically identical wording?

Very much so, I hadn’t noticed your reply when I responded here :slight_smile:

hrm… Did some switching… Apparently it ISN’T fcgi, cgi, etc… I tried switching through CGI/mod_php and what not… Same behavior happens across the board. Okay… something else is mysteriously happening.

mod_rewrite can be quite the b*tch to debug, especially with the rather complex ruleset you partially posted up there. :wink:

My suggestion would be to either step by step remove lines from the desired .htaccess, or step by step add lines to an initially empty one, until you hopefully stumble upon the one(s) that cause your intended ruleset to break.

Welp… Found out how to debug it

I threw
Rewrite Log “/somelocation”
RewriteLogLevel 5

in my site definition file and debugged it. As well as moved the actual definitions to the site definition file as well… I end up just rewriting the rules more or less, the previous system it was on was a FreeBSD system (and it worked on my local mac which is BSD based). I’m thinking perhaps there is some wild chance FreeBSD handles regexps slightly different, because it worked both on my local mac MAMP testing environment and the production environment which is freebsd… Anywho the target system in question is debian, a GNU environment so…

After I rewrote the rules they look like this and it works.

 RewriteRule ^/([^.\/]+)/?$ /index.php?page=$1 [L]

RewriteRule ^/([^.\/]+)/([^.\/]+)/?$ /index.php?page=$1&state=$2 [L]

RewriteRule ^/([^.\/]+)/([^.\/]+)/?$ /index.php?page=$1&product_id=$2 [L]

RewriteRule ^/([^.\/]+)/([^.\/]+)/([^.\/]+)/?$ /index.php?page=$1&state=$2&city=$3 [L]

RewriteRule ^/([^.\/]+)/([^.\/]+)/([^.\/]+)/([^.\/]+)/?$ /index.php?page=$1&state=$2&city=$3&quote=turf [L]