On development server, MEDIA_URL exists without setting context_instance. Works properly in mod_python.

[chazmatazz]

Steps to repeat the problem:

1. In settings.py set TEMPLATE_CONTEXT_PROCESSORS to include 'django.core.context_processors.media'

2. In settings.py set MEDIA_URL to a non empty string e.g. '/media/'

3. In views.py, run render_to_response _without_ setting context_instance.

4. Have in the template used by render_to_response {{ MEDIA_URL }}

Expected:

{{ MEDIA_URL }} evaluates to '/media/'

What should happen

{{ MEDIA_URL }} evaluates to . This is what happens in mod_python.

Other notes

This is a bug in the development server. It's annoying because you think you have a working setup in development, but then you go to deploy and it's not working.

[Karen Tracey]

This report is a bit confusing because there is "Expected" and "What should happen" as opposed to "Expected" and "Actual Results" or "What happens" and "What should happen". Since your "Expected" seems to be, rather, "Unexpected", I'm guessing you meant "What happens" there. It is also unclear what you mean by "without setting context instance". You mean passing no context into render_to_response? Passing a Context but not a RequestContext? Bare bones snippets of code could have clarified here.

At any rate I cannot recreate a problem here. Using these views:

from django.shortcuts import render_to_response
from django.template import RequestContext
def mq0(request):
    return render_to_response('mq.tmpl')

def mq1(request):
    return render_to_response('mq.tmpl', {'view_name': 'mq1'})

def mq2(request):
    return render_to_response('mq.tmpl', RequestContext(request, {'view_name': 'mq2'}))

and this mq.tmpl:

View: {{ view_name }}
Media_url: {{ MEDIA_URL }}

only the mq2 view displays the MEDIA_URL value that is set in settings.py, as expected since the context processor that does this is documented to only affect RequestContexts. Tested using the development server on trunk r9817.