@michela Hello, I tried something similar to what you said and then the email template overriding now works properly.

I moved 'django.contrib.admin' below 'registration' in my INSTALLED_APPS.

The admin app was having priority with template rendering over other apps.

Thank you.

from django-registration.

I'm able to reproduce this. Appears to have been introduced in 12aba22 when templates were added to the application. Django version should not matter here.

To reproduce this: Override registration/activation_email.txt but do not override registration/activation_email.html. The default .html template will be used in the emails.

Cause: The issue is that the code first looks for the .txt version of the template, and then checks for the .html version. It finds your .txt version just fine, but then finds the newly included .html template, and uses that instead.

Before 12aba22, no templates were included, so if you never created a .html version, your .txt version would be used.

It looks like you will now need to override registration/activation_email.html as well.

from django-registration.

@riklaunim this was addressed in #57.

The solution is to either override the registration/activation_email.html template or add the following to settings.py:

REGISTRATION_EMAIL_HTML = False

from django-registration.

I'll check this out.

from django-registration.

I have both .txt and .html templates

from django-registration.

This doesn't solve the problem. I've override both templates and more and still the .txt template is fetched in the original form (/env/lib/python3.4/site-packages/registration/templates/registration/activation_email.txt) which results in

django.core.urlresolvers.NoReverseMatch: Reverse for 'registration_activate' with arguments '('',)' and keyword arguments '{}' not found. 0 pattern(s) tried: []

from django-registration.

Able to repro error with Django 1.8.1/django-registration-redux==1.2c0/python2.7

riklaunim can you elaborate on your hack above so I can try it?

I can hack it by providing dirs value (either filtered or reversed):

Is this a patch to django-registration-redux?

from django-registration.

Ugly workaround for anyone else with broken password reset:

Move the django.contrib.admin.template out of the way so app templates used

./site-packages/django/contrib/admin/templates/registration$ mv password_reset_email.html password_reset_email.html.ori

Advice on cleaner approach pre-patch welcome!

from django-registration.

For django 1.7 you can pass a list of directories for the select_template and other methods:

from django.template.loaders.app_directories import app_template_dirs
dirs = sorted(app_template_dirs, reverse=True)

template = loader.select_template(MY_TEMPLATES_NAMES_HERE, dirs=dirs)

When it's reversed it finds my template first and uses it. For Django 1.8 the API is totally different and I don't know if there is an equivalent hack for this. It should work without hacks in the first place.

from django-registration.

I'm not able to reproduce the broken overrides. Can you post your settings.py? I'm curious about your INSTALLED_APPS, TEMPLATE_DIRS, and TEMPLATE_LOADERS settings. I'm also curious if you've seen this same issue with any other Django apps? I noticed that @michela mentioned not being able to override a built-in Django template as well. That leans me to believe this is not an issue with django-registration-redux, but an issue with template loading order in general.

from django-registration.

In INSTALLED_APPS registration is before my app. I have app_directories and filesystem loaders and reversing their order doesn't help either. Seems like other third party templates get overriden as before. TEMPLATES_DIR is not used.

from django-registration.

AMeng, I haven't seen this issue with any other apps. Stripped out legacy loaders that aren't used in Django 1.8 startproject script

TEMPLATE_LOADERS = (
'django.template.loaders.app_directories.Loader',
)
TEMPLATE_DIRS = (os.path.join(BASE_DIR, "templates"),)
INSTALLED_APPS = (
'django.contrib.staticfiles',
'django_extensions',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
# Uncomment the next line to enable the admin:
'django.contrib.admin',
# Uncomment the next line to enable admin documentation:
'django.contrib.admindocs',
'django_granular_permissions',
'prod',
'registration',
'rest_framework',
'debug_toolbar',

'django_mobile',

'django_nose',
'paypal.standard.ipn',
'django_jenkins',
'floppyforms',

)

from django-registration.

It's possible that an odd import of itself within django-registration causes Django to register the application or its templates to soon.

from django-registration.

https://docs.djangoproject.com/en/1.7/ref/templates/api/#django.template.loaders.app_directories.Loader INSTALLED_APPS order causes this.

The solution is to use TEMPLATE_DIRS:

BASE_DIR = os.path.dirname(os.path.dirname(__file__))
TEMPLATE_DIRS = (
    os.path.join(BASE_DIR, 'your_app/templates/'),
)

Or put templates in an application that can go before "registration" in INSTALLED_APPs (my app has some import/model dependencies so I would have to move the templates to blank new app).

from django-registration.

Sounds like this is just a side effect of including templates in a third party application. I don't think there is anything we can do within the project to improve this experience.

from django-registration.

For me this was caused by the following in settings.py:

TEMPLATE_DIRS = (
os.path.join(SITE_ROOT, 'templates'),
os.path.join(SITE_ROOT, 'templates/registration'),
)

Commenting out the second line fixed it. I was doing an upgrade from django 1.3 to 1.8 when I encountered the issue.

from django-registration.