My rewrite rule isn't working - apache

I currently want my site to rewrite from
.com/page/1234
to
.com/?view=page&id=1234
Heres my .htaccess content:
RewriteBase /
RewriteRule ^/page/([0-9]+)$ /index.php?view=page&id=$1
ErrorDocument 404 errors/404.html
When I type ".com/page/1" my site just redirects to the 404 page.
What have I done wrong? I tried to the simplest:
RewriteRule ^/page$ /about.php
But it doesn't work either. So I'm having some suspect that 000webhost (my current host) is not supporting RewriteRule although they stated they support it.

From personal experience, I know they -do- support RewriteRule, but it is somewhat horrible to test them. In "per-directory"-context, the slash from a directory is appended to the "prefix" part of the url. .htaccess always works as in "per-directory"-context. A RewriteRule that begins with a slash in .htaccess will therefore never match anything.
If you change your .htaccess to the following, everything should work as expected:
RewriteBase /
RewriteRule ^page/([0-9]+)$ /index.php?view=page&id=$1
ErrorDocument 404 errors/404.html
I recommend reading the documentation for mod_rewrite. It contains a lot of useful information.

Related

htaccess mod_rewrite giving me 404

SO I have this in my .htaccess file
RewriteEngine On
RewriteBase /core/
RewriteCond %{QUERY_STRING} ^page=([0-9]+)$
RewriteRule ^page page/%1/? [L]
my url is
http://localhost/core/page.php?page=8
with the rules applied I'm getting..
Not Found
The requested URL /core/page/8/ was not found on this server.
This is running on wampserver 2.2
the file structure looks like
c:/wamp/www/core
the .htaccess is inside the /core/ directory.
What is it that I'm missing.. i've checked my apache.conf file and it looks fine.
I think you got it the wrong way around. When logically thinking of rewriting you don't rewrite original URL to new URL (for example page.php?page=8 to page/8/) you actually rewrite page/8/ to page.php?page=8. You tell the server how it should interpret the unfamiliar URL.
So if I understood correctly what you want to achieve is:
User visits localhost/core/page/8/
User is served (under the hood) localhost/core/page.php?page=8
I believe the following RewriteRule will do the trick (The query string condition is not necessary):
RewriteRule ^page/(\d+)/$ page.php?page=$1 [L]

Url rewrite not working; 404 error and no url change

I'm working on a website where I want the url
www.example.com/directory1/states/california.php
to point to
www.example.com/directory1/california
And a similar url change for the city pages as well:
www.example.com/directory1/cities/miami.php
should point to
www.example.com/directory1/miami
I'm using the following rules in my access file to change the url:
RewriteRule ^directory1/(alabama|alaska|arizona|arkansas|california|colorado|connecticut|delaware|florida|georgia|guam|hawaii|idaho|illinois|indiana|iowa|kansas|kentucky|louisiana|maine|maryland|massachusetts|michigan|minnesota|mississippi|missouri|montana|nationwide|nebraska|nevada|new_hampshire|new_jersey|new_mexico|new_york|north_carolina|north_dakota|ohio|oklahoma|oregon|pennsylvania|rhode_island|south_carolina|south_dakota|tennesee|texas|us_virgin_islands|utah|vermont|virginia|washington|west_virigina|wisconsin|wyoming)$ /directory1/states/$1.php [L]
RewriteRule ^directory1/(.*)$ /directory1/cities/$1.php [L]
However, nothing changes in the url bar and I always get a 404 not found. When I tested it with the htaccess checker, the output url is always correct. What is wrong with my rules? Is there a way to test how/if mod_rewrite is even functioning?
Some server configs require you to turn the rewrite engine on in your .htaccess file. Right at the top:
RewriteEngine on
I've also known some server configs where the file path starts/ends with a / (due to other rewrite rules already being run on the request) so perhaps allow for that to be there in the rules:
RewriteRule ^/?directory1/(alabama|alaska|arizona|arkansas|california|colorado|connecticut|delaware|florida|georgia|guam|hawaii|idaho|illinois|indiana|iowa|kansas|kentucky|louisiana|maine|maryland|massachusetts|michigan|minnesota|mississippi|missouri|montana|nationwide|nebraska|nevada|new_hampshire|new_jersey|new_mexico|new_york|north_carolina|north_dakota|ohio|oklahoma|oregon|pennsylvania|rhode_island|south_carolina|south_dakota|tennesee|texas|us_virgin_islands|utah|vermont|virginia|washington|west_virigina|wisconsin|wyoming)/?$ /directory1/states/$1.php [L]
RewriteRule ^/?directory1/(.*)/?$ /directory1/cities/$1.php [L]

301 redirect query string to SEO friendly URLs through .htaccess

I’ve written some code on my .htaccess file which allows the use of SEO friendly URLs instead of ugly query strings. The following code rewrites the SEO friendly version in the browser to the query string version on the server.
RewriteEngine On
RewriteRule ^seo/([^/]*)/$ /directory/script.php?size=large&colour=green&pattern=$1 [L]
So that the ugly
http://www.mysite.com/directory/script.php?size=large&colour=green&pattern=striped
Is now beautiful
http://www.mysite.com/directory/seo/striped/
Just to explain the code a bit; seo is there to add more keywords to the URL, /directory/ is the directory in which the .htaccess file is located, parameters size=large and colour=green never change, while pattern=$1 can be many different values.
The above code works perfectly. However, the problem is I am now stuck with two URLs that point to exactly the same content. To solve this, I would like to 301 redirect the old, ugly querystrings to the SEO friendly URLs. What I have tried so far does not work - and Google is not being particularly friendly today.
Can anybody offer working code to put in my .htaccess file that redirects ugly to new URL, while retaining the rewrite? Thanks!
This should do the trick:
RewriteEngine On
## Redirect to pretty urls
# The '%1' in the rewrite comes from the group in the previous RewriteCond
RewriteCond %{REQUEST_URI} !seo
RewriteCond %{QUERY_STRING} ^size=large&colour=green&pattern=([a-zA-Z]*)$
RewriteRule (.*) /directory\/seo\/%1\/? [L,R=301]
## Rewrite to long url, additional parameter at the end will cause
## the internal redirect not to match the previous rule (would cause redirect loop)
RewriteRule ^directory\/seo\/([^/]*)/$ /directory/script.php? size=large&colour=green&pattern=$1&rewrite [L]
You can also match the size and colour if needed, by changing those to regex groups as well, and using the corresponding %N
Hope this helps.
Not tested, but this may work...
RewriteRule ^directory/script.php?size=large&colour=green&pattern=(.*)$ /seo/$1/? [R=301,NE,NC,L]

.htaccess redirect doesn't hide url

my .htaccess in the root folder includes the following lines :
Options +FollowSymlinks
RewriteEngine on
RewriteRule ^(.*)\.htm$ http://example.com/?city=$1 [NC]
when I open the address http://example.com/bla.htm, my browser doesn't hide the GET values specified in the .htaccess, it redirects me to ?city=bla. eventhough I'm not using the [R] switch. This has always worked for me before (as I remember, haven't dealt with htaccess in a while). What's wrong here ?
When you redirect to an entire URL, it doesn't do URL rewriting (you can't exactly rewrite URLs on someone else's website).
Assuming both URLs are on the same server, you need to do something like
RewriteRule ^(.*)\.htm$ index.php?city=$1 [NC]
Also, I'd recommend getting into the habit of using the [L] switch whenever you can - it helps avoid bugs when you have a lot of URLs to rewrite.

Mod-Rewrite Problems (Apache) with / slashes

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 :-)