Opened 7 years ago

Closed 3 years ago

Last modified 3 years ago

#11698 closed New feature (wontfix)

Add Django Debug Toolbar to contrib

Reported by: Russell Keith-Magee Owned by: nobody
Component: Contrib apps Version: 1.1
Severity: Normal Keywords:
Cc: rob@…, chris@…, Idan Gazit, ShawnMilo,… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Rob Hudson's Django Debug Toolbar should be considered for inclusion in django.contrib.

There are some issues that need to be resolved - in particular, the usage of jQuery in rendering the UI. There is also a need to determine the set of plugins that will be shipped by default. Some UI polish may also be required.

Change History (19)

comment:2 Changed 7 years ago by mrts

Can some of the improvements by dcramer, in particular profiling support which is very useful, be also integrated? See

comment:3 Changed 7 years ago by Chris Adams

Cc: chris@… added

comment:4 Changed 7 years ago by Idan Gazit

Cc: Idan Gazit added

comment:5 Changed 7 years ago by Russell Keith-Magee

Triage Stage: UnreviewedSomeday/Maybe

DDT is a great tool, but we're not going to integrate it before Rob is happy with it. It can live quite happily as an external project in the meantime.

comment:6 Changed 6 years ago by Julien Phalip

Severity: Normal
Type: New feature

comment:7 Changed 5 years ago by gumuz

Easy pickings: unset
UI/UX: unset

After discussing this with Jannis, here are some ideas of how something like this might work:

Instead of having middleware appending html content to the response like it does now, debug data can be stored server-side so it can be requested on demand using javascript for example.

Storing this data might be done using the existing logger infrastructure. This basically turns the whole debug toolbar into a live log viewer, but with the addition of structured/serialized debug data embedded into the log messages, which makes it possible to present this data in a useful way. Some care has to be taken to ensure the the data is only from the viewers session and that individual requests can be identified.

The advantages of this approach are that the data is not inserted as html anymore and is not restricted to just the current request. This way for example also enable ajax request/response inspection.

comment:8 Changed 5 years ago by Chris Adams

The Chrome SpeedTracer ( API does something similar: the server simply provides a header containing a URL to retrieve trace data for instrumented clients. I implemented this in simply by storing the report data in the cache using a UUID for each request. This approach worked really well both for performance - no problems like debug-toolbar has generating huge HTML stack traces for a page which accidentally does too many queries - and it's easy to have this pulled out using XHR or even, assuming some sort of user-keyed storage, retrieved from another machine in context such as mobile development where the client doesn't have your diagnostic tools.

comment:9 Changed 5 years ago by ShawnMilo

Cc: ShawnMilo added

comment:10 Changed 5 years ago by Jannis Leidel

@acdha Wow, that looks really good, +1 on using that approach. Combined with DDT's panels for data collection this would be great.

comment:11 Changed 5 years ago by Jannis Leidel

Triage Stage: Someday/MaybeAccepted

comment:12 Changed 5 years ago by Jannis Leidel

FTR, there was some work done to revamp the way the toolbar injects itself in the page at

comment:13 Changed 5 years ago by Matt Harasymczuk

Cc:… added

comment:14 Changed 3 years ago by loic84

Is there still a long term goal of adding DDT to django.contrib?

comment:15 Changed 3 years ago by Jannis Leidel

Resolution: wontfix
Status: newclosed

Marking as wontfix since we're increasingly removing apps from contrib and are promoting standard Python packaging tools instead. FTR, I'm a committer to the debug toolbar and would happily encourage feedback about it.

comment:16 Changed 3 years ago by Aymeric Augustin

jezdez, do you think we should point to the DDT in the tutorial?

It's probably the most widely used addon for Django after the admin.

comment:17 Changed 3 years ago by Marc Tamlyn

This comes back to the whole concept of recommended external packages in the docs. I'm +0 on the idea, but it's not a discussion for this ticket.

comment:18 Changed 3 years ago by Jannis Leidel

aaugustin, sure why not -- as soon as DDT has a Django > 1.5 and Python 3 compatible release out.

comment:19 Changed 3 years ago by Aymeric Augustin

DDT 1.0 was released with support for Django 1.4+ and Python 2.6+/3.2+.

Note: See TracTickets for help on using tickets.
Back to Top