Django\u2019s redirects framework lets you manage redirects easily by storing them in a database and treating them as any other Django model object. For example, you can use the redirects framework to tell Django, \u201cRedirect any request to \/music\/ to \/sections\/arts\/music\/.\u201d This comes in handy when you need to move things around on your site; Web developers should do whatever is necessary to avoid broken links.<\/p>\n
Using the Redirects Framework<\/strong> – To install the redirects application, follow these steps:<\/p>\n manage.py syncdb creates a django_redirect table in your database. This is a simple lookup table with site_id, old_path, and new_path fields. You can create redirects through either the Django admin interface or the Django database API.<\/p>\n Once you\u2019ve created redirects, the RedirectFallbackMiddleware class does all of the work. Each time any Django application raises a 404 error, this middleware checks the redirects database for the requested URL as a last resort. Specifically, it checks for a redirect with the given old_path with a site ID that corresponds to the SITE_ID setting. (See the earlier section \u201cSites\u201d for more information on SITE_ID and the sites framework.) Then it follows these steps:<\/p>\n The middleware only gets activated for 404 errors \u2014 not for 500 errors or responses of any other status code. Note that the order of MIDDLEWARE_CLASSES matters. Generally, you can put<\/p>\n RedirectFallbackMiddleware toward the end of the list, because it\u2019s a last resort.<\/p>\n Note<\/strong> – If you\u2019re using both the redirect and flatpage fallback middleware, consider which one (redirect or flatpage) you\u2019d like checked first. We suggest flatpages before redirects (thus putting the flatpage middleware before the redirect middleware), but you might feel differently.<\/p>\n\n
\n