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?
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.
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 184.91.72.177] 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"e=turf [L]
RewriteRule rss/(.*)\.rss$ rss/$1.php [L]
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. 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
</Directory>
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.
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. 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.
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.
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.
I threw
Rewrite Log “/somelocation”
and
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.