The Django Debug Toolbar ships with a series of built-in panels. In addition, several third-party panels are available.
The following panels are enabled by default.
Path: debug_toolbar.panels.versions.VersionsPanel
Shows versions of Python, Django, and installed apps if possible.
Path: 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_CLASSES won’t be visible in the panel. The WSGI server itself may also add response headers such as Date and Server.
Path: debug_toolbar.panels.sql.SQLPanel
SQL queries including time to execute and links to EXPLAIN each query.
Path: debug_toolbar.panels.templates.TemplatesPanel
Templates and context used, and their template paths.
Path: debug_toolbar.panels.staticfiles.StaticFilesPanel
Used static files and their locations (via the staticfiles finders).
Path: debug_toolbar.panels.logging.LoggingPanel
Logging output via Python’s built-in logging module.
Path: 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.
The following panels are disabled by default. You must add them to the DEBUG_TOOLBAR_PANELS setting to enable them.
Path: debug_toolbar.panels.profiling.ProfilingPanel
Profiling information for the view function.
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!
URL: https://github.com/streeter/django-haystack-panel
Path: haystack_panel.panel.HaystackDebugPanel
See queries made by your Haystack backends.
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.
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.
URL: https://github.com/dmclain/django-debug-toolbar-line-profiler
Path: debug_toolbar_line_profiler.panel.ProfilingPanel
This package provides a profiling panel that incorporates output from line_profiler.
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.
URL: https://github.com/hmarr/django-debug-toolbar-mongo
Path: debug_toolbar_mongo.panel.MongoDebugPanel
Adds MongoDB debugging information.
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.
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.
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.
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.
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. They’re no public CSS or JavaScript API at this time, but they can assume jQuery is available in djdt.jQuery.
Base class for panels.
Title shown in the side bar. Defaults to title.
Subtitle shown in the side bar. Defaults to the empty string.
True if the panel can be displayed in full screen, False if it’s only shown in the side bar. Defaults to True.
Title shown in the panel when it’s displayed in full screen.
Mandatory, unless the panel sets has_content to False.
Template used to render content.
Mandatory, unless the panel sets has_content to False or overrides attr:content`.
Content of the panel when it’s displayed in full screen.
By default this renders the template defined by template. Statistics stored with record_stats() are available in the template’s context.
Return URLpatterns, if the panel has its own views.
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.process_request. It should be idempotent.
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 DebugToolbarMiddleware.process_response. It should be idempotent.
Store data gathered by the panel. stats is a dict.
Each call to record_stats updates the statistics dictionary.
Access data stored by the panel. Returns a dict.
Like process_request in Django’s middleware.
Write panel logic related to the request there. Save data with record_stats().
Like process_view in Django’s middleware.
Write panel logic related to the view there. Save data with record_stats().
Like process_response in Django’s middleware.
Write panel logic related to the response there. Post-process data gathered while the view executed. Save data with record_stats().