As reported in Django's Trac ticket #27774, enabling the "Templates" panel on a page that does a lot of template-widget rendering (#15667) results in unacceptably slow page load. I'm not sure what an appropriate resolution might be. A possibility could be to have the debug toolbar ignore analysis for widget rendering.

In order to use debug toolbar with a content security policy enabled, no inline scripts or styles can be used. This commit replaces all style attributes with CSS or javascript. It uses data attributes to handle the dynamic styles, like width and color.

In addition, this required updating jQuery to 1.8, because 1.7 is not CSP compatible.

See also #307, which began implementing CSP compatibility.

In latest master lazy querysets in template context are re-evaluting on every template context rendering so instead of e.g. 15 queries 100+ sql queries are executed with django-debug-toolbar enabled. Turning off 'debug_toolbar.panels.template.TemplateDebugPanel' brings sql query count back to 15. Extra queries information: http://pix.am/G8M0/

Latest commit in SQL refactoring branch that works for me was 4d69dbea, starting from 5aff6ee7 debug toolbar either fails with an exception (None in not iterable, not all arguments are converted on string formatting) or generates extra sql queries (I may be wrong because I haven't tried all the commits).

The setup is postgres, django 1.3 and TemplateResponse, the view is not wrapped in transaction. Using HttpResponse or wrapping view in transaction doesn't change anything.

(edited: corrected commit numbers)

Some browsers support navigation timing via javascript. Since these metrics fit the category of timing, this commit adds a section to the timing panel containing key metrics from the browser, triggered soon after the onLoad event.

The change is plain javascript, so no library dependencies.

Background: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Screenshot: http://dl.dropbox.com/u/15940111/browser_timing.png

Tested on Chrome 22 and Firefox 14

in my setup i always have seperate dev settings and in those settings i enable debug toolbar for all requests. i've always done that with the following config

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': lambda request: True,
}

after updating my virtualenv this morning i started getting errors that i've tracked down to trying to run rsplit on func_path

line 45 of debu_toolbar/middleware.py:

    mod_path, func_name = func_path.rsplit('.', 1)

it looks like the meaning of SHOW_TOOLBAR_CALLBACK may have changed to require a string and not support a callable. if that's the case i'm not sure what the solution would be. i'd rather not have to define a function somewhere and point this at it just to return true. i'd prefer if SHOW_TOOLBAR_CALLBACK supported being presented a callable.

Since Django 1.5 StreamingHttpResponse is introduced, this response class does not have content attribute, django-debug-toolbar middleware should be aware of that.

Now I get this error:

Traceback (most recent call last):
  File "/usr/lib/python2.7/wsgiref/handlers.py", line 85, in run
    self.result = application(self.environ, self.start_response)
  File "/home/sirex/.buildout/eggs/Django-1.5-py2.7.egg/django/contrib/staticfiles/handlers.py", line 72, in __call__
    return self.application(environ, start_response)
  File "/home/sirex/.buildout/eggs/Django-1.5-py2.7.egg/django/core/handlers/wsgi.py", line 255, in __call__
    response = self.get_response(request)
  File "/home/sirex/.buildout/eggs/Django-1.5-py2.7.egg/django/core/handlers/base.py", line 187, in get_response
    response = middleware_method(request, response)
  File "/home/sirex/.buildout/eggs/django_debug_toolbar-0.9.4-py2.7.egg/debug_toolbar/middleware.py", line 131, in process_response
    smart_unicode(response.content),
  File "/home/sirex/.buildout/eggs/Django-1.5-py2.7.egg/django/http/response.py", line 341, in content
    "Use `streaming_content` instead." % self.__class__.__name__)
AttributeError: This StreamingHttpResponse instance has no `content` attribute. Use `streaming_content` instead.

I use Django 1.5 and django-debug-toolbar 0.9.4.

        # if not internal ip, and not DEBUG
        if not (remote_addr in settings.INTERNAL_IPS or settings.DEBUG):
            return False

The above line of code causes debug info to be shown to non privileged IPs.

This is extremely bad and is completely against the documentation:

"The default checks are that DEBUG must be set to True and the IP of the request must be in INTERNAL_IPS. "

Please release an urgent fix for this by using:

        # if not internal ip, and not DEBUG
        if not (remote_addr in settings.INTERNAL_IPS and settings.DEBUG):
            return False

I'm creating a new issue to track in a single place all the problems related to the way the Debug Toolbar inserts jQuery into the page. #440 was supposed to fix the problem, but it didn't work for the trivial case of an HTML page without any JavaScript.

I went for a very dumb solution in 2b6f5d6661dac283b7fb1cdfc6e252b6b6367d19. I don't know any better and I'm unable to assess the solutions that have been offered.

As a consequence, until the other maintainers have a look at this issue or the toolbar gains new maintainers, this issue is unlikely to move forwards.

I will now close all the issues that are variations of this issue as duplicates.

patch_root_urlconf appears to cause an ImproperlyConfigured error for me:

The included urlconf project.urls doesn't have any patterns in it

This happens after adding debug_toolbar to INSTALLED_APPS.

From the traceback it looks like the admin autodiscover triggers invocation of DDT's patching, but the project urlconf is still empty at that point.

apps/project/urls.py looks as follows:

# imports and autocomplete_light setup
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns(
    '',
    (r'^grappelli/', include('grappelli.urls')),
    url(r'^admin/', include(admin.site.urls)),

    # …
)

This does not happen with DDT 0.10.2.

I have also tried / are currently DDT master.

Django Version: 1.6.2.dev20140104173735

Traceback:
File "/home/daniel/src/django-stable/django/core/handlers/base.py" in get_response
  101.                 resolver_match = resolver.resolve(request.path_info)
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in resolve
  318.             for pattern in self.url_patterns:
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in url_patterns
  346.         patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in urlconf_module
  341.             self._urlconf_module = import_module(self.urlconf_name)
File "/home/daniel/src/django-stable/django/utils/importlib.py" in import_module
  40.         __import__(name)
File "/home/daniel/projects/tmm/apps/project/urls.py" in <module>
  15. admin.autodiscover()
File "/home/daniel/src/django-stable/django/contrib/admin/__init__.py" in autodiscover
  29.             import_module('%s.admin' % app)
File "/home/daniel/src/django-stable/django/utils/importlib.py" in import_module
  40.         __import__(name)
File "/home/daniel/src/django-stable/django/contrib/auth/admin.py" in <module>
  182. admin.site.register(Group, GroupAdmin)
File "/home/daniel/src/django-stable/django/contrib/admin/sites.py" in register
  92.                     admin_class.validate(model)
File "/home/daniel/src/django-stable/django/contrib/admin/options.py" in validate
  105.         validator = cls.validator_class()
File "/home/daniel/src/django-stable/django/contrib/admin/validation.py" in __init__
  20.         models.get_apps()
File "/home/daniel/src/django-stable/django/db/models/loading.py" in get_apps
  139.         self._populate()
File "/home/daniel/src/django-stable/django/db/models/loading.py" in _populate
  75.                 self.load_app(app_name, True)
File "/home/daniel/src/django-stable/django/db/models/loading.py" in load_app
  99.             models = import_module('%s.models' % app_name)
File "/home/daniel/src/django-stable/django/utils/importlib.py" in import_module
  40.         __import__(name)
File "/home/daniel/.virtualenvs/tmm/src/django-debug-toolbar/debug_toolbar/models.py" in <module>
  63.     patch_root_urlconf()
File "/home/daniel/.virtualenvs/tmm/src/django-debug-toolbar/debug_toolbar/models.py" in patch_root_urlconf
  51.         reverse('djdt:render_panel')
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in reverse
  480.                 app_list = resolver.app_dict[ns]
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in app_dict
  310.             self._populate()
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in _populate
  262.         for pattern in reversed(self.url_patterns):
File "/home/daniel/src/django-stable/django/core/urlresolvers.py" in url_patterns
  350.             raise ImproperlyConfigured("The included urlconf %s doesn't have any patterns in it" % self.urlconf_name)

Exception Type: ImproperlyConfigured at /
Exception Value: The included urlconf project.urls doesn't have any patterns in it

Steps to reproduce:

1. Refresh a page
2. Open a the debug toolbar
3. Select the SQL panel
4. Press the + button for an SQL request

Result:

• Nothing happens, the + button is not responsive (whatever the SQL request)
• (There is no such issue in earlier versions, including 2.2, 3.0, 3.1.)

Expected result:

• The + button should show the details of the SQL request

Environement:

• django 3.1.5
• debug-toolbar 3.2
• python 3.6.8

Hello, I'm getting the following message in some pages:

Data for this panel isn't available anymore. Please reload the page and retry.

I tried updating to the latest version (1.3.2), but still get the same message. It's really strange that for some pages works fine and for others not. Any ideas?

Thanks

by upgrading django to version 4.0.2 view function on django-debug-toolbar doesn't display properly. The expected string should be the class name: DashboardView not "backend_base.views.view". "backend_base" is app name.

The class itself is very simple: class DashboardView(LoginRequiredMixin, NavBarMixin, TemplateView): template_name = 'dashboard.html'

backend_base.views.view

source of issue: mario-signorino on stackoverflow.

Some time ago I updated to DjDT 3.4.0 from the previous version and instantly ran into issues on certain pages of the Django project (but not others).

The page loading times out and when I check the logs I see:

Error running WSGI application
RecursionError: maximum recursion depth exceeded while calling a Python object

I suspect there is an issue related to DjDT because the problems appeared after the update to DjDT 3.4.0 and when I disable DjDT by setting ‘Debug = False’ I don’t have any issues. Also, there appear to have been similar issues in DjDT years ago.

This is what it says in the DjDT version panel. Django 3.2.13 Python 3.9.5 debug_toolbar Debug Toolbar 3.4.0 django_tables2 Django_Tables2 2.4.1

I’m on the LTS version of Django for a reason and I use Python 3.9.5 because that’s supplied by my hosting provider.

Could this be a regression? Is there anything specific you need to narrow it down?

Hello,

using Django Debug Toolbar 3.2.4 with Django 4.0.3, I get the following stack trace:

Traceback (most recent call last):
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/debug_toolbar/middleware.py", line 93, in __call__
    response.content = insert_before.join(bits)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/template/response.py", line 143, in content
    HttpResponse.content.fset(self, value)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/http/response.py", line 387, in content
    content = self.make_bytes(value)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/http/response.py", line 296, in make_bytes
    return bytes(value.encode(self.charset))
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 181020-181021: surrogates not allowed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/wsgi.py", line 132, in __call__
    response = self.get_response(request)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/base.py", line 140, in get_response
    response = self._middleware_chain(request)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/exception.py", line 57, in inner
    response = response_for_exception(request, exc)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/exception.py", line 139, in response_for_exception
    response = handle_uncaught_exception(
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/core/handlers/exception.py", line 180, in handle_uncaught_exception
    return debug.technical_500_response(request, *exc_info)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/views/debug.py", line 67, in technical_500_response
    return HttpResponse(html, status=status_code, content_type="text/html")
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/http/response.py", line 355, in __init__
    self.content = content
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/http/response.py", line 387, in content
    content = self.make_bytes(value)
  File "/home/carsten/.virtualenvs/Lori/lib/python3.8/site-packages/django/http/response.py", line 296, in make_bytes
    return bytes(value.encode(self.charset))
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 5995-5996: surrogates not allowed

The related section around line 93 in debug_toolbar/middleware.py is:

        # Always render the toolbar for the history panel, even if it is not
        # included in the response.
        rendered = toolbar.render_toolbar()

        # …

        # Insert the toolbar in the response.
        content = response.content.decode(response.charset)
        insert_before = dt_settings.get_config()["INSERT_BEFORE"]
        pattern = re.escape(insert_before)
        bits = re.split(pattern, content, flags=re.IGNORECASE)
        if len(bits) > 1:
            bits[-2] += rendered
            response.content = insert_before.join(bits)
            if "Content-Length" in response:
                response["Content-Length"] = len(response.content)
        return response

If I replace line

            bits[-2] += rendered

with

            bits[-2] += rendered.encode('ascii', 'replace').decode()

in order to get rid of any problematic characters, it works.

Unfortunately, I've no idea what might cause this and I'm not sure how to proceed from here?

toolbar will show when you login admin , however it will not show when you use Render or HttpResponse function in view function . like class Vue3API(APIView): def get(self, request, **kwargs): """ Return a list of all users. """ books = Book.objects.all() se = BookSerializerPro(books, many=True) # this code will show debug panel return Response(se.data) # this code will not show debug panel #return render(request, "register.html", {"foo": "bar"}) #return HttpResponse(content="tesing".encode())

i use the windows 10 even i have configure the HKEY_CLASSES_ROOT.js in register table !
Django |   | 3.2.10 Python |   | 3.9.1 debug_toolbar | Debug Toolbar | 3.2.4

The cache panel is causing a very large slowdown in page loads when it is enabled.

I've just tested an admin list page, and without the cache panel enabled it loads in ~750ms, but with it enabled it takes 25 - 30 seconds (I averaged 3 page loads of each for these numbers). The cache panel shows that there are 12 total calls on this page, and times them at ~1.4ms.

I feel like this behaviour is relatively recent, so I tried dropping our version of Django which we upgraded recently. On Django 3.2.11, the page load time with the panel disabled is the same, but with it enabled the times are lower at 13 - 18s. Django pre-4.0 is faster, but still much slower than I think would be expected.

Trying on a non-admin page, I found the page loads times to be low for both Django versions with the panel disabled, and around 10x higher for both with it enabled.

For all these tests, the load times were not very reproducible when flicking between versions and restarting Django, so I've only included a few of them here. What I did notice across all of this testing is that with the panel enabled, load times often increase on each reload e.g. first load takes 2s, then 2.5s, then 3s...

This test was run on MacOS, and I've had a colleague confirm my observations on Linux also.

I'm happy to do some debugging if pointed in the right direction.

Versions: Python 3.9.9 Django 4.0.1 django-debug-toolbar 3.2.4