Upgrading from previous versions¶
Prior to 2.0, the last widely-deployed release of
django-registration
was 0.8; a 1.0 release was published, and
2.0 is mostly backwards-compatible with it, but 1.0 appears not
to have seen wide adoption. As such, this guide covers the process of
upgrading from django-registration
0.8, as well as from 1.0.
Backends are now class-based views¶
In django-registration
0.8, a registration workflow was
implemented as a class with specific methods for the various steps of
the registration process. In django-registration
2.0, a
registration workflow is implemented as one or more class-based views.
In general, the required changes to implement a 0.8 registration
workflow in django-registration
2.0 is:
0.8 backend class implementation | 2.0 view subclass implementation |
---|---|
Backend class implementing register() |
registration.views.RegistrationView.register() |
Backend class implementing activate() |
registration.views.ActivationView.activate() |
Backend class implementing registration_allowed() |
registration.views.RegistrationView.registration_allowed() |
Backend class implementing get_form_class() |
registration.views.RegistrationView.get_form_class() |
Backend class implementing post_registration_redirect() |
registration.views.RegistrationView.get_success_url() |
Backend class implementing post_activation_redirect() |
registration.views.ActivationView.get_success_url() |
URLconf changes¶
If you were using one of the provided workflows in
django-registration
0.8 without modification, you will not need to
make any changes; both registration.backends.default.urls
and
registration.backends.simple.urls
have been updated in
django-registration
2.0 to correctly point to the new
class-based views:
0.8 URLconf view reference | 2.0 URLconf view reference |
---|---|
registration.views.register |
registration.views.RegistrationView.as_view() |
registration.views.activate |
registration.views.ActivationView.as_view() |
However, if you were using the two-step model-activation workflow, you
should begin referring to
registration.backends.model_activation.urls
instead of
registration.backends.default.urls
or registration.urls
, as
the latter two are deprecated and support for them will be removed in
a future release.
If you were passing custom arguments to the built-in registration views, those arguments should continue to work, so long as your URLconf is updated to refer to the new class-based views. For details of how to pass custom arguments to class-based views, see the Django class-based view documentation.
Template changes¶
When using RegistrationForm
, the error
from mismatched passwords now is attached to the password2
field
rather than being a form-level error. To check for and display this
error, you will need to change to accessing it via the password2
field rather than via non_field_errors()
or the __all__
key in
the errors dictionary.
Changes since 1.0¶
If you used django-registration
1.0, or a pre-release checkout of
the 2.0 code, you will need to make some minor adjustments.
If you previously used registration.backends.default
, you will now
see deprecation warnings, as the former “default” workflow is now
found in registration.backends.model_activation
. Use of
registration.backends.default
continues to work in
django-registration
2.0, but will be removed in the future.
Similarly, references to registration.urls
should become
references to registration.backends.model_activation.urls
, and
registration.urls
is deprecated and will be removed in a future
release.
If you had written custom subclasses of
RegistrationView
or of
RegistrationView
subclasses in the built-in workflows, the
following changes need to be noted:
- The
register
method now receives theRegistrationForm
instance used during signup, rather than keyword arguments corresponding to the form’scleaned_data
. RegistrationForm
itself is now a subclass of Django’s built-inUserCreationForm
, and as such is now aModelForm
subclass. This can cause metaclass conflict errors if you write a class which is a subclass of bothRegistrationForm
and a non-ModelForm
form class; to avoid this, ensure that subclasses ofRegistrationForm
and/orModelForm
come first in your subclass’ method resolution order.- As noted above, the password-mismatch error message is now attached
to the
password2
field rather than being a form-level error.