Setting up 301 redirect in .HTACCESS, except some folders at root leve

Setting up 301 redirect in .HTACCESS, except some folders at root level

[joydeep]

Hi,

We have a WordPress website, which have over 2000 posts (at root level) and normally our URL structure is: http://www.example.com/post-name/

Now we want to move all these posts inside the "blog" folder (except some folders).
Example: http://www.example.com/blog/post-name/

I tried .HTACCESS Redirect Conditions. Below is my code, but it seems not to be working, what am I doing wrong?

RewriteEngine on
RewriteBase /

## list conditions for redirecitons: by equality or inequality, as needed
RewriteCond %{http_host} !^www.example.com$ [nc]
RewriteCond %{THE_REQUEST} !^.*\/index\.php\ HTTP/
RewriteCond %{THE_REQUEST} !^.*\/catalog\/*\ HTTP/
RewriteCond %{THE_REQUEST} !^.*\/some-folder-not-to-be-moved\/*\ HTTP/
### and so on, whatever conditions
RewriteRule ^(.*)$ http://www.example.com/$1 [r=301,nc,L]

[g1smd]

Why are you testing the host name in the first condition?

The / does not need to be escaped.

/* means "one or more slashes".

Literal periods should be escaped.

.* at the beginning of a RegEx pattern is always wrong. See the previous few thousand times it has been mentioned here. :)

Matching the GET / part of the request is easily performed with ^[A-Z]{3,9}\ /

.* in the middle of a pattern is always wrong too.

You mentioned you are moving to /blog/ in the new URLs, yet /blog/ appears nowhere in your code.

[lucy24]

This bit

 !^.*\/index\.php

is not simply wrong, it's unnecessary. It means "there may or may not be some stuff before the part I'm interested in". You can achieve exactly the same thing by simply saying

!/index\.php$

You probably should anchor the closing php, just in case there's some weirditude going on. Oh, and the whole set of conditions can be given as

!/(catalog|protectedplace|othergoodplace)/?

Both of the directory slashes go outside the parentheses so they can be shared by all items. With some further jiggery-pokery you could put "index.php" into the same package, but it may be safer to keep directories and files on separate lines.

And, yes, ahem, you forgot /blog in your Rule. As written, the Rule simply changes things back into exactly what they were before.

[killahbeez]

@g1msd

/* means "ZERO or more slashes".

[g1smd]

Yep. Typo. Spotted it long after the post was closed from further editing.

What I meant to say was that it would match multiple slashes like

example.com/something/catalog//////

which is obviously not intended.

[joydeep]

@g1msd this is what I am using right now and still facing the problem, now it is redirecting to blog folder multiple times.

E.g.

http://www.example.com/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/post-name/

######################################

Options +FollowSymlinks
RewriteEngine On

RewriteCond %{http_host} !^www.example.com$ [nc]

RewriteCond %{REQUEST_URI} !^/misc
RewriteCond %{REQUEST_URI} !^/images
RewriteCond %{REQUEST_FILENAME} !^(.+)\.css$
RewriteCond %{REQUEST_FILENAME} !^(.+)\.js$
RewriteCond %{REQUEST_FILENAME} !^(.+)\.ico$

RewriteRule ^(.*)$ http://www.example.com/blog/$1 [r=301,nc,L]

[lucy24]

now it is redirecting to blog folder multiple times

Well, you told it to. You didn't tell it to stop after the first, tenth or fiftieth recursion. Remember, it's just a dumb machine.

Every time you redirect (as opposed to rewrite), the request has to go outside and start over again as if it had never before set foot in your domain. The name

http://www.example.com/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/blog/post-name/

still meets all the conditions in your RewriteRule and RewriteCond, so mod_rewrite will dutifully attach a fresh /blog in front of all the existing ones.

Your Conditions need cleaning-up anyway. There are only two after the (sub)domain-name one. Possibly even one, if your filenames are old-fashioned decently dressed ones with .php at the end.

EITHER
RewriteCond %{REQUEST_URI} !^/(misc|images|blog)
RewriteRule ([^.]+\.php)$ http://www.example.com/blog/$1 [r=301,nc,L]

OR
RewriteCond %{REQUEST_URI} !^/(misc|images|blog)
RewriteCond %{REQUEST_FILENAME} !\.(css|js|ico)$
RewriteRule (.*)$ http://www.example.com/blog/$1 [r=301,nc,L]
You only need an anchor if you're looking for specific beginning text and/or ending text, because Regular Expressions will always start grabbing as soon as they can and go on for as long as they can. So the first Condition needs only an opening anchor, and the second one needs only a closing anchor.

[joydeep]

Hi lucy24 - I changed it as per your instructions, still getting this error in FF

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
This problem can sometimes be caused by disabling or refusing to accept cookies.

[lucy24]

Well, it's nice of FF to suggest a diagnosis, but it can hardly be a cookie issue when you haven't even got to the page in the first place :)

To backtrack... What was the reason for checking the hostname in a Condition? Thankfully this isn't one of those subdomain redirects where you start with blahblah.example.com and if the blahblah is anything other than www. you rewrite.

I'm now looking at

RewriteCond %{http_host} !^www.example.com$ [nc]

and thinking that if you exclude the canonical form of the hostname-- which should be given as

!^(www\.example\.com)?$ [NC]

but that shouldn't affect the behavior of the rule-- then what does the rule apply to? That's assuming you are showing that piece of your htaccess as-is, not skipping a chunk in the middle so you've accidentally included a piece of a different rule.

If you sit at your browser and type in

www.example.com/blog/blahblah

do you get redirected to

www.example.com/blog/blog/blahblah

or does FF immediately say "I'm not touching this one because it will lead to no good"? I've been mildly suspicious of Live Headers ever since I saw it showing me a 304 (which in fact was what I expected) while the server calmly returned a 200.