#17005 closed New feature (fixed)
Add CurrentSiteMiddleware to set the current site on the request
Reported by: | Owned by: | chrismedrela | |
---|---|---|---|
Component: | contrib.sites | Version: | |
Severity: | Normal | Keywords: | |
Cc: | krzysiumed@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I end up doing something like the following all over my code:
from django.contrib.sites.models import Site def my_view(request, template_name="foo.html"): site = Site.objects.get_current() ... return render(request, template_name, locals())
Seems like it would save time (and possibly reduce database requests, depending on where else in the application the Site object is being used) if django.contrib.sites.middleware.SiteMiddleware
was added, which either set request.site
to Site.objects.get_current()
or added site
or current_site
to the RequestContext
I just did a search for "Site.objects.get_current" in one of my web apps and came up with 26 hits. There's really no reason to have to write out that code so many times. It should just be present as a variable somewhere.
Attachments (1)
Change History (16)
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 13 years ago
I'd be happy to be involved with the coding of it.
It's similar to the static and media context processors."
So do you think it should be made available via a context processor, or as middleware?
comment:2 by , 13 years ago
I'd be happy to be involved with the coding of it.
It's similar to the static and media context processors."
So do you think it should be made available via a context processor, or as middleware?
comment:3 by , 13 years ago
A middleware is more appropriate — I expect the current site object to be used in the view rather than in the template.
The comparison with the static and media context processors was just about the triviality of the code.
comment:4 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 13 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:6 by , 13 years ago
Status: | new → assigned |
---|
by , 13 years ago
Attachment: | 17005.diff added |
---|
comment:7 by , 13 years ago
I'd written a patch. It contains docs and tests (I believe they are not necessary, because the middleware is very simple). Sorry for my poor English in docs.
comment:8 by , 13 years ago
Has patch: | set |
---|
comment:9 by , 13 years ago
Cc: | added |
---|
comment:10 by , 12 years ago
#13559 is about adding a context processor for the same purpose in templates.
comment:11 by , 11 years ago
Owner: | changed from | to
---|
I've updated the patch: https://github.com/django/django/pull/1939. BTW, krzysiumed is my old nick.
comment:12 by , 11 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
The code looks good to me. Can someone review the docs?
comment:13 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:14 by , 11 years ago
Summary: | Adding django.contrib.site.middleware ? → Add CurrentSiteMiddleware to set the current site on the request |
---|
I think the cleanest solution is to set
request.site = Site.objects.get_current()
. I wouldn't useget_current_site()
because this middleware doesn't make sense when thesites
app isn't enabled. The current site is cached, so the performance impact is negligible.This middleware will be trivial, but it could be useful, and I don't see any reason not to include it in Django. It's similar to the
static
andmedia
context processors.