November 14th, 2013, 09:40 AM
My .htaccess rewriteRule is failing
I'm having trouble understanding why this rewrite isn't doing what its told.
NOTE: the first rewrite in my .htaccess file works properly so its not a problem with using mod_rewrite on local host.
i have URIs which i know will be in the format:
when site goes live:
my .htaccess file reads thus:
To achieve clean URls like:
RewriteRule ^([a-z\-]+)$ $1.php [L]
RewriteRule ^my-manager-([0-9]+)-([a-z]+) my-manager.php?i=$1&t=$2 [PT]
Ideally i dont really want the first capture group ([0-9]+) since i dont really want the 'i' value in the resultant clean url - so ideally id like:
However ive not even got the rewrite to work so far at all having tried:
* leading forward-slash on the target (though i know its not necessary)
* tried changing the '&' ampersand in the target to use &
* removing the [PT] passthru flag replaced with and without [L] flag
* tried most 'least' restrictive character classes in the pattern i.e. (.*) instead of ([0-9]+)
* commented 'out' the first RewriteRule which works flawlessly BTW - so using the troublesome rule in isolation
Non of these have worked - the second rewrite rule has no effect on the target urls so i cant even see were the discrepancy is. I'm still new to mod_rewrite so sort of rely on an informative fail so i can work out were my reg-ex is wrong but i suspect its just being ignored since im getting 'zilch' back!!
BTW: my .htaccess file is in the 'managerhub' directory although i even tried a rewriteBase to it (quite unnecessary) that didn't work either.
Any help appreciated - maybe with a pointer to this folly.
Last edited by devinia; November 14th, 2013 at 09:47 AM.
Reason: more helpful info
November 14th, 2013, 01:00 PM
The question is about whether my-manager.php needs that i value or not. If it does then it needs to show up in the URL somewhere, otherwise yes you can remove it.
Originally Posted by devinia
- Forward-slash on the target could make a difference if there was actually a file "/my-manager.php" in the root of the filesystem. I doubt there is so having one doesn't matter.
- You generally don't need the [PT] flag while you do generally need [L].
So to confirm: with the two Rules
what URLs are you trying (for both) and which ones work (if any) and which ones don't (if any)?
RewriteRule ^([a-z\-]+)$ $1.php [L]
RewriteRule ^my-manager-([0-9]+)-([a-z]+) my-manager.php?i=$1&t=$2 [L]
November 14th, 2013, 02:29 PM
still no rewite joy
@requinix - thanks for this input,
Yes 'i' is actually very important/integral to the logic of the site - i thought that the rewrite only affected what the user sees in the address bar the query string 'i is still available
much the same way as the first rewrite visibly removes the extension '.php' but you are not actually removing the extension (which would be disasterous) your simply changing
how the url appears to the user.
Tried fowrard slash on the target just in case; it doesn't work either way - also i used [L] with and without [PT] - ill put it back as you advise but its only what i did before without any joy!
The first rewrite which hides the file extension '.php' from all URI requests works perfectly as expected throughout the entire site.
so typically if i request:
in the browser it maps to
The second (problematic) rewrite rule with the query string args has not responded to any URI passed via the browser - i know the exact format that the
URI will take since i've created the links internally so typically for this rewrite i'm using urls like:
I just cant see what the heck is wrong even though i'm not a mod_rewrite/regex guru (yet) ive read tutorials and the Apache docs over and over and seen similar
tutorials doing exactly as im doing and (supposedly) they work. The lack of any change at all in the second rewrite makes me belive its just not matching at all.
even replacing the character classes in the pattern with (.*) to match everything (and the kitchen sink) doesn't work. commenting out the first rewrite and using the second
by itself has no effect whatsoever. Finally today i moved it to the live server to see if the issue was my localhost - its the SAME issue on the web-hosts' server.
I'm now right out of ideas
Last edited by devinia; November 14th, 2013 at 02:41 PM.
Reason: referenced replier