- {% trans "The Django Debug Toolbar has intercepted a redirect to the above URL for debug viewing purposes. You can click the above link to continue with the redirect as normal." %}
+ {% translate "The Django Debug Toolbar has intercepted a redirect to the above URL for debug viewing purposes. You can click the above link to continue with the redirect as normal." %}
diff --git a/debug_toolbar/toolbar.py b/debug_toolbar/toolbar.py
index 11f8a1daa..04e5894c5 100644
--- a/debug_toolbar/toolbar.py
+++ b/debug_toolbar/toolbar.py
@@ -2,21 +2,25 @@
The main DebugToolbar class that loads and renders the Toolbar.
"""
+import re
import uuid
from collections import OrderedDict
-from functools import lru_cache
+from functools import cache
from django.apps import apps
+from django.conf import settings
from django.core.exceptions import ImproperlyConfigured
+from django.core.handlers.asgi import ASGIRequest
from django.dispatch import Signal
from django.template import TemplateSyntaxError
from django.template.loader import render_to_string
-from django.urls import path, resolve
+from django.urls import include, path, re_path, resolve
from django.urls.exceptions import Resolver404
from django.utils.module_loading import import_string
from django.utils.translation import get_language, override as lang_override
from debug_toolbar import APP_NAME, settings as dt_settings
+from debug_toolbar.panels import Panel
class DebugToolbar:
@@ -36,7 +40,7 @@ def __init__(self, request, get_response):
# Use OrderedDict for the _panels attribute so that items can be efficiently
# removed using FIFO order in the DebugToolbar.store() method. The .popitem()
# method of Python's built-in dict only supports LIFO removal.
- self._panels = OrderedDict()
+ self._panels = OrderedDict[str, Panel]()
while panels:
panel = panels.pop()
self._panels[panel.panel_id] = panel
@@ -61,6 +65,16 @@ def enabled_panels(self):
"""
return [panel for panel in self._panels.values() if panel.enabled]
+ @property
+ def csp_nonce(self):
+ """
+ Look up the Content Security Policy nonce if there is one.
+
+ This is built specifically for django-csp, which may not always
+ have a nonce associated with the request.
+ """
+ return getattr(self.request, "csp_nonce", None)
+
def get_panel_by_id(self, panel_id):
"""
Get the panel with the given id, which is the class name by default.
@@ -96,12 +110,18 @@ def should_render_panels(self):
If False, the panels will be loaded via Ajax.
"""
if (render_panels := self.config["RENDER_PANELS"]) is None:
- # If wsgi.multiprocess isn't in the headers, then it's likely
- # being served by ASGI. This type of set up is most likely
- # incompatible with the toolbar until
- # https://github.com/jazzband/django-debug-toolbar/issues/1430
- # is resolved.
- render_panels = self.request.META.get("wsgi.multiprocess", True)
+ # If wsgi.multiprocess is true then it is either being served
+ # from ASGI or multithreaded third-party WSGI server eg gunicorn.
+ # we need to make special check for ASGI for supporting
+ # async context based requests.
+ if isinstance(self.request, ASGIRequest):
+ render_panels = False
+ else:
+ # The wsgi.multiprocess case of being True isn't supported until the
+ # toolbar has resolved the following issue:
+ # This type of set up is most likely
+ # https://github.com/django-commons/django-debug-toolbar/issues/1430
+ render_panels = self.request.META.get("wsgi.multiprocess", True)
return render_panels
# Handle storing toolbars in memory and fetching them later on
@@ -163,14 +183,14 @@ def is_toolbar_request(cls, request):
# not have resolver_match set.
try:
resolver_match = request.resolver_match or resolve(
- request.path, getattr(request, "urlconf", None)
+ request.path_info, getattr(request, "urlconf", None)
)
except Resolver404:
return False
return resolver_match.namespaces and resolver_match.namespaces[-1] == APP_NAME
@staticmethod
- @lru_cache(maxsize=None)
+ @cache
def get_observe_request():
# If OBSERVE_REQUEST_CALLBACK is a string, which is the recommended
# setup, resolve it to the corresponding callable.
@@ -185,4 +205,28 @@ def observe_request(request):
"""
Determine whether to update the toolbar from a client side request.
"""
- return not DebugToolbar.is_toolbar_request(request)
+ return True
+
+
+def debug_toolbar_urls(prefix="__debug__"):
+ """
+ Return a URL pattern for serving toolbar in debug mode.
+
+ from django.conf import settings
+ from debug_toolbar.toolbar import debug_toolbar_urls
+
+ urlpatterns = [
+ # ... the rest of your URLconf goes here ...
+ ] + debug_toolbar_urls()
+ """
+ if not prefix:
+ raise ImproperlyConfigured("Empty urls prefix not permitted")
+ elif not settings.DEBUG:
+ # No-op if not in debug mode.
+ return []
+ return [
+ re_path(
+ r"^{}/".format(re.escape(prefix.lstrip("/"))),
+ include("debug_toolbar.urls"),
+ ),
+ ]
diff --git a/debug_toolbar/utils.py b/debug_toolbar/utils.py
index 3a9d0882e..f4b3eac38 100644
--- a/debug_toolbar/utils.py
+++ b/debug_toolbar/utils.py
@@ -1,23 +1,28 @@
+from __future__ import annotations
+
import inspect
import linecache
import os.path
import sys
import warnings
+from collections.abc import Sequence
from pprint import PrettyPrinter, pformat
-from typing import Any, Dict, List, Optional, Sequence, Tuple, Union
+from typing import Any
from asgiref.local import Local
from django.http import QueryDict
from django.template import Node
from django.utils.html import format_html
from django.utils.safestring import SafeString, mark_safe
+from django.views.debug import get_default_exception_reporter_filter
from debug_toolbar import _stubs as stubs, settings as dt_settings
_local_data = Local()
+safe_filter = get_default_exception_reporter_filter()
-def _is_excluded_frame(frame: Any, excluded_modules: Optional[Sequence[str]]) -> bool:
+def _is_excluded_frame(frame: Any, excluded_modules: Sequence[str] | None) -> bool:
if not excluded_modules:
return False
frame_module = frame.f_globals.get("__name__")
@@ -39,7 +44,7 @@ def _stack_trace_deprecation_warning() -> None:
)
-def tidy_stacktrace(stack: List[stubs.InspectStack]) -> stubs.TidyStackTrace:
+def tidy_stacktrace(stack: list[stubs.InspectStack]) -> stubs.TidyStackTrace:
"""
Clean up stacktrace and remove all entries that are excluded by the
HIDE_IN_STACKTRACES setting.
@@ -99,7 +104,7 @@ def render_stacktrace(trace: stubs.TidyStackTrace) -> SafeString:
return mark_safe(html)
-def get_template_info() -> Optional[Dict[str, Any]]:
+def get_template_info() -> dict[str, Any] | None:
template_info = None
cur_frame = sys._getframe().f_back
try:
@@ -129,7 +134,7 @@ def get_template_info() -> Optional[Dict[str, Any]]:
def get_template_context(
node: Node, context: stubs.RequestContext, context_lines: int = 3
-) -> Dict[str, Any]:
+) -> dict[str, Any]:
line, source_lines, name = get_template_source_from_exception_info(node, context)
debug_context = []
start = max(1, line - context_lines)
@@ -146,7 +151,7 @@ def get_template_context(
def get_template_source_from_exception_info(
node: Node, context: stubs.RequestContext
-) -> Tuple[int, List[Tuple[int, str]], str]:
+) -> tuple[int, list[tuple[int, str]], str]:
if context.template.origin == node.origin:
exception_info = context.template.get_exception_info(
Exception("DDT"), node.token
@@ -212,23 +217,53 @@ def getframeinfo(frame: Any, context: int = 1) -> inspect.Traceback:
return inspect.Traceback(filename, lineno, frame.f_code.co_name, lines, index)
-def get_sorted_request_variable(
- variable: Union[Dict[str, Any], QueryDict],
-) -> Dict[str, Union[List[Tuple[str, Any]], Any]]:
+def sanitize_and_sort_request_vars(
+ variable: dict[str, Any] | QueryDict,
+) -> dict[str, list[tuple[str, Any]] | Any]:
"""
Get a data structure for showing a sorted list of variables from the
- request data.
+ request data with sensitive values redacted.
"""
+ if not isinstance(variable, (dict, QueryDict)):
+ return {"raw": variable}
+
+ # Get sorted keys if possible, otherwise just list them
+ keys = _get_sorted_keys(variable)
+
+ # Process the variable based on its type
+ if isinstance(variable, QueryDict):
+ result = _process_query_dict(variable, keys)
+ else:
+ result = _process_dict(variable, keys)
+
+ return {"list": result}
+
+
+def _get_sorted_keys(variable):
+ """Helper function to get sorted keys if possible."""
try:
- if isinstance(variable, dict):
- return {"list": [(k, variable.get(k)) for k in sorted(variable)]}
- else:
- return {"list": [(k, variable.getlist(k)) for k in sorted(variable)]}
+ return sorted(variable)
except TypeError:
- return {"raw": variable}
+ return list(variable)
-def get_stack(context=1) -> List[stubs.InspectStack]:
+def _process_query_dict(query_dict, keys):
+ """Process a QueryDict into a list of (key, sanitized_value) tuples."""
+ result = []
+ for k in keys:
+ values = query_dict.getlist(k)
+ # Return single value if there's only one, otherwise keep as list
+ value = values[0] if len(values) == 1 else values
+ result.append((k, safe_filter.cleanse_setting(k, value)))
+ return result
+
+
+def _process_dict(dictionary, keys):
+ """Process a dictionary into a list of (key, sanitized_value) tuples."""
+ return [(k, safe_filter.cleanse_setting(k, dictionary.get(k))) for k in keys]
+
+
+def get_stack(context=1) -> list[stubs.InspectStack]:
"""
Get a list of records for a frame and all higher (calling) frames.
@@ -286,7 +321,7 @@ def get_source_file(self, frame):
def get_stack_trace(
self,
*,
- excluded_modules: Optional[Sequence[str]] = None,
+ excluded_modules: Sequence[str] | None = None,
include_locals: bool = False,
skip: int = 0,
):
@@ -353,3 +388,16 @@ def get_stack_trace(*, skip=0):
def clear_stack_trace_caches():
if hasattr(_local_data, "stack_trace_recorder"):
del _local_data.stack_trace_recorder
+
+
+_HTML_TYPES = ("text/html", "application/xhtml+xml")
+
+
+def is_processable_html_response(response):
+ content_encoding = response.get("Content-Encoding", "")
+ content_type = response.get("Content-Type", "").split(";")[0]
+ return (
+ not getattr(response, "streaming", False)
+ and content_encoding == ""
+ and content_type in _HTML_TYPES
+ )
diff --git a/debug_toolbar/views.py b/debug_toolbar/views.py
index b93acbeed..b9a410db5 100644
--- a/debug_toolbar/views.py
+++ b/debug_toolbar/views.py
@@ -2,10 +2,12 @@
from django.utils.html import escape
from django.utils.translation import gettext as _
+from debug_toolbar._compat import login_not_required
from debug_toolbar.decorators import render_with_toolbar_language, require_show_toolbar
from debug_toolbar.toolbar import DebugToolbar
+@login_not_required
@require_show_toolbar
@render_with_toolbar_language
def render_panel(request):
@@ -16,7 +18,7 @@ def render_panel(request):
"Data for this panel isn't available anymore. "
"Please reload the page and retry."
)
- content = "
%s
" % escape(content)
+ content = f"
{escape(content)}
"
scripts = []
else:
panel = toolbar.get_panel_by_id(request.GET["panel_id"])
diff --git a/docs/architecture.rst b/docs/architecture.rst
new file mode 100644
index 000000000..54b3b9318
--- /dev/null
+++ b/docs/architecture.rst
@@ -0,0 +1,87 @@
+Architecture
+============
+
+The Django Debug Toolbar is designed to be flexible and extensible for
+developers and third-party panel creators.
+
+Core Components
+---------------
+
+While there are several components, the majority of logic and complexity
+lives within the following:
+
+- ``debug_toolbar.middleware.DebugToolbarMiddleware``
+- ``debug_toolbar.toolbar.DebugToolbar``
+- ``debug_toolbar.panels``
+
+^^^^^^^^^^^^^^^^^^^^^^
+DebugToolbarMiddleware
+^^^^^^^^^^^^^^^^^^^^^^
+
+The middleware is how the toolbar integrates with Django projects.
+It determines if the toolbar should instrument the request, which
+panels to use, facilitates the processing of the request and augmenting
+the response with the toolbar. Most logic for how the toolbar interacts
+with the user's Django project belongs here.
+
+^^^^^^^^^^^^
+DebugToolbar
+^^^^^^^^^^^^
+
+The ``DebugToolbar`` class orchestrates the processing of a request
+for each of the panels. It contains the logic that needs to be aware
+of all the panels, but doesn't need to interact with the user's Django
+project.
+
+^^^^^^
+Panels
+^^^^^^
+
+The majority of the complex logic lives within the panels themselves. This
+is because the panels are responsible for collecting the various metrics.
+Some of the metrics are collected via
+`monkey-patching `_, such as
+``TemplatesPanel``. Others, such as ``SettingsPanel`` don't need to collect
+anything and include the data directly in the response.
+
+Some panels such as ``SQLPanel`` have additional functionality. This tends
+to involve a user clicking on something, and the toolbar presenting a new
+page with additional data. That additional data is handled in views defined
+in the panels package (for example, ``debug_toolbar.panels.sql.views``).
+
+Logic Flow
+----------
+
+When a request comes in, the toolbar first interacts with it in the
+middleware. If the middleware determines the request should be instrumented,
+it will instantiate the toolbar and pass the request for processing. The
+toolbar will use the enabled panels to collect information on the request
+and/or response. When the toolbar has completed collecting its metrics on
+both the request and response, the middleware will collect the results
+from the toolbar. It will inject the HTML and JavaScript to render the
+toolbar as well as any headers into the response.
+
+After the browser renders the panel and the user interacts with it, the
+toolbar's JavaScript will send requests to the server. If the view handling
+the request needs to fetch data from the toolbar, the request must supply
+the store ID. This is so that the toolbar can load the collected metrics
+for that particular request.
+
+The history panel allows a user to view the metrics for any request since
+the application was started. The toolbar maintains its state entirely in
+memory for the process running ``runserver``. If the application is
+restarted the toolbar will lose its state.
+
+Problematic Parts
+-----------------
+
+- ``debug.panels.templates.panel``: This monkey-patches template rendering
+ when the panel module is loaded
+- ``debug.panels.sql``: This package is particularly complex, but provides
+ the main benefit of the toolbar
+- Support for async and multi-threading: ``debug_toolbar.middleware.DebugToolbarMiddleware``
+ is now async compatible and can process async requests. However certain
+ panels such as ``TimerPanel``, ``RequestPanel`` and ``ProfilingPanel`` aren't
+ fully compatible and currently being worked on. For now, these panels
+ are disabled by default when running in async environment.
+ follow the progress of this issue in `Async compatible toolbar project `_.
diff --git a/docs/changes.rst b/docs/changes.rst
index e2a610991..6d6f34b2d 100644
--- a/docs/changes.rst
+++ b/docs/changes.rst
@@ -4,6 +4,169 @@ Change log
Pending
-------
+* Added support for checking if pytest as the test runner when determining
+ if tests are running.
+
+5.2.0 (2025-04-29)
+------------------
+
+* Added hook to RedirectsPanel for subclass customization.
+* Added feature to sanitize sensitive data in the Request Panel.
+* Fixed dark mode conflict in code block toolbar CSS.
+* Properly allowed overriding the system theme preference by using the theme
+ selector. Removed the ``DEFAULT_THEME`` setting, we should always default to
+ system-level defaults where possible.
+* Added support for using django-template-partials with the template panel's
+ source view functionality. The same change possibly adds support for other
+ template loaders.
+* Introduced `djade `__ to format Django
+ templates.
+* Swapped display order of panel header and close button to prevent style
+ conflicts
+* Added CSS for resetting the height of elements too to avoid problems with
+ global CSS of a website where the toolbar is used.
+
+5.1.0 (2025-03-20)
+------------------
+
+* Added Django 5.2 to the tox matrix.
+* Updated package metadata to include well-known labels.
+* Added resources section to the documentation.
+* Wrap ``SHOW_TOOLBAR_CALLBACK`` function with ``sync_to_async``
+ or ``async_to_sync`` to allow sync/async compatibility.
+* Make ``require_toolbar`` decorator compatible to async views.
+* Added link to contributing documentation in ``CONTRIBUTING.md``.
+* Replaced ESLint and prettier with biome in our pre-commit configuration.
+* Added a Makefile target (``make help``) to get a quick overview
+ of each target.
+* Avoided reinitializing the staticfiles storage during instrumentation.
+* Avoided a "forked" Promise chain in the rebound ``window.fetch`` function
+ with missing exception handling.
+* Fixed the pygments code highlighting when using dark mode.
+* Fix for exception-unhandled "forked" Promise chain in rebound window.fetch
+* Create a CSP nonce property on the toolbar ``Toolbar().csp_nonce``.
+
+5.0.1 (2025-01-13)
+------------------
+* Fixing the build and release process. No functional changes.
+
+5.0.0 (2025-01-11)
+------------------
+
+* Added Python 3.13 to the CI matrix.
+* Removed support for Python 3.8 as it has reached end of life.
+* Converted to Django Commons PyPI release process.
+* Fixed a crash which occurred when using non-``str`` static file values.
+* Documented experimental async support.
+* Improved troubleshooting doc for incorrect mime types for .js static files
+
+Please see everything under 5.0.0-alpha as well.
+
+5.0.0-alpha (2024-09-01)
+------------------------
+
+* Support async applications and ASGI from
+ `Google Summer of Code Project 2024
+ `__.
+* Added Django 5.1 to the CI matrix.
+* Added support for the ``LoginRequiredMiddleware`` introduced in Django 5.1.
+* Support select and explain buttons for ``UNION`` queries on PostgreSQL.
+* Fixed internal toolbar requests being instrumented if the Django setting
+ ``FORCE_SCRIPT_NAME`` was set.
+* Increase opacity of show Debug Toolbar handle to improve accessibility.
+* Changed the ``RedirectsPanel`` to be async compatible.
+* Increased the contrast of text with dark mode enabled.
+* Add translations for Bulgarian and Korean.
+* Update translations for several languages.
+* Include new translatable strings for translation.
+* Fixed a crash which happened in the fallback case when session keys cannot be
+ sorted.
+
+4.4.6 (2024-07-10)
+------------------
+
+* Changed ordering (and grammatical number) of panels and their titles in
+ documentation to match actual panel ordering and titles.
+* Skipped processing the alerts panel when response isn't a HTML response.
+
+4.4.5 (2024-07-05)
+------------------
+
+* Avoided crashing when the alerts panel was skipped.
+* Removed the inadvertently added hard dependency on Jinja2.
+
+4.4.4 (2024-07-05)
+------------------
+
+* Added check for StreamingHttpResponse in alerts panel.
+* Instrument the Django Jinja2 template backend. This only instruments
+ the immediate template that's rendered. It will not provide stats on
+ any parent templates.
+
+4.4.3 (2024-07-04)
+------------------
+
+* Added alerts panel with warning when form is using file fields
+ without proper encoding type.
+* Fixed overriding font-family for both light and dark themes.
+* Restored compatibility with ``iptools.IpRangeList``.
+* Limit ``E001`` check to likely error cases when the
+ ``SHOW_TOOLBAR_CALLBACK`` has changed, but the toolbar's URL
+ paths aren't installed.
+* Introduce helper function ``debug_toolbar_urls`` to
+ simplify installation.
+* Moved "1rem" height/width for SVGs to CSS properties.
+
+4.4.2 (2024-05-27)
+------------------
+
+* Removed some CSS which wasn't carefully limited to the toolbar's elements.
+* Stopped assuming that ``INTERNAL_IPS`` is a list.
+* Added a section to the installation docs about running tests in projects
+ where the toolbar is being used.
+
+
+4.4.1 (2024-05-26)
+------------------
+
+* Pin metadata version to 2.2 to be compatible with Jazzband release
+ process.
+
+4.4.0 (2024-05-26)
+------------------
+
+* Raised the minimum Django version to 4.2.
+* Automatically support Docker rather than having the developer write a
+ workaround for ``INTERNAL_IPS``.
+* Display a better error message when the toolbar's requests
+ return invalid json.
+* Render forms with ``as_div`` to silence Django 5.0 deprecation warnings.
+* Stayed on top of pre-commit hook updates.
+* Added :doc:`architecture documentation ` to help
+ on-board new contributors.
+* Removed the static file path validation check in
+ :class:`StaticFilesPanel `
+ since that check is made redundant by a similar check in Django 4.0 and
+ later.
+* Deprecated the ``OBSERVE_REQUEST_CALLBACK`` setting and added check
+ ``debug_toolbar.W008`` to warn when it is present in
+ ``DEBUG_TOOLBAR_SETTINGS``.
+* Add a note on the profiling panel about using Python 3.12 and later
+ about needing ``--nothreading``
+* Added ``IS_RUNNING_TESTS`` setting to allow overriding the
+ ``debug_toolbar.E001`` check to avoid including the toolbar when running
+ tests.
+* Fixed the bug causing ``'djdt' is not a registered namespace`` and updated
+ docs to help in initial configuration while running tests.
+* Added a link in the installation docs to a more complete installation
+ example in the example app.
+* Added check to prevent the toolbar from being installed when tests
+ are running.
+* Added test to example app and command to run the example app's tests.
+* Implemented dark mode theme and button to toggle the theme,
+ introduced the ``DEFAULT_THEME`` setting which sets the default theme
+ to use.
+
4.3.0 (2024-02-01)
------------------
diff --git a/docs/checks.rst b/docs/checks.rst
index 6ed1e88f4..1c41d04fc 100644
--- a/docs/checks.rst
+++ b/docs/checks.rst
@@ -21,3 +21,6 @@ Django Debug Toolbar setup and configuration:
* **debug_toolbar.W007**: JavaScript files are resolving to the wrong content
type. Refer to :external:ref:`Django's explanation of
mimetypes on Windows `.
+* **debug_toolbar.W008**: The deprecated ``OBSERVE_REQUEST_CALLBACK`` setting
+ is present in ``DEBUG_TOOLBAR_CONFIG``. Use the ``UPDATE_ON_FETCH`` and/or
+ ``SHOW_TOOLBAR_CALLBACK`` settings instead.
diff --git a/docs/conf.py b/docs/conf.py
index f87b8f19a..6e67aac2e 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -25,7 +25,7 @@
copyright = copyright.format(datetime.date.today().year)
# The full version, including alpha/beta/rc tags
-release = "4.3.0"
+release = "5.2.0"
# -- General configuration ---------------------------------------------------
diff --git a/docs/configuration.rst b/docs/configuration.rst
index 8271092ca..377c97da8 100644
--- a/docs/configuration.rst
+++ b/docs/configuration.rst
@@ -29,6 +29,7 @@ default value is::
'debug_toolbar.panels.sql.SQLPanel',
'debug_toolbar.panels.staticfiles.StaticFilesPanel',
'debug_toolbar.panels.templates.TemplatesPanel',
+ 'debug_toolbar.panels.alerts.AlertsPanel',
'debug_toolbar.panels.cache.CachePanel',
'debug_toolbar.panels.signals.SignalsPanel',
'debug_toolbar.panels.redirects.RedirectsPanel',
@@ -72,6 +73,19 @@ Toolbar options
The toolbar searches for this string in the HTML and inserts itself just
before.
+.. _IS_RUNNING_TESTS:
+
+* ``IS_RUNNING_TESTS``
+
+ Default: ``"test" in sys.argv or "PYTEST_VERSION" in os.environ``
+
+ This setting whether the application is running tests. If this resolves to
+ ``True``, the toolbar will prevent you from running tests. This should only
+ be changed if your test command doesn't include ``test`` or if you wish to
+ test your application with the toolbar configured. If you do wish to test
+ your application with the toolbar configured, set this setting to
+ ``False``.
+
.. _RENDER_PANELS:
* ``RENDER_PANELS``
@@ -139,16 +153,30 @@ Toolbar options
implication is that it is possible to execute arbitrary SQL through the
SQL panel when the ``SECRET_KEY`` value is leaked somehow.
+ .. warning::
+
+ Do not use
+ ``DEBUG_TOOLBAR_CONFIG = {"SHOW_TOOLBAR_CALLBACK": lambda request: DEBUG}``
+ in your project's settings.py file. The toolbar expects to use
+ ``django.conf.settings.DEBUG``. Using your project's setting's ``DEBUG``
+ is likely to cause unexpected results when running your tests. This is because
+ Django automatically sets ``settings.DEBUG = False``, but your project's
+ setting's ``DEBUG`` will still be set to ``True``.
+
.. _OBSERVE_REQUEST_CALLBACK:
* ``OBSERVE_REQUEST_CALLBACK``
Default: ``'debug_toolbar.toolbar.observe_request'``
+ .. note::
+
+ This setting is deprecated in favor of the ``UPDATE_ON_FETCH`` and
+ ``SHOW_TOOLBAR_CALLBACK`` settings.
+
This is the dotted path to a function used for determining whether the
- toolbar should update on AJAX requests or not. The default checks are that
- the request doesn't originate from the toolbar itself, EG that
- ``is_toolbar_request`` is false for a given request.
+ toolbar should update on AJAX requests or not. The default implementation
+ always returns ``True``.
.. _TOOLBAR_LANGUAGE:
@@ -173,6 +201,7 @@ Toolbar options
request when it occurs. This is especially useful when using htmx
boosting or similar JavaScript techniques.
+
Panel options
~~~~~~~~~~~~~
@@ -351,10 +380,10 @@ Here's what a slightly customized toolbar configuration might look like::
Theming support
---------------
-The debug toolbar uses CSS variables to define fonts. This allows changing
-fonts without having to override many individual CSS rules. For example, if
-you preferred Roboto instead of the default list of fonts you could add a
-**debug_toolbar/base.html** template override to your project:
+The debug toolbar uses CSS variables to define fonts and colors. This allows
+changing fonts and colors without having to override many individual CSS rules.
+For example, if you preferred Roboto instead of the default list of fonts you
+could add a **debug_toolbar/base.html** template override to your project:
.. code-block:: django
@@ -370,4 +399,4 @@ you preferred Roboto instead of the default list of fonts you could add a
The list of CSS variables are defined at
`debug_toolbar/static/debug_toolbar/css/toolbar.css
-`_
+`_
diff --git a/docs/contributing.rst b/docs/contributing.rst
index 5e11ee603..1ab7077aa 100644
--- a/docs/contributing.rst
+++ b/docs/contributing.rst
@@ -1,19 +1,14 @@
Contributing
============
-.. image:: https://jazzband.co/static/img/jazzband.svg
- :target: https://jazzband.co/
- :alt: Jazzband
-
-This is a `Jazzband `_ project. By contributing you agree
-to abide by the `Contributor Code of Conduct `_
-and follow the `guidelines `_.
+This is a `Django Commons `_ project. By contributing you agree
+to abide by the `Contributor Code of Conduct `_.
Bug reports and feature requests
--------------------------------
You can report bugs and request features in the `bug tracker
-`_.
+`_.
Please search the existing database for duplicates before filing an issue.
@@ -21,13 +16,13 @@ Code
----
The code is available `on GitHub
-`_. Unfortunately, the
+`_. Unfortunately, the
repository contains old and flawed objects, so if you have set
`fetch.fsckObjects
`_
you'll have to deactivate it for this repository::
- git clone --config fetch.fsckobjects=false https://github.com/jazzband/django-debug-toolbar.git
+ git clone --config fetch.fsckobjects=false https://github.com/django-commons/django-debug-toolbar.git
Once you've obtained a checkout, you should create a virtualenv_ and install
the libraries required for working on the Debug Toolbar::
@@ -48,6 +43,12 @@ For convenience, there's an alias for the second command::
Look at ``example/settings.py`` for running the example with another database
than SQLite.
+Architecture
+------------
+
+There is high-level information on how the Django Debug Toolbar is structured
+in the :doc:`architecture documentation `.
+
Tests
-----
@@ -79,6 +80,12 @@ or by setting the ``DJANGO_SELENIUM_TESTS`` environment variable::
$ DJANGO_SELENIUM_TESTS=true make coverage
$ DJANGO_SELENIUM_TESTS=true tox
+Note that by default, ``tox`` enables the Selenium tests for a single test
+environment. To run the entire ``tox`` test suite with all Selenium tests
+disabled, run the following::
+
+ $ DJANGO_SELENIUM_TESTS= tox
+
To test via ``tox`` against other databases, you'll need to create the user,
database and assign the proper permissions. For PostgreSQL in a ``psql``
shell (note this allows the debug_toolbar user the permission to create
@@ -100,10 +107,10 @@ For MySQL/MariaDB in a ``mysql`` shell::
Style
-----
-The Django Debug Toolbar uses `black `__ to
-format code and additionally uses ruff. The toolbar uses
-`pre-commit `__ to automatically apply our style
-guidelines when a commit is made. Set up pre-commit before committing with::
+The Django Debug Toolbar uses `ruff `__ to
+format and lint Python code. The toolbar uses `pre-commit
+`__ to automatically apply our style guidelines when a
+commit is made. Set up pre-commit before committing with::
$ pre-commit install
@@ -117,11 +124,23 @@ To reformat the code manually use::
$ pre-commit run --all-files
+
+Typing
+------
+
+The Debug Toolbar has been accepting patches which add type hints to the code
+base, as long as the types themselves do not cause any problems or obfuscate
+the intent.
+
+The maintainers are not committed to adding type hints and are not requiring
+new code to have type hints at this time. This may change in the future.
+
+
Patches
-------
Please submit `pull requests
-`_!
+`_!
The Debug Toolbar includes a limited but growing test suite. If you fix a bug
or add a feature code, please consider adding proper coverage in the test
@@ -148,8 +167,11 @@ Prior to a release, the English ``.po`` file must be updated with ``make
translatable_strings`` and pushed to Transifex. Once translators have done
their job, ``.po`` files must be downloaded with ``make update_translations``.
+You will need to
+`install the Transifex CLI `_.
+
To publish a release you have to be a `django-debug-toolbar project lead at
-Jazzband `__.
+Django Commons `__.
The release itself requires the following steps:
@@ -177,7 +199,8 @@ The release itself requires the following steps:
#. Push the commit and the tag.
-#. Publish the release from the Jazzband website.
+#. Publish the release from the GitHub actions workflow.
-#. Change the default version of the docs to point to the latest release:
- https://readthedocs.org/dashboard/django-debug-toolbar/versions/
+#. **After the publishing completed** edit the automatically created GitHub
+ release to include the release notes (you may use GitHub's "Generate release
+ notes" button for this).
diff --git a/docs/index.rst b/docs/index.rst
index e53703d4f..48c217b1a 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -10,5 +10,7 @@ Django Debug Toolbar
tips
panels
commands
+ resources
changes
contributing
+ architecture
diff --git a/docs/installation.rst b/docs/installation.rst
index a350d9c3a..b89a2f563 100644
--- a/docs/installation.rst
+++ b/docs/installation.rst
@@ -9,7 +9,8 @@ fully functional.
.. warning::
- The Debug Toolbar does not currently support `Django's asynchronous views `_.
+ The Debug Toolbar now supports `Django's asynchronous views `_ and ASGI environment, but
+ still lacks the capability for handling concurrent requests.
1. Install the Package
^^^^^^^^^^^^^^^^^^^^^^
@@ -30,7 +31,7 @@ instead with the following command:
.. code-block:: console
- $ python -m pip install -e git+https://github.com/jazzband/django-debug-toolbar.git#egg=django-debug-toolbar
+ $ python -m pip install -e git+https://github.com/django-commons/django-debug-toolbar.git#egg=django-debug-toolbar
If you're upgrading from a previous version, you should review the
:doc:`change log ` and look for specific upgrade instructions.
@@ -81,6 +82,11 @@ Add ``"debug_toolbar"`` to your ``INSTALLED_APPS`` setting:
"debug_toolbar",
# ...
]
+.. note:: Check out the configuration example in the
+ `example app
+ `_
+ to learn how to set up the toolbar to function smoothly while running
+ your tests.
4. Add the URLs
^^^^^^^^^^^^^^^
@@ -90,14 +96,15 @@ Add django-debug-toolbar's URLs to your project's URLconf:
.. code-block:: python
from django.urls import include, path
+ from debug_toolbar.toolbar import debug_toolbar_urls
urlpatterns = [
- # ...
- path("__debug__/", include("debug_toolbar.urls")),
- ]
+ # ... the rest of your URLconf goes here ...
+ ] + debug_toolbar_urls()
+
+By default this uses the ``__debug__`` prefix for the paths, but you can
+use any prefix that doesn't clash with your application's URLs.
-This example uses the ``__debug__`` prefix, but you can use any prefix that
-doesn't clash with your application's URLs.
5. Add the Middleware
^^^^^^^^^^^^^^^^^^^^^
@@ -145,25 +152,84 @@ option.
.. warning::
- If using Docker the following will set your ``INTERNAL_IPS`` correctly in Debug mode::
+ If using Docker, the toolbar will attempt to look up your host name
+ automatically and treat it as an allowable internal IP. If you're not
+ able to get the toolbar to work with your docker installation, review
+ the code in ``debug_toolbar.middleware.show_toolbar``.
+
+7. Disable the toolbar when running tests (optional)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If you're running tests in your project you shouldn't activate the toolbar. You
+can do this by adding another setting:
+
+.. code-block:: python
+
+ TESTING = "test" in sys.argv or "PYTEST_VERSION" in os.environ
+
+ if not TESTING:
+ INSTALLED_APPS = [
+ *INSTALLED_APPS,
+ "debug_toolbar",
+ ]
+ MIDDLEWARE = [
+ "debug_toolbar.middleware.DebugToolbarMiddleware",
+ *MIDDLEWARE,
+ ]
- if DEBUG:
- import socket # only if you haven't already imported this
- hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
- INTERNAL_IPS = [ip[: ip.rfind(".")] + ".1" for ip in ips] + ["127.0.0.1", "10.0.2.2"]
+You should also modify your URLconf file:
+
+.. code-block:: python
+
+ from django.conf import settings
+ from debug_toolbar.toolbar import debug_toolbar_urls
+
+ if not settings.TESTING:
+ urlpatterns = [
+ *urlpatterns,
+ ] + debug_toolbar_urls()
+
+Alternatively, you can check out the :ref:`IS_RUNNING_TESTS `
+option.
Troubleshooting
---------------
-On some platforms, the Django ``runserver`` command may use incorrect content
-types for static assets. To guess content types, Django relies on the
-:mod:`mimetypes` module from the Python standard library, which itself relies
-on the underlying platform's map files. If you find improper content types for
-certain files, it is most likely that the platform's map files are incorrect or
-need to be updated. This can be achieved, for example, by installing or
-updating the ``mailcap`` package on a Red Hat distribution, ``mime-support`` on
-a Debian distribution, or by editing the keys under ``HKEY_CLASSES_ROOT`` in
-the Windows registry.
+If the toolbar doesn't appear, check your browser's development console for
+errors. These errors can often point to one of the issues discussed in the
+section below. Note that the toolbar only shows up for pages with an HTML body
+tag, which is absent in the templates of the Django Polls tutorial.
+
+Incorrect MIME type for toolbar.js
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When this error occurs, the development console shows an error similar to:
+
+.. code-block:: text
+
+ Loading module from “http://127.0.0.1:8000/static/debug_toolbar/js/toolbar.js” was blocked because of a disallowed MIME type (“text/plain”).
+
+On some platforms (commonly on Windows O.S.), the Django ``runserver``
+command may use incorrect content types for static assets. To guess content
+types, Django relies on the :mod:`mimetypes` module from the Python standard
+library, which itself relies on the underlying platform's map files.
+
+The easiest workaround is to add the following to your ``settings.py`` file.
+This forces the MIME type for ``.js`` files:
+
+.. code-block:: python
+
+ import mimetypes
+ mimetypes.add_type("application/javascript", ".js", True)
+
+Alternatively, you can try to fix your O.S. configuration. If you find improper
+content types for certain files, it is most likely that the platform's map
+files are incorrect or need to be updated. This can be achieved, for example:
+
+- On Red Hat distributions, install or update the ``mailcap`` package.
+- On Debian distributions, install or update the ``mime-support`` package.
+- On Windows O.S., edit the keys under ``HKEY_CLASSES_ROOT`` in the Windows
+ registry.
Cross-Origin Request Blocked
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -205,11 +271,12 @@ And for Apache:
Django Channels & Async
^^^^^^^^^^^^^^^^^^^^^^^
-The Debug Toolbar currently doesn't support Django Channels or async projects.
-If you are using Django channels are having issues getting panels to load,
-please review the documentation for the configuration option
-:ref:`RENDER_PANELS `.
+The Debug Toolbar currently has experimental support for Django Channels and
+async projects. The Debug Toolbar is compatible with the following exceptions:
+- Concurrent requests aren't supported
+- ``TimerPanel``, ``RequestPanel`` and ``ProfilingPanel`` can't be used
+ in async contexts.
HTMX
^^^^
diff --git a/docs/panels.rst b/docs/panels.rst
index db4e9311f..a116bff1e 100644
--- a/docs/panels.rst
+++ b/docs/panels.rst
@@ -22,8 +22,8 @@ snapshot of the toolbar to view that request's stats.
``True`` or if the server runs with multiple processes, the History Panel
will be disabled.
-Version
-~~~~~~~
+Versions
+~~~~~~~~
.. class:: debug_toolbar.panels.versions.VersionsPanel
@@ -69,19 +69,30 @@ SQL
SQL queries including time to execute and links to EXPLAIN each query.
-Template
-~~~~~~~~
+Static files
+~~~~~~~~~~~~
+
+.. class:: debug_toolbar.panels.staticfiles.StaticFilesPanel
+
+Used static files and their locations (via the ``staticfiles`` finders).
+
+Templates
+~~~~~~~~~
.. class:: debug_toolbar.panels.templates.TemplatesPanel
Templates and context used, and their template paths.
-Static files
-~~~~~~~~~~~~
+Alerts
+~~~~~~~
-.. class:: debug_toolbar.panels.staticfiles.StaticFilesPanel
+.. class:: debug_toolbar.panels.alerts.AlertsPanel
-Used static files and their locations (via the ``staticfiles`` finders).
+This panel shows alerts for a set of pre-defined cases:
+
+- Alerts when the response has a form without the
+ ``enctype="multipart/form-data"`` attribute and the form contains
+ a file input.
Cache
~~~~~
@@ -90,8 +101,8 @@ Cache
Cache queries. Is incompatible with Django's per-site caching.
-Signal
-~~~~~~
+Signals
+~~~~~~~
.. class:: debug_toolbar.panels.signals.SignalsPanel
@@ -111,6 +122,11 @@ 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.
+To further customize the behavior, you can subclass the ``RedirectsPanel``
+and override the ``get_interception_response`` method to manipulate the
+response directly. To use a custom ``RedirectsPanel``, you need to replace
+the original one in ``DEBUG_TOOLBAR_PANELS`` in your ``settings.py``.
+
.. _profiling-panel:
Profiling
@@ -123,6 +139,10 @@ Profiling information for the processing of the request.
This panel is included but inactive by default. You can activate it by default
with the ``DISABLE_PANELS`` configuration option.
+For version of Python 3.12 and later you need to use
+``python -m manage runserver --nothreading``
+Concurrent requests don't work with the profiling panel.
+
The panel will include all function calls made by your project if you're using
the setting ``settings.BASE_DIR`` to point to your project's root directory.
If a function is in a file within that directory and does not include
@@ -306,7 +326,7 @@ Panels can ship their own templates, static files and views.
Any views defined for the third-party panel use the following decorators:
- ``debug_toolbar.decorators.require_show_toolbar`` - Prevents unauthorized
- access to the view.
+ access to the view. This decorator is compatible with async views.
- ``debug_toolbar.decorators.render_with_toolbar_language`` - Supports
internationalization for any content rendered by the view. This will render
the response with the :ref:`TOOLBAR_LANGUAGE ` rather than
diff --git a/docs/resources.rst b/docs/resources.rst
new file mode 100644
index 000000000..d5974badb
--- /dev/null
+++ b/docs/resources.rst
@@ -0,0 +1,78 @@
+Resources
+=========
+
+This section includes resources that can be used to learn more about
+the Django Debug Toolbar.
+
+Tutorials
+---------
+
+Django Debugging Tutorial
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Originally presented as an in-person workshop at DjangoCon US 2022, this
+tutorial by **Tim Schilling** covers debugging techniques in Django. Follow
+along independently using the slides and GitHub repository.
+
+* `View the tutorial details on the conference website `__
+* `Follow along with the GitHub repository `__
+* `View the slides on Google Docs `__
+* Last updated: February 13, 2025.
+* Estimated time to complete: 1-2 hours.
+
+Mastering Django Debug Toolbar: Efficient Debugging and Optimization Techniques
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This tutorial by **Bob Belderbos** provides an in-depth look at effectively
+using Django Debug Toolbar to debug Django applications, covering installation,
+configuration, and practical usage.
+
+* `Watch on YouTube `__
+* Published: May 13, 2023.
+* Duration: 11 minutes.
+
+Talks
+-----
+
+A Related Matter: Optimizing Your Web App by Using Django Debug Toolbar
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Presented at DjangoCon US 2024 by **Christopher Adams**, this talk delves into
+optimizing web applications using Django Debug Toolbar, focusing on SQL query
+analysis and performance improvements.
+
+* `View the talk details on the conference website `__
+* `Watch on DjangoTV `__
+* Published: December 6, 2024.
+* Duration: 26 minutes.
+
+Fast on My Machine: How to Debug Slow Requests in Production
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Presented at DjangoCon Europe 2024 by **Raphael Michel**, this talk explores
+debugging slow requests in production. While not focused on Django Debug
+Toolbar, it highlights performance issues the tool can help diagnose.
+
+* `View the talk details on the conference website `__
+* `Watch on DjangoTV `__
+* Published: July 11, 2024.
+* Duration: 23 minutes.
+
+Want to Add Your Content Here?
+------------------------------
+
+Have a great tutorial or talk about Django Debug Toolbar? We'd love to
+showcase it! If your content helps developers improve their debugging skills,
+follow our :doc:`contributing guidelines ` to submit it.
+
+To ensure relevant and accessible content, please check the following
+before submitting:
+
+1. Does it at least partially focus on the Django Debug Toolbar?
+2. Does the content show a version of Django that is currently supported?
+3. What language is the tutorial in and what languages are the captions
+ available in?
+
+Talks and tutorials that cover advanced debugging techniques,
+performance optimization, and real-world applications are particularly
+welcome.
diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt
index 436977bdc..79b05cb06 100644
--- a/docs/spelling_wordlist.txt
+++ b/docs/spelling_wordlist.txt
@@ -6,13 +6,17 @@ Pympler
Roboto
Transifex
Werkzeug
+aenable
ajax
+asgi
async
backend
backends
backported
+biome
checkbox
contrib
+csp
dicts
django
fallbacks
@@ -21,6 +25,7 @@ flatpages
frontend
htmx
inlining
+instrumentation
isort
jQuery
jinja
@@ -36,6 +41,7 @@ mousedown
mouseup
multi
neo
+nothreading
paddings
pre
profiler
@@ -43,18 +49,23 @@ psycopg
py
pyflame
pylibmc
+pytest
pyupgrade
querysets
refactoring
+reinitializing
resizing
+runserver
spellchecking
spooler
stacktrace
stacktraces
startup
+staticfiles
theming
timeline
tox
uWSGI
+unhandled
unhashable
validator
diff --git a/example/README.rst b/example/README.rst
index 94c09f8e5..5102abd18 100644
--- a/example/README.rst
+++ b/example/README.rst
@@ -13,9 +13,10 @@ interfere with common JavaScript frameworks.
How to
------
-The example project requires a working installation of Django::
+The example project requires a working installation of Django and a few other
+packages::
- $ python -m pip install Django
+ $ python -m pip install -r requirements_dev.txt
The following command must run from the root directory of Django Debug Toolbar,
i.e. the directory that contains ``example/``::
@@ -46,3 +47,13 @@ environment variable::
$ DB_BACKEND=postgresql python example/manage.py migrate
$ DB_BACKEND=postgresql python example/manage.py runserver
+
+Using an asynchronous (ASGI) server:
+
+Install [Daphne](https://pypi.org/project/daphne/) first:
+
+ $ python -m pip install daphne
+
+Then run the Django development server:
+
+ $ ASYNC_SERVER=true python example/manage.py runserver
diff --git a/example/asgi.py b/example/asgi.py
new file mode 100644
index 000000000..9d7c78703
--- /dev/null
+++ b/example/asgi.py
@@ -0,0 +1,9 @@
+"""ASGI config for example project."""
+
+import os
+
+from django.core.asgi import get_asgi_application
+
+os.environ.setdefault("DJANGO_SETTINGS_MODULE", "example.settings")
+
+application = get_asgi_application()
diff --git a/example/django-debug-toolbar.png b/example/django-debug-toolbar.png
index 414df59e0..e074973e6 100644
Binary files a/example/django-debug-toolbar.png and b/example/django-debug-toolbar.png differ
diff --git a/example/settings.py b/example/settings.py
index d2bd57387..06b70f7fa 100644
--- a/example/settings.py
+++ b/example/settings.py
@@ -1,12 +1,14 @@
"""Django settings for example project."""
import os
+import sys
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
# Quick-start development settings - unsuitable for production
+
SECRET_KEY = "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
DEBUG = True
@@ -16,17 +18,16 @@
# Application definition
INSTALLED_APPS = [
+ *(["daphne"] if os.getenv("ASYNC_SERVER", False) else []), # noqa: FBT003
"django.contrib.admin",
"django.contrib.auth",
"django.contrib.contenttypes",
"django.contrib.sessions",
"django.contrib.messages",
"django.contrib.staticfiles",
- "debug_toolbar",
]
MIDDLEWARE = [
- "debug_toolbar.middleware.DebugToolbarMiddleware",
"django.middleware.security.SecurityMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.common.CommonMiddleware",
@@ -41,6 +42,12 @@
STATIC_URL = "/static/"
TEMPLATES = [
+ {
+ "NAME": "jinja2",
+ "BACKEND": "django.template.backends.jinja2.Jinja2",
+ "APP_DIRS": True,
+ "DIRS": [os.path.join(BASE_DIR, "example", "templates", "jinja2")],
+ },
{
"BACKEND": "django.template.backends.django.DjangoTemplates",
"APP_DIRS": True,
@@ -54,14 +61,14 @@
"django.contrib.messages.context_processors.messages",
],
},
- }
+ },
]
USE_TZ = True
WSGI_APPLICATION = "example.wsgi.application"
+ASGI_APPLICATION = "example.asgi.application"
-DEBUG_TOOLBAR_CONFIG = {"ROOT_TAG_EXTRA_ATTRS": "data-turbo-permanent hx-preserve"}
# Cache and database
@@ -97,3 +104,17 @@
}
STATICFILES_DIRS = [os.path.join(BASE_DIR, "example", "static")]
+
+# Only enable the toolbar when we're in debug mode and we're
+# not running tests. Django will change DEBUG to be False for
+# tests, so we can't rely on DEBUG alone.
+ENABLE_DEBUG_TOOLBAR = DEBUG and "test" not in sys.argv
+if ENABLE_DEBUG_TOOLBAR:
+ INSTALLED_APPS += [
+ "debug_toolbar",
+ ]
+ MIDDLEWARE += [
+ "debug_toolbar.middleware.DebugToolbarMiddleware",
+ ]
+ # Customize the config to support turbo and htmx boosting.
+ DEBUG_TOOLBAR_CONFIG = {"ROOT_TAG_EXTRA_ATTRS": "data-turbo-permanent hx-preserve"}
diff --git a/example/templates/async_db.html b/example/templates/async_db.html
new file mode 100644
index 000000000..771c039e3
--- /dev/null
+++ b/example/templates/async_db.html
@@ -0,0 +1,14 @@
+
+
+
+
+ Async DB
+
+
+
Async DB
+
+ Value
+ {{ user_count }}
+
+
+
diff --git a/example/templates/bad_form.html b/example/templates/bad_form.html
new file mode 100644
index 000000000..f50662c6e
--- /dev/null
+++ b/example/templates/bad_form.html
@@ -0,0 +1,14 @@
+{% load cache %}
+
+
+
+
+ Bad form
+
+
+
Index of Tests (htmx) - Page {{page_num|default:"1"}}
+
Index of Tests (htmx) - Page {{ page_num|default:"1" }}
For the debug panel to remain through page navigation, add the setting:
diff --git a/example/templates/index.html b/example/templates/index.html
index 382bfb0e9..4b25aefca 100644
--- a/example/templates/index.html
+++ b/example/templates/index.html
@@ -9,11 +9,13 @@