Built in password reset views resulting in Caught NoReverseMatch while rendering: Reverse for 'django.contrib.auth.views.password_reset_confirm'
Cromulent
I've read the documentation and this is what I have for my urls.py
file:
password_reset_dict = {
'post_reset_redirect' : '/profiles/login/',
'email_template_name' : 'registration/password_reset_email.html',
'template_name' : 'registration/password_reset_form.html',
}
password_reset_confirm_dict = {
'template_name' : 'registration/password_reset_confirm.html',
'post_reset_redirect':'/profiles/login/',
}
(r'^reset/$', 'django.contrib.auth.views.password_reset',
password_reset_dict),
(r'^reset/confirm/$',
'django.contrib.auth.views.password_reset_confirm', \
password_reset_confirm_dict),
(r'^reset/done/$', 'django.contrib.auth.views.password_reset_done'),
(r'^reset/complete/$',
'django.contrib.auth.views.password_reset_complete'),
The strange thing is that when the error comes back the generic view
does not seem to be using the templates that I have specified in the
dictionary, instead the error points to the internal
password_reset_email.html template and this line in particular:
{{ protocol }}://{{ domain }}{% url
django.contrib.auth.views.password_reset_confirm uidb36=uid
token=token %}
I've done a fair bit of Googling and tried the various methods
mentioned but the ones that seemed most promising require you to
change the template and as it does not actually get to my template I'm
at a bit of a loss.
Can anyone tell me where I am going wrong with this at all?
Any help is very much appreciated.
Cromulent
something other than the default value. This seems like a bug to me.
Surely Django should use a provided template if it is available and
only fall back on the built in ones as an absolute last resort?
Especially as I had specified in the dictionary the correct template
name and that they were available.
Mike Dewhirst
Have considered the sequence in which templates are loaded?
See http://docs.djangoproject.com/en/dev/ref/settings/
If you put the filesystem template loader ahead of the app_directories
django will find your own versions named identically with django
versions and use them instead.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.load_template_source',
'django.template.loaders.app_directories.load_template_source',
)
hth
Mike
Cromulent
Thanks for the response. I did think of that. My template loaders
setting is as follows:
TEMPLATE_LOADERS = (
'django.template.loaders.app_directories.Loader',
'django.template.loaders.filesystem.Loader',
)
all of my templates are stored in the template directory for each
individual Django application to save on cross dependencies or global
dependencies as I want to maximise the modularity of them. From
reading the docs the app_directories loader is the correct one for
this situation.
The problem with the filesystem loader is that you need to specify all
your template paths in the settings file, which is something I was
trying to avoid as the app_directories loader was what I wanted. I
guess the app_directories loader works on the order of apps listed in
the INSTALLED_APPS tuple?
On May 31, 2:05 am, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> Simon
>
> Have considered the sequence in which templates are loaded?
>
Mike Dewhirst
> Hi Mike,
>
> Thanks for the response. I did think of that. My template loaders
> setting is as follows:
>
> TEMPLATE_LOADERS = (
> 'django.template.loaders.app_directories.Loader',
> 'django.template.loaders.filesystem.Loader',
> )
>
> all of my templates are stored in the template directory for each
> individual Django application to save on cross dependencies or global
> dependencies as I want to maximise the modularity of them. From
> reading the docs the app_directories loader is the correct one for
> this situation.
I'm not sure this is correct but that is just my own uncertainty because
I haven't read those docs recently. However I took a different approach
which probably came from following one of the django books.
# if templates are not found here look in app_name/templates
TEMPLATE_DIRS = (os.path.join(PROJECT_ROOT, 'templates')
My PROJECT_ROOT is the path to settings.py
> The problem with the filesystem loader is that you need to specify all
> your template paths in the settings file, which is something I was
> trying to avoid as the app_directories loader was what I wanted.
As you can see I only specify one templates dir. If I want to use my own
templates for an imported app (or my own for that matter) I just create
a sub-directory in TEMPLATE_DIRS and give it the app name. Django just
knows where to look and uses any template it finds there in preference
to one of the same name in the installed site-packages app.
Cheers
Mike
> I guess the app_directories loader works on the order of apps listed in
> the INSTALLED_APPS tuple?
I don't know. You'd need to lok at the gjango source to get that.