homepage Welcome to WebmasterWorld Guest from 54.163.72.86
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / Apache Web Server
Forum Library, Charter, Moderators: Ocean10000 & incrediBILL & phranque

Apache Web Server Forum

    
.htaccess. Please help
light_bulb




msg:4538515
 3:03 am on Jan 23, 2013 (gmt 0)

This probably goes against best practice, however, my website has a number of pages that need to have hard coded specific rewrites, but I'm having trouble getting them to work in the manner I would prefer.
WAMP server.

EG:
.htaccess looks like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^user/account.php index.php?page=custom&file=paypal/user_menu_pack.php [L]
RewriteRule ^user/watchlist.php index.php?page=custom&file=watchlist/watchlist.php [L]
RewriteRule ^user/promocode.php index.php?page=custom&file=promo_codes/user_promo_code.php [L]
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>


If a person visits domain.com/user/account.php it correctly rewrites to index.php?page=custom&file=paypal/user_menu_pack.php
However, I want to achieve that without needing a file type specified; I want the redirect to apply if a person visits domain.com/user/account (without the trailing .php)

Can anyone kindly help me?

 

lucy24




msg:4538529
 3:54 am on Jan 23, 2013 (gmt 0)

I want the redirect to apply if a person visits domain.com/user/account (without the trailing .php)

No, you don't. Really.

If you were talking about a redirect, it would be OK, though not obligatory. But here you've got a rewrite. Do you really want the search engines to come away thinking your site is made up of pairs of identical pages?

user/account = user/account.php

user/watchlist = user/watchlist.php

More than pairs, in fact, because all those unescaped . in the pattern mean that

account.php = accountaphp = accountzphp = account/php

... and so on.

Pick one canonical name for each page-- with or without .php --and stick with it. Anyone who asks for the wrong form gets redirected before the rewrite kicks in.

This rule
RewriteRule ^index\.php$ - [L]
needs a preceding RewriteCond to grab users who asked for index.php and redirect them to www.example.com alone. Your server is allowed to ask for index.php by name; people from outside aren't.

light_bulb




msg:4538559
 5:00 am on Jan 23, 2013 (gmt 0)

I'm not sure if I follow correctly.
user/account.php doesn't exist as an actual file on the server. I couldn't get rewrites working with site.com/user/account unless I appended a file extension, so I ended up with site.com/user/account.php <- I want to figure out if I can avoid having to append a file extension.

I hope this clarifies things a bit better.

g1smd




msg:4538579
 5:32 am on Jan 23, 2013 (gmt 0)

The problem is you're using the words redirect and rewrite interchangeably. They are two different things. Both can be coded using RewriteRules, and the syntax difference is very small between the two.

There are three steps you need:

Link to
href="/user/account" from the pages of your site. URLs are defined in links. htaccess cannot change a URL, it can only act on a URL request after a link has been clicked.

# Redirect requests for example.com/user/account.php to example.com/user/account
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /user/account.php\ HTTP/
RewriteRule ^user/account.php http://www.example.com/user/account [R=301,L]

That takes care of users that continue to ask for the old URL from browser bookmarks or stale SERPs.

# Rewrite requests for example.com/user/account to fetch the content
RewriteRule ^user/account$ /index.php?page=custom&file=paypal/user_menu_pack.php [L]
The rule pattern tries to match the requested URL. In this case the modification is as simple as replacing \.php with $ in each rule.

Getting the rewrite to work is the easy bit. You should also add the redirect for existing traffic and you must change the links on the page so that users start off by asking for the correct URL when they click the link.

Beware that unescaped slashes are NOT a valid character within query string parameters. That may cause you some trouble.

lucy24




msg:4538588
 6:45 am on Jan 23, 2013 (gmt 0)

user/account.php doesn't exist as an actual file on the server.

That's fine. mod_rewrite doesn't care if a requested file really exists or not, unless you specifically ask it to check (the -f and -d flags).

I couldn't get rewrites working with site.com/user/account unless I appended a file extension

Uh-oh, there's something wrong here. Are there any other rules you haven't told us about?

htaccess cannot change a URL, it can only act on a URL request after a link has been clicked.

Expanding:

When you're a human browsing the web, it often looks as if an URL has been changed: you type in one thing, and the next thing you know, your browser's address bar says something different. But this is because your browser, acting on your behalf-- hence the term "User Agent"-- has received an instruction to ask for a different URL. And it quietly puts in this second request without asking your permission. (It has also asked for a zillion stylesheets and images without making you type in each name separately. Your browser does not get paid enough.)

When you are running your own site you can see it in action by looking at the logs. Request for such-and-such gets a 301 response, immediately followed by a request for something else from the same person. Between those two log lines, the browser has gone out into the Internet and entered your site all over again as if it had never been there before. (Well, presumably it knows where to look and doesn't have to hunt down the DNS all over again. But that's down to your browser.) You might even see a 301 immediately followed by a request for the same file. That's the with/without www. redirect in action.

Rewrites on the other hand don't show up in logs at all, and the browser doesn't know it's being rewritten. Your only clue is that the filesize might be different from the size of the file your visitor originally asked for (assuming it's something that really does exist). If someone asks for a 75K jpg and logs say they were given 2K, that's your anti-hotlinking routine at work ;) And if someone asks for something that doesn't exist, and logs show a 200 response with some appropriate filesize, that's your rewrite doing its thing.

:: memo to self: add foregoing to boilerplate somewhere ::



Beware that unescaped slashes are NOT a valid character within query string parameters. That may cause you some trouble.

Urk! Isn't there a question about that, just a few posts further down this forum? If you do have a slash, does something break outright or are you just left with an unhappy php page plotting revenge?

g1smd




msg:4538618
 9:33 am on Jan 23, 2013 (gmt 0)

I couldn't get rewrites working with site.com/user/account unless I appended a file extension

Uh-oh, there's something wrong here. Are there any other rules you haven't told us about?

The rules in the original post require the .php in the URL request.

The OP is merely asking how to modify those rules.

Beware that unescaped slashes are NOT a valid character within query string parameters. That may cause you some trouble.
Urk! Isn't there a question about that, just a few posts further down this forum? If you do have a slash, does something break outright or are you just left with an unhappy php page plotting revenge?

While not valid, they do work on some systems. It's not something to rely on though.

I usually block any and all requests with http or slashes, and a number of other things, in any query string as those are things that hackers may use.

lucy24




msg:4538620
 10:25 am on Jan 23, 2013 (gmt 0)

The OP is merely asking how to modify those rules.

My understanding was that he never wanted the extension in the first place, but he couldn't get the original rule to work otherwise. That's where you have to suspect interference from something else in htaccess.

In any case it is good that you are hammering all this out in WAMP ahead of time. Much better than getting the whole site up and running and then deciding six months later that your naming system is all wrong :)

light_bulb




msg:4538771
 9:54 pm on Jan 23, 2013 (gmt 0)

I've posted the entire .htaccess in the first post.
My goal is to get the rewrite to work without requiring the .php at the end. - Is this possible?

Please forgive me for getting redirects and rewrites mixed up - typing before brain engaged.

g1smd




msg:4538781
 10:58 pm on Jan 23, 2013 (gmt 0)

My goal is to get the rewrite to work without requiring the .php at the end. - Is this possible?

Yes. Message #4538579 (barring stupid typos) gives you the three steps.


Please forgive me for getting redirects and rewrites mixed up - typing before brain engaged.

No problem. Thanks for clarifying that we don't need to run through that stuff again - though there's several threads in the last few days where it's explained in gory detail, and dozens more similar threads over the last few years. It's a common problem that many people don't know the difference. :)

lucy24




msg:4538807
 1:14 am on Jan 24, 2013 (gmt 0)

Let me double check something. This site doesn't exist yet, right? That means you don't have to do the extra step of redirecting (not rewriting)

account.php and similar
to
account

because nobody will have any outdated links or bookmarks that lead to the .php form. Right? You can include redirect code if you want to, but it won't be essential.

Make sure any rules involving rewrites-- not redirects-- have both opening and closing anchors. Not because leaving off the anchor will break the rule. The opposite in fact. You only want the rule to work on one form of the name; the anchor(s) will enforce this.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved