Opened 16 years ago

Closed 16 years ago

Last modified 11 years ago

#6377 closed Uncategorized (wontfix)

Use RequestContext if possible in default 500 error view

Reported by: Jason Davies Owned by: nobody
Component: Core (Other) Version: dev
Severity: Normal Keywords: error, handler500, 500
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

It would be nice if the default handler500 error view tried to use RequestContext by default, and fell back to using Context if an Exception is raised.

Currently, various context variables such as MEDIA_URL are not populated in error pages, since only Context is being used.

Attachments (1)

defaults.py.diff (562 bytes ) - added by Jason Davies 16 years ago.

Download all attachments as: .zip

Change History (7)

by Jason Davies, 16 years ago

Attachment: defaults.py.diff added

comment:1 by James Bennett, 16 years ago

Resolution: duplicate
Status: newclosed

Duplicate of #5617, which was wontfix'd. See that ticket for the explanation, and please search the ticket archive in the future.

in reply to:  1 comment:2 by Jason Davies, 16 years ago

Resolution: duplicate
Status: closedreopened

Replying to ubernostrum:

Duplicate of #5617, which was wontfix'd. See that ticket for the explanation, and please search the ticket archive in the future.

The explanation given was:

The default server-error handler was deliberately written this way to lessen the odds of new exceptions being raised during the execution of the server_error view.

I fully understand this reasoning. However, unlike the patches for #5617, my patch falls back to using the ordinary Context in the event of any new exceptions being raised. Is there any reason why this would be a bad idea? I have several clients who make heavy use of MEDIA_URL and so on for branding their sites, and the default 500 error handler looks rather ugly without any CSS or images, and thus confuses their customers.

Granted, it is extremely easy for me to override the default handler and do this myself, but, in keeping with the Django philosophy, I just wanted to make sure we have friendly defaults here if at all possible.

comment:3 by Karen Tracey <kmtracey@…>, 16 years ago

Resolution: wontfix
Status: reopenedclosed

The procedure (described here: http://www.djangoproject.com/documentation/contributing/) for revisiting wontfix tickets is to raise the issue on django-developers. If you get support from a core developer there to change the decision, then reopen the ticket. There's a good reason for this -- any individual ticket gets looked at by a tiny fraction of the community, while django-developers has a far wider audience. That makes the mailing list a much better place to determine if you've come up with a compelling reason to reverse the previous decision.

comment:4 by Tom Christie, 13 years ago

Easy pickings: unset
Severity: Normal
Type: Uncategorized
UI/UX: unset

comment:5 by anonymous, 11 years ago

I see... And for all those of us ending up here thinking this is a good idea, how exactly do we follow the discussion and find out why this was (presumably) rejected? Hunting through 5+years of mailing list archives? What a wonderful system...

in reply to:  5 comment:6 by Luke Plant, 11 years ago

Replying to anonymous:

I see... And for all those of us ending up here thinking this is a good idea, how exactly do we follow the discussion and find out why this was (presumably) rejected? Hunting through 5+years of mailing list archives? What a wonderful system...

The comment immediately previous to yours links directly to a short thread which contains more than enough rationale for this decision - Carl Meyer's first email in particular. I wouldn't call that hunting through 5 years of email. We couldn't have made it much easier for you.

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