Upgrade guide — django-registration 0.8 documentation

### Navigation

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

# Upgrade guide

The 0.8 release of django-registration represents a complete rewrite of the previous codebase, and introduces several new features which greatly enhance the customizability and extensibility of django-registration. Whenever possible, changes were made in ways which preserve backwards compatibility with previous releases, but some changes to existing installations will still be required in order to upgrade to 0.8. This document provides a summary of those changes, and of the new features available in the 0.8 release.

## Django version requirement

As of 0.8, django-registration requires Django 1.3 or newer; older Django releases may work, but are officially unsupported.

## Backwards-incompatible changes

If you’re upgrading from an older release of django-registration, and if you were using the default setup (i.e., the included default URLconf and no custom URL patterns or custom arguments to views), most things will continue to work as normal (although you will need to create one new template; see the section on views below). However, the old default URLconf has been deprecated and will be removed in version 1.0 of django-registration, so it is recommended that you begin migrating now. To do so, change any use of `registration.urls` to `registration.backends.default.urls`. For example, if you had the following in your root URLconf:

    (r'^accounts/', include('registration.urls')),

you should change it to:

    (r'^accounts/', include('registration.backends.default.urls')),

The older include will continue to work until django-registration 1.0; in 0.8 it raises a `PendingDeprecationWarning` (which is ignored by default in Python), in 0.9 it will raise `DeprecationWarning` (which will begin printing warning messages on import) and in 1.0 it will be removed entirely.

### Changes to registration views

The views used to handle user registration have changed significantly as of django-registration 0.8. Both views now require the keyword argument `backend`, which specifies the registration backend to use, and so any URL pattern for these views must supply that argument. The URLconf provided with the default backend properly passes this argument.

The `profile_callback` argument of the `register()` view has been removed; the functionality it provided can now be implemented easily via a custom backend, or by connecting listeners to the signals sent during the registration process.

The `activate()` view now issues a redirect upon successful activation; in the default backend this is to the URL pattern named `registration_activation_complete`; in the default setup, this will redirect to a view which renders the template `registration/activation_complete.html`, and so this template should be present when using the default backend and default configuration. Other backends can specify the location to redirect to through their `post_activation_redirect()` method, and this can be overridden on a case-by-case basis by passing the (new) keyword argument `success_url` to the `activate()` view. On unsuccessful activation, the `activate()` view still displays the same template, but its context has changed: the context will simply consist of any keyword arguments captured in the URL and passed to the view.

### Changes to registration forms

Previously, the form used to collect data during registration was expected to implement a `save()` method which would create the new user account. This is no longer the case; creating the account is handled by the backend, and so any custom logic should be moved into a custom backend, or by connecting listeners to the signals sent during the registration process.

### Changes to the `RegistrationProfile` model

The `create_inactive_user()` method of `RegistrationManager` now has an additional required argument: `site`. This allows django-registration to easily be used regardless of whether `django.contrib.sites` is installed, since a `RequestSite` object can be passed in place of a regular `Site` object.

The `user_registered` signal is no longer sent by `create_inactive_user()`, and the `user_activated` signal is no longer sent by `activate_user()`; these signals are now sent by the backend after these methods have been called. Note that these signals were added after the django-registration 0.7 release but before the refactoring which introduced the backend API, so only installations which were tracking the in-development codebase will have made use of them.

The sending of activation emails has been factored out of `create_inactive_user()`, and now exists as the method `send_activation_email()` on instances of `RegistrationProfile`.

### Navigation

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