Help With Redirects In .htaccess files

[bluewaves]

RewriteCond %{HTTP_HOST} ^sampledomain\.com
RewriteRule ^(.*)$ [sampledomain.com...] /$1 [R=permanent,L]

What does the above code actually do?

What I am looking for is a way to make all these
www.sampledomain.com/index.php
www.sampledomain.com/

go to
[sampledomain.com...]

I am not sure if the trailing slash should be the main target or the .com should be the main target.

Can anyone explain this to me?

Thanks in advance.

[bluewaves]

Like this?

#Here should be rules for redirecting
RewriteCond %{THE_REQUEST} index\.php
RewriteRule ^(([^/]+/)*)index\.php http://www.example.com/$1 [R=301,L]


#Redirect all external .php requests to the extensionless urls
RewriteCond %{THE_REQUEST} ([^.]+)\.php
RewriteRule ^([^.]+)\.php http://www.example.com/$1? [R=301,L]



RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

#Rewrites extensionless requests to find the correct .php file
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(([^/]+/)*[^.]+)$ /$1.php [L]

[lucy24]

Think that's it

#1 redirect requests for "index.php" by name

#2 redirect all other requests for ".php" by name

#3 redirect requests for wrong forms of domain name

#4 rewrite extensionless URLs to serve content from .php form of name

Now, I am not 100% sure that this will work on all Apache installations. But on my system-- which has got to be fairly generic since it's shared hosting from a major provider-- I can run Rule 1 without any condition at all if I add the [NS] flag. Rule 2 needs the condition, but adding the [NS] flag means that in some cases the Condition does not need to be evaluated.

[bluewaves]

Thank you so much for your help. I have run this and it is working perfectly. So all my issues have been fixed.

Do you have any reference books you would recommend?

How did you learn all of this?

Can't thank you enough. I feel good that everything is working.

[lucy24]

How did you learn all of this?

By reading this forum :)

I came in knowing a good bit about Regular Expressions because I come from an e-book background. Things like

(?<!\p{Upper}|[Ii]\.e|[Ee]\.g|[Cc][fp]|viz|etc|poss|orig|esp|Esq|[Ss]c|&c|[Vv]ol|\.\.)\.["”]*( |\r?\n)(?:<i>|_)?\p{Lower}

(test for extraneous periods (full stops) that may be either typos or mis-scanned flyspecks)

or

\([^({\[)}\]]*[}\]]|{[^({\[)}\]]*[\)\]]|\[[^({\[)}\]]*[}\)]

(test for mismatched brackets)

Yes, OK, I just used a Regular Expression to pull out two of the longest and scariest-looking formulas.

Sometimes you can get away with things in a text editor that you can't in Apache, on account of those multiplying nanoseconds. But I'm not kidding when I say that 95% of mod_rewrite is Regular Expressions. And probably 95% of this forum is mod_rewrite, so there you go.


Awright, wise guy, I saw you playing around with PathInfo :P Har de har har. (Not you, hottrout. But he knows who he is. Pure coincidence that I pulled the daily logs only minutes after the fact.)

[bluewaves]

That is admirable. I appreciate your help.

Tonight I tried adding a domain to my hosting plan and they told me something in my .htacess file was causing a problem with the addon domain.

So this addon domain won't pull up the domain without redirecting to http://www.example.com/addondomain

Would this be the reason?

RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

[g1smd]

Add a condition before that rule that says:
RewriteCond %{HTTP_HOST} !example\.com
where example.com in this line is the add-on.

[lucy24]

Do you have the kind of hosting where an "addon" domain lives in a directory inside your first domain's directory, as if it were a subdomain? If so, it does get stickier. (I've got the other configuration: a userspace which can contain one or more domains, and I can put htaccess files at either or both levels.)

You now will need two canonicalization redirects. One goes

RewriteCond {domain name that contains "firstexample"}
RewriteCond {but is not exactly www.firstexample.com}

and the other goes

RewriteCond {domain name that contains "secondexample"}
RewriteCond {but is not exactly www.secondexample.com}

[bluewaves]

Yes. The addon goes in a subfolder. None of my other subfolders with addon domains have been affected.

I am confused about first example and second example.

Is the first example the main domain with the second example being the addon?

Do I just write out the above and {bracket it?}

[g1smd]

Those are the conditions that go before the respective RewriteRules discussed just a couple of posts back, one for each rule. Use the normal RewriteCond {HTTP_HOST} syntax, those were shorthand examples.

[lucy24]

None of my other subfolders with addon domains have been affected.

Without naming names: Is it possible that the name of your latest addon overlaps your primary domain name? Or that one of the two is contained within the other? (The same thing you have to watch out for with subdomains.)

[bluewaves]

What a day. The hosting company got it working by adding some rewrites in the new sites' .htaccess file. They failed to tell me that they also tested a blank htaccess file on my main site and left it there. So my site was useless for 2 hours.

So the second domain is now working properly, but my main domain still has an issue with only one of it's directories. That directory shows the index.php page, but no other pages in the directory.

This is what I have for the redirects;

RewriteCond %{THE_REQUEST} index\.php
RewriteRule ^(([^/]+/)*)index\.php http://www.example.com/$1 [R=301,L]


RewriteCond %{THE_REQUEST} ^([^.]+)\.php
RewriteRule ^([^.]+)\.php http://www.example.com/$1 [R=301,L]


#Redirect all external .php requests to the extensionless urls
RewriteCond %{THE_REQUEST} ([^.]+)\.php
RewriteRule ^([^.]+)\.php http://www.example.com/$1? [R=301,L]


(When this is turned on - the result is 404 error - when it is off - it shows a redirect error)
#RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
#RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

#Rewrites extensionless requests to find the correct .php file
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(([^/]+/)*[^.]+)$ /$1.php [L]

[bluewaves]

G1smd: I am trying to make sense of what you told me to do.
Is this what you meant by your earlier suggestion?

RewriteCond %{HTTP_HOST} !addondomain\.com
RewriteCond %{HTTP_HOST} !^(www\.example\.com)?$
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]

[bluewaves]

Sorry - to update this - I now have only one file in a directory that won't show - simply shows the index.php file. But all the other files in the directory do show up fine.

[lucy24]

We're going to need more information :) Luckily the needed information doesn't involve divulging your domain name.

So what's the one troublemaking file? (Both its URL and its "real" filename.) Using Live Headers or similar, what happens step by step when you request it?

[bluewaves]

http://www.example.com/disneyxxxxx/tinkerbellxxxxxxxx

When requested, it returns this page:
http://www.example.com/disneyxxxxx/
no error message.

The hardcoded link on the page reads:
<li><a href="<?=$base_url?>/disneyxxxxx/tinkerbellxxxxxxx">Tinkerbell xxxxx</a><li>

Is that enough information?

Can you help me learn what these symbols mean in regards to the .htaccess file
?
*
$

[g1smd]

? - preceding character optional

()? - all the stuff inside ( ) optional

* - zero or more of the preceding item

$ - end anchor

^ - start anchor

. - any character

\. - a literal period

[bluewaves]

Thank you g1smd!

[lucy24]

What's hiding behind the xxxx? Anything other that simple alphanumerics? Tinkerbell wouldn't also be the name of a directory would she? Er, it.

[bluewaves]

Just words. No numbers.

[lucy24]

Mystifying, to be sure. Let's have the real names. If necessary, misspell something. But first test the misspelling and make sure it behaves the same as the correct spelling :) If it doesn't, you are that much closer to your explanation.*

#1 name of page that redirects to directory (You did say redirect, right, not silent rewrite?)

#2 name of directory

#3 name of some other random pages in same directory that behave as intended

Did you get any information from Live Headers? Save the result to a text file so you can spread it out and read at your leisure.


* Earlier today I spent several hours trying to figure out why the latest piwik didn't work. The problem turned out to be a line of seemingly unrelated code ... which, if absent, would have prevented the earlier versions from working. (And in fact did prevent them from working in several directories. All this time I thought I just hadn't got around to installing the tracker.) I do not pretend to understand this. But Live Headers definitely got a workout.

[bluewaves]

Well. I don't know a thing about the live headers. How do I find out about that?

RewriteRule ^tinkerbellbankchecks http://www.example.com/disneychecks/tinkerbellbankchecks [R=301,L]

[lucy24]

Live Headers is a Firefox add-on. I think there are equivalents in some other browsers, but Live Headers is the best known.

Essentially it gives you-as-user the same information the site owner gets. There's a text file that shows each consecutive browser request followed by the full response. So you'll see all your 301s and 404s and whatnot. It doesn't (and can't) show server-internal activity like includes and rewrites.

Tip: Unless you particularly need to track requests for peripheral files, I suggest going to the Config tab in Live Headers and set the "Exclude URLs with regexp" line to read something like

\.(jpg|ico|css|png|gif)$

That way, all it tracks is requests for pages. In most situations, that's all you are interested in.

[bluewaves]

Request URL:http://www.example.com
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:PHPSESSID=02537dd0cdb637c5c7d249b7124e21c8; cookie_sid=gan; __utma=135194467.1566611119.1362975138.1362975138.1362975138.1; __utmb=135194467.3.10.1362975138; __utmc=135194467; __utmz=135194467.1362975138.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Host:www.example.com
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22
Response Headersview source
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cache-Control:max-age=864000
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:3509
Content-Type:text/html
Date:Mon, 11 Mar 2013 04:16:46 GMT
Expires:Thu, 19 Nov 1981 08:52:00 GMT
Keep-Alive:timeout=10, max=30
Pragma:no-cache
Server:Apache
Vary:Accept-Encoding

****
I know this is getting off topic, but I found the headers and wondered why the headers show this expire: Expires:Thu, 19 Nov 1981 08:52:00 GMT - How can I change that?

My mystery page seems to be showing up in Safari and Chrome.

[bluewaves]

I have duplicate content issues now in webmastertools

I'm not sure what I did wrong, but the extensionless urls seems to be at the bottom of it.

I resubmited sitemaps of the new urls, to no avail.

[lucy24]

Are the old, with-extension URLs 301 redirecting to the new, extensionless forms? If so, any Duplicate Content issues should be transitory. It simply means that search engines are crawling the new URLs as they discover them, but have not yet learned that all of the old, previously indexed URLs are redirecting to the new URLs.

At least, that's your best-case scenario. And if you're redirecting properly, it's the most likely.

A sitemap is inclusive, not exclusive. That is: It doesn't say "Only these URLs exist, and none others." It only says "These URLs exist, in addition to any others you may happen to know about."

[bluewaves]

This:

RewriteCond %{THE_REQUEST} ([^.]+)\.php
RewriteRule ^([^.]+)\.php http://www.example.com/$1? [R=301,L]

takes care of all the redirects, doesn't it?

Any chance I could email you privately?

[lucy24]

Yup, if you've got the rule in place then everything is getting redirected. Assuming you've checked some random pages, either with Live Headers or looking directly at logs, and verified that the redirect is happening as intended.

Next step is to pick some random pages-- starting if possible with some specific ones that are prompting cries of Duplicate Content-- and see which versions g### has crawled.