Problems while redirecting in .htaccess

[tsdtsdtsd]

Hi,

I'm reworking and upgrading an old system to processwire. The old versions of that site have some 301 redirect from even older versions of the site.

What i did is, while deploying to the live server I prepend the redirects to the top of the PW htaccess automatically.

Two kinds of redirects look like this:

Redirect 301 /contact /legal

RedirectMatch  permanent  /index.php/k_radio.*  /knowhow

While checking the first redirect I had a strange behaviour which I can't explain. The old URL /contact should redirect to /legal. Instead it redirects to /legal?it=contact. The result is a 404. While /legal exists, PW tries to load another page with the "it" parameter and fails.

The RedirectMatch statement works perfect, only the Redirect 301 doesn't work.

The easy fix would be to use RedirectMatch for everything, but I want to understand what's the problem here

The Redirect should stop further processing of the htaccess, redirect, and start from top with the new url. I don't get why it doesn't

[arjen]

Hi, perhaps the excellent redirect plugin by Apeisa could be an option since the .htaccess may get replaced when you upgrade PW to a newer version.

[tsdtsdtsd]

Thanks arjen. I prefer the rewrites directly on apache because it's faster / uses less resources.

A new version from PW is not a problem for me, because i don't touch the original. While deploying to live server, a shell script automatically prepends my additions to it.

-- OFF-TOPIC --

Maybe someone is interested, i'll explain it in detail:

- I store my projects in private git repositories on bitbucket.org

- I have environment variables on my local machine, so I can differentiate in config.php which config is needed on runtime (like database, debug mode...). That allows me to have one version of the project which auomatically runs on live and development server

- when i want to do a live or preview update, i just start a shell script which:

1. creates a fresh clone of the repository in a subdirectory like "live-2012-06-28"

2. if needed, it sets chown and chmod for caching directories

3. it compresses my javascript and css files with yui-compressor (my environment switch will print out minified in live and normal scripts in development)

4. it checks for htaccess-extra files, which then get prepended or appended to the original .htaccess (like redirects, expires)

5. the docroot is not a folder, it's a symlink. final step is to set the symlink to the new updated folder

And thats it. I can make changes in my code without touching the PW core, push everything to git, and run the update script to deploy everything. If something goes wrong, I only have to reset the symlink to the previous version folder.

A second script does nearly the same, but instead deploying live it depoys to a preview subdomain. So i can check my changes on the live server environment first, before destroying the live

[ryan]

I'm not sure why you are getting that behavior with the redirects. I don't personally use this style of redirect, so don't know the options available. It does appear that it's getting your redirects mixed in with ProcessWire's rewrite rules. When you use a RewriteRule redirect, you add the 'L' option to it to prevent processing any more rules, like this:

RewriteRule ^about-us/?$ /about/ [R=301,L]

So I'm thinking you need the equivalent of the 'L' option in your redirects, but I don't know what the equivalent is for that type. If it were me, I'd just use the above style of Rewrite Engine rules, rather than Redirect/RedirectMatch. Though if you prefer the type you are using, I bet there would be a solution in Apache's Redirect/RedirectMatch docs. However, I find these a little difficult to wade through sometimes.

[tsdtsdtsd]

Thanks for your answer ryan.

Why I use Redirect/RedirectMatch instead of Rewrite is because it uses mod_alias, which does less logic and is therefor a tiny tiny tiny tiny tiny bit faster than mod_rewrite

But it doesn't matter for this project, it's not a high traffic site anyway.

I'm not sure, but this quote from the apache docs is maybe the explanation:

The new URL should be an absolute URL beginning with a scheme and hostname.

...

Redirect /service http://foo2.bar.com/service

If the client requests http://myserver/service/foo.txt, it will be told to access http://foo2.bar.com/service/foo.txt instead.

I used relative path for the destination, so i guess my redirect from /contact to /legal redirects to http://domain.com/legal/contact which is a 404. Doesn't explain why i get the extra ?it parameter but well... enough explanation for me

[ryan]

That extra "?it" parameter is coming from ProcessWire's RewriteRule at the bottom of your .htaccess. Somehow that RewriteRule is getting included in your redirect. But I'm also a loss to know why.

[DaveP]

Just spotted (via Google Webmaster Tools) that I had the same problem on one of my sites that had been migrated from Joomla. I had put 301 redirects in the .htaccess file, and must have tested them at the time, but they were having the '?it' parameter added as well.

To be honest, I have no idea why I didn't use Antti's excellent plugin in the first place, but I have now and of course everything now works as it should.

[hheyne]

In my case it helped to rename the index.php to pw.php. I had the problem that I had to redirect index.php?pageid=1&kategorie=5 to ProcessWire pages. After that I can successful use Antti's plugin.

[Mike Rockett]

There's also Jumplinks, which supports redirects containing index.php, without needing to rename it.