0đź‘Ť
I think the neatest way to accomplish what you look for would be to fork django-registration, and in your app use the fork instead of the original project.
That being said, you can have a non-email registration in django-registration without changing the code of the app. I’ve done it by creating a custom registration backend that sets the users as activated upon creation. Here you can see other ways to do the same.
19đź‘Ť
In general, you should reuse and override the behavior in 3rd party apps and not modify their sources.
What you’ll most often encounter is that apps ship models that may not necessarily cover your needs, but do most of the work; you’ll have forms that are almost perfect, but need that little something; you’ll have views that would be perfect if you can just change one thing; you’ll have URLs that are sane, but you need something more from them.
In most cases, that would just require that you create a custom app and rewire everything. Ship your own URLs that map to views that you’ve extended and overrode methods for custom behavior; supply it with a model form who’s Meta
is using the new model that you’ve extended from the original; so forth…
That’s just the tip of the iceberg of what you can do, there’s more ways when your creative. I can give you an example of how I’ve used the RegistrationProfile
model, but shipped my own URL patterns and a custom class-based view that handled the registration process.
Now, where virtualenv comes into play is that you’ll most likely be using pip to specify and supply your required dependencies in the requirements file format. That’s when you want to say: “I’ve extended the django-registration app, but it won’t work cleanly with just any version. It has to be of release X”, or , “a checkout from the repository of commit Y”.
- Django, python3, on install I get: "Parent module 'setuptools' not loaded"
- Big integer field in django models
- Should I use google-app-engine-django or app-engine-patch or neither or something else?
- X-editable inline editing in Django – how to get CSRF protection?
- Amazon s3 and django – Allow only the users from my website and not the anonymous users
12đź‘Ť
This blog post that adresses this issue is extremely helpful. For convenience I copy-paste it here:
You don’t touch external app code
You are not supposed to edit the code from an external app. Unless you fork it first on github.
So, how to override without forking:
Overriding a template
If you want to override templates/userena/activate_fail.html
, then all you have to do is create your own templates/userena
directory and make your own activate_fail.html
in it.
Overriding a url
Probably the first thing you should check in an external app is its urls.py. Views that are properly coded should support plenty of arguments. For example, userena has a signup view with such a signature (at the time of writing):
def signup(request, signup_form=SignupForm,
template_name='userena/signup_form.html', success_url=None,
extra_context=None):
This means that you can replace the form used by the signup view. To do so, open your urls.py, add what we are going to need at the top:
from userena import views as userena_views
from yourforms import YourSignupForm
Then, find the include the external app’s urls, something like:
url(r'^userena/', include('userena.urls')),
Before that, add your url override:
url(r'^userena/signup/$', userena_views.signup, {'signup_form': YourSignupForm}, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Now, your custom url definition will be the first to be hit when a visitor hits /userena/signup/
. Which means that /userena/signup/
will use YourSignupForm instead of userena’s signup form.
This trick works with any view argument. The ones you should see the most often are:
template_name
: lets you change the template nameextra_context
: lets you add a dict that will be added to the
context
Almost every view should have these arguments.
Overriding a view
Overriding a view requires to override the url of the view you want to replace. If you want your own signup view to be used, then just override the url:
import yourviews
# ...
url(r'^userena/signup/$', yourviews.yoursignup, name='userena_signup'),
url(r'^userena/', include('userena.urls')),
Decorating a view
Decorating a view is like overriding a view, but reuses the external app’s view. Basically, it’s the same than overriding a view (see above), but your view will look like this
from userena import views as userena_views
def yoursignup(request):
# do stuff before userena signup view is called
# call the original view
response = userena_views.signup(request)
# do stuff after userena signup view is done
# return the response
return response
Forking an app
If you are not familiar with pip and virtualenv first, please read the post about using pip and virtualenv first.
For example:
- You installed django-userena as such: pip install django-userena
- First you should uninstall it: pip uninstall django-userena
- Then go on the app’s github page
- Click on the fork button
- This will make you a repository with a copy of django-userena
- Install it as such: pip install -e
git+git@github.com:your-username/django-userena.git#egg=django-userena - Then you can edit the code in yourenv/src/django-userena
- Push your commits
Credits to the post writer!
- Command 01_migrate failed on Amazon Linux 2 AMI
- Heroku Upload – Could not find a version that satisfies the requirement anaconda-client==1.4.0
- RuntimeError: Model class xxx doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS
- Change default Django REST Framework home page title
- Django Inner Join Queryset