Don't run context processors for redirect template.

[living180]

In certain configurations, applying the context processors when rendering the redirect template can cause exceptions. For example, assume the folllowing Django settings:

APPEND_SLASH = True

MIDDLEWARE_CLASSES = (
    'debug_panel.middleware.DebugPanelMiddleware',
    'django.middleware.common.CommonMiddleware',
    ...
    'custom.middleware.CustomMiddleware'
)

TEMPLATE_CONTEXT_PROCESSORS = (
    ...
    'custom.context_processors.custom',
    ....
)

Further, assume that custom.middleware.CustomMiddleware sets an attribute on the request that custom.context_processors.custom tries to access. If django.middleware.common.CommonMiddleware causes a redirect, (e.g. as a result of the APPEND_SLASH setting), the attribute that custom.context_processors.custom needs will never get set on the request. Then when initializing the RequestContext in order to render debug_toolbar/redirect.html,an exception will occur when custom.context_processors.custom tries to access the missing attribute.

Since no context processors are needed to render the debug_toolbar/redirect.html template, avoid this problem by replacing render with render_to_response, which does not apply context processors to the template context.

[aaugustin]

Ah, I changed this recently because I couldn't figure out why the DDT used render_to_response instead of the more common render. This needs a test. Other views may have the same problem.

[catalanojuan]

This can be closed now since I added the same fix with the missing test in the PR shown above.

[aaugustin]

No, it cannot. There are other instances of render() that may trigger the same issue.

[catalanojuan]

@aaugustin thanks for your answer! I thought that this PR referred only to the instance in the redirects panel, but I get it that it might be better to also fix the other ones, should I extend the patch in the other PR to fix the other instances?

[aaugustin]

Do as you wish!