Related
I have a Django problem which only occasionally has problems finding Templates. It will be running fine for hours, and then suddenly not be able to serve certain templates. Occasionally the problem will correct itself, but can always be fixed by running touch <template>. My current solution is a cronjob which executes touch <project root> every minute, and that works so long as cron keeps up. However, I want to figure out a proper solution to my problem.
Relevant Settings:
PROJECT_ROOT = os.path.dirname(__file__)
APPS_ROOT = os.path.abspath(os.path.join(PROJECT_ROOT, "apps"))
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
)
TEMPLATE_DIRS = (
(PROJECT_ROOT + '/templates'),
)
TEMPLATE_CONTEXT_PROCESSORS = (
"django.contrib.auth.context_processors.auth",
"django.core.context_processors.request",
"django.core.context_processors.i18n",
"django.contrib.messages.context_processors.messages",
"base_site.context_processors.app_list"
)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)
Just wanted to add another case where you may get the Template Does Not Exist error.
Make sure you've added your app in the INSTALLED_APPS variable inside your settings.py file. The startapp command is not enough.
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'myappname', # add your app here :)
]
I know it's silly, but I know people that have failed their driver's test because of forgetting to fasten their seat belt, so forgetting a line of code isn't as rare as it sounds.
Try updating your settings like so:
PROJECT_ROOT = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
TEMPLATE_DIRS = (os.path.join(PROJECT_ROOT, 'templates'),)
(This is the default way of getting the BASE_DIR in django 1.8). Prior to Python 3.4, __file__ is not guaranteed to give the absolute file path.
You should also try and remain platform agnostic by using os.path.join rather than adding the directory as a string (other platforms use backslashes).
So it turns out my problem was not with Django itself but with my environment. I was running the Django server from ~/Django-project, and our dev server encrypts home directories once all sessions are signed out which means the service could no longer find it. Moving the project to /var/ and daemonizing the manage.py runserver command has kept the project free of Template Does Not Exist errors.
I've got a very simple project running on Django (no models yet) and I need to do the following:
I have created 2 apps, 'Ebony' and 'Ivory' that need to communicate with each other through JSON messages (originally designed to run on different machines but for now one is good enough).
The problem is that the Django Debug server is just one process which runs in a specific port. What I want to do is make each 'App' listen to its own port on the same server and if possible under the same Django project. Is such a scenario possible? And if yes, how should I go about it?
Thanks in advance
This is possible, but not the way you're conceptualizing it. A Django app is one part of what runs on a given web server. Thus a Django project, which has one or more apps, runs as a part of one web server.
The solution is to run multiple instances of Django. Not sure how well this is going to work for you with the debug servers. You can run each server on its own port by giving it a parameter telling it where to open the port, for example:
./manage.py runserver 8000
runs a debug server on 127.0.0.1:8000, and
./manage.py runserver 8080
runs another debug server on 127.0.0.1:8080. Usually this is done in separate shells.
You will need to make sure that the INSTALLED_APPS setting on one of these has 'Ebony' in it, and the other has 'Ivory'. You will also need to figure out some way to tell each instance how to connect to the other (usually by specifying a root URL).
That said, later on you will need to figure out if your two apps will be sharing the same database. If so, make sure that both machines can get to it. If not, make sure the DATABASES value in settings.py is different for each one. If you're sharing the database, Django's sites framework can help you keep things straight in your models.
To have both running from the same project, you have to tell Django which one to run. I prefer to use an environment variable. This changes the above runserver commands to:
SHARD=Ebony ./manage.py runserver 8000
and
SHARD=Ivory ./manage.py runserver 8080
In your settings.py file, this variable can be accessed through os.environ. So, for example, for the INSTALLED_APPS setting to have different values for each shard, you write something like:
SHARD = os.environ["SHARD"]
# Apps common to all shards go here.
LOCAL_APPS = [
commonApp,
]
# Add apps specific to each shard.
if SHARD == "Ebony":
LOCAL_APPS += [
Ebony,
]
elif SHARD == "Ivory":
LOCAL_APPS += [
Ivory,
]
# Add them to the apps that aren't mine.
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.admin',
# ... omitted for brevity ...
'django_extensions',
'south',
'debug_toolbar',
) + LOCAL_APPS
By defining SHARD as a setting in this file, you avoid having to have all your code access the environment variable, and you confine the logic for setting SHARD to settings.py, in case you want to change it later. Your other Python files, if needed, can get the setting with from django.conf.settings import SHARD.
A similar mechanism can be used to give each shard its own DATABASES setting, too. And anything else in settings.py.
Then later in your urls.py file, you use that to pull in your apps' URLs:
from django.conf.urls import *
from django.conf import settings
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
url(r'^$', 'commonApp.views.get_homepage', name='home'),
url(r'^login$', 'django.contrib.auth.views.login', name="login"),
url(r'^logout$', 'django.contrib.auth.views.logout',
{"next_page": "/"}, name="logout"),
# Admin
url(r'^admin/doc/', include('django.contrib.admindocs.urls')),
url(r'^admin/', include(admin.site.urls)),
)
# Auto-add the applications.
for app in settings.LOCAL_APPS:
urlpatterns += patterns('',
url(r'^{0}/'.format(app), include(app + '.urls', namespace=app)),
)
This means your apps need their own urls.py files, and your app URL names get prefixed with your app names. So if the app Ebony defines a URL pattern with name="index", you would get that URL in a template with {% url 'Ebony:index' %}.
I am trying to set up multiple setting files (development, production, ..) that include some base settings. Cannot succeed though. When I try to run ./manage.py runserver I am getting the following error:
(cb)clime#den /srv/www/cb $ ./manage.py runserver
ImproperlyConfigured: The SECRET_KEY setting must not be empty.
Here is my settings module:
(cb)clime#den /srv/www/cb/cb/settings $ ll
total 24
-rw-rw-r--. 1 clime clime 8230 Oct 2 02:56 base.py
-rw-rw-r--. 1 clime clime 489 Oct 2 03:09 development.py
-rw-rw-r--. 1 clime clime 24 Oct 2 02:34 __init__.py
-rw-rw-r--. 1 clime clime 471 Oct 2 02:51 production.py
Base settings (contain SECRET_KEY):
(cb)clime#den /srv/www/cb/cb/settings $ cat base.py:
# Django base settings for cb project.
import django.conf.global_settings as defaults
DEBUG = False
TEMPLATE_DEBUG = False
INTERNAL_IPS = ('127.0.0.1',)
ADMINS = (
('clime', 'clime7#gmail.com'),
)
MANAGERS = ADMINS
DATABASES = {
'default': {
#'ENGINE': 'django.db.backends.postgresql_psycopg2', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'.
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'cwu', # Or path to database file if using sqlite3.
'USER': 'clime', # Not used with sqlite3.
'PASSWORD': '', # Not used with sqlite3.
'HOST': '', # Set to empty string for localhost. Not used with sqlite3.
'PORT': '', # Set to empty string for default. Not used with sqlite3.
}
}
# Local time zone for this installation. Choices can be found here:
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
# although not all choices may be available on all operating systems.
# In a Windows environment this must be set to your system time zone.
TIME_ZONE = 'Europe/Prague'
# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE = 'en-us'
SITE_ID = 1
# If you set this to False, Django will make some optimizations so as not
# to load the internationalization machinery.
USE_I18N = False
# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale.
USE_L10N = False # TODO: make this true and accustom date time input
DATE_INPUT_FORMATS = defaults.DATE_INPUT_FORMATS + ('%d %b %y', '%d %b, %y') # + ('25 Oct 13', '25 Oct, 13')
# If you set this to False, Django will not use timezone-aware datetimes.
USE_TZ = True
# Absolute filesystem path to the directory that will hold user-uploaded files.
# Example: "/home/media/media.lawrence.com/media/"
MEDIA_ROOT = '/srv/www/cb/media'
# URL that handles the media served from MEDIA_ROOT. Make sure to use a
# trailing slash.
# Examples: "http://media.lawrence.com/media/", "http://example.com/media/"
MEDIA_URL = '/media/'
# Absolute path to the directory static files should be collected to.
# Don't put anything in this directory yourself; store your static files
# in apps' "static/" subdirectories and in STATICFILES_DIRS.
# Example: "/home/media/media.lawrence.com/static/"
STATIC_ROOT = '/srv/www/cb/static'
# URL prefix for static files.
# Example: "http://media.lawrence.com/static/"
STATIC_URL = '/static/'
# Additional locations of static files
STATICFILES_DIRS = (
# Put strings here, like "/home/html/static" or "C:/www/django/static".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
)
# List of finder classes that know how to find static files in
# various locations.
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
# 'django.contrib.staticfiles.finders.DefaultStorageFinder',
)
# Make this unique, and don't share it with anybody.
SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'
# List of callables that know how to import templates from various sources.
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
# 'django.template.loaders.eggs.Loader',
)
TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'django.core.context_processors.request',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
'django.core.context_processors.media',
'django.core.context_processors.static',
'django.core.context_processors.tz',
'django.contrib.messages.context_processors.messages',
'web.context.inbox',
'web.context.base',
'web.context.main_search',
'web.context.enums',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'watson.middleware.SearchContextMiddleware',
'debug_toolbar.middleware.DebugToolbarMiddleware',
'middleware.UserMemberMiddleware',
'middleware.ProfilerMiddleware',
'middleware.VaryOnAcceptMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
ROOT_URLCONF = 'cb.urls'
# Python dotted path to the WSGI application used by Django's runserver.
WSGI_APPLICATION = 'cb.wsgi.application'
TEMPLATE_DIRS = (
# Put strings here, like "/home/html/django_templates" or "C:/www/django/templates".
# Always use forward slashes, even on Windows.
# Don't forget to use absolute paths, not relative paths.
'/srv/www/cb/web/templates',
'/srv/www/cb/templates',
)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'south',
'grappelli', # must be before admin
'django.contrib.admin',
'django.contrib.admindocs',
'endless_pagination',
'debug_toolbar',
'djangoratings',
'watson',
'web',
)
AUTH_USER_MODEL = 'web.User'
# A sample logging configuration. The only tangible logging
# performed by this configuration is to send an email to
# the site admins on every HTTP 500 error when DEBUG=False.
# See http://docs.djangoproject.com/en/dev/topics/logging for
# more details on how to customize your logging configuration.
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'formatters': {
'standard': {
'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s",
'datefmt' : "%d/%b/%Y %H:%M:%S"
},
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
},
'null': {
'level':'DEBUG',
'class':'django.utils.log.NullHandler',
},
'logfile': {
'level':'DEBUG',
'class':'logging.handlers.RotatingFileHandler',
'filename': "/srv/www/cb/logs/application.log",
'maxBytes': 50000,
'backupCount': 2,
'formatter': 'standard',
},
'console':{
'level':'INFO',
'class':'logging.StreamHandler',
'formatter': 'standard'
},
},
'loggers': {
'django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
'django': {
'handlers':['console'],
'propagate': True,
'level':'WARN',
},
'django.db.backends': {
'handlers': ['console'],
'level': 'DEBUG',
'propagate': False,
},
'web': {
'handlers': ['console', 'logfile'],
'level': 'DEBUG',
},
},
}
LOGIN_URL = 'login'
LOGOUT_URL = 'logout'
#ENDLESS_PAGINATION_LOADING = """
# <img src="/static/web/img/preloader.gif" alt="loading" style="margin:auto"/>
#"""
ENDLESS_PAGINATION_LOADING = """
<div class="spinner small" style="margin:auto">
<div class="block_1 spinner_block small"></div>
<div class="block_2 spinner_block small"></div>
<div class="block_3 spinner_block small"></div>
</div>
"""
DEBUG_TOOLBAR_CONFIG = {
'INTERCEPT_REDIRECTS': False,
}
import django.template.loader
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
django.template.loader.add_to_builtins('web.templatetags.tag_library')
WATSON_POSTGRESQL_SEARCH_CONFIG = 'public.english_nostop'
One of the setting files:
(cb)clime#den /srv/www/cb/cb/settings $ cat development.py
from base import *
DEBUG = True
TEMPLATE_DEBUG = True
ALLOWED_HOSTS = ['127.0.0.1', '31.31.78.149']
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'cwu',
'USER': 'clime',
'PASSWORD': '',
'HOST': '',
'PORT': '',
}
}
MEDIA_ROOT = '/srv/www/cb/media/'
STATIC_ROOT = '/srv/www/cb/static/'
TEMPLATE_DIRS = (
'/srv/www/cb/web/templates',
'/srv/www/cb/templates',
)
Code in manage.py:
(cb)clime#den /srv/www/cb $ cat manage.py
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "cb.settings.development")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
If I add from base import * into /srv/www/cb/cb/settings/__init__.py (which is otherwise empty), it magically starts to work but I don't understand why. Anyone could explain to me what's going on here? It must be some python module magic.
EDIT: Everything also starts to work if I remove this line from base.py
django.template.loader.add_to_builtins('web.templatetags.cb_tags')
If I remove this line from web.templatetags.cb_tags, it also starts to work:
from endless_pagination.templatetags import endless
I guess it is because, in the end, it leads to
from django.conf import settings
PER_PAGE = getattr(settings, 'ENDLESS_PAGINATION_PER_PAGE', 10)
So it creates some weird circular stuff and game over.
I had the same error and it turned out to be a circular dependency between a module or class loaded by the settings and the settings module itself. In my case it was a middleware class which was named in the settings which itself tried to load the settings.
I ran into the same problem after restructuring the settings as per the instructions from Daniel Greenfield's book Two scoops of Django.
I resolved the issue by setting
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "project_name.settings.local")
in manage.py and wsgi.py.
Update:
In the above solution, local is the file name (settings/local.py) inside my settings folder, which holds the settings for my local environment.
Another way to resolve this issue is to keep all your common settings inside settings/base.py and then create 3 separate settings files for your production, staging and dev environments.
Your settings folder will look like:
settings/
__init__.py
base.py
local.py
prod.py
stage.py
and keep the following code in your settings/__init__.py
from .base import *
env_name = os.getenv('ENV_NAME', 'local')
if env_name == 'prod':
from .prod import *
elif env_name == 'stage':
from .stage import *
else:
from .local import *
I had the same error with python manage.py runserver.
For me, it turned out that it was because of a stale compiled binary (.pyc) file. After deleting all such files in my project, server started running again. :)
So if you get this error, out of nowhere, i.e without making any change seemingly-related to django-settings, this could be a good first measure.
Remove .pyc files
Ubuntu terminal command for deleting .pyc :
find . -name "*.pyc" -exec rm -rf {} \;
I have got same error when I did python manage.py runserver. It was because .pyc file. I deleted .pyc file from project directory then it was working.
I hadn't specified the settings file:
python manage.py runserver --settings=my_project.settings.develop
I had the same problem with Celery. My setting.py before:
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')
after:
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', <YOUR developing key>)
If the environment variables are not defined then: SECRET_KEY = YOUR developing key
It starts working because on the base.py you have all information needed in a basic settings file. You need the line:
SECRET_KEY = '8lu*6g0lg)9z!ba+a$ehk)xt)x%rxgb$i1&022shmi1jcgihb*'
So it works and when you do from base import *, it imports SECRET_KEY into your development.py.
You should always import basic settings before doing any custom settings.
EDIT:
Also, when django imports development from your package, it initializes all variables inside base since you defined from base import * inside __init__.py
I think that it is the Environment error,you should try setting : DJANGO_SETTINGS_MODULE='correctly_settings'
For anyone using PyCharm: the green "Run selected configuration" button would produce this error, yet running the following works:
py manage.py runserver 127.0.0.1:8000 --settings=app_name.settings.development
To fix this you need to edit the configuration's environment variables. To do this click the "Select run/debug configuration" drop-down menu to the left of the green run button and then click on "edit configuration". Under the "environment" tab change the environment variable DJANGO_SETTINGS_MODULE to app_name.settings.development.
for development just update settings.py, and should work
SECRET_KEY = '*'
In the init.py of the settings directory write the correct import, like:
from Project.settings.base import *
No need to change wsgi.py or manage.py
I solved this problem occurring on OS X with Django both 1.5 and 1.6 by deactivating all active sessions to virtualenv and starting it again.
To throw another potential solution into the mix, I had a settings folder as well as a settings.py in my project dir. (I was switching back from environment-based settings files to one file. I have since reconsidered.)
Python was getting confused about whether I wanted to import project/settings.py or project/settings/__init__.py. I removed the settings dir and everything now works fine.
I just wanted to add that I got this error when my database name was spelled wrong in my settings.py file so the DB couldn't be created.
I solved this problem on 1.8.4 by fixing the TEMPLATES settings which had a typo (removing TEMPLATES['debug'] solved it)
Go over the settings that you have changed recently, make sure all keys are by-the-book.
My Mac OS didn't like that it didn't find the env variable set in the settings file:
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = os.environ.get('MY_SERVER_ENV_VAR_NAME')
but after adding the env var to my local Mac OS dev environment, the error disappeared:
export MY_SERVER_ENV_VAR_NAME ='fake dev security key that is longer than 50 characters.'
In my case, I also needed to add the --settings param:
python3 manage.py check --deploy --settings myappname.settings.production
where production.py is a file containing production specific settings inside a settings folder.
The issue for me was calling get_text_noop in the LANGUAGES iterable.
Changing
LANGUAGES = (
('en-gb', get_text_noop('British English')),
('fr', get_text_noop('French')),
)
to
from django.utils.translation import gettext_lazy as _
LANGUAGES = (
('en-gb', _('British English')),
('fr', _('French')),
)
in the base settings file resolved the ImproperlyConfigured: The SECRET_KEY setting must not be empty exception.
The reason why there are so many different answers is because the exception probably doesn't have anything to do with the SECRET_KEY.
It is probably an earlier exception that is being swallowed.
Turn on debugging using DEBUG=True to see the real exception.
In my case, it was because I was trying to setup django-environ and I missed an important step:
Note: In the instructions below .env.example and .env should be saved in the same folder as settings.py
I incorrectly assumed that .env belonged in the root of my project. Moving it to the same folder as settings.py fixed the problem.
This error message in the Python console was the clue that set me on the right path:
Warning: /Users/allen/PycharmProjects/myapp/myapp/.env doesn't exist - if you're not configuring your environment separately, create one.
I solved this problem by removing the spaces around equal signs (=) in my .env file.
In my case the problem was - I had my app_folder and settings.py in it. Then I decided to make Settings folder inside app_folder - and that made a collision with settings.py. Just renamed that Settings folder - and everything worked.
I solved the above problem by commenting the line in my settings.py
SECRET_KEY=os.environ.get('SECRET_KEY')
SECRET_KEY declared in my ~/.bashrc file(for linux Ubuntu users)
For development purpose on my localmachine I did not use evironmnet variable
SECRET_KEY = '(i9b4aes#h1)m3h_8jh^duxrdh$4pu8-q5vkba2yf$ptd1lev_'
above line didn't give the error
In my case, while setting up a Github action I just forgot to add the env variables to the yml file:
jobs:
build:
env:
VAR1: 1
VAR2: 5
In my case, after a long search I found that PyCharm in your Django settings (Settings > Languages & Frameworks > Django) had the configuration file field undefined. You should make this field point to your project's settings file. Then, you must open the Run / Debug settings and remove the environment variable DJANGO_SETTINGS_MODULE = existing path.
This happens because the Django plugin in PyCharm forces the configuration of the framework. So there is no point in configuring any os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myapp.settings')
Import base.py in __init__.py alone. make sure you won't repeat the same configuration again!.
set environment variable
SET DJANGO_DEVELOPMENT =dev
settings/
__init__.py
base.py
local.py
production.py
In __init__.py
from .base import *
if os.environ.get('DJANGO_DEVELOPMENT')=='prod':
from .production import *
else:
from .local import *
In base.py configured the global configurations. except for Database. like
SECRET_KEY, ALLOWED_HOSTS,INSTALLED_APPS,MIDDLEWARE .. etc....
In local.py
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'database',
'USER': 'postgres',
'PASSWORD': 'password',
'HOST': 'localhost',
'PORT': '5432',
}
}
I came here looking for answer as I was facing the same issues, none of the answers here worked for me. Then after searching in other websites i stumbled upon this simple fix. It worked for me
wsgi.py
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings')
to
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'yourProject.settings.dev')
Let me share m interesting solution!
I put the
SECRET_KEY = "***&^%$#" in settings packages init.py file and the error disappeared! it's actually a loading problem!
Hope this quick workaround is useful for some of you!
try import django then run django.setup() after the secret_key definition. like so:
SECRET_KEY = 'it5bs))q6toz-1gwf(+j+f9#rd8%_-0nx)p-2!egr*y1o51=45XXCV'
django.setup()
For anyone using Wing IDE: set the DJANGO_SETTINGS_MODULE in your project properties to DJANGO_SETTINGS_MODULE=${DJANGO_SITENAME}.config.settings.development
You will find the settings under: Project --> Project Properties and set the value in the field Environment
(I am using Pycharm, I also tried every solution in here and found out that the solutions works on some codes and some doesn't so I just did this solution)
The easiest Resolution that I did is I deleted the LIB where the installed sitepackages are, opened python interpreter in the settings and then it gave me an option where the program(Pycharm) installed the pip/sitepackges and I reinstalled the rest of the packges for example rest_framewrok etc. in the virtual environment of the project using cmd(or any command prompt tool) and it fixed my problem.
I have created a production_settings.py in which I am putting all the production env variables and values eg:
import dj_database_url
DATABASES['default'] = dj_database_url.config()
I thought I'd declare an env variable like
MYPROJECT_PRODUCTION
and set this like
heroku config:add MYPROJECT_PRODUCTION=True or export MYPROJECT_PRODUCTION=True
In the settings.py (which is the default created by django) ,I thought I'd add at the end of the file
import os
if os.environ.has_key('MYPROJECT_PRODUCTION') and os.environ.get('MYPROJECT_PRODUCTION')=='True':
from production_settings import *
Is this the correct way of doing this?
I am getting an import error when I try python manage shell
export DJANGO_SETTINGS_MODULE='myproject.settings'
export MYPROJECT_PRODUCTION=True
me#ubuntu:~/dev/python/django/myproject$ python manage.py shell
Error: Can't find the file 'settings.py' in the directory containing 'manage.py'. It appears you've customized things.
You'll have to run django-admin.py, passing it your settings module.
(If the file settings.py does indeed exist, it's causing an ImportError somehow.)
the manage.py exists in the same folder as settings.py ..still the error occurs.
I checked echo $MYPROJECT_PRODUCTION which outputs True
Personally, I keep my production settings in settings.py then include a local_settings.py file (that's excluded from revision control with .hgignore).
I add the following to the end of settings.py
try:
from local_settings import *
except ImportError, e:
pass
Then in my local_settings.py I override the appropriate settings -
DEBUG = True
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'tag',
'USER': 'tag',
'PASSWORD': 'tag',
'HOST': 'localhost',
'PORT': '5432',
}
}
I'm under the impression that this is a fairly well used method (I picked it up from colleagues but I've seen it blogged about too)
EDIT
In response to balazs very good point you might include a variation on this method, in order to keep sensitive data private. Perhaps include the following after the local_settings import -
try:
from production_settings import *
except ImportError, e:
pass
Then exclude production_settings.py from version control. I guess you may need to use a different method to deploy production_settings.py, but I don't suppose that's too big a deal.
I advise against using different settings files for different environments in favour of customising your settings with environment variables. This allows you by default to use your local development settings and override it in production.
For example database and static / media root settings
# Default database URL is a local SQLite instance
DATABASE_URL = 'sqlite:///%s' % os.path.join(os.path.dirname(__file__), 'db.sqlite')
DATABASES = {
'default': dj_database_url.config('DATABASE_URL', default=DATABASE_URL),
}
MEDIA_ROOT = os.environ.get('MEDIA_ROOT',
os.path.join(os.path.dirname(__file__), 'media'))
MEDIA_URL = os.environ.get('MEDIA_URL', '/media/')
STATIC_ROOT = os.environ.get('STATIC_ROOT',
os.path.join(os.path.dirname(__file__), 'static'))
STATIC_URL = os.environ.get('STATIC_URL', '/static/')
This allows you to set any setting on Heroku via heroku config:set and removes the complexity of dealing with multiple settings files, for example:
heroku config:set MEDIA_URL=http://custom-media-server.com/media/
heroku config:set STATIC_URL=http://custom-media-server.com/static/
I have also created a custom Django project template that can take most settings from environment variables.
You should also look at the 12 Factor Application website and specifically at how to store configuration.
Have you defined DATABASES as a dictionary? by:
DATABASES = {}
also show your heroku logs
I looked at other questions and can't figure it out...
I did the following to install django-debug-toolbar:
pip install django-debug-toolbar
added to middleware classes:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
'debug_toolbar.middleware.DebugToolbarMiddleware',
)
3 Added INTERNAL_IPS:
INTERNAL_IPS = ('174.121.34.187',)
4 Added debug_toolbar to installed apps
I am not getting any errors or anything, and the toolbar doesn't show up on any page, not even admin.
I even added the directory of the debug_toolbar templates to my TEMPLATE_DIRS
What is DEBUG set to? It won't load unless it's True.
If it's still not working, try adding '127.0.0.1' to INTERNAL_IPS as well.
UPDATE
This is a last-ditch-effort move, you shouldn't have to do this, but it will clearly show if there's merely some configuration issue or whether there's some larger issue.
Add the following to settings.py:
def show_toolbar(request):
return True
SHOW_TOOLBAR_CALLBACK = show_toolbar
That will effectively remove all checks by debug toolbar to determine if it should or should not load itself; it will always just load. Only leave that in for testing purposes, if you forget and launch with it, all your visitors will get to see your debug toolbar too.
For explicit configuration, also see the official install docs here.
EDIT(6/17/2015):
Apparently the syntax for the nuclear option has changed. It's now in its own dictionary:
def show_toolbar(request):
return True
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK" : show_toolbar,
}
Their tests use this dictionary.
Debug toolbar wants the ip address in request.META['REMOTE_ADDR'] to be set in the INTERNAL_IPS setting. Throw in a print statement in one of your views like such:
print("IP Address for debug-toolbar: " + request.META['REMOTE_ADDR'])
And then load that page. Make sure that IP is in your INTERNAL_IPS setting in settings.py.
Normally I'd think you would be able to determine the address easily by looking at your computer's ip address, but in my case I'm running the server in a Virtual Box with port forwarding...and who knows what happened. Despite not seeing it anywhere in ifconfig on the VB or my own OS, the IP that showed up in the REMOTE_ADDR key was what did the trick of activating the toolbar.
If everything else is fine, it could also be that your template lacks an explicit closing <body> tag—
Note: The debug toolbar will only display itself if the mimetype of the response is either text/html or application/xhtml+xml and contains a closing tag.
Docker
If you're developing with a Django server in a Docker container with docker, the instructions for enabling the toolbar don't work. The reason is related to the fact that the actual address that you would need to add to INTERNAL_IPS is going to be something dynamic, like 172.24.0.1.
Rather than trying to dynamically set the value of INTERNAL_IPS, the straightforward solution is to replace the function that enables the toolbar, in your settings.py, for example:
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': lambda _request: DEBUG
}
This should also work for other dynamic routing situations, like Vagrant or Heroku.
Here are some more details for the curious. The code in django_debug_tool that determines whether to show the toolbar examines the value of REMOTE_ADDR like this:
if request.META.get('REMOTE_ADDR', None) not in INTERNAL_IPS:
return False
so if you don't actually know the value of REMOTE_ADDR due to your dynamic docker routing, the toolbar will not work. You can use the docker network command to see the dynamic IP values, for example docker network inspect my_docker_network_name
The current stable version 0.11.0 requires the following things to be true for the toolbar to be shown:
Settings file:
DEBUG = True
INTERNAL_IPS to include your browser IP address, as opposed to the server address. If browsing locally this should be INTERNAL_IPS = ('127.0.0.1',). If browsing remotely just specify your public address.
The debug_toolbar app to be installed i.e INSTALLED_APPS = (..., 'debug_toolbar',)
The debug toolbar middleware class to be added i.e. MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware', ...). It should be placed as early as possible in the list.
Template files:
Must be of type text/html
Must have a closing </html> tag
Static files:
If you are serving static content make sure you collect the css, js and html by doing:
./manage.py collectstatic
Note on upcoming versions of django-debug-toolbar
Newer, development versions have added defaults for settings points 2, 3 and 4 which makes life a bit simpler, however, as with any development version it has bugs. I found that the latest version from git resulted in an ImproperlyConfigured error when running through nginx/uwsgi.
Either way, if you want to install the latest version from github run:
pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git#egg=django-debug-toolbar
You can also clone a specific commit by doing:
pip install -e git+https://github.com/django-debug-toolbar/django-debug-toolbar.git#ba5af8f6fe7836eef0a0c85dd1e6d7418bc87f75#egg=django_debug_toolbar
I tried everything, from setting DEBUG = True, to settings INTERNAL_IPS to my client's IP address, and even configuring Django Debug Toolbar manually (note that recent versions make all configurations automatically, such as adding the middleware and URLs). Nothing worked in a remote development server (though it did work locally).
The ONLY thing that worked was configuring the toolbar as follows:
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK" : lambda request: True,
}
This replaces the default method that decides if the toolbar should be shown, and always returns true.
I have the toolbar working just perfect. With this configurations:
DEBUG = True
INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
The middleware is the first element in MIDDLEWARE_CLASSES:
MIDDLEWARE_CLASSES = (
'debug_toolbar.middleware.DebugToolbarMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)
I hope it helps
Add 10.0.2.2 to your INTERNAL_IPS on Windows, it is used with vagrant internally
INTERNAL_IPS = (
'10.0.2.2',
)
This should work.
I had the same problem and finally resolved it after some googling.
In INTERNAL_IPS, you need to have the client's IP address.
Another thing that can cause the toolbar to remain hidden is if it cannot find the required static files. The debug_toolbar templates use the {{ STATIC_URL }} template tag, so make sure there is a folder in your static files called debug toolbar.
The collectstatic management command should take care of this on most installations.
I know this question is a bit old, but today i installed django-toolbar with docker and came across with the same issue, this solved it for me
INTERNAL_IPS = ["127.0.0.1", "10.0.2.2"]
import socket
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS += [".".join(ip.split(".")[:-1] + ["1"]) for ip in ips]
As i read in a comment, the issue is that docker uses a dynamic ip, to solve this we can get the ip from the code above
An addition to previous answers:
if the toolbar doesn't show up, but it loads in the html (check your site html in a browser, scroll down)
the issue can be that debug toolbar static files are not found (you can also see this in your site's access logs then, e.g. 404 errors for /static/debug_toolbar/js/toolbar.js)
It can be fixed the following way then (examples for nginx and apache):
nginx config:
location ~* ^/static/debug_toolbar/.+.(ico|css|js)$ {
root [path to your python site-packages here]/site-packages/debug_toolbar;
}
apache config:
Alias /static/debug_toolbar [path to your python site-packages here]/site-packages/debug_toolbar/static/debug_toolbar
Or:
manage.py collectstatic
more on collectstatic here: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#collectstatic
Or manualy move debug_toolbar folder of debug_toolbar static files to your set static files folder
I tried the configuration from pydanny's cookiecutter-django and it worked for me:
# django-debug-toolbar
MIDDLEWARE_CLASSES = Common.MIDDLEWARE_CLASSES + ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS += ('debug_toolbar',)
INTERNAL_IPS = ('127.0.0.1',)
DEBUG_TOOLBAR_CONFIG = {
'DISABLE_PANELS': [
'debug_toolbar.panels.redirects.RedirectsPanel',
],
'SHOW_TEMPLATE_CONTEXT': True,
}
# end django-debug-toolbar
I just modified it by adding 'debug_toolbar.apps.DebugToolbarConfig' instead of 'debug_toolbar' as mentioned in the official django-debug-toolbar docs, as I'm using Django 1.7.
django 1.8.5:
I had to add the following to the project url.py file to get the debug toolbar display. After that debug tool bar is displayed.
from django.conf.urls import include
from django.conf.urls import patterns
from django.conf import settings
if settings.DEBUG:
import debug_toolbar
urlpatterns += patterns('',
url(r'^__debug__/', include(debug_toolbar.urls)),
)
django 1.10: and higher:
from django.conf.urls import include, url
from django.conf.urls import patterns
from django.conf import settings
if settings.DEBUG:
import debug_toolbar
urlpatterns =[
url(r'^__debug__/', include(debug_toolbar.urls)),
] + urlpatterns
Also don't forget to include the debug_toolbar to your middleware.
The Debug Toolbar is mostly implemented in a middleware. Enable it in your settings module as follows:
(django newer versions)
MIDDLEWARE = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
#
Old-style middleware:(need to have _CLASSES keywork in the Middleware)
MIDDLEWARE_CLASSES = [
# ...
'debug_toolbar.middleware.DebugToolbarMiddleware',
# ...
]
For me this was as simple as typing 127.0.0.1:8000 into the address bar, rather than localhost:8000 which apparently was not matching the INTERNAL_IPS.
In my case, it was another problem that hasn't been mentioned here yet: I had GZipMiddleware in my list of middlewares.
As the automatic configuration of debug toolbar puts the debug toolbar's middleware at the top, it only gets the "see" the gzipped HTML, to which it can't add the toolbar.
I removed GZipMiddleware in my development settings. Setting up the debug toolbar's configuration manually and placing the middleware after GZip's should also work.
In my case I just needed to remove the python compiled files (*.pyc)
Like you said I have configured everything said in documentation, still debug_toolbar was not showing up.
Then I tried it in Firefox, it worked fine.
Then from chrome, I inspect the webpage and change classname class="djdt-hidden". You can try changing it or removing it.
run manage.py collectstatic and repeat the above step
Actually you can skip steps 2 and 3, by editing
.djdt-hidden{ display: none;}
from path
debug_toolbar/static/debug_toolbar/css/toolbar.css
Add this two lines somewhere in settings.py
import mimetypes
mimetypes.add_type("application/javascript", ".js", True)
in urls.py
import debug_toolbar
urlpatterns += [ path('__debug__/', include(debug_toolbar.urls)),]
Use reference django debug toolbar installation
If it still doesn't working then,
create launch.json and mention different port number for debugging
`
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Django",
"type": "python",
"request": "launch",
"program": "${workspaceFolder}\\manage.py",
"args": [
"runserver",
"9000",
],
"django": true
}
]
}
`
Important step: check your webpage/template is in proper format inorder to show debug_toolbar. use html boilerplate template to edit your page or add missing elements/tags like
<html></html>
<body></body>
<head><head>
etc to your django template or import a layout
This wasn't the case for this specific author but I just have been struggling with the Debug Toolbar not showing and after doing everything they pointed out, I found out it was a problem with MIDDLEWARE order. So putting the middleware early in the list could work. Mine is first:
MIDDLEWARE_CLASSES = (
'debug_toolbar.middleware.DebugToolbarMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'dynpages.middleware.DynpageFallbackMiddleware',
'utils.middleware.UserThread',
)
I got the same problem, I solved it by looking at the Apache's error log.
I got the apache running on mac os x with mod_wsgi
The debug_toolbar's tamplete folder wasn't being load
Log sample:
==> /private/var/log/apache2/dummy-host2.example.com-error_log <==
[Sun Apr 27 23:23:48 2014] [error] [client 127.0.0.1] File does not exist: /Library/WebServer/Documents/rblreport/rbl/static/debug_toolbar, referer: http://127.0.0.1/
==> /private/var/log/apache2/dummy-host2.example.com-access_log <==
127.0.0.1 - - [27/Apr/2014:23:23:48 -0300] "GET /static/debug_toolbar/css/toolbar.css HTTP/1.1" 404 234 "http://127.0.0.1/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0"
I just add this line to my VirtualHost file:
Alias /static/debug_toolbar /Library/Python/2.7/site-packages/debug_toolbar/static/debug_toolbar
Of course you must change your python path
It works for me.
#urls.py
if settings.DEBUG:
from django.conf.urls.static import static
import debug_toolbar
import mimetypes
mimetypes.add_type("application/javascript", ".js", True)
urlpatterns += static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
urlpatterns = [path('__debug__/', include(debug_toolbar.urls)), ] + urlpatterns
you have to make sure there is a closing tag in your templates.
My problem is that there is no regular html tags in my templates, I just display content in plain text. I solved it by inheriting every html file from base.html, which has a tag.
I had the same problem using Vagrant. I solved this problem by adding ::ffff:192.168.33.1 to the INTERNAL_IPS as below example.
INTERNAL_IPS = (
'::ffff:192.168.33.1',
)
Remembering that 192.168.33.10 is the IP in my private network in Vagrantfile.
I had this problem and had to install the debug toolbar from source.
Version 1.4 has a problem where it's hidden if you use PureCSS and apparently other CSS frameworks.
This is the commit which fixes that.
The docs explain how to install from source.
For anyone who is using Pycharm 5 - template debug is not working there in some versions. Fixed in 5.0.4, affected vesions - 5.0.1, 5.0.2
Check out issue
Spend A LOT time to find that out. Maybe will help someone
In the code I was working on, multiple small requests were made during handling of main request (it's very specific use case). They were requests handled by the same Django's thread. Django debug toolbar (DjDT) doesn't expect this behaviour and includes DjDT's toolbars to the first response and then it removes its state for the thread. So when main request was sent back to the browser, DjDT was not included in the response.
Lessons learned: DjDT saves it's state per thread. It removes state for a thread after the first response.
What got me is an outdated browser!
Noticed that it loads some stylesheets from debug toolbar and guessed it might be a front-end issue.
After many trial and error, this worked for me in Django=3.1
After writing all internal_ip, middleware, appending in url, put this code in settings.py at below
def show_toolbar(request):
return True
DEBUG_TOOLBAR_CONFIG = {
"SHOW_TOOLBAR_CALLBACK": show_toolbar,
'INSERT_BEFORE': '</head>'
}
Many of them suggested SHOW_TOOLBAR_CALLBACK, but in my case it only worked after added 'INSERT_BEFORE'
have same issue
after adding
urls.py
mimetypes.add_type("application/javascript", ".js", True)
urlpatterns = [...
and
DEBUG_TOOLBAR_CONFIG = {
'INTERCEPT_REDIRECTS': False,
'SHOW_TOOLBAR_CALLBACK': lambda request: True,
'SHOW_TEMPLATE_CONTEXT': True,
'INSERT_BEFORE': '</head>'
}
javascripts files added but all tags have class djdt-hidden and hidden
<div id="djDebug" class="djdt-hidden" dir="ltr" data-default-show="true">
i was using GoogleChrome
in FireFox bug was fixed and django toolbar icon appear
if you are using windows, it might be from your registery.
set HKEY_CLASSES_ROOT.js\Content Type to text/javascript instead of text/plain.