Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#35370 closed Cleanup/optimization (wontfix)

`context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:

Reported by: Marc Gibbons Owned by: nobody
Component: Template system Version: 5.0
Severity: Normal Keywords: context processors, internal ips, debug, template
Cc: Marc Gibbons Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I went down a rabbit hole recently with the django.templates.context_processors.debug context processor.

What I was looking for:

  • A context variable called debug which is always present
  • context['debug'] is True when settings.DEBUG = True and context['debug'] is False when settings.DEBUG = False

What I got:

  • A context variable named debug is sometimes included, but only when both settings.DEBUG is True and if request.META['REMOTE_ADDR'] in settings.INTERNAL_IPS. In other words, debug exists and is true only when your project has DEBUG turned on AND you’re visiting from an allowed list of IPs.
  • A context variable named sql_queries lazily returns all SQL queries executed in the request for the purpose of profiling.

Some context:

  • This context variable debug and its assignment is as old as Django. It appears in one of the first commits ever, and aside from being moved around over the years, has remained unchanged.
  • In no other area of Django is INTERNAL_IPS used to determine if you’re in DEBUG – this is an outlier.

Ideally, debug in templates would have the same meaning as it does in Python / the rest of the framework. Example:

def debug(request):
    return {"debug": settings.DEBUG}

Changing the context processor this way could be catastrophic.

Some thoughts:

  • debug, and its evaluation (when present) in request context is confusing (at least to me).
  • This context processor has a variety of concerns: evaluating DEBUG, determining if you’re trusted on a network, and gathering SQL queries. Would it make sense to split it up accordingly?
  • Or, given the risk security of changing how debug evaluates, could the entire context processor be marked for deprecation? Profiling SQL queries could be left to third party libraries like django-debug-toolbar.
  • INTERNAL_IPS might also be a candidate for deprecation.

Change History (3)

comment:1 by Marc Gibbons, 7 months ago

Summary: `request.context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:`context["debug"] is not settings.DEBUG` and the future of `django.templates.context_processors.debug`:

comment:2 by Tim Graham, 7 months ago

Resolution: wontfix
Status: newclosed

Hi Marc, it seems you summarized the documentation for the processor. I understand it doesn't meet your needs, but I don't see that as a reason to deprecate it. Use the DevelopersMailingList if you want to try to gather more opinions.

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