Code

Opened 6 years ago

Closed 6 years ago

Last modified 15 months ago

#6377 closed Uncategorized (wontfix)

Use RequestContext if possible in default 500 error view

Reported by: esaj Owned by: nobody
Component: Core (Other) Version: master
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 esaj 6 years ago.

Download all attachments as: .zip

Change History (7)

Changed 6 years ago by esaj

comment:1 follow-up: Changed 6 years ago by ubernostrum

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

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

comment:2 in reply to: ↑ 1 Changed 6 years ago by esaj

  • Resolution duplicate deleted
  • Status changed from closed to reopened

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 Changed 6 years ago by Karen Tracey <kmtracey@…>

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 Changed 3 years ago by tomchristie

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

comment:5 follow-up: Changed 15 months ago by 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...

comment:6 in reply to: ↑ 5 Changed 15 months ago by lukeplant

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.