Django 1.8 Tutorial – 5. Django Registration Redux

This text is a work in progress. I’m not even done with this part myself.

In doing some digging, I found out that the leading registration app, django-registration, was abandoned. Some time later, django-registration-redux picked up the ball and has maintained it. There’s also another alternative django-allauth, which does registration and integrates with social sites.

The instructions for django-registration-redux are pretty good. Just read through them, and consider this tutorial just a slight gloss of what’s covered, plus some specifics about our demo app.

First, add ‘registration’ to the apps, and define ACCOUNT_ACTIVATION_DAYS and REGISTRATION_AUTO_LOGIN.

Registration includes some urlpatterns from the django auth. You should put the registration urls before the django auth urls.

    url(r'^accounts/', include('registration.backends.default.urls')),
    url(r'^accounts/', include('django.contrib.auth.urls')),

When you order them like this, the registration urls will be handled first, then the default auth will capture the old URLs.

Though the old urls and the new ones can co-exist, it’ll just confuse people when there are multiple login and logouts. It also confuses developers, so you should fix things to prefer the new urls.

The names of the old urls in registration are different – they start with “auth_”, so “login” is now “auth_login”. “logout” is now “auth_logout”, and so forth. Here’s the list:

^accounts/ ^activate/complete/$ [name='registration_activation_complete']
^accounts/ ^activate/(?P<activation_key>w+)/$ [name='registration_activate']
^accounts/ ^register/complete/$ [name='registration_complete']
^accounts/ ^register/closed/$ [name='registration_disallowed']
^accounts/ ^register/$ [name='registration_register']
^accounts/ ^login/$ [name='auth_login']
^accounts/ ^logout/$ [name='auth_logout']
^accounts/ ^password/change/$ [name='auth_password_change']
^accounts/ ^password/change/done/$ [name='auth_password_change_done']
^accounts/ ^password/reset/$ [name='auth_password_reset']
^accounts/ ^password/reset/complete/$ [name='auth_password_reset_complete']
^accounts/ ^password/reset/done/$ [name='auth_password_reset_done']
^accounts/ ^password/reset/confirm/(?P<uidb64>[0-9A-Za-z_-]+)/(?P<token>.+)/$ [name='auth_password_reset_confirm'] 

You’ll need to update your templates to reflect this change.

Just look for login, logout, password_reset, password_change, and fix them. (If you’re on Unix, you can use grep.)

I had to change comment_list.html, login.html, logged_out.html, password_reset_email.html, password_reset_email_html.html.

You must also alter the URL config in the file that enables the HTML email for password resets, so it overrides the new password changing URL and has the name “auth_password_reset”.


At this point, the system should function, except there’s no registration. You need to make the following templates. See the docs for details about what variables are defined in the context.


These are all in the tgz file.

If you’d rather start from scratch, here’s a command to create the files.

cd templates; cd registration; touch registration_form.html registration_complete.html activate.html activation_complete.html activation_email_subject.txt activation_email.txt activation_email.html

You can also find templates on Github and in some packages.

A small modification
A view with a few links was added to the root of the site. This is to make it easier to test the registration features.

I’m going to do Allauth soon, but not yet. It’s a bit more involved than this.

Attachment Size
minimal5.tgz 16.74 KB