robhudson / django-debug-toolbar

See http://www.djangosnippets.org/snippets/605/. My thinking is this will trigger a new request to profile that specific URL and show the results.

There is a "localize" branch started but it needs to be completed. Vote for this if it's a high priority for you.

Malcolm has a patch on his tree that's mostly there:
git://sharp.pointy-stick.com/django-debug-toolbar.git

See notes here: http://code.google.com/p/django-debug-toolbar/issues/detail?id=13

When INTERCEPT_REDIRECTS enabled, cookies set by app's redirect response will be lost.

By example, in a login view, app set a user_id cookie on a redirect response, but this cookie does not send to browser actually.

(Originally added by: flytwokites on Google Code)

What steps will reproduce the problem?

1. Make any kind of sub selects with orm (like in example, or query with "WHERE ..._id IN ( SELECT ... ) ..." )

   SELECT (SELECT group_id FROM auth_user_groups WHERE auth_user_groups.user_id = auth_user.id LIMIT 1) AS first_user_group, auth_user.id, auth_user.username, auth_user.first_name, auth_user.last_name, auth_user.email, auth_user.password, auth_user.is_staff, auth_user.is_active, auth_user.is_superuser, auth_user.last_login, auth_user.date_joined FROM auth_user LEFT OUTER JOIN auth_user_groups ON (auth_user.id = auth_user_groups.user_id) ORDER BY auth_user_groups.group_id ASC

What is the expected output? What do you see instead?

Correct output should looks like this:

SELECT
(SELECT
    group_id FROM auth_user_groups
    WHERE
auth_user_groups.user_id = auth_user.id LIMIT 1) AS `first_user_group`,
`auth_user`.`id`, `auth_user`.`username`, `auth_user`.`first_name`,
`auth_user`.`last_name`, `auth_user`.`email`, `auth_user`.`password`,
`auth_user`.`is_staff`, `auth_user`.`is_active`,
`auth_user`.`is_superuser`, `auth_user`.`last_login`, `auth_user`.`date_joined`
FROM
`auth_user`
LEFT OUTER JOIN
`auth_user_groups` ON (`auth_user`.`id` = `auth_user_groups`.`user_id`)
ORDER BY
`auth_user_groups`.`group_id` ASC

What version of the product are you using? On what operating system?

ea1f943

Originally added by overkrik on Google Code.

Similar to Dowser, look at implementing a memory tracking panel.

Consider adding python-sqlparse as an optional library to parse/display SQL queries vs our hack job.

See:
http://code.google.com/p/python-sqlparse/

Consider using Jannis' package for docs hosted on PyPI:
http://pypi.python.org/pypi/Sphinx-PyPI-upload/

After looking briefly I believe the problem is using force_unicode on each parameter resulting in a parameter of (True,) turning into ("True",), which doesn't get turned back into the raw boolean when trying to re-execute the query resulting in a database error.

I was wondering if it would be a good idea to provide a separate panel that would allow the user to toggle each panel from the frontend. That'd useful e.g. in case the SQL panel takes to long to render and wouldn't require deactivating it site-wide.

Additionally this could be only used on a specific url/path, so that the toggle would survive clicking around the site. That option would be given the user to make in the panel, too.

I guess the toggle state could be saved in a cookie.

For whatever reason, I can't seem to hide the toolbar on FF3 mac.

django-debug-toolbar failed for me on a site running jQuery 1.3.2 - I think it's because of library version incompatibilities.

Armin describes a way of ensuring the version of jQuery that ships with the toolbar is the one used by its scripts, without interfering with the jQuery version in use on the site, here:

http://lucumr.pocoo.org/2009/9/26/jquery-in-middlewares

I'm seing some rather high loading times when I have the toolbar enabled, here's a profiler dump: http://dpaste.de/NSve/

Some 18 seconds spent in render_node. This is when working on http://github.com/mikl/pinax/commits/mingus and it happens for every page load.

I'm not quite sure how to debug this further, but it is on Django 1.0.3.

enjoy http://aur.archlinux.org/packages.php?ID=26003

For some debugging I've been doing, I've found it useful to configure the debug toolbar to only appear when a GET param is present, but then disappear again when a different GET param is present. This doesn't currently work. Fix in my fork at http://github.com/durin42/django-debug-toolbar/tree/master

It would be great if the toolbar templates had access to template context processors.

Passing "context_instance=RequestContext(self.request)" to the render_to_string call in "loader.py - render_toolbar()" does the trick.

It makes it easier for anyone who wants to overload the templates and wants for example to change the location of the toolbar media or change how they are served.

SQL Log Middleware is here: http://www.djangosnippets.org/snippets/344/

Working solution proposition:

http://dumpz.org/12573/
http://dumpz.org/12575/

this feature focuses on adding an icon beside every file path that is displayed by the debug toolbar and by clicking that icon, the file path opens with your default editor.

In case someone else wants this and has time before I do:

It'd be really awesome if we collapsed the contents of the context display panel for either huge elements or simply the common boilerplate like context['request']. It seems like this would require manually serializing the context objects so they could be styled - maybe it'd be worth switching entirely to nested

s, with a jQuery toggle on click?

If you redirect to a URL that needs quoting, clicking on the link in the interstitial page fails.

I've fixed this (trivially) in
http://github.com/philz/django-debug-toolbar/commit/aa07a663cb7b94cf626540112d35f991e5195deb

Thanks!

I use both django-extensions and django-debug-toolbar. I run runserver_plus on my development machine (and thus use werkzeug debugger) and when I access any page on my webserver from the outside I get page with bottom filled with diferent info from debug-toolbar (though toolbar css doesn't work).

Using Mingus blog engine, the Debug tool bar displays on all pages except added Flatpages.. I'm new to this so it could be me.

Seems the rendering of the toolbar crashes when default_charset="iso-8859-1" in settings.py.

----Snipp---------------

Traceback (most recent call last):

File "c:\Python25\Lib\site-packages\django\core\servers\basehttp.py", line 278, in run

self.result = application(self.environ, self.start_response)

File "c:\Python25\Lib\site-packages\django\core\servers\basehttp.py", line 635, in call

return self.application(environ, start_response)

File "c:\Python25\lib\site-packages\django\core\handlers\wsgi.py", line 245, in call

response = middleware_method(request, response)

File "c:\Python25\lib\site-packages\django_debug_toolbar-0.7.0-py2.5.egg\debug_toolbar\middleware.py", line 93, in process_response

response.content = replace_insensitive(smart_unicode(response.content), u'</body>', smart_unicode(self.debug_toolbar.render_toolbar() + u'</body>'))

File "c:\Python25\lib\site-packages\django\utils\encoding.py", line 42, in smart_unicode

return force_unicode(s, encoding, strings_only, errors)

File "c:\Python25\lib\site-packages\django\utils\encoding.py", line 77, in force_unicode

raise DjangoUnicodeDecodeError(s, *e.args)

DjangoUnicodeDecodeError: 'utf8' codec can't decode bytes in position 4432-4434: invalid data. You passed in '\n\n\n\n\n\n<!DOblablablab (my iso-8859-1 encoded page with lots of nordic characters like æøå)

--------end snippet---------

The debug toolbar works if default_charset is set to "utf-8", but that is not an option for me...

I'm not seeing "field" in the context displayed for the included template. Not sure if with really modifies the context but it'd be good if this was visible when debugging.

{% with form.fullname as field %}
{% include "project/field-snippet.html" %}
{% endwith %}

Debug toolbar crashes with TemplateDebugPanel enabled when there is a {{ block.super }} variable in template and django template filters with unicode parameters are used in super-block.

Debug toolbar tries to render this {{ block.super }} variable using pformat. But it fails for Django template variables when there is unicode data to show as django.template.Variable class have only str method, not unicode. I think it's more Django bug than debug toolbar bug, but to work-around it here is more simple as it does not affect anything but django-debug-toolbar.

The patched version can be found in my fork (http://github.com/kmike/django-debug-toolbar ).

Fix is here:
http://github.com/kmike/django-debug-toolbar/commits/ui-rf-patch

You can check it here:
http://github.com/kmike/django-debug-toolbar/tree/ui-rf-locale_ru

Please note that I also mark a couple of strings in templates and code as translateble.

My case was passing custom form class to login view. The solution can be the same we've done with context (bypass objects with broken unicode) but with this solution we'll hide some view arguments.

Full traceback:

Traceback (most recent call last):

File "/opt/local/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 279, in run

self.result = application(self.environ, self.start_response)

File "/opt/local/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 651, in call

return self.application(environ, start_response)

File "/opt/local/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 245, in call

response = middleware_method(request, response)

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/debug_toolbar/middleware.py", line 91, in process_response

response.content = replace_insensitive(smart_unicode(response.content), u'</body>', smart_unicode(self.debug_toolbars[request].render_toolbar() + u'</body>'))

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/debug_toolbar/toolbar/loader.py", line 72, in render_toolbar

'BASE_URL': self.request.META.get('SCRIPT_NAME', ''),

File "/opt/local/lib/python2.5/site-packages/django/template/loader.py", line 108, in render_to_string

return t.render(context_instance)

File "/opt/local/lib/python2.5/site-packages/django/test/utils.py", line 29, in instrumented_test_render

return self.nodelist.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 779, in render

bits.append(self.render_node(node, context))

File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 71, in render_node

result = node.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/defaulttags.py", line 155, in render

nodelist.append(node.render(context))

File "/Users/kmike/dev/tur/smart_tags/templatetags/smart_if.py", line 213, in render

return self.nodelist_true.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 779, in render

bits.append(self.render_node(node, context))

File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 71, in render_node

result = node.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 87, in render

output = force_unicode(self.filter_expression.resolve(context))

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 546, in resolve

obj = self.var.resolve(context)

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 687, in resolve

value = self._resolve_lookup(context)

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 722, in _resolve_lookup

current = current()

File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/debug_toolbar/panels/request_vars.py", line 40, in content

return render_to_string('debug_toolbar/panels/request_vars.html', context)

File "/opt/local/lib/python2.5/site-packages/django/template/loader.py", line 108, in render_to_string

return t.render(context_instance)

File "/opt/local/lib/python2.5/site-packages/django/test/utils.py", line 29, in instrumented_test_render

return self.nodelist.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/init.py", line 779, in render

bits.append(self.render_node(node, context))

File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 81, in render_node

raise wrapped

TemplateSyntaxError: Caught an exception while rendering: unbound method unicode() must be called with EmailAuthenticationForm instance as first argument (got nothing instead)

Original Traceback (most recent call last):
File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 71, in render_node

result = node.render(context)

File "/opt/local/lib/python2.5/site-packages/django/template/defaulttags.py", line 155, in render

nodelist.append(node.render(context))

File "/opt/local/lib/python2.5/site-packages/django/template/debug.py", line 87, in render

output = force_unicode(self.filter_expression.resolve(context))

File "/opt/local/lib/python2.5/site-packages/django/utils/encoding.py", line 71, in force_unicode

s = unicode(s)

TypeError: unbound method unicode() must be called with EmailAuthenticationForm instance as first argument (got nothing instead)

This happens because django-flatblocks' template tag {% flatblock %} passes RequestContext object to rendered template and debug toolbar thinks it is a context layer. Exception is raised because RequestContext doesn't have 'items' attribute and then the exception is hided somewhere, but the Templates panel becomes absolutely empty.

The simple fix (introduced in my fork) is to check if context layer has an 'items' attribute before pre-processing. All information for flatblock's RequestContext object is readable but unformatted with this fix.

It seems that django-flatblocks behaviour is valid because all template variables passed in it's way are available in the template.

The other possible way to fix this problem is to use recursion but I think it's an overkill.

When the debug toolbar is enabled, then the urlpatterns are multiplied everytime a request is made.

I tested this by setting debug to True and entering an address that I don't have a pattern for. Every time I refresh the page, the urlpatterns increases.

If I do the same but with the debug toolbar disabled, then the urlpatterns does not increase.

to demonstrate visually:
what it should lok like : http://delfick.test.googlepages.com/urlpatterns.png
what it looks like after a refresh : http://delfick.test.googlepages.com/urlpatterns2.png
(and for every refresh it increases)

...

[ sorry, wrong bugtracker :\ ]

I have a manager that takes 'name' and performs the following:

 SELECT year as y
  FROM data_locations 
  WHERE year IS NOT NULL AND name='%(name)s'
  GROUP BY y
  ORDER BY y ASC 

When name=niederösterreich I get a UnicodeEncodeError caused by line 108 of panels/sql.py:

'hash': sha_constructor(settings.SECRET_KEY + sql + _params).hexdigest(),

Note, the query works without the debug toolbar installed

[Tue Sep 22 22:04:43 2009] [info] [client 127.0.0.1] mod_wsgi (pid=45241, process='perslijst.smartpr', application=''): Loading WSGI script '/Users/tim/Sites/smartpr/perslijst/parts/smartpr.wsgi.app/wsgi'.
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] mod_wsgi (pid=45241): Exception occurred processing WSGI script '/Users/tim/Sites/smartpr/perslijst/parts/smartpr.wsgi.app/wsgi'.
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] Traceback (most recent call last):
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/core/handlers/wsgi.py", line 243, in __call__
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     response = middleware_method(request, response)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/Users/tim/Sites/smartpr/perslijst/parts/django-debug-toolbar.pkg/debug_toolbar/middleware.py", line 93, in process_response
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     response.content = replace_insensitive(smart_unicode(response.content), u'</body>', smart_unicode(self.debug_toolbar.render_toolbar() + u'</body>'))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/Users/tim/Sites/smartpr/perslijst/parts/django-debug-toolbar.pkg/debug_toolbar/toolbar/loader.py", line 72, in render_toolbar
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     'BASE_URL': self.request.META.get('SCRIPT_NAME', ''),
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/loader.py", line 107, in render_to_string
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     return t.render(context_instance)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/test/utils.py", line 15, in instrumented_test_render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     return self.nodelist.render(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/__init__.py", line 768, in render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     bits.append(self.render_node(node, context))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/debug.py", line 71, in render_node
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     result = node.render(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/defaulttags.py", line 148, in render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     nodelist.append(node.render(context))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/defaulttags.py", line 245, in render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     return self.nodelist_true.render(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/__init__.py", line 768, in render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     bits.append(self.render_node(node, context))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/debug.py", line 81, in render_node
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     raise wrapped
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] TemplateSyntaxError: Caught an exception while rendering: request object has expired
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] 
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] Original Traceback (most recent call last):
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/debug.py", line 71, in render_node
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     result = node.render(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/debug.py", line 87, in render
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     output = force_unicode(self.filter_expression.resolve(context))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/__init__.py", line 535, in resolve
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     obj = self.var.resolve(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/__init__.py", line 676, in resolve
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     value = self._resolve_lookup(context)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/template/__init__.py", line 711, in _resolve_lookup
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     current = current()
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/Users/tim/Sites/smartpr/perslijst/parts/django-debug-toolbar.pkg/debug_toolbar/panels/request_vars.py", line 26, in content
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     'post': [(k, self.request.POST.getlist(k)) for k in self.request.POST.iterkeys()],
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/core/handlers/wsgi.py", line 169, in _get_post
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     self._load_post_and_files()
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/core/handlers/wsgi.py", line 149, in _load_post_and_files
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     self._post, self._files = http.QueryDict(self.raw_post_data, encoding=self._encoding), datastructures.MultiValueDict()
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/core/handlers/wsgi.py", line 203, in _get_raw_post_data
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     size=content_length)
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]   File "/usr/local/share/buildout/eggs/Django-1.0.2_final-py2.5.egg/django/core/handlers/wsgi.py", line 69, in safe_copyfileobj
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1]     buf = fsrc.read(min(length, size))
[Tue Sep 22 22:04:44 2009] [error] [client 127.0.0.1] RuntimeError: request object has expired

Enhancement:
It would be really handy if the debug toolbar could tell me:
1) which urlconfs were used to arrive at the current view
2) which view was rendered, and with what arguments

This is especially useful when you have a lot of apps, each with their own urlconf, and you don't immediately know which app owns the url pattern that was just matched, or which app owns the view that was rendered as a result. The url pattern and the view it matches may be in different apps, and there may have been several include()s before this urlpattern was reached.

I see you already tell us which template was chosen, which is nice.

The use of try ... except ... finally in line 113 in panels/sql.py breaks Python 2.4 compatibilty. This has been introduced in commit f6ada2c.

Any plans for jinja2 templates support?
dcramer fork support jinja2, but they have some annoying features and bugs (remote javascript loading from google, random crashes with apache+mod_wsgi, jquery 1.3.2 compatibility problems, etc..)

A new panel which displays tidy html errors and warning on current page

(requires python-utidylib but degrades nicely if the library is not available on python system path)

git patch against current master : http://bit.ly/4pVmAW

I have a template tag which adds to the context some additional variables. When I go to the Templates panel and click Toggle Context, those new variables are not listed.

(debug_toolbar-0.7.0-py2.5)

The part of the tests that have to do with the admin break with the toolbar enabled. The test failure log is exactly the same as in the django ticket 9095: http://code.djangoproject.com/ticket/9095

To reproduce in an arbitrary project:
Turn debug toolbar off Run manage.py test -> Tests succeed Turn debug toolbar on Run manage.py test -> Tests fail

it is really annoying to always have errors because of debug-toolbar.

The corrections are really small to be XHTML compliant :
<br> => <br/> correct closing of <pre> in sql.html & => &amp; between parameters in hrefs of sql.html include <style> in <head> replace href="" by href="#" for "close" and "back" links avoid empty span for djDebugLineChart in sql.html