bluewaves
msg:4549887 | 4:16 pm on Feb 28, 2013 (gmt 0) |
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
msg:4549996 | 12:29 am on Mar 1, 2013 (gmt 0) |
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
msg:4550001 | 1:00 am on Mar 1, 2013 (gmt 0) |
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
msg:4550009 | 2:13 am on Mar 1, 2013 (gmt 0) |
| 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
msg:4552414 | 4:38 am on Mar 8, 2013 (gmt 0) |
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
msg:4552485 | 8:55 am on Mar 8, 2013 (gmt 0) |
Add a condition before that rule that says:
RewriteCond %{HTTP_HOST} !example\.com
where example.com in this line is the add-on.
|
lucy24
msg:4552513 | 10:53 am on Mar 8, 2013 (gmt 0) |
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
msg:4552647 | 3:55 pm on Mar 8, 2013 (gmt 0) |
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
msg:4552675 | 6:01 pm on Mar 8, 2013 (gmt 0) |
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
msg:4552729 | 10:31 pm on Mar 8, 2013 (gmt 0) |
| 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
msg:4552737 | 11:23 pm on Mar 8, 2013 (gmt 0) |
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
msg:4552739 | 11:28 pm on Mar 8, 2013 (gmt 0) |
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
msg:4552741 | 11:44 pm on Mar 8, 2013 (gmt 0) |
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
msg:4552802 | 5:31 am on Mar 9, 2013 (gmt 0) |
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
msg:4552873 | 2:46 pm on Mar 9, 2013 (gmt 0) |
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
msg:4552875 | 2:56 pm on Mar 9, 2013 (gmt 0) |
? - 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
msg:4552879 | 3:32 pm on Mar 9, 2013 (gmt 0) |
Thank you g1smd!
|
lucy24
msg:4552981 | 2:47 am on Mar 10, 2013 (gmt 0) |
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
msg:4553012 | 4:47 am on Mar 10, 2013 (gmt 0) |
Just words. No numbers.
|
lucy24
msg:4553016 | 6:35 am on Mar 10, 2013 (gmt 0) |
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
msg:4553263 | 2:23 am on Mar 11, 2013 (gmt 0) |
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
msg:4553264 | 2:40 am on Mar 11, 2013 (gmt 0) |
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
That way, all it tracks is requests for pages. In most situations, that's all you are interested in.
|
bluewaves
msg:4553276 | 4:23 am on Mar 11, 2013 (gmt 0) |
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
msg:4553679 | 12:12 am on Mar 12, 2013 (gmt 0) |
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
msg:4553696 | 12:43 am on Mar 12, 2013 (gmt 0) |
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
msg:4554019 | 6:47 pm on Mar 12, 2013 (gmt 0) |
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
msg:4554100 | 9:56 pm on Mar 12, 2013 (gmt 0) |
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.
|
| This 57 message thread spans 2 pages: < < 57 ( 1 [2] ) |
|
|
