171

I looked at other questions and can't figure it out...

I did the following to install django-debug-toolbar:

  1. pip install django-debug-toolbar
  2. 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

Srikar Appalaraju
  • 71,928
  • 54
  • 216
  • 264
AlexBrand
  • 11,971
  • 20
  • 87
  • 132
  • 16
    If you're using Vagrant, make sure that your `INTERNAL_IPS` is correct. One way to check is in a view, print your `request.META['REMOTE_ADDR']`, then add that to your `INTERNAL_IPS`. – Will Oct 22 '15 at 16:38
  • 2
    This might help somebody. I was trying by adding `'*'` in the internal IPs, but that does not work. You have to enter specific IPs. – Luv33preet May 17 '18 at 06:46
  • In my settings.py, it's now MIDDLEWARE only, not MIDDLEWARE_CLASSES – Bertie Jun 20 '19 at 02:27
  • You should include the Debug Toolbar middleware as early as possible in the list. As per https://django-debug-toolbar.readthedocs.io/en/latest/installation.html – Tarun Kumar Dec 26 '21 at 08:19

36 Answers36

215

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.

vvvvv
  • 25,404
  • 19
  • 49
  • 81
Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • 3
    Yeah, so there's some larger issue going on here. If you're using something other than `runserver` make sure you restart it. Heck, restart `runserver`, too. Make sure your changes to settings.py *actually* got saved/commited. You might want to try removing *.pyc files. In *nix, you can do that simply with `find . -name "*.pyc" -exec rm {} \;` from the project root. Finally, run `python manage.py shell` and execute `from django.conf import settings` and check the value of `settings.INSTALLED_APPs`. – Chris Pratt May 09 '12 at 14:42
  • Settings are definitely being applied.. I commented out my template dirs and it couldn't find the templates for me.. I really don't know what is going on... Do you think that the fact that when you browse to the IP address, you don't get the site might have something to do with it? – AlexBrand May 09 '12 at 14:59
  • 4
    I'm not sure what you mean with the last question, but if you're referring to `INTERNAL_IPS`, those are for the client not the server (Django). In other words, you put in *your* IP address so *you* can see debug toolbar, no matter what IP the site may be running on. – Chris Pratt May 09 '12 at 15:13
  • The `INTERNAL_IPS` is what did me in... darn you cable ISP for changing out my IP without notice. – Jordan Reiter Aug 27 '12 at 17:18
  • 10
    INTERNAL_IPS got me aswell.. Thanks for the info – Lee Dec 09 '12 at 15:57
  • 14
    or even `SHOW_TOOLBAR_CALLBACK = lambda x: True` – John Mee Jun 21 '13 at 06:35
  • 2
    callback setting atleast for 0.9.4 should be DEBUG_TOOLBAR_CONFIG.update({'SHOW_TOOLBAR_CALLBACK': show_toolbar,}) – Arpit Singh Feb 10 '14 at 06:43
  • I can't see it either, even though there's debug toolbar html in the page source and output in the server log. This is probably the culprit: https://github.com/django-debug-toolbar/django-debug-toolbar/issues/624 – Rob Grant Aug 20 '14 at 08:29
  • @RobertGrant You may want to check your static files then. If the HTML is there, then the javascript may not be functioning correctly to display it. – schillingt Sep 11 '14 at 12:15
  • 6
    @schillingt yes, apologies I should've checked this. I think I had to run `collectstatic` to make everything appear. – Rob Grant Sep 11 '14 at 12:47
  • 1
    Just FYI, `show_toolbar` function trick above won't bypass a missing `INTERNAL_IPS` setting, v.1.2.2 (so double-check your `INTERNAL_IPS` first). – Jheasly Feb 18 '15 at 23:47
  • Since I'm running Django in a Vagrant box, I had to add 10.0.2.2 to my `INTERNAL_IPS` and since I'm using Pycharm to execute `runserver`, I had to edit the host part in its run configuration to 0.0.0.0, I had [::] there earlier, but that failed to make debug-toolbar work for me. Thanks all for the discussion, especially @ChrisPratt – Lauri Elias Apr 21 '15 at 11:21
  • I was returning a simple string in the response without full HTML but with content-type header as 'text/html'. Enclosing the string inside `` tag did the work. Link : http://django-debug-toolbar.readthedocs.org/en/latest/tips.html – xtreak Jul 23 '15 at 11:41
  • For more info on the ip issue you may want to check my code samples on the answer to this question: http://stackoverflow.com/questions/42104980/how-do-i-get-django-debug-toolbar-to-only-display-on-my-ip-address-hosted-on-pyt/42105384#42105384 – Tim Feb 08 '17 at 21:55
  • INTERNAL_IPS helped in my case – ihoru Dec 21 '17 at 07:04
  • I'm running Django 1.8. `show_toolbar()` and `DEBUG_TOOLBAR_CONFIG` helped me. I don't have a clue as to why it didn't work prior to that. – Vishal May 14 '18 at 15:00
  • One would assume that 127.0.0.1 would be set in the default settings since the docs discourage any alterations in the config – PunchyRascal Jun 11 '18 at 14:55
  • Updated format for @JohnMee's lambda comment: `DEBUG_TOOLBAR_CONFIG = {"SHOW_TOOLBAR_CALLBACK" : lambda x: True}` – Christian Long Jun 26 '20 at 16:28
  • Adding this indeed made it appear for me: `DEBUG_TOOLBAR_CONFIG = {"SHOW_TOOLBAR_CALLBACK": lambda request: True}`. So that's wonderful if I remove that it disappears, if I add it appears. That's great to know, **but** wouldn't it be nice to know *why* this is needed? What could be wrong with configs to necessitate this? I've used the toolbar many times before and it always worked as documented. On this one project not, so here I am research why, and found this workaround and it worked, but *why?*. – Bernd Wechner Feb 21 '23 at 09:39
96

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.

Denilson Sá Maia
  • 47,466
  • 33
  • 109
  • 111
timothyashaw
  • 1,309
  • 13
  • 7
  • 2
    I was getting to my page via nginx proxy pass through so the remote_addr was my proxy and not my real ip. I needed to add my proxy ip address to `INTERNAL_IPS` and it started working. – Kurt Feb 01 '16 at 06:43
  • 1
    From my guest machine in VirtualBox, my host machine is seen as 10.0.0.2, if it can help someone. :) – mrmuggles Jun 21 '16 at 08:17
  • VERY useful to CHECK IP if you use some virtualization like VAGRANT – andilabs May 12 '17 at 15:26
  • 5
    In docker my REMOTE_ADDR was not what I would have assumed. – Aaron McMillin Jun 13 '17 at 21:59
69

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.

user1569050
  • 6,099
  • 2
  • 18
  • 14
  • In my case adding to settings.py `DEBUG_TOOLBAR_CONFIG = {'INSERT_BEFORE':''}` worked – wojteck Jul 20 '20 at 11:54
  • Thanks for including this tip. I had a syntax error in a comment near the bottom of my template which caused the closing body and html tags to be ignored. – cmc Nov 03 '22 at 20:49
  • That was it for me, tried to install DjDT following the [Django Tutorial 08](https://docs.djangoproject.com/en/4.2/intro/tutorial08/), but having ignored the note from the [Tutorial 03](https://docs.djangoproject.com/en/4.2/intro/tutorial03/) about using [complete HTML documents](https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/Getting_started#anatomy_of_an_html_document) for templates. – paime Jul 28 '23 at 01:28
35

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

Mark Chackerian
  • 21,866
  • 6
  • 108
  • 99
  • I'm hosted on heroku and this is the only thing that worked – Tom May 22 '21 at 05:52
  • Obscure, but when I set `DEBUG=True` and then ran DRF `APIClient` endpoint tests, I got exceptions (`TypeError: 'SQLPanel' object is not subscriptable`, `KeyError: 'djdt'`, `django.urls.exceptions.NoReverseMatch: 'djdt' is not a registered namespace`). I was using `if settings.DEBUG` to conditionally add debug toolbar urlpatterns to `urls.py`. Because Django sets `DEBUG=False` during tests, but seemingly only _after_ `settings.py` has been imported, the app and middleware were getting installed and the toolbar was being forced to show, but the required urlpatterns were absent. – kcontr Dec 03 '21 at 17:47
32

The current stable version 0.11.0 requires the following things to be true for the toolbar to be shown:

Settings file:

  1. DEBUG = True
  2. 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.
  3. The debug_toolbar app to be installed i.e INSTALLED_APPS = (..., 'debug_toolbar',)
  4. 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:

  1. Must be of type text/html
  2. 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
donturner
  • 17,867
  • 8
  • 59
  • 81
28

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.

Anoyz
  • 7,431
  • 3
  • 30
  • 35
15

I have the toolbar working just perfect. With this configurations:

  1. DEBUG = True
  2. INTERNAL_IPS = ('127.0.0.1', '192.168.0.1',)
  3. DEBUG_TOOLBAR_CONFIG = {'INTERCEPT_REDIRECTS': False,}
  4. 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

Abid A
  • 7,588
  • 4
  • 32
  • 32
César
  • 9,939
  • 6
  • 53
  • 74
  • 3
    You should probably redact your IP address from your answer. Since most people are running broadband these days and most broadband connections rarely change IP address if ever. You probably don't want that hanging around on the interwebs. – Chris Pratt May 09 '12 at 14:53
  • 192.168.*.* is an internal local IP address assigned to the computer by the router. The external IP address is different. – Robeezy Nov 21 '13 at 00:59
  • @rpod that's exactly why somebody edited it to that. – Yuji 'Tomita' Tomita Dec 06 '13 at 21:16
  • If you're using the One True Config File, and only want Debug Toolbar in dev, instead of adding it to the middleware_classes in `base.py` you might want to add this to your `local.py`: `MIDDLEWARE_CLASSES = ('debug_toolbar.middleware.DebugToolbarMiddleware',) + MIDDLEWARE_CLASSES`. – Rob Grant Aug 20 '14 at 08:59
12

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.

Bas Koopmans
  • 341
  • 4
  • 14
6

I had the same problem and finally resolved it after some googling.

In INTERNAL_IPS, you need to have the client's IP address.

ЯegDwight
  • 24,821
  • 10
  • 45
  • 52
Farhan Hafeez
  • 634
  • 1
  • 6
  • 22
5

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

4

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.

AgDude
  • 1,167
  • 1
  • 10
  • 27
3

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

Bob
  • 5,809
  • 5
  • 36
  • 53
3

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.

metakermit
  • 21,267
  • 15
  • 86
  • 95
3

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',
# ...
]
Stryker
  • 5,732
  • 1
  • 57
  • 70
3
  1. 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.

  2. Then from chrome, I inspect the webpage and change classname class="djdt-hidden". You can try changing it or removing it.

  3. run manage.py collectstatic and repeat the above step

  4. Actually you can skip steps 2 and 3, by editing

    .djdt-hidden{ display: none;}

    from path

    debug_toolbar/static/debug_toolbar/css/toolbar.css

  5. Add this two lines somewhere in settings.py

    import mimetypes

    mimetypes.add_type("application/javascript", ".js", True)

  6. in urls.py

    import debug_toolbar

    urlpatterns += [ path('__debug__/', include(debug_toolbar.urls)),]

  7. Use reference django debug toolbar installation

  1. 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
    }
]

} `

  1. 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

  • For **Windows** users in **2022** _(with modern Django `4.1` and django-debug-toolbar `3.5.0`)_ **steps 5, 6 and 7 should be enough**. If you want to avoid step 5 you must edit your system registry as mentioned in [this answer below](https://stackoverflow.com/a/69352647/3366563). Also you can avoid redundant `import debug_toolbar` in step 6 if you pass module as string to include() function, i.e. `urlpatterns += [path('__debug__/', include('debug_toolbar.urls'))]` – hotenov Aug 11 '22 at 16:15
2

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.

TimStaley
  • 515
  • 4
  • 21
2

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.

RemcoGerlich
  • 30,470
  • 6
  • 61
  • 79
  • Even enabling GZip at the view level with `gzip_page` makes the toolbar disappear. https://docs.djangoproject.com/en/2.0/topics/http/decorators/#django.views.decorators.gzip.gzip_page – Brachamul Jul 12 '18 at 14:34
2

In my case I just needed to remove the python compiled files (*.pyc)

dnaranjo
  • 3,647
  • 3
  • 27
  • 41
  • Thank you for this comment, it saved me a mental breakdown this morning. If everything else looks right - and this project had been working before just fine for me - try this and see if it resolves it. The DDT HTML/JS was on the page, everything looked fine, but it still wouldn't actually show up. I cleared the pyc files and it started showing up again – Shane Jul 07 '20 at 17:22
1

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', )

Anderson Santos
  • 169
  • 1
  • 1
  • 6
1

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
1

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
0

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.

user1552891
  • 527
  • 5
  • 4
0

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.

Adriano Silva
  • 2,518
  • 1
  • 17
  • 29
0

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.

Petko M
  • 653
  • 2
  • 5
  • 18
0

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

wolendranh
  • 4,202
  • 1
  • 28
  • 37
0

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.

jozo
  • 4,232
  • 1
  • 27
  • 29
0

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.

ogurets
  • 618
  • 1
  • 12
  • 20
0

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'

0

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

hn_tired
  • 690
  • 10
  • 21
0

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.

0

Everything is done, but in Chrome no "django debug toolbar" is showed.

Chrome console: Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec. (toolbar.js;1)

In EDGE, exactly from the same server and url, is the toolbar showed.

Bob Baeck
  • 81
  • 1
  • 3
0

I have the same problem and I have tried all the solutions above and non of them worked. Then I tried to find out what is the main issues of this problem in my project, and it was coming from the template file. Make sure that your template content is inside the <body></body>.

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>

</body>
</html>

Dhia Shalabi
  • 1,332
  • 1
  • 13
  • 29
0

I was getting the below error, but I was able to see the related components to the debug_toolbar in view page source. Then inspect page shows the below error.

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/plain". Strict MIME type checking is enforced for module scripts per HTML spec.

enter image description here

Then I added this in the settings.py and the error disappeared and I was able to see the toolbar.

if DEBUG:
import mimetypes
mimetypes.add_type("application/javascript", ".js", True)
cdev
  • 5,043
  • 2
  • 33
  • 32
0

I hobbled together a few of these answers into one that worked for me. Versions:

Django 4.2.1

django-debug-toolbar 4.1.0

  1. Add this to settings.py :

    if DEBUG:
        import mimetypes
        mimetypes.add_type("application/javascript", ".js", True)
    
  2. Delete pycache .pyc files.

  3. Clear web cache (ctrl+shft+delete)

mkohler
  • 139
  • 5
-1

One stupid thing got me.. that if you use apache wsgi, remember to touch the .wsgi file to force your code recompile. just waste 20 minutes of my time to debug the stupid error :(

igameland
  • 11
  • 1
-2

Run the following command:

python manage.py migrate

Now run the server again

Ryan M
  • 18,333
  • 31
  • 67
  • 74