Django-allauth: Make it easy to override templates by moving them to allauth subdirectory

[owais]

Right now the templates sit at root of the templates directory which makes it harder to override some templates.

For example, to override the base.html template, one has to put base.html in projects templates directory but projects might have their own base.html. Some projects might have account subdirectory in templates causing more conflicts.

The solution to this would be to put all the templates under a directory called 'allauth' so base.html will become allauth/base.html.

This way anyone can override any template from allauth very easily.

Django's admin app does exactly this and makes it very easy to override template without causing conflicts with project's or other apps' templates.

[pennersr]

All templates inherit (either directly or indirectly) from account/base.html.
The base.html is only used by account/base.html.

So, it is already very well possible to change the template base used by allauth by just touching account/base.html.

As for putting things below "allauth" -- this I do not agree with. It is Django convention to have the directory in which the templates and static files reside correspond 1:1 with the app name. In our case, "allauth" is not the app name, "account" and "socialaccount" are the app names. You cannot have 2 apps in the same Django project with identical names -- this is not supported by Django. So, there cannot/should not be another app (besides the allauth account app) that puts stuff below "account/".

So, the only thing I see that could be improved is removing the top "base.html" file completely.

[owais]

I see. I was of the impression that every template inherits from "base.html". If everything inherits from "account/base.html" then we are golden. I guess removing "base.html" can be a good move. It'll reduce confusion.

Also, it should probably be mentioned in docs that "account/base.html" is the mother of all templates.

[sayguno]

This issue gave me some headaches too recently. Although it is not a big deal, I think that all templates should go into allauth directory just for namespacing purposes. I don't think it is against Django conventions. For example, if we consider the project settings file when including 'account' application we put the setting 'allauth.account'. 'account' app is under allauth module. The same thing would be nice for templates. Just 'account' is not specific enough, I could easily have a custom app in my project with that name with templates.

First I ran into the issue because of the top level 'base.html' template which was extended by 'base.html' in 'account' directory. The 'base.html' template in my project directory overwrote the top level 'base.html' in 'allauth', which was not my intention. Then, I thought this might be feature, right? If you use 'allauth' in your project your top level base template is used automagically, which is what you probably want anyway. But then I realized that the real problem would occur with the templates of apps under allauth (like account), because they are not namespaced with allauth and the names are not specific enough.

[miguelfg]

I also got headaches.
What about to do an allauth setting variable to define if templates are in the local app that it's using allauth or, as default, in site-packages/allauth/...?

Because now even if you move templates to your app, you have to be very carefull of INSTALLED_APPS order. It would render the templates from site-packages/allauth/... since, allauth must be placed in the top of INSTALLED_APPS. This drove me nuts. So overriding is tricky.

The problem of this solution is that if you want to override 1 template, you should move ALL allauth templates there, not just one, because is going to search only there. And also set this brand new variable I say to look in your app directory.

[stavinsky]

I also had problems and spend 2-3 hours to solve problem. I solved it by changing TEMPLATE_DIRS but I this is no very good way. Templates have to be placed just like django convention said. This is first of tens app that made so much problems just with templates

[LoveIsGrief]

I actually ran into similar problems when namespacing allauth urlconfs e.g url(r'^user/', include('allauth.urls', namespace="auth")). allauth couldn't resolve any urls anymore. Maybe that particular issue needs a new separate issue, but it's somewhat linked to this one.

[craiga]

For what it's worth, I found that just adding your base application's templates directory to Django's configuration is probably the cleanest workaround for this.

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [
            "my_cool_app/templates",  # add this with your app name to use your own base.html
        ],
        "APP_DIRS": True,
        "OPTIONS": {
            "context_processors": [
                "django.template.context_processors.debug",
                "django.template.context_processors.request",
                "django.contrib.auth.context_processors.auth",
                "django.contrib.messages.context_processors.messages",
            ]
        },
    }
]

[CodePint]

I've spent the last hour trying to work out the best way of integrating this. I did have to go revisit how the template short circuiting worked as well (new to django)

I would like to propose the following change:

• move base.htmlto account/base.html

There seems little point having it in the root level directory and causing confusion with users base.html if it is only ever referenced via account/base.html and has been for the past 7 years.