25👍
I eventually resorted to loading my app before django-allauth. In settings.py
:
INSTALLED_APPS = (
...
'myapp',
'allauth',
'allauth.account'
)
This solution goes against what’s presented in example app, but I was not able to solve it in other way.
7👍
Adding a template directory for allauth in template dirs
will do the trick. In Django 1.8 his can be done by editing template dir settingsTEMPLATES
as follows.
TEMPLATES = [
...
'DIRS': [
os.path.join(BASE_DIR, 'templates'),
os.path.join(BASE_DIR, 'templates', 'allauth'),
],
]
I think below code will work on other versions of django
TEMPLATE_DIRS = [
os.path.join(BASE_DIR, 'templates'),
os.path.join(BASE_DIR, 'templates', 'allauth'),
]
7👍
To this day— we’re now on Django-1.10.5— the django-allauth docs remain most unhelpful on this score. It does seem to be that Django looks in the templates directory of the first app listed, the setting of DIRS
in TEMPLATES
in settings.py
notwithstanding. I’m providing an answer only to help you implement Adam Starrh’s answer, to help with the reverse urls (I got errors until I took care of those).
In your urls.py file put:
from allauth.account.views import SignupView, LoginView, PasswordResetView
class MySignupView(SignupView):
template_name = 'signup.html'
class MyLoginView(LoginView):
template_name = 'login.html'
class MyPasswordResetView(PasswordResetView):
template_name = 'password_reset.html'
urlpatterns = [
url(r'^accounts/login', MyLoginView.as_view(), name='account_login'),
url(r'^accounts/signup', MySignupView.as_view(), name='account_signup'),
url(r'^accounts/password_reset', MyPasswordResetView.as_view(), name='account_reset_password'),
]
Presently the views.py file is here, so you can extend the above to other templates.
I must add that you still need in TEMPLATES
, something like:
'DIRS': [
os.path.join(PROJECT_ROOT, 'templates', 'bootstrap', 'allauth', 'account'),
],
And in this example that would be if your templates are in /templates/bootstrap/allauth/account
, which they are in my case. And:
PROJECT_ROOT = os.path.normpath(os.path.dirname(os.path.abspath(__file__)))
EDIT… THE PROPER WAY:
OK, the above works, to a point, and it’s good that it directly sets the template to what you want. But as soon as you include social apps you’ll start to get reverse url errors such as for dropbox_login
, for which you have not provided a named view.
After reading Burhan Khalid’s comment on this other stackoverflow thread that the questioner found, I eventually found that the following works:
'DIRS': [
os.path.join(PROJECT_ROOT, 'templates', 'example'),
]
And this yields /home/mike/example/example/templates/example
on the development server in my case, as I am running the example
app from git clone git://github.com/pennersr/django-allauth.git
.
Into that dir of DIRS
I copied the entire subdirectories account
and socialaccount
from the provided sample bootstrap
templates. This is utterly contrary to the directory structure of example
as it comes from github
and to notes in the settings.py
file of example
.
And you leave urls.py
just as in the example
app, with simply:
url(r'^accounts/', include('allauth.urls')),
4👍
In your views:
from allauth.account.views import SignupView, LoginView
class MySignupView(SignupView):
template_name = 'my_signup.html'
class MyLoginView(LoginView):
template_name = 'my_login.html'
4👍
It’s quite easy once you know Django’s template look up order and you configure the TEMPLATE =[]
properly as per your need. There’s no need to play with views or Python code if it’s just about overriding allauth’s templates.
Let’s understand the Django’s template look up order at first, just a little. Django’s template lookup order is as follows, all of these are configured inside TEMPLATE =[]
in project’s settings.py.
I. 'Loader'
: Give you the option to use Template Loaders which are responsible for locating templates, loading them, and returning Template objects. General implementations don’t use it much. If you haven’t configured a template loader then one of the following two option would decide which template is used by your view.
II. 'DIRS'
: Here you get the option to explicitly tell Django where to search for templates, in order, up to down.
III. 'APP_DIRS'
: If this field is set to true then Django looks for your template in your apps’ dir. To correctly use this option you need to organize your templates as follows:
root_dir
app1_dir
templates
your_template.html
app2_dir
templates
your_template.html
You must name your templates dir as "templates" and you must put your templates in that dir only for this to work
Third option is little weird though, if a template in your app’s view isn’t found in corresponding app’s template dir Django will go through template dir of other apps to find it.
It works well if templates are organized properly and naming convention of templates is standardized, so that when a template isn’t found in local app’s dir, that template shouldn’t be erroneously found in other app’s dir. Well, you may have some scenarios where you would want it to work that way.
Now, to the point answer to your question:
Allauth by default uses the templates from:
Python installed directory or virtual env --> *Lib --> site-packages --> allauth --> templates*
You would usually want to override all the allauth’s templates as they are very basic and you would want to beautify/modify them all, following are the steps which would enable you to override them all, if you don’t wish to override all of them do as follows, but just don’t change the HTML for that template, simple!
Suppose your project structure is as follows:
projectdir
app1_dir
app2_dir
projectname_dir
Copy the templates dir from Python installed directory or virtual env --> Lib --> site-packages --> allauth --> templates
to a dir of your choice, suppose you chose to keep it in app1_dir (you may chose any dir, makes no difference, but you should choose an appropriate one as per your requirements), then create a dir in app1_dir named ‘allauth’ (you could name it anything you like), then paste the copied allauth’s templates dir in this dir, so now your project structure would look as follows:
projectdir
app1_dir
allauth
templates
account
openid
socialaccount
base.html
app2_dir
projectname_dir
Change your TEMPLATES = []
in project settings as follows:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'allauth', 'templates'),
],
'APP_DIRS': True,
},
]
Here BASE_DIR is projectdir (root dir)
Basically you may keep the copied template dir from allauth dir in any project’s dir of your choice, but you must enusre that you provided the correct path here:
'DIRS': [os.path.join(BASE_DIR, 'allauth', 'templates')
If it doesn’t work then, set 'APP_DIRS': False
, then you would see a debug message from Django and it wouldn’t use app dir (allauth dir in site-packages). And then looking at that error you may figure out what’s wrong with your config.
- Django 1.7 removing Add button from inline form
- How to emit SocketIO event on the serverside
- Django database delete specific number of entries
- How do I get the django HttpRequest from a django rest framework Request?
- Logout Django Rest Framework JWT
2👍
For me only one solution works:
first make TEMPLATE_LOADERS to load filesystem.Loader
TEMPLATE_LOADERS = [
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
# 'django.template.loaders.eggs.Loader',
]
second – make TEMPLATE_DIRS with path where you copied templates from allauth. Make sure you copied full folder hierarchy from templates folder of allauth app.
TEMPLATE_DIRS = [
os.path.join(BASE_DIR, 'cms', 'templates', 'allauth'),
]
in this example a made path to my app, named cms because this is the main app of my project
after you could start to edit base.html template
- Django's {{ csrf_token }} is outputting the token value only, without the hidden input markup
- Is exposing a session's CSRF-protection token safe?
- Django admin many-to-many intermediary models using through= and filter_horizontal
- Subclassing Django ModelForms
- Python/Django "BadStatusLine" error
1👍
I found a better way to do this but forgot. All Auth allows you to do this very easy but and low on documentation. Here is my next easiest solution, until I rediscover the vaster way. #lol
The code creates a custom login page but the pattern is simple and easy to replicate. You can put all this code in urls.py
, or not:
from allauth.account.views import LoginView
class Lvx(LoginView):
# Login View eXtended
# beware ordering and collisions on paths
template_name = "components/login.html"
# don't forget to create the login page, see All Auth docs
# for use. /components is in your app templates path
login = Lvx.as_view()
urlpatterns = [
url(r'^accounts/login/$', login), # usually up top
...
]
There is also a setting you can use to point to a custom page, will edit this at some point. Feedback welcome.
1👍
As per the documentation provided here, it is possible to override the templates by replicating the directory structure inside the template base location of your project. For instance, by just creating the account/logout.html
, I was able to override the logout.html
file provided by allauth
. The settings.py
in my case is stated here
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'templates')],
}
]
1👍
In django v2.0. I use this method and its works. By following the django book, [https://djangobook.com/mdj2-django-templates/] .
The important way is to use [os.path.join(BASE_DIR, 'name_of_your_file/templates/allauth')]
instead of using 'DIRS': [os.path.join(BASE_DIR, 'templates'), os.path.join(BASE_DIR, 'templates', 'allauth')],
TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'name_of_your_file/templates/allauth')],
'APP_DIRS': True,
This is my first time post at stackoverflow yah,i find this solution long time and finally its work so i share it, hope can help someone.
- Django load local json file
- Django testing: Got an error creating the test database: database "database_name" already exists
- Django OneToOneField with possible blank field