It’s easy to create a custom template for HTTP 500 errors. All you have to do is create a file named 500.html in any of the application’s TEMPLATE_DIRS. But in almost all cases you want to use media in this page. It’s good to have an error page with the same look and feel of the system itself.
The default HTTP 500 handler in django uses Context instead of RequestContext. It means that none of your template context processors will be loaded, and the MEDIA_URL variable available in the template system comes exactly from one of these processors. So, without template context processors, we get no MEDIA_URL variable in templates.
Searching in google for a solution to this problem I found a snippet[1] that solves the MEDIA_URL problem. But it still doesn’t load the processors, all it does is pass the MEDIA_URL variable to the context for template. So I decided to make simple changes in it to load the processors. And here is the complete code:
def server_error(request, template_name='500.html'):
from django.template import RequestContext
from django.http import HttpResponseServerError
t = loader.get_template(template_name)
return HttpResponseServerError(t.render(RequestContext(request)))
Put this code in any views file you want and then define it as the handler500 in your urls.py:
handler500 = 'views.server_error'
[1] http://www.djangosnippets.org/snippets/1199/
As Felipe Prenholato mentioned in comments, if you use this code and one of your template context processors raises an Exception it will break badly and will show an ungly HTTP 500 page from your http server.
November 30th, 2009 09:51
Simple use render_to_response tag.
November 30th, 2009 14:54
render to response returns the HTTP 500 code?
February 1st, 2011 14:49
I did it several times in my projects, but use of RequestContext(request) still showing errors if it happens in some parte of request object (let’s say some middleware). My solution always is, put it as arguments to template instead use RequestContext.
February 1st, 2011 18:30
You are right. It’s a problem in RequestContext use for this. I agree with you now, but it will be the context processors that will be responsible for breaking your software not the middlewares, since the middlewares are called with or without the use of the RequestContext. When I wrote this post I didn’t think about this and now I see this problem.