admin-interface - 500 error - missing MEDIA_URL

[Brot]

Hello,

I have defined a 500.html template in my root template directory.
This template "extends" from my base.html template. In the base
template I have something like:
<link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}css/
default.css" />

But if there is an 500 error in the admin interface, it seems that
MEDIA_URL is empty.
('django.core.context_processors.media' is activated in the
settings.py file)

Could this be a bug or is this expected behaviour?

Regares
Bernd

[Marty Alchin]

On Nov 9, 2007 12:34 PM, Brot <schl...@gmail.com> wrote:
> I have defined a 500.html template in my root template directory.
> This template "extends" from my base.html template. In the base
> template I have something like:
> <link rel="stylesheet" type="text/css" href="{{ MEDIA_URL }}css/
> default.css" />
>
> But if there is an 500 error in the admin interface, it seems that
> MEDIA_URL is empty.
> ('django.core.context_processors.media' is activated in the
> settings.py file)

I've been having this exact problem, but hadn't gotten around to
figuring out why.

> Could this be a bug or is this expected behaviour?

I seem to remember something a while back about 500 not processing too
much, to reduce the possibility of getting into a recursive loop of
exceptions. I can't seem to find that now, but that could be what
we're running into.

-Gul

[James Bennett]

On Nov 9, 2007 12:49 PM, Marty Alchin <gulo...@gamemusic.org> wrote:
> I seem to remember something a while back about 500 not processing too
> much, to reduce the possibility of getting into a recursive loop of
> exceptions. I can't seem to find that now, but that could be what
> we're running into.

The default Django "internal server error" view loads and renders the
template '500.html', with NO context variables whatsoever, not even
context processors. This is to avoid getting into a situation where
rendering the error template raises another exception.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Brot]

does this mean, that there is no solution for this problem or is there
a smart workaround?

I think I could use a custom templatetag. But this would violate DRY.

Regards
Bernd

On Nov 9, 7:49 pm, "Marty Alchin" <gulop...@gamemusic.org> wrote:

[James Bennett]

On Nov 9, 2007 1:29 PM, Brot <schl...@gmail.com> wrote:
> does this mean, that there is no solution for this problem or is there
> a smart workaround?

This means there is absolutely nothing in Django which will, in the
server error view, attempt to run your context processors. There is
not a switch you can flip or a button you can press or an argument you
can pass or a setting you can change to affect this: Django assumes
that when things break badly enough to result in a 500, it's not safe
to rely on anything at all being in working condition.

If you want to specify a different handler for 500s, that's up to you,
but be prepared for the inevitable complete breaking of your site when
something running inside it raises another exception.

[Marty Alchin]

On Nov 9, 2007 2:40 PM, James Bennett <ubern...@gmail.com> wrote:
> If you want to specify a different handler for 500s, that's up to you,
> but be prepared for the inevitable complete breaking of your site when
> something running inside it raises another exception.

I think I'll settle for hardcoding the path to my CSS in one template.
Certainly the easiest way to go about it. It doesn't have to be
portable either, since I won't even be using that template during
development, it's solely for production.

-Gul

[sime]

Now I expect this again is going to be defended religiously; but the
fact that 500's don't run context processors, to me, serves as a nice
little reminder that {% media_url %} or similar needs to be a core
template tag. Where is the sense in bothering with a custom 500 if you
can't conveniently use css, images, etc?

On Nov 10, 5:40 am, "James Bennett" <ubernost...@gmail.com> wrote:

> On Nov 9, 2007 1:29 PM, Brot <schla...@gmail.com> wrote:
>
> > does this mean, that there is no solution for this problem or is there
> > a smart workaround?
>
> This means there is absolutely nothing in Django which will, in the

> server error view, attempt to run yourcontextprocessors. There is

> not a switch you can flip or a button you can press or an argument you
> can pass or a setting you can change to affect this: Django assumes

> that when things break badly enough to result in a500, it's not safe

[Malcolm Tredinnick]

On Sun, 2007-11-11 at 16:51 -0800, sime wrote:
> Now I expect this again is going to be defended religiously; but the
> fact that 500's don't run context processors, to me, serves as a nice
> little reminder that {% media_url %} or similar needs to be a core
> template tag. Where is the sense in bothering with a custom 500 if you
> can't conveniently use css, images, etc?

At the point you need a 500 page, things have completely and utterly
failed. It's called an "internal server error" for a reason. You need to
do the minimum possible and get out of there, because the code's in an
unstable state. Running more code is definitely not what the doctor
ordered there, and that includes running arbitrary template tags.

The point, since you asked, of having a custom 500 page is so that you
can display minimal related information that the user can report so you
can investigate via your logs and other external problem recording
mechanisms. there's no way a one-size-fits-all page could possibly meet
requirements there. The range obviously doesn't go immediately from
"everybody gets the same page" to "you must be able to run all this
complex customisation stuff".

Fortunately, with Django being a fully nicely extensible framework, you
can happily change this if you really want to. Simply override the
handler class to do something different when it receives a 500 error.

Malcolm

--
A conclusion is the place where you got tired of thinking.
http://www.pointy-stick.com/blog/