The User model in Django is intentionally basic, defining only the username, first and last name, password and email address. It’s intended more for authentication than for handling user profiles. To create an extended user model you’ll need to define a custom class with a ForeignKey to User, then tell your project which model defines the Profile class. In your settings, use something like:
AUTH_PROFILE_MODULE = 'accounts.UserProfile'
To make it easier to let users create and edit their own Profile data, James Bennett (aka ubernostrum), who is the author of Practical Django Projects and the excellent b-list blog, created the reusable app django-profiles. It’s a companion to django-registration, which provides pluggable functionality to let users register and validate their own accounts on Django-based sites.
Both apps are excellent, and come with very careful documentation. But here’s the rub: Bennett’s documentation style comes from the mind of an engineer, rather than an average user who just needs to get things done quickly. For people who write Django code every day and are intimately familiar with the official Django docs, they’re probably sufficient. For those of us who don’t have the luxury of being full-time programmers, who don’t live and breathe Django, they’re frustrating. Sample templates are not included, and no clues are given as to what should go in the templates you create. Likewise, the ability to customize the default behavior of the apps is only hinted at, not spelled out. Users coming from a CMS world where you install and configure a plugin and get instant functionality for your site quickly become frustrated.
From IRC logs, it appears that Bennett believes banging your head against a wall is a great way to learn. To an extent, that’s true. I know there’s no better way to learn a new tool than having to solve real-world problems with it. But at the same time, learning doesn’t only take place in the Django docs – it happens on mailing lists, in code samples on djangosnippets.org (which, by the way, is another of Bennett’s projects), and, yes, in documentation for add-on apps like django-profiles.
Let’s take an example: A developer wants to let users edit their own profiles. They get their Profile model registered, install django-profiles, and create a template at profiles/edit_profile.html. What goes in that template? Not much is needed, but the django-profiles docs don’t give you a clue (nor do they give you a clue where to find the answer in the Django docs). You’ll need something like this:
{% extends "base.html" %}
{% block title %}Edit Profile{% endblock %}
{% block content %}
<h1>Edit contact info for {{ user }}</h1>
<form action="" method="POST">{{ form }} <input id="submit" type="submit" name="submit" value="Update" /></form>
{% endblock content %}
Now access /profiles/edit/ and you’ll see all fields on your profile model represented with appropriate field types. So far so good. Now you probably want to customize two things, right off the bat. You may have fields on the profile that only administrators should be able to edit, and you want to hide those fields. And you may want to modify the success_url, to control where the user is sent after a successful form submission. The docs for django-profiles say that the provided edit_profile view takes optional form_class and success_url arguments. But how can you pass in arguments? You’re simply linking to the predefined URL /profiles/edit/ – there is no code of your own from which you can pass in arguments.
This is where things became inscrutable to me. I was at an impasse, with no clue or hint as to what to do next. If the django-profiles docs had included a link to the section of the Django docs that contained the answer (or some kind of directional indicator) I could have done the research and gotten things moving. Fortunately, a friend and fellow Django developer had been down this road before and had the solution. Here’s how the pieces connect:
First, you need to create a custom ModelForm based on your Profile model. If you don’t already have a forms.py in your app, create one, then add something like:
from django.db import models
from django.forms import ModelForm
from ourcrestmont.itaco.models import *
class ProfileForm(ModelForm):
class Meta:
model = Foo
exclude = ('field1','field2','field3',)
The idea is to pass your custom ModelForm to django-profiles with the name form_class, thereby overriding the default object of the same name. django-profiles will then operate against your custom ProfileForm rather than from a default representation of your Profile model. Once I understood this, the light went on and things started to snap into place.
Still, how can you pass this custom form_class to django-profiles, when there’s no view code in your own app to handle this? That’s where trick #2 comes in: The seldom-used ability to pass dictionaries of custom values in from your urlconf. So wiring things up now becomes a pretty straightforward task. In urls.py, import your custom form and pass it through to the django-profiles view, right before the reference to the django-profiles urlconf. Because Django will use the first matching URL it finds, you want to do this before the django-profiles-provided URL is found so you can override it.
from projname.appname.forms import ProfileForm
('^profiles/edit', 'profiles.views.edit_profile', {'form_class': ProfileForm,}),
(r'^profiles/', include('profiles.urls')),</pre>
You can pass in your custom success_url value in the same way:
<pre lang="python">from projname.appname.forms import ProfileForm
('^profiles/edit', 'profiles.views.edit_profile', {'form_class': ProfileForm,'success_url':'/my/custom/url',}),
(r'^profiles/', include('profiles.urls')),
Now access /profiles/edit/ again and you’ll find that the view is using your custom form definition, rather a default one derived from the profile model. Pretty easy once you see how the pieces fit together.
If you need even more control than that, there’s another alternative to passing a dict in through the urlconf – write your own view with the name edit_profile, overriding aspects of the provided view of the same name:
from profiles import views as profile_views from myprofiles.forms import ProfileForm def edit_profile(request): return profile_views.edit_profile(request, form_class=ProfileForm)
(I haven’t tried this method).
profile_detail and profile_list
django-profiles enables other templates as well. As documented, the “details” template lets you retrieve all data associated with a single profile by sending an object named “profile” to the template profile/profile_detail.html, e.g.:
<strong>Address 2:</strong>{{ profile.address2 }}
<strong>City:</strong>
{{ profile.city }}
It’s not quite so clear how to get a list of all profiles in the system. The docs say:
profiles/profile_list.html will display a list of user profiles, using the list_detail.object_list generic view
You’ll access the list view at /profiles/, with template code along the lines of:
{% for p in object_list %}
<a href="{% url profiles_profile_detail p.user %}">{{ p }}</a>>
{% endfor %}
(in other words you can ignore the “list_detail.” portion of the object name referenced in the docs).
Let Users Edit Their Own Email Addresses
A common task when editing profile data would be to change one’s email address. But since the email address is included in the User model and not in the Profile model, it doesn’t show up in the {{form}} object.
The solution is to add an email field to the Form object (not the Profile model – that would not be DRY), then put a custom save method on the form that retrieves the corresponding User and updates its email field. Here’s a complete ProfileForm that does all of the above. With a little tweaking, this will also let users edit their first and last names.
class ProfileForm(ModelForm):
def __init__(self, *args, **kwargs):
super(ProfileForm, self).__init__(*args, **kwargs)
try:
self.fields['email'].initial = self.instance.user.email
# self.fields['first_name'].initial = self.instance.user.first_name
# self.fields['last_name'].initial = self.instance.user.last_name
except User.DoesNotExist:
pass
email = forms.EmailField(label="Primary email",help_text='')
class Meta:
model = Profile
exclude = ('user',)
def save(self, *args, **kwargs):
"""
Update the primary email address on the related User object as well.
"""
u = self.instance.user
u.email = self.cleaned_data['email']
u.save()
profile = super(ProfileForm, self).save(*args,**kwargs)
return profile
With a few well-placed links and code samples, the django-profiles docs could be a great learning opportunity for this kind of Lego-like site construction. Until then, I’ll update this post with any other tips users provide on django-profiles implementation.
Despite my gripes about the docs, many thanks to Bennett for all of his excellent free code, writing, and other contributions to the Django community. And a ton of thanks to mandric for the golden ticket on how to wire up the pieces.
No missing profiles!
Update: Astute readers (OK, Enis in the comments :) will have noticed that the profile editing form works fine for users with existing profiles, but breaks for new users who don’t yet have profiles. The trick is to make sure there are no users in your system who don’t have profiles – having a profile must be a baseline requirement of your system.
You’ll need to create a signal that automatically generates a blank profile record whenever a User instance is created. You’ll also need to back-fill your database to make sure all old users have profiles. Here’s how I solved those problems.
# in models.py:
from django.db.models import signals
from bucket.signals import create_profile
# When model instance is saved, trigger creation of corresponding profile
signals.post_save.connect(create_profile, sender=User)</pre>
... and then the actual signal to be fired:
<pre lang="python"># in signals.py:
def create_profile(sender, instance, signal, created, **kwargs):
"""When user is created also create a matching profile."""
from bucket.models import Profile
if created:
Profile(user = instance).save()
# Do additional stuff here if needed, e.g.
# create other required related records
Now try creating a new User object, either via the admin or by registering, and check to make sure a corresponding blank Profile record has been created. If that’s working, all you need to do is back-fill your system so everyone has a profile. Something like this should do the trick:
$ python manage.py shell
from django.contrib.auth.models import User
from bucket.models import Profile
users = User.objects.all()
for u in users:
try:
p = u.get_profile()
except p.DoesNotExist:
Profile(user = u).save()
There is one potential gotcha if you’re starting out with a fresh system, or migrating to another database, etc. – if syncdb asks if you want to create a superuser and you say yes, that user will end up without a profile, because your fancy new signal can’t be invoked. You may then end up with some odd SQL errors when trying to syncdb later on. Solution: Skip that step and create your superuser later on (with manage.py createsuperuser).
That should do it!
Looking for a set of starter templates for django_profiles? Here is the set used on bucketlist.org (I am the developer for that site). You will of course need to hack and modify them to suit your needs.