Why Use a Plugin for Redirects?
If you have just a few static redirects, then your best bet is to put them in your
.htaccess file, or better yet, in your
.conf file for your virtual host. However, there are a number of cases where using a plugin to handle it is a better solution:
- If you have a large number of redirects, it will slow down every single request your web server handles unnecessarily if they are in
- Often the URL patterns from the legacy site do not match the new site URLs in a deterministic way, which makes creating redirects difficult
- Sometimes you don’t have access to the server config files, or you want to give your client the ability to manage redirects easily
Retour solves these problems:
- Retour only attempts to do a redirect after the web server has already thrown a 404 exception. Once a redirect mapping is successfully determined, it also caches the result for speedy resolution of the next redirect request.
- Retour also gives you the ability to do Dynamic Redirects that allow you to import a piece of legacy data into your entries to use as a key for determining the new URL mapping. In this way, utterly dissimilar URLs can be mapped for redirection effectively.
- It provides an easy to use GUI that the client can use from Craft’s Control Panel, and keeps statistics on the 404 hits (and misses)
A Word about .htaccess
People using the Apache webserver are familiar with the
.htaccess file, and may even be using it for redirects. It’s very likely that you should not be using
.htaccess at all; instead you should disable
AllowOverride none and make your configuration changes in your webserver configuration files. From Apache HTTP Server Tutorial: .htaccess files
There are two main reasons to avoid the use of .htaccess files. The first of these is performance. When AllowOverride is set to allow the use of .htaccess files, httpd will look in every directory for .htaccess files. Thus, permitting .htaccess files causes a performance hit, whether or not you actually even use them! Also, the .htaccess file is loaded every time a document is requested. Further note that httpd must look for .htaccess files in all higher-level directories, in order to have a full complement of directives that it must apply. (See section on how directives are applied.) Thus, if a file is requested out of a directory /www/htdocs/example, httpd must look for the following files: /.htaccess /www/.htaccess /www/htdocs/.htaccess /www/htdocs/example/.htaccess And so, for each file access out of that directory, there are 4 additional file-system accesses, even if none of those files are present. (Note that this would only be the case if .htaccess files were enabled for /, which is not usually the case.) In the case of RewriteRule directives, in .htaccess context these regular expressions must be re-compiled with every request to the directory, whereas in main server configuration context they are compiled once and cached. Additionally, the rules themselves are more complicated, as one must work around the restrictions that come with per-directory context and mod_rewrite. Consult the Rewrite Guide for more detail on this subject.
As you can see, avoiding the use of
.htaccess completely is best if at all possible, and especially avoid it for
RewriteRule directives, such as 404 rewrites.
You can read more in the Stop using .htaccess files! No, really. article.
Brought to you by nystudio107