I'm using a couple of rewrite directives that always works before on apache2 but now trying a new shared hosting and the rewrite rules do not seem to get applied.
I've reduced the .htaccess files to the following essential rules:
RewriteEngine On
Rewritebase /demo/
RewriteRule ^(.*)$ index.php/$1 [L]
As you can see, i want to rewrite every request to my index.php file in the demo folder from root.
So everything like http://www.example.com/demo/albums/show/1 should be processed by http://www.example.com/demo/index.php for a standard MVC setup. (I'm using CodeIgniter btw)
The directives above results in a 500 error, so i thought maybe because of some possible syntax differences between 1.3 and 2.x.
After some trail and error editing, i've found the rewrite rule itself to be at fault but i really don't understand why.
Any ideas to why my rewrite rule doesn't work? it did before on lots of different servers.
Suggestions how to fix it?
Note: mod_rewrite does work, i've written a small test to be sure.
In your position, I'd probably look in the Apache error log first, then would try to eliminate one moving part by doing
RewriteEngine On
RewriteRule ^/demo/index.php$ /demo/index.php [L]
RewriteRule ^/demo/(.*)$ /demo/index.php/$1 [L]
If that worked, I'd try reintroducing RewriteBase.
Did you set:
Options +FollowSymLinks
… before the rewrite rules? If FollowSymLinks is disabled mod_rewrite won’t work.
It may be that you’re running into an infinite recursion since index.php/… is also matched by ^(.*)$. So try to exclude your target:
RewriteCond $1 !^index\.php/
RewriteRule ^(.*)$ index.php/$1 [L]
Related
I had this rewrite rule set up in .htaccess and it was all working fine...
Options +FollowSymLinks +ExecCGI
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/mypage(.*)$ [NC]
RewriteRule ^(.*) http://example.com/PHProxy/poxy-0.5b2/index.php?url=http://example.org/mypage [L,R=302,NC]
However, when I change the url in the RewriteRule to
http://example.com/PHProxy/poxy-0.5b2/index.php?url=http://example.org/mypage it still redirects to the old URL.
After some research, I added a syntax error into the .htaccess file to check the .htaccess file was being used (and indeed it was - as it resulted in an Internal Server Error when you tried to load a page from that directory).
There seems to be some caching somewhere, but I'm not sure. Any ideas why my change is not being picked up / how to troubleshoot and resolve?
Problem solved. Just noticed that there is a mypage subdirectory which still contained the old rewrite rule, so that was the one being executed.
Please excuse me as I'm pretty new to using .htaccess, and am having a few issues with it as the setup I need is, despite being simple, seemingly rare.
Basically, I'm working on a secondary domain trying to hide .php extensions from pages, but whilst also redirecting requests for nonexistent pages to a custom search page. The overall desired effect is:
realpage => realpage.php
and
falsepage => search.php?q=falsepage
So far, the code I have (see below) seems to apply the latter correctly, but rather than returning 'realpage.php' for 'domain.com/realpage' it returns a 404 error.
I've found variations which also move realpage to 'search.php?q=missing' in case that gives any indication what might be going wrong!
My .htaccess file at the moment:
Options +FollowSymLinks
Options +Indexes
RewriteEngine On
RewriteBase /
RewriteRule ^([^\.]+)$ $1.php [L]
RewriteCond %{SCRIPT_FILENAME} !-f
RewriteRule ^(.*)\.php$ search.php?q=$1 [L]
Thanks for any help you can offer! It's very much appreciated!
I think for your first rule, you want something along the lines of:
RewriteBase /
RewriteRule ^([^.]+)$ $1.php [L]
I ran that through the rewrite rule tester, and it will direct 'realpage' to 'realpage.php'. If that doesn't work, I would suggest disabling your second rule, making sure the first one works well, then adding the check for missing files in later.
Once in a while I have to fuddle around with mod_rewrite or rather Apache's redirect. Now I have a simple task, that drives me nuts, cause I can't get it working:
Everything that was under /journal/(.*) is now under /blog/(.*).
This is what I have now:
RewriteEngine on
RewriteBase /
RewriteRule ^/journal/([^/]+)$ /blog/$1
If it matters: this is a drupal installation.
Drupal has existing rewrite rules in .htaccess. If you put your rules at the top of the file, Drupal's rules may override them.
I don't think you want the starting / in your rule.
If you're expecting the rule to redirect folks who use the old /blog/ URL, you're mistaken. If that's what you're trying to do, you'll need to perform a redirection, like this:
.
RewriteEngine on
RewriteBase /
RewriteRule ^journal/(.+)$ http://example.com/blog/$1 [R=301,L]
since your rewrite base is / I think you can leave out the / in front of journal. so try
RewriteRule ^journal/([^/]+)$ /blog/$1
Also if you have any other rules happening you can append [L] to the end of the statement to make sure no other rewrites happen.
I want to be able to rewrite this
http://localhost/.../identicon/f528764d624db129b32c21fbca0cb8d6.png
to
http://localhost/.../identicon.php?hash=f528764d624db129b32c21fbca0cb8d6
so I add to the /.../.htaccess so this is it:
RewriteEngine On
RewriteRule ^resource/ - [L]
RewriteRule ^identicon/(.+)\.png$ identicon.php?hash=$1 [QSA,L]
RewriteRule ^(.*)$ index.php?t=$1 [QSA,L]
Which doesn't work for some reason because it redirects it to index.php?t=identicon.php; even though the L flag is set! Why?
Add a condition to the last rule to exclude requests that can be mapped to existing files:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?t=$1 [QSA,L]
That is necessary because the L flag generates an internal redirect with the new URL as the request URL:
Remember, however, that if the RewriteRule generates an internal redirect (which frequently occurs when rewriting in a per-directory context), this will reinject the request and will cause processing to be repeated starting from the first RewriteRule.
(Not correct answer; left for reference)
I just figured out what may be the issue - it's something that thwarted me for a long time.
Depending on your server settings, it very well may be interpreting identicon/xxx.png as a request to identicon.php/xxx.png, assuming that the PHP extension is what you wanted. Try going to /index instead of /index.php - if it loads the PHP file, this is the issue affecting you.
This is the MultiViews Apache option, and it's stupid, but it has to be enabled specifically. Go into your site configuration file and see where it is enabled, and remove it.
If you don't have total control over your server configuration, the following may work in .htaccess (depending, ironically, on your server configuration).
Options -Multiviews
I am betting on an obvious problem here I am not seeing.
Here's the important bits for those of you familiar with Mod-Rewrite
.htaccess file with mod-rewrite rules exists here:
http://www.thedomain.com/.htaccess
User goes to this URL:
http://www.thedomain.com/test/blog
Mod-Rewrite rules should actually tell the server to access this URL:
http://www.thedomain.com/index.php?page=blog
.htaccess:
Options FollowSymLinks
Options -MultiViews
RewriteEngine on
RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]
This combination of code/request does not work. If you're wondering about the code snippet ^test not being ^/test instead, it is because apparently this is a problem on GoDaddy, the code fails with the / after the ^ - this seems like it may be related to my problem, which I'll explain further... If I change the .htaccess code line:
RewriteRule ^test/([^/.]+)$ /index.php?page=$1 [L]
to
RewriteRule ^test([^/.]+)$ /index.php?page=$1 [L]
(just removing the / here: ^test/([^/.]+) )
The code works when the requested URL is changed to accomodate (remove the slash; http://www.thedomain.com/testblog) as the user views the proper index.php?page=blog server response. It seems to me I cannot use any slashes within the darn match side of the RewriteRule. What gives?
Update: If at all relevent, this .htaccess file and the relevant files to the question all exist in a subdirectory off of the GoDaddy server that is hosting this although the domain points to the subdirectory as the root. Not sure if this is relevant.
Update: This server (at the server root) is actually running wordpress with pretty URLs enabled and they work perfectly fine. I assume wordpress uses mod-rewrite to make crazy urls like thedomain.com/2008/11/15/the-article-title.html work...?
Thanks so much.
Is RewriteBase what you're looking for?
there is a nice test utility for windows here
http://www.helicontech.com/download-isapi_rewrite.htm
try changing your code to:
^/test/([^/]+)$ /index.php?page=$1 [L]
or without slashes
^test[^a-z]+([a-z]*)$ /index.php?page=$1 [L]
I was unable to find a solid method around this problem on GoDaddy; for whatever reason I could not have slashes within the URL that was attempting to be rewritten aside from the base (http://www.somedomain.com/testingthis would work but http://www.somedomain.com/testing/this died).
I ended up instead using the Wordpress .htaccess to send all non-existant file/directory requests back to my index.php. I then used the $_SERVER['REQUEST_URI'] var with pathinfo() to parse the URL and then direct what content to load from the parsing. This works well, is fast, and is probably the same method Wordpress uses.
Thanks for the attemps!
If you're wondering about the code snippet ^test not being ^/test instead, it is because apparently this is a problem on GoDaddy, the code fails with the / after the ^ […]
That’s not odd but necessary:
Per-directory Rewrites
When using the rewrite engine in .htaccess files the per-directory prefix (which always is the same for a specific directory) is automatically removed for the pattern matching and automatically added after the substitution has been done.
And that per-directory prefix is for a .htaccess file in the document root (/.htaccess) the URL path root (/). Thus patterns with the ^ must be written without that per-directory prefix /.
On the same way the substitution is handled. After a rule is applied, the per-directory prefix is added to the substituion. So try this rule:
RewriteRule ^test/([^/.]+)$ index.php?page=$1 [L]
OK, first off, I think that the GoDaddy apache server simply has some of the options turned off. I think that if they don't have an AllowOverride FileInfo in their configuration, RewriteRule won't work so well, or at all.
Which means its surprising that the URL http://www.thedomain.com/testblog works at all, and gets re-written. So I guess I'm a little confused.
Here's an idea: Try creating a directory named test, and put the .htaccess file in there! It would look like this:
Options FollowSymLinks
RewriteEngine on
RewriteRule ^([^/]+)$ /index.php?page=$1 [L]
OK, another idea: Use RewriteCond. Maybe you can check the request URI directly, like this:
Options FollowSymLinks
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/test/([^/]+)
RewriteRule . /index.php?page=%1 [L]
Last idea: maybe your browser sees the URL http://www.thedomain.com/test/blog and thinks it's a directory, and adds a slash? So the URL is sends is http://www.thedomain.com/test/blog/. In that case, the REGEX won't match unless you allow for a trailing slash:
RewriteRule ^test/([^/.]+)/?$ /index.php?page=$1 [L]
Whoops. Sorry for gushing - there's just some many things that can go wrong in an HTTP request that goes through rewriting, and as many ways to try and overcome the problems :-)