Opened 7 years ago

Closed 7 years ago

#25697 closed Cleanup/optimization (fixed)

Default error views shouldn't silence TemplateDoesNotExist errors if a custom template name was specified

Reported by: Simon Charette Owned by: Iacopo Spalletti
Component: Generic views Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Simon Charette)

Default error views attempt to load a template from a default name and fallback to a string value if a TemplateDoesNotExist error is raised in the process.

This behavior should be altered to actually raise the error if a custom template_name is specified.

The affected views are:

  1. django.views.defaults.page_not_found
  2. django.views.defaults.server_error
  3. django.views.defaults.bad_request
  4. django.views.defaults.permission_denied

Note that the views were identified during a preliminary search and it's possible this pattern is used elsewhere in the Django code base.

We should consider deprecating this behavior instead of simply turning it on since it's slightly backward incompatible.

Thanks to Raphael Michel at #DUTH for helping identifying this issue.

Change History (10)

comment:1 Changed 7 years ago by Simon Charette

Description: modified (diff)

comment:2 Changed 7 years ago by Carl Meyer

Yes, I think we'd need a deprecation path here where initially we raise a PendingDeprecationWarning on an explicitly-specified nonexistent template, then a DeprecationWarning, and then finally switch to raising the TemplateNotFound.

comment:3 Changed 7 years ago by Iacopo Spalletti

Owner: changed from nobody to Iacopo Spalletti
Status: newassigned

comment:4 Changed 7 years ago by Iacopo Spalletti

Has patch: set

comment:5 Changed 7 years ago by Tim Graham

I'm lukewarm on deprecations (since it adds a lot of overhead for us) instead of making minor backwards incompatible changes in cases like this where it seems to simply delay revealing probable errors in user code. A similar case was select_related() field name validation where we made a backwards-incompatible change -- Carl, I believe you said you thought that should have gone through a deprecation. Just wanted to bring it up for discussion so I can crystallize my thinking around changes like this. Thanks!

comment:6 Changed 7 years ago by Tim Graham

Easy pickings: unset
Patch needs improvement: set

No one indicated an opposition on the mailing list to skipping a deprecation and making this a backwards incompatible change.

comment:7 Changed 7 years ago by Iacopo Spalletti

Ok, I'll change the PR to avoid the deprecation period and edit the changelog the reflect this change

comment:8 Changed 7 years ago by Tim Graham

Patch needs improvement: unset

comment:9 Changed 7 years ago by Tim Graham

Triage Stage: AcceptedReady for checkin

comment:10 Changed 7 years ago by Tim Graham <timograham@…>

Resolution: fixed
Status: assignedclosed

In 21bf685:

Fixed #25697 -- Made default error views error when passed a nonexistent template_name.

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