Is it possible to make django-admin interface not to include some of the template context processors?
in settings.py:
TEMPLATE_CONTEXT_PROCESSORS = (
..some.django.context.processors,
'myapp.views.context_processor',
)
in my.views.py:
def context_processor(request):
return {'user': my_custom_string}
So, data returning in 'my' context_processor overrides 'user' variable in django-admin template context and i've got an error.
And the second problem is that 'my' context_processor returnes 'fat' dict. There is no need to have it in admin's interface
You have the request object available to your context processor; you can examine the request's path to see if it's under the root path of the admin.
Related
Following the docs
If TEMPLATE_CONTEXT_PROCESSORS contains this processor, every
RequestContext will contain these variables:
user – An auth.User instance representing the currently logged-in user
(or an AnonymousUser instance, if the client isn’t logged in). perms –
An instance of django.contrib.auth.context_processors.PermWrapper,
representing the permissions that the currently logged-in user has.
I added these lines to settings.py
TEMPLATE_CONTEXT_PROCESSORS = (
"django.contrib.auth.context_processors.auth",
)
Rendering my templates as follows
def profile_view(request):
return render_to_response('profile.html', { 'profile' : 1 })
I was under the impression that the request context along with the user will be passed automatically. Is that not the case, or should i explicitly add context_instance=template.RequestContext(request)) to every view ?
Thanks.
Yes, if you want to use render_to_response and you want template context data available, you should pass in a RequestContext instance.
Alternatively, if you render your page with django.shortcuts.render, the RequestContext will be injected automatically.
You may find this answer useful, too: Django - what is the difference between render(), render_to_response() and direct_to_template()?
What's the simplest way to access the name of the current app within template code?
Alternatively, what's the simplest way to define a template variable to hold the name of the current app?
(The goal here is to minimize the number of places I need to edit if I rename an app.)
Since Django 1.5 there is a "resolver_match" attribute on the request object.
https://docs.djangoproject.com/en/dev/ref/request-response/
This contains the matched url configuration including "app_name", "namespace", etc.
https://docs.djangoproject.com/en/2.2/ref/urlresolvers/#django.urls.ResolverMatch
The only caveat is that it is not populated until after the first middleware passthrough, so is not available in process_request functions of middleware. However it is available in middleware process_view, views, and context processors. Also, seems like resolver_match is not populated in error handlers.
Example context processor to make available in all templates:
def resolver_context_processor(request):
return {
'app_name': request.resolver_match.app_name,
'namespace': request.resolver_match.namespace,
'url_name': request.resolver_match.url_name
}
There's a way to obtain an app name for a current request.
First, in your project's urls.py, considering your app is called 'main':
#urls.py
url(r'^', include('main.urls', app_name="main")),
Then, a context processsor:
#main/contexts.py
from django.core.urlresolvers import resolve
def appname(request):
return {'appname': resolve(request.path).app_name}
Don't forget to enable it in your settings:
#settings.py
TEMPLATE_CONTEXT_PROCESSORS = (
"django.core.context_processors.request",
"main.contexts.appname",)
You can use it in your template like any other variable: {{ appname }}.
I used a pre-built example templates for Django registration and I noticed that for those pages, Django understands user and I do things like user.is_authenticated and user.username.
I tried looking at the views.py code in both Django registration and the django.contrib.auth.views, but I couldn't figure out how those two always sent the user information to the templates.
I could could always explicitly send the user Context information to every view, but that would be violating the DRY principle.
I tried using this solution, but I get an error saying
Put 'django.contrib.auth.context_processors.auth' in your TEMPLATE_CONTEXT_PROCESSORS setting in order to use the admin application.
And even if I placed the above path inside settings.py like this
TEMPLATE_CONTEXT_PROCESSORS = (
'django.contrib.auth.context_processors.auth',
'doors.processor_file_name.user',
)
my templates still doesn't know about user.
It turns out that every time I was using render_to_response in my views.py...
def order_all( request ) :
orders = Order.objects.all()
return render_to_response( 'doors/order/list.html', { 'orders' : orders } )
the dictionary isn't a RequestContext. Using a RequestContext will automatically include the TEMPLATE_CONTEXT_PROCESSORS, which in my case will include django.contrib.auth.context_processors.auth, which will pass along the user information to the every template.
So in other words, I just need to change the code above to this
def order_all( request ) :
orders = Order.objects.all()
return render_to_response( 'doors/order/list.html', context_instance = RequestContext( request, { 'orders' : orders } ) )
Don't forget to import RequestContext too
from django.template import RequestContext
It also turns out I don't need to explicity include django.contrib.auth.context_processors.auth (or write my custom doors.processor_file_name.user) in the TEMPLATE_CONTEXT_PROCESSORS because django.contrib.auth.context_processors.auth is included by default
I realise this is an old question, but for anyone else who runs into this problem, you could use "render", instead of "render_to_response":
def order_all(request):
orders = Order.objects.all()
return render(request, 'doors/order/list.html', { 'orders': order })
This also negates the need to import RequestContext. According to the django docs, "render" is the same as "render_to_response", but has a context instance argument that forces the use of RequestContext.
I call a template like this from my view:
return render_to_response('mytemplate.html', context_instance=RequestContext(request))
I'm trying to access the hostname of my current server (in this case, localhost), but it just prints blank when I place {{request.META.SERVER_NAME}} in the template.
In my settings.py file, I don't have any TEMPLATE_CONTEXT_PROCESSORS defined. I'm not sure if I need to specify anything there, or if that could solve the problem.
You have to add the request context processor to have it added to the template context automatically. Or you could explicitly add the request to the context dictionary render_to_response('foo', {'request': request})
https://docs.djangoproject.com/en/dev/ref/templates/api/#django-core-context-processors-request
Note that if you add the request context processor, you should remember to add the defaults as well.
I have been trying to use the updated yourlabs subscription example, and the installation has worked fine except that
Each of the views in the subscription app returns the request variable in the render to template.
this request context variable is not received in the template and as a result I am getting the following error
Caught VariableDoesNotExist while rendering: Failed lookup for key [request] in u
Since this is being returned in every view I can't solve this problem by making some tweaks in a particular template
This is happening because request isn't in your template's context and the template is using some template code that expected it to be there. That code (e.g. a custom template tag) should better handle VariableDoesNotExist
In addition, your views probably shouldn't return request in every response explicitly. Let Django handle this for you.
To do this, add the request template context processor that ships with Django to your TEMPLATE_CONTEXT_PROCESSORS:
TEMPLATE_CONTEXT_PROCESSORS = (
...
'django.core.context_processors.request',
...
)
If you are already using this template context processor, ensure that render_to_response is called with context_instance=RequestContext(request) as the final argument (the below example is from the docs):
def some_view(request):
# ...
return render_to_response('my_template.html',
my_data_dictionary,
context_instance=RequestContext(request))
This ensures that all the dicts returned by the template context processors in TEMPLATE_CONTEXT_PROCESSORS are passed to the template.
You could also use the rendershortcut, which will automatically render the template with an instance of Requestcontext.
Another option added in Django 1.3 is the TemplateResponse, which will also use an instance of RequestContext.