Release notes — django-registration 0.8 documentation

### Navigation

- index
- modules |
- next |
- previous |
- django-registration 0.8 documentation »

# Release notes

The 0.8 release of django-registration represents a complete rewrite of the previous codebase, and as such introduces a number of new features and greatly enhances the flexibility and customizability of django-registration. This document summarizes those features; for a list of changes which impact existing installations, consult the upgrade guide.

## The backend system

The largest overall change consists of factoring out the logic of user registration into pluggable/swappable backend classes. The registration views now accept a (required) argument, `backend`, which indicates the backend class to use, and that class has full control over the registration (and, if needed, activation) process, including:

- Determining whether registration will be allowed at all, on a per-request basis.
- Specifying a form class to use for account registration.
- Implementing the actual process of account creation.
- Determining whether a separate activation step is needed, and if so what it will entail.
- Specifying actions to take (e.g., redirects, automatic login, etc.) following successful registration or activation.

For full details, see the documentation for the backend API.

The workflow used by previous releases of django-registration (two-step registration/activation) has been implemented using this system, and is shipped as the default backend in django-registration 0.8.

## Other new features

An alternate one-step registration system is provided, for use by sites which do not require a two-step registration/activation system.

During the registration and (optional) activation process, custom signals are now sent, allowing easy injection of custom processing into the registration workflow without needing to write a full backend.

The default backend now supplies several custom admin actions to make the process of administering a site with django-registration simpler.

The `activate()` view now supplies any captured keyword arguments from the URL (in the case of the default backend, this is the activation key) to its template in case of unsuccessful activation; this greatly simplifies the process of determining why activation failed and displaying appropriate error messages.

### Navigation

- index
- modules |
- next |
- previous |
- django-registration 0.8 documentation »