Heya, Thanks for the feedback. I quite like the explicit 'STATIC_URL' only approach, although I think a lot of users would still run into a problem there, because 'request' isn't also added in explicitly to the Context...
For context, my particular use case is a simple '500.html' template, that extends a 'base.html' template. I don't use any other context in the base template other than 'request' and 'STATIC_URL'. In the case of a 500 error, I'd see the template render correctly, except that it'd look like the user isn't logged in. Coming across that as a dev that'd confuse the hell out of me the first time I came across it unless I already understood the 500 Context behavior, and it's not ideal from the end-user perspective either. I'd imagine that plenty of other setups would have a similar setup, so you could argue that returning this: Context({'STATIC_URL': settings.STATIC_URL, 'request': request}) would be an okay thing to do in the default 500 handler. Personally I think that'd probably be absolutely fine (and the most sensible default 500 view), although the obvious counter argument is that that's getting into the realms of special-case, rather than default-case. (That's not my opinion, but it'd be a valid argument.) What do you reckon? Cheers, Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Ac1EeU-n6xAJ. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.