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

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!

CSS looks like it should catch, but it's not: #djDebug .panelContent .djDebugClose {

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

Working solution proposition:

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

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

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.

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.

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.

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.

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'', smart_unicode(self.debug_toolbars[request].render_toolbar() + u''))

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)

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/

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

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

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.

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

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.

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

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

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

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

[ sorry, wrong bugtracker :\ ]

1. 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 … ) …” )

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

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

ea1f9430ddb58f28b50cc702f9eb2612f19e308d

Originally added by overkrik on Google Code.

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.

It appears to work pretty well on 2.4 except for debug_toolbar/panels/sql.py line 113. Python 2.4 does not support try, except, finally, but needs two seperate try statements. After this change I did not see any issues. Can this be fixed?

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.

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

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 æøå)

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

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

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

It could show all the registered handlers for each of the signals built into django (and probably have a hook for registering custom signals).

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

Similar to [Dowser](http://www.aminus.net/browser/dowser), look at implementing a memory tracking panel.

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

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)

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 %}

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)

...

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)

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

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.

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.

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.

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?

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