Redmine 0.9.0 offers tons of improvements but one among all forced my decision to upgrade without waiting for a final release: Rails 2.3.5. Redmine 0.8.x is built on Rails 2.1.0 and there seems to be some kind of weird Rails-Redmine-Passenger-Ruby EE memory leaks.

With the new release, Redmine has changed the most part of its URLs. The development team basically migrated all routes to a more RESTful-oriented architecture. They did a wonderful job, unfortunately they probably chose the worst way to ensure backward-compatibility: duplication.

All the old routes are still available along with the new ones and this can cause several duplicate content issues. To patch the problem, I configured some Apache redirection rules in order to permanently redirect the old URLs to the new ones.

The gist doesn’t pretend to solve all issues. It’s just a quick and (quite) dirty fix.

From Redmine side, I would have setup a Rails Metal to redirect all the old URLs to the new ones. This is not as efficient as relying on the web server, but this is compatible with any user environment.

Feel free to fork, clone and update the gist. After all, this is a Git repository!

Related posts

1. Configuring a Git repository with Redmine
2. Apache .htaccess query string redirects
3. Generic Apache configuration snippets

If you need to mass-redirect a group of pages you would probably need to use the RedirectMatch directive.

This will redirect any page from the oldfolder to the corresponding one in newfolder with a convenient one-by-one redirect.

Unfortunately, either Redirect nor RedirectMatch allow you to specify a query string for the redirect source. It other words, the following statements are invalid and they will simply be ignored.

The solution requires to change the focus from mod_alias to mod_rewrite. Here’s an example.

Let me explain the solution for those who wants to learn and not only to copy.

The first line enables the RewriteEngine module. Please note that mod_rewrite Apache module must be installed and enabled in order to use the RewriteEngine.

The RewriteCond statements set all the rewrite conditions. The forth line, the real rewrite directive, will be executed if and only if all conditions are satisfied by the current request.

First I want to check the request is for the page I need to redirect. Skipping this condition might cause some unexpected behavior if other pages in my website are using the id parameter. Then I want to base the rewrite rule on the value for the current request query string. Be sure to wrap the id value within a regular expression match to be able to reuse the match later as a back-reference.

Finally I can write my redirection rule. This line looks like a RedirectMatch statement. First I specify the pattern for the redirection source, then the redirection target. As you can see, the value for the id parameter captured by the last RewriteCond is referenced in the target with the %N keyword.

The comma separated values at the end of the RewriteRule line define which flags should be applied for this rule. I want to setup a 302 Redirection and be sure Apache won’t execute any other rule after this one.

PS. If you suffer from “write-as-less-as-possible” sickness you might want to change the original rewrite statement with

Related posts

1. Apache RewriteRule and query string
2. Generic Apache configuration snippets
3. Apache Log Regex: a lightweight Ruby Apache log parser