Django’s 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, “Redirect any request to /music/ to /sections/arts/music/.” 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.
Using the Redirects Framework – To install the redirects application, follow these steps:
- Add ‘django.contrib.redirects’ to your INSTALLED_APPS.
- Add ‘django.contrib.redirects.middleware.RedirectFallbackMiddleware’ to your MIDDLEWARE_CLASSES
- Run the command py syncdb to install the single required table into your database.
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.
Once you’ve 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 “Sites” for more information on SITE_ID and the sites framework.) Then it follows these steps:
- If it finds a match, and new_path is not empty, it redirects to new_path.
- If it finds a match, and new_path is empty, it sends a 410 (“Gone”) HTTP header and an empty (contentless) response.
- If it doesn’t find a match, the request continues to be processed as usual.
The middleware only gets activated for 404 errors — not for 500 errors or responses of any other status code. Note that the order of MIDDLEWARE_CLASSES matters. Generally, you can put
RedirectFallbackMiddleware toward the end of the list, because it’s a last resort.
Note – If you’re using both the redirect and flatpage fallback middleware, consider which one (redirect or flatpage) you’d like checked first. We suggest flatpages before redirects (thus putting the flatpage middleware before the redirect middleware), but you might feel differently.
Adding, Changing, and Deleting Redirects – You can add, change and delete redirects in two ways:
Via the Admin Interface – If you’ve activated the automatic Django admin interface, you should see a “Redirects” section on the admin index page. Edit redirects as you would edit any other object in the system.
Via the Python API – Redirects are represented by a standard Django model that lives in django/contrib/redirects/models.py. Hence, you can access redirect objects via the Django database API, for example:
>> from django.contrib.redirects.models import Redirect
>> from django.contrib.sites.models import Site
>> red = Redirect(… site=Site.objects.get(id=1)
,… old_path=’/music/’
,… new_path=’/sections/arts/music/’
,… )
>> red.save()
>> Redirect.objects.get(old_path=’/music/’)
<Redirect: /music/ —> /sections/arts/music/>
