Panels¶
The Django Debug Toolbar ships with a series of built-in panels. In addition, several third-party panels are available.
Default built-in panels¶
The following panels are enabled by default.
History¶
-
class
debug_toolbar.panels.history.
HistoryPanel
¶
This panel shows the history of requests made and allows switching to a past snapshot of the toolbar to view that request’s stats.
Version¶
-
class
debug_toolbar.panels.versions.
VersionsPanel
¶
Shows versions of Python, Django, and installed apps if possible.
Headers¶
-
class
debug_toolbar.panels.headers.
HeadersPanel
¶
This panels shows the HTTP request and response headers, as well as a selection of values from the WSGI environment.
Note that headers set by middleware placed before the debug toolbar middleware
in MIDDLEWARE
won’t be visible in the panel. The WSGI server itself may
also add response headers such as Date
and Server
.
SQL¶
-
class
debug_toolbar.panels.sql.
SQLPanel
¶
SQL queries including time to execute and links to EXPLAIN each query.
Template¶
-
class
debug_toolbar.panels.templates.
TemplatesPanel
¶
Templates and context used, and their template paths.
Static files¶
-
class
debug_toolbar.panels.staticfiles.
StaticFilesPanel
¶
Used static files and their locations (via the staticfiles
finders).
Cache¶
-
class
debug_toolbar.panels.cache.
CachePanel
¶
Cache queries. Is incompatible with Django’s per-site caching.
Logging¶
-
class
debug_toolbar.panels.logging.
LoggingPanel
¶
Logging output via Python’s built-in logging
module.
Redirects¶
-
class
debug_toolbar.panels.redirects.
RedirectsPanel
¶
When this panel is enabled, the debug toolbar will show an intermediate page upon redirect so you can view any debug information prior to redirecting. This page will provide a link to the redirect destination you can follow when ready.
Since this behavior is annoying when you aren’t debugging a redirect, this
panel is included but inactive by default. You can activate it by default with
the DISABLE_PANELS
configuration option.
Third-party panels¶
Note
Third-party panels aren’t officially supported!
The authors of the Django Debug Toolbar maintain a list of third-party panels, but they can’t vouch for the quality of each of them. Please report bugs to their authors.
If you’d like to add a panel to this list, please submit a pull request!
Flamegraph¶
URL: https://github.com/23andMe/djdt-flamegraph
Path: djdt_flamegraph.FlamegraphPanel
Generates a flame graph from your current request.
Haystack¶
URL: https://github.com/streeter/django-haystack-panel
Path: haystack_panel.panel.HaystackDebugPanel
See queries made by your Haystack backends.
HTML Tidy/Validator¶
URL: https://github.com/joymax/django-dtpanel-htmltidy
Path: debug_toolbar_htmltidy.panels.HTMLTidyDebugPanel
HTML Tidy or HTML Validator is a custom panel that validates your HTML and displays warnings and errors.
Inspector¶
URL: https://github.com/santiagobasulto/debug-inspector-panel
Path: inspector_panel.panels.inspector.InspectorPanel
Retrieves and displays information you specify using the debug
statement.
Inspector panel also logs to the console by default, but may be instructed not
to.
LDAP Tracing¶
URL: https://github.com/danyi1212/django-windowsauth
Path: windows_auth.panels.LDAPPanel
LDAP Operations performed during the request, including timing, request and response messages, the entries received, write changes list, stack-tracing and error debugging. This panel also shows connection usage metrics when it is collected. Check out the docs.
Line Profiler¶
URL: https://github.com/mikekeda/django-debug-toolbar-line-profiler
Path: debug_toolbar_line_profiler.panel.ProfilingPanel
This package provides a profiling panel that incorporates output from line_profiler.
Mail¶
URL: https://github.com/scuml/django-mail-panel
Path: mail_panel.panels.MailToolbarPanel
This panel captures and displays emails sent from your application.
Memcache¶
URL: https://github.com/ross/memcache-debug-panel
Path: memcache_toolbar.panels.memcache.MemcachePanel
or memcache_toolbar.panels.pylibmc.PylibmcPanel
This panel tracks memcached usage. It currently supports both the pylibmc and memcache libraries.
MongoDB¶
URL: https://github.com/hmarr/django-debug-toolbar-mongo
Path: debug_toolbar_mongo.panel.MongoDebugPanel
Adds MongoDB debugging information.
Neo4j¶
URL: https://github.com/robinedwards/django-debug-toolbar-neo4j-panel
Path: neo4j_panel.Neo4jPanel
Trace neo4j rest API calls in your Django application, this also works for neo4django and neo4jrestclient, support for py2neo is on its way.
Pympler¶
URL: https://pythonhosted.org/Pympler/django.html
Path: pympler.panels.MemoryPanel
Shows process memory information (virtual size, resident set size) and model instances for the current request.
Request History¶
URL: https://github.com/djsutho/django-debug-toolbar-request-history
Path: ddt_request_history.panels.request_history.RequestHistoryPanel
Switch between requests to view their stats. Also adds support for viewing stats for AJAX requests.
Requests¶
URL: https://github.com/marceltschoppch/django-requests-debug-toolbar
Path: requests_panel.panel.RequestsDebugPanel
Lists HTTP requests made with the popular requests library.
Sites¶
URL: https://github.com/elvard/django-sites-toolbar
Path: sites_toolbar.panels.SitesDebugPanel
Browse Sites registered in django.contrib.sites
and switch between them.
Useful to debug project when you use django-dynamicsites which sets SITE_ID
dynamically.
Template Profiler¶
URL: https://github.com/node13h/django-debug-toolbar-template-profiler
Path: template_profiler_panel.panels.template.TemplateProfilerPanel
Shows template render call duration and distribution on the timeline. Lightweight. Compatible with WSGI servers which reuse threads for multiple requests (Werkzeug).
Template Timings¶
URL: https://github.com/orf/django-debug-toolbar-template-timings
Path: template_timings_panel.panels.TemplateTimings.TemplateTimings
Displays template rendering times for your Django application.
User¶
URL: https://github.com/playfire/django-debug-toolbar-user-panel
Path: debug_toolbar_user_panel.panels.UserPanel
Easily switch between logged in users, see properties of current user.
VCS Info¶
URL: https://github.com/giginet/django-debug-toolbar-vcs-info
Path: vcs_info_panel.panels.GitInfoPanel
Displays VCS status (revision, branch, latest commit log and more) of your Django application.
uWSGI Stats¶
URL: https://github.com/unbit/django-uwsgi
Path: django_uwsgi.panels.UwsgiPanel
Displays uWSGI stats (workers, applications, spooler jobs and more).
API for third-party panels¶
Third-party panels must subclass Panel
,
according to the public API described below. Unless noted otherwise, all
methods are optional.
Panels can ship their own templates, static files and views. All views should
be decorated with debug_toolbar.decorators.require_show_toolbar
to prevent
unauthorized access. There is no public CSS API at this time.
-
class
debug_toolbar.panels.
Panel
(toolbar, get_response)¶ Base class for panels.
Title shown in the side bar. Defaults to
title
.
Subtitle shown in the side bar. Defaults to the empty string.
-
has_content
¶ True
if the panel can be displayed in full screen,False
if it’s only shown in the side bar. Defaults toTrue
.
-
title
¶ Title shown in the panel when it’s displayed in full screen.
Mandatory, unless the panel sets
has_content
toFalse
.
-
template
¶ Template used to render
content
.Mandatory, unless the panel sets
has_content
toFalse
or overrides attr:content`.
-
content
¶ Content of the panel when it’s displayed in full screen.
By default this renders the template defined by
template
. Statistics stored withrecord_stats()
are available in the template’s context.
-
scripts
¶ Scripts used by the HTML content of the panel when it’s displayed.
-
classmethod
get_urls
()¶ Return URLpatterns, if the panel has its own views.
-
enable_instrumentation
()¶ Enable instrumentation to gather data for this panel.
This usually means monkey-patching (!) or registering signal receivers. Any instrumentation with a non-negligible effect on performance should be installed by this method rather than at import time.
Unless the toolbar or this panel is disabled, this method will be called early in
DebugToolbarMiddleware
. It should be idempotent.
-
disable_instrumentation
()¶ Disable instrumentation to gather data for this panel.
This is the opposite of
enable_instrumentation()
.Unless the toolbar or this panel is disabled, this method will be called late in the middleware. It should be idempotent.
-
record_stats
(stats)¶ Store data gathered by the panel.
stats
is adict
.Each call to
record_stats
updates the statistics dictionary.
-
process_request
(request)¶ Like __call__ in Django’s middleware.
Write panel logic related to the request there. Save data with
record_stats()
.Return the existing response or overwrite it.
-
generate_stats
(request, response)¶ Called after
process_request
, but may not be executed on every request. This will only be called if the toolbar will be inserted into the request.Write panel logic related to the response there. Post-process data gathered while the view executed. Save data with
record_stats()
.Does not return a value.
-
classmethod
run_checks
()¶ Check that the integration is configured correctly for the panel.
This will be called as a part of the Django checks system when the application is being setup.
Return a list of :class: django.core.checks.CheckMessage instances.
JavaScript API¶
Panel templates should include any JavaScript files they need. There are a few common methods available.
-
djdt.
close
()¶ Closes the topmost level (window/panel/toolbar)
This is a helper function to fetch values stored in the cookies.
- Arguments
key – The key for the value to be fetched.
This is a helper function to set a value stored in the cookies.
- Arguments
key – The key to be used.
value – The value to be set.
options – The options for the value to be set. It should contain the properties
expires
andpath
.
-
djdt.
hide_toolbar
()¶ Closes any panels and hides the toolbar.
-
djdt.
show_toolbar
()¶ Shows the toolbar.