django-debug-toolbar not showing up - python
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.
Related
React&Django stack. Deploy on Heroku when Set Debug = False app Show blank page but admin page working [duplicate]
Once I change the DEBUG = False, my site will generate 500 (using wsgi & manage.py runserver), and there is no error info in Apache error log and it will run normally when I change debug to True . I'm using Django 1.5 & Python 2.7.3 here is Apache access log and without any log in apache error log www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET / HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22" www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET /favicon.ico HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22" www.beta800.net:80 222.247.56.11 - - [28/Feb/2013:13:42:28 +0800] "GET /favicon.ico HTTP/1.1" 500 257 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22" Here is my settings file: import os.path DEBUG = False #TEMPLATE_DEBUG = DEBUG HERE = os.path.dirname(__file__) ADMINS = ( ('admin', 'xyzadmin#qq.com'), ) MANAGERS = ADMINS DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. 'NAME': 'zdm', # Or path to database file if using sqlite3. 'USER': 'root', # Not used with sqlite3. 'PASSWORD': 'passwd', # 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 = 'America/Chicago' # 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 = True # If you set this to False, Django will not format dates, numbers and # calendars according to the current locale. USE_L10N = True # 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 = '' # 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 = '' # 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 = os.path.join(HERE, 'static').replace('\\','/') # URL prefix for static files. # Example: "http://media.lawrence.com/static/" STATIC_URL = '/static/' #STATIC_ROOT = os.path.join(HERE, 'static').replace('\\','/') S= os.path.join(HERE, 'static').replace('\\','/') # 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. '/home/zdm/static', ) # 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 = '9a7!^gp8ojyk-^^d#*whuw!0rml+r+uaie4ur$(do9zz_6!hy0' # 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', ) 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', ) ROOT_URLCONF = 'zdm.urls' # Python dotted path to the WSGI application used by Django's runserver. WSGI_APPLICATION = 'zdm.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. '/home/zdm/templates', ) INSTALLED_APPS = ( 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'django.contrib.messages', 'django.contrib.staticfiles', # Uncomment the next line to enable the admin: 'django.contrib.admin', # Uncomment the next line to enable admin documentation: # 'django.contrib.admindocs', 'zdm', 'portal', 'admin', 'tagging', )
Django 1.5 introduced the allowed hosts setting that is required for security reasons. A settings file created with Django 1.5 has this new section which you need to add: # Hosts/domain names that are valid for this site; required if DEBUG is False # See https://docs.djangoproject.com/en/1.9/ref/settings/#allowed-hosts ALLOWED_HOSTS = [] Add your host here like ['www.beta800.net'] or ['*'] for a quick test, but don't use ['*'] for production.
I know this is late but I ended up here with a search for my error 500 with DEBUG=False, in my case it did turn out to be the ALLOWED_HOSTS but I was using os.environ.get('variable') to populate the hosts, I did not notice this until I enabled logging, you can log all errors to file with the below and it will log even when DEBUG=False: # settings.py LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'formatters': { 'verbose': { 'format' : "[%(asctime)s] %(levelname)s [%(name)s:%(lineno)s] %(message)s", 'datefmt' : "%d/%b/%Y %H:%M:%S" }, 'simple': { 'format': '%(levelname)s %(message)s' }, }, 'handlers': { 'file': { 'level': 'DEBUG', 'class': 'logging.FileHandler', 'filename': 'mysite.log', 'formatter': 'verbose' }, }, 'loggers': { 'django': { 'handlers':['file'], 'propagate': True, 'level':'DEBUG', }, 'MYAPP': { 'handlers': ['file'], 'level': 'DEBUG', }, } }
I encountered the same issue just recently in Django 2.0. I was able to figure out the problem by setting DEBUG_PROPAGATE_EXCEPTIONS = True. See here: https://docs.djangoproject.com/en/2.0/ref/settings/#debug-propagate-exceptions In my case, the error was ValueError: Missing staticfiles manifest entry for 'admin/css/base.css'. I fixed that by locally running python manage.py collectstatic.
In my case, reading docs of third party apps properly saved me. The culprit? django_compressor I had {% load compress %} {% compress css %} ... css files linked here .. {% endcompress %} DEBUG = True always gave me 500. To fix it, I needed a line in my settings to get it running COMPRESS_ENABLED = os.environ.get('COMPRESS_ENABLED', False)
Its mid 2019 and I faced this error after a few years of developing with Django. Baffled me for an entire night! It wasn't allowed host (which should throw a 400), everything else checked out, finally did some error logging only to discover that some missing / or messed up static files manifest (after collectstatic) were screwing with the setup. Long story short, for those who are stumped AND SO HAPPEN ARE USING WHITENOISE OR THE DJANGO STATICFILE BACKEND WITH CACHE (manifest static files) , maybe this is for you. Make sure you setup everything (as I did for the whitenoise backend...django backends read on nonetheless) http://whitenoise.evans.io/en/stable/django.html If error code 500 still shoots you down, take note on your settings.STATICFILES_STORAGE. Set it to either (for whitenoise backend with compression) STATICFILES_STORAGE = 'whitenoise.storage.CompressedStaticFilesStorage' or (leave as django default) STATICFILES_STORAGE = django.contrib.staticfiles.storage.StaticFilesStorage All in all, THE PROBLEM seemed to come from the fact that this whitenoise cache + compression backend --> STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage' or the django's own caching backend --> STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage' ...didnt quite work well for me, since my css was referencing some other sources which may be mixed up during collectstatic / backend caching. This issue is also potentially highlighted in http://whitenoise.evans.io/en/stable/django.html#storage-troubleshoot
Right, in Django 1.5 if DEBUG = False, configure ALLOWED_HOSTS, adding domains without the port number. example: ALLOWED_HOSTS = ['localhost']
You must also check your URLs all over the place. When the DEBUG is set to False, all URLs without trailing / are treated as a bug, unlike when you have DEBUG = True, in which case Django will append / everywhere it is missing. So, in short, make sure all links end with a slash EVERYWHERE.
Complementing the main answer It is annoying to change the ALLOWED_HOSTS and DEBUG global constants in settings.py when switching between development and production. I am using this code to set these setting automatically: import socket if socket.gethostname() == "server_name": DEBUG = False ALLOWED_HOSTS = [".your_domain_name.com",] ... else: DEBUG = True ALLOWED_HOSTS = ["localhost", "127.0.0.1",] ... If you use macOS you could write a more generic code: if socket.gethostname().endswith(".local"): # True in your local computer DEBUG = True ALLOWED_HOSTS = ["localhost", "127.0.0.1",] else: ...
For what it's worth - I was getting a 500 with DEBUG = False on some pages only. Tracing back the exception with pdb revealed a missing asset (I suspect the {% static ... %} template tag was the culprit for the 500.
ALLOWED_HOSTS is NOT the only issue, for me I had to make a 404.html and put it in the base level of my templates (not app level) - Also, you can make a 404 view and add a 404handler url but I think thats optional. 404.html fixed it in mainproject.urls handler404 = 'app.views.custom_404' in app.views def custom_404(request): return render(request, '404.html', {}, status=404) then make a templates/404.html template got this from another S/O post that I cannot find it EDIT also, I get 500 errors when I serve assets with whitenoise. Could not figure that out for the life of me, error was ValueError from whitenoise not being able to find an asset that I also could not find, had to go with default django serving for now
I have a hilarious story for all. After reaching this page I said "Eureka! I'm saved. That MUST be my problem." So I inserted the required ALLOWED_HOSTS list in setting.py and... nothing. Same old 500 error. And no, it wasn't for lack of a 404.html file. So for 2 days I busied myself with wild theories, such as that it had something to do with serving static files (understand that I am a noob and noobs don't know what they're doing). So what was it? It is now Mr. Moderator that we come to a useful tip. Whereas my development Django is version 1.5.something, my production server version is 1.5.something+1... or maybe plus 2. Whatever. And so after I added the ALLOWED_HOSTS to the desktop version of settings.py, which lacked what hwjp requested--- a "default value in settings.py, perhaps with an explanatory comment"--- I did the same on the production server with the proper domain for it. But I failed to notice that on the production server with the later version of Django there WAS a default value in settings.py with an explanatory comment. It was well below where I made my entry, out of sight on the monitor. And of course the list was empty. Hence my waste of time.
I know that this is a super old question, but maybe I could help some one else. If you are having a 500 error after setting DEBUG=False, you can always run the manage.py runserver in the command line to see any errors that wont appear in any web error logs.
I was searching and testing more about this issue and I realized that static files directories specified in settings.py can be a cause of this, so fist, we need to run this command python manage.py collectstatic in settings.py, the code should look something like this: STATIC_URL = '/static/' STATICFILES_DIRS = ( os.path.join(BASE_DIR, 'static'), ) STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
I faced the same problem when I did DEBUG = FALSE. Here is a consolidated solution as scattered in answers above and other posts. By default, in settings.py we have ALLOWED_HOSTS = [] . Here are possible changes you will have to make in ALLOWED_HOSTS value as per scenario to get rid of the error: 1: Your domain name: ALLOWED_HOSTS = ['www.example.com'] # Your domain name here 2: Your deployed server IP if you don't have domain name yet (which was my case and worked like a charm): ALLOWED_HOSTS = ['123.123.198.123'] # Enter your IP here 3: If you are testing on local server, you can edit your settings.py or settings_local.py as: ALLOWED_HOSTS = ['localhost', '127.0.0.1'] 4: You can also provide '*' in the ALLOWED_HOSTS value but its not recommended in the production environment due to security reasons: ALLOWED_HOSTS = ['*'] # Not recommended in production environment I have also posted a detailed solution on my blog which you may want to refer.
You might want to run python manage.py collectstatic after you set DEBUG = False and ALLOWED_HOSTS = ['127.0.0.1'] in settings.py. After these two steps my web application ran well in my local server even with DEBUG=False mode. BTW I have these settings in settings.py. MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'whitenoise.middleware.WhiteNoiseMiddleware', # what i added 'django.middleware.common.CommonMiddleware', # and so on... ] STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage' I assume maybe whitenoise setting has something to do with collectstatic command.
I have the similar issue, in my case it was caused by having a Commented script inside the body tag. <!--<script> </script>-->
I know this post is quite old but it's still perfectly relevant today. For what it's worth - I was getting a 500 with DEBUG = False for all pages on my site. I got no traceback when in debug. I had to go through every static link in my templates within my site and found one / (forward slash) in front of my image source. {% static ... %}. This caused the 500 error in DEBUG = False but worked perfectly fine in Debug = True with no errors. Very annoying! Be warned! Many hours of time wasted due to a forward slash...
I think it could also be the http server settings. Mine is still broken and had ALLOWED_HOSTS the entire time. I can access it locally (i use gunicorn), but not via the domain name when DEBUG=False. when I try using the domain name it then gives me the error, so makes me think its a nginx related issue. Here is my conf file for nginx: server { listen 80; server_name localhost myproject.ca www.myproject.ca; root /var/web/myproject/deli_cms; # serve directly - analogous for static/staticfiles location /media/ { # if asset versioning is used if ($query_string) { expires max; } } location /admin/media/ { # this changes depending on your python version root /var/web/myproject/lib/python2.6/site-packages/django/contrib; } location /static/ { alias /var/web/myproject/deli_cms/static_root/; } location / { proxy_pass_header Server; proxy_set_header Host $http_host; proxy_redirect off; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Scheme $scheme; proxy_connect_timeout 10; proxy_read_timeout 10; proxy_pass http://localhost:8000/; } # what to serve if upstream is not available or crashes error_page 500 502 503 504 /media/50x.html; }
A bit late to the party, and off course there could be a legion of issues but I've had a similar issue and it turned out that I had {% %} special characters inside my html remark... <!-- <img src="{% static "my_app/myexample.jpg" %}" alt="My image"/> -->
I ran into this issue. Turns out I was including in the template, using the static template tag, a file that did not exist anymore. A look in the logs showed me the problem. I guess this is just one of many possible reasons for this kind of error. Moral of the story: always log errors and always check logs.
Thanks to #squarebear, in the log file, I found the error: ValueError: The file 'myapp/styles.css' could not be found with <whitenoise.storage.CompressedManifestStaticFilesStorage ...>. I had a few problems in my django app. I removed the line STATICFILES_STORAGE = 'whitenoise.django.GzipManifestStaticFilesStorage' which I found from the heroku's documentation. I also had to add extra directory (thanks to another SO answer) static in the root of django application as myapp/static even though I wasn't using it. Then running the command python manage.py collectstatic before running the server solved the problem. Finally, it started working fine.
this maybe help someone else, in my case the problem with the missing favicon.
I know this is an old question, but I was also getting a 500 error when DEBUG=False. After several hours, I realized I had forgot to end some of the links in my base.html with a trailing slash.
This is old and my problem ended up being related to the problem but not for the OP but my solution is for anyone else who tried the above to no avail. I had a setting in a modified version of Django to minify CSS and JS files that only ran when DEBUG was off. My server did not have the CSS minifier installed and threw the error. If you are using Django-Mako-Plus, this might be your issue.
One small thing to note, If the array has None in it, then all the subsequent allowed hosts are ignored. ALLOWED_HOSTS = [ "localhost", None, 'example.com', # First DNS alias (set up in the app) #'www.example.com', # Second DNS alias (set up in the app) ] Django version 1.8.4
I had one view that threw a 500 error in debug=false but worked in debug=true. For anyone who is getting this kind of thing and Allowed Hosts is not the problem, I fixed my view by updating a template's static tag that was pointing to the wrong location. So I'd suggest just checking links and tags are airtight in any templates used, maybe certain things slip through the net in debug but give errors in production.
I found yet another cause of the 500 error when DEBUG=False. I use the Django compressor utility and our front-end engineer added references to font files inside a compress css block in a Django template. Like this: {% compress css %} <link href="{% static "css/bootstrap.css" %}" rel="stylesheet"> <link href="{% static "css/bootstrap-spinedit.css" %}" rel="stylesheet"> <link href="{% static "djangular/css/styles.css" %}" rel="stylesheet"> <link href="{% static "fonts/fontawesome-webfont.ttf" %}" rel="stylesheet"> {% endcompress %} The solution was to move the link to the ttf file below the endcompress line.
I started to get the 500 for debug=False in the form of django.urls.exceptions.NoReverseMatch: Reverse for 'home' not found. or... django.urls.exceptions.NoReverseMatch: Reverse for 'about' not found. when raising django.core.exceptions.ValidationError instead of raising rest_framework.serializers.ValidationError To be fair, it was already raising a 500 before, but as a ValidationError, with debug=False, this changed into the NoReverseMatch.
I had a problem similar to this and I will report how I solved mine because it could be that someone is also experiencing the same. In my case, the error was caused because the server was not finding some static files from the homepage. So make sure the error only occurs in the index or occurs on another page. If the problem is only occurring in the index very probably you need to check the static files. I recommend opening the Chrome preview console and checking for any errors. In my case, the server couldn't find favicon.ico and two other CSS. To fix this I passed python manage.py collectstatic and it worked.
my problem was in wrong 404.html template - I copy&pasted <a href="{% url 'home:index' %}"> instead of (in my case) <a href="{% url 'posts:index' %}"> that's why 500 apperar
Django app runs locally but I get CSRF verification failed on Heroku
My app runs fine at heroku local but after deployed to Heroku, every time I try to login/register/login as admin, it returns this error shown below. I have tried to put #csrf_exempt on profile views, but that didn't fix the issue. What can I do?
The error message is fairly self-explanatory (please excuse typos as I can't copy from an image): Origin checking failed - https://pacific-coast-78888.herokuapp.com does not match any trusted origins The domain you are using is not a trusted origin for CSRF. There is then a link to the documentation, which I suspect goes to the Django CSRF documentation, though the documentation for the CSRF_TRUSTED_ORIGINS setting might be more useful: A list of trusted origins for unsafe requests (e.g. POST). For requests that include the Origin header, Django’s CSRF protection requires that header match the origin present in the Host header. Look in your settings.py for CSRF_TRUSTED_ORIGINS and add https://pacific-coast-78888.herokuapp.com to the list. If that setting doesn't already exist, simply add it: CSRF_TRUSTED_ORIGINS = ["https://pacific-coast-78888.herokuapp.com"]
If Heroku uses django "4.x.x" version: Then, if the error is as shown below: Origin checking failed - https://example.com does not match any trusted origins. Add this code below to "settings.py": CSRF_TRUSTED_ORIGINS = ['https://example.com'] In your case, you got this error: Origin checking failed - https://pacific-coast-78888.herokuapp.com does not match any trusted origins. So, you need to add this code below to your "settings.py": CSRF_TRUSTED_ORIGINS = ['https://pacific-coast-78888.herokuapp.com']
It appears you do not have your heroku address as a trusted origin in the setting.py file of your project, to do this, you can use corsheaders pip install django-cors-headers then in your settings.py file INSTALLED_APPS = [ ... 'corsheaders', ... ] MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', ... 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'corsheaders.middleware.CorsMiddleware', ] If you were not yet deployed you could add CORS_ORIGIN_ALLOW_ALL = True but because you know where your app is deployed using a whitelist for the origins is a much better idea CORS_ORIGIN_WHITELIST = ( 'https://pacific-coast-78888.herokuapp.com', )
when i upgrade django-debug-toolbar at 1.6 is does not working
Hi I'm create study project using django==1.9.7 when I use django-debug-toolbar==1.4, i works find and I upgrade 1.4 => django-debug-toolbar==1.6, and restart runserver, I doesn't woking.. my django-debug-toolbar setting is settings.py INSTALLED_APPS = [ # ... # 'debug_toolbar', # ...# ] MIDDLEWARE_CLASSES = [ #...#, 'debug_toolbar.middleware.DebugToolbarMiddleware', ] STATIC_URL = '/static/' DEBUG = True(of course!) when I settings these three parts, 1.4versions works find, but when I upgrade 1.6(and settings no change) it does not working, So, I see document document Support for automatic setup has been removed as it was frequently problematic. Installation now requires explicit setup. The DEBUG_TOOLBAR_PATCH_SETTINGS setting has also been removed as it is now unused. See the installation documentation for details. It seems automatic setup has been removed I see Install ducoment(stable version) but I can't find what is different with Install document(1.4 versions) I needs some advise. thank you
From what I can see, you might be missing two things. In your urls.py: from django.conf import settings from django.conf.urls import include, url if settings.DEBUG: import debug_toolbar urlpatterns += [ url(r'^__debug__/', include(debug_toolbar.urls)), ] And in your settings.py: INTERNAL_IPS = ('127.0.0.1') assuming you're running on localhost right now. Do these changes and tell me if this helps you.
Django serving each app separately in each its port
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' %}.
django: admin site not formatted
I have a mostly entirely plain django project, with no adding of my own media or customization of the admin interface in any way. Running the server with python manage.py runserver results in a nicely-formatted admin interface. Running the server with gunicorn_django does not. Why is this the case, and how can I fix it? It's definitely an issue of not finding the css files, but where are they stored? I never configured this, and the MEDIA_ROOT setting is ''. EDIT: I just want to know how django-admin serves the non-existent admin files... and how can I get gunicorn_django to do the same?
If you use contrib.static, you have to execute a collectstatic command to get all the app-specific static files (including admin's own) into the public directory that is served by gunicorn.
I've run into this problem too (because I do some development against gunicorn), and here's how to remove the admin-media magic and serve admin media like any other media through urls.py: import os import django ... admin_media_url = settings.ADMIN_MEDIA_PREFIX.lstrip('/') + '(?P<path>.*)$' admin_media_path = os.path.join(django.__path__[0], 'contrib', 'admin', 'media') urlpatterns = patterns('', url(r'^admin/', include(admin.site.urls)), url(r'^' + admin_media_url , 'django.views.static.serve', { 'document_root': admin_media_path, }, name='admin-media'), ... ) Also: http://djangosnippets.org/snippets/2547/ And, of course, #include <production_disclaimer.h>.
I think the easiest way is to add alias to nginx (are you using one?!) configuration file: location /static/admin/ { alias /<path_to_your_admin_static_files>/; } it worked immediately for me
Ok, got it. Just had to add this line to settings.py: MEDIA_ROOT = '/home/claudiu/server/.virtualenv/lib/python2.5/site-packages/django/contrib/admin/media/'
David Wolever's answer was close, for my installation, but I think some paths may have changed in newer django. In particular I set admin_media_path = os.path.join(django.__path__[0], 'contrib', 'admin', 'static', 'admin') and in urlpatterns added: url(r'^static/admin/(?P<path>.*)$', 'django.views.static.serve', { 'document_root': admin_media_path, }), based on info found here: https://docs.djangoproject.com/en/dev/howto/static-files/ works for me, but more "magical" than I like.