The following are miscellaneous common questions and answers related to installing/using django-registration-redux, culled from bug reports, emails and other sources.
- What license is django-registration-redux under?
- django-registration-redux is offered under a three-clause BSD-style
license; this is an OSI-approved open-source license, and allows
you a large degree of freedom in modifiying and redistributing the
code. For the full terms, see the file
LICENSEwhich came with your copy of django-registration-redux; if you did not receive a copy of this file, you can view it online.
- Why are the forms and models for the default backend not in the default backend?
The model and manager used by the default backend are in
registration.models, and the default form class (and various subclasses) are in
registration.forms; logically, they might be expected to exist in
registration.backends.default, but there are several reasons why that’s not such a good idea:
- Older versions of django-registration-redux made use of the model and
form classes, and moving them would create an unnecessary
importstatements would need to be changed, and some database updates would be needed to reflect the new location of the
- Due to the design of Django’s ORM, the
RegistrationProfilemodel would end up with an
default, which isn’t particularly descriptive and may conflict with other applications. By keeping it in
registration.models, it retains an
registration, which more accurately reflects what it does and is less likely to cause problems.
- Although the
RegistrationProfilemodel and the various form classes are used by the default backend, they can and are meant to be reused as needed by other backends. Any backend which uses an activation step should feel free to reuse the
RegistrationProfilemodel, for example, and the registration form classes are in no way tied to a specific backend (and cover a number of common use cases which will crop up regardless of the specific backend logic in use).
- Older versions of django-registration-redux made use of the model and form classes, and moving them would create an unnecessary backwards incompatibility:
Installation and setup¶
- How do I install django-registration-redux?
- Full instructions are available in the quick start guide.
- Do I need to put a copy of django-registration-redux in every project I use it in?
- No; putting applications in your project directory is a very bad
habit, and you should stop doing it. If you followed the
instructions mentioned above, django-registration-redux was installed
into a location that’s on your Python import path, so you’ll only
ever need to add
INSTALLED_APPSsetting (in any project, or in any number of projects), and it will work.
Do I need to rewrite the views to change the way they behave?
Not always. Any behavior controlled by an attribute on a class-based view can be changed by passing a different value for that attribute in the URLConf. See Django’s class-based view documentation for examples of this.
For more complex or fine-grained control, you will likely want to subclass
ActivationView, or both, add your custom logic to your subclasses, and then create a URLConf which makes use of your subclasses.
- I don’t want to write my own URLconf because I don’t want to write patterns for all the auth views!
- You’re in luck, then; django-registration-redux provides a URLconf which
only contains the patterns for the auth views, and which you can
include in your own URLconf anywhere you’d like; it lives at
- I don’t like the names you’ve given to the URL patterns!
- In that case, you should feel free to set up your own URLconf which uses the names you want.
I’ve got functions listening for the registration/activation signals, but they’re not getting called!
The most common cause of this is placing django-registration-redux in a sub-directory that’s on your Python import path, rather than installing it directly onto the import path as normal. Importing from django-registration-redux in that case can cause various issues, including incorrectly connecting signal handlers. For example, if you were to place django-registration-redux inside a directory named
django_apps, and refer to it in that manner, you would end up with a situation where your code does this:from django_apps.registration.signals import user_registered
But django-registration-redux will be doing:from registration.signals import user_registered
From Python’s point of view, these import statements refer to two different objects in two different modules, and so signal handlers connected to the signal from the first import will not be called when the signal is sent using the second import.
To avoid this problem, follow the standard practice of installing django-registration-redux directly on your import path and always referring to it by its own module name:
registration(and in general, it is always a good idea to follow normal Python practices for installing and using Django applications).
I want to use custom templates, but django keeps using the admin templates instead of mine!
To fix this, make sure that in the
settings.pythe entry for the
registrationapp is placed above
Tips and tricks¶
- How do I log a user in immediately after registration or activation?
- Take a look at the implementation of the simple backend, which logs a user in immediately after registration.
- How do I re-send an activation email?
- Assuming you’re using the default backend, a custom admin action
is provided for this; in the admin for the
RegistrationProfilemodel, simply click the checkbox for the user(s) you’d like to re-send the email for, then select the “Re-send activation emails” action.
- How do I manually activate a user?
- In the default backend, a custom admin action is provided for
this. In the admin for the
RegistrationProfilemodel, click the checkbox for the user(s) you’d like to activate, then select the “Activate users” action.