Middleware for contrib.sites to get the site matching the current host name

SetSiteFromHost? middleware

We don't ever change settings so I'm not sure this is an accepted way to handle this problem.

A more explicit way to handle this may be to have another helper function on SiteManager. Something like:

    def get_current_from_request(self, request):
        from django.conf import settings
        try:
            return self.get(domain=request.META.get('HTTP_HOST'))
        except Site.DoesNotExist:
            return self.get(pk=settings.SITE_ID)

...which isn't as transparent (and doesn't affect CurrentSiteManager) but it doesn't mess with settings.

Replying to SmileyChris:

We don't ever change settings so I'm not sure this is an accepted way to handle this problem.

Is there any specific reason for this policy? Is it spelled out explicitly anywhere? I have to admit, this is the first time I've heard it put that way, and I wouldn't know where to search for anything like that in the documentation. I'd appreciate a link if you have one...

I realize that settings shouldn't be modified lightly, but disallowing all modifications seems too strict. Also, if that were the case, why not make them read only properties on import into django.conf? Regardless, IMHO, SetRemoteAddrFromForwardedFor munges request.META and to me that seems it should be more sacrosanct (data from the request environment/http server) from middleware than settings...

Note: I'm not suggesting this middleware should be installed by default, only that it be provided as a possible helpful tool, with perhaps a warning that it affects settings.SITE_ID.

A more explicit way to handle this may be to have another helper function on SiteManager. Something like: {{{ #!python def get_current_from_request(self, request): from django.conf import settings try: return self.get(domain=request.META.get('HTTP_HOST')) except Site.DoesNotExist?: return self.get(pk=settings.SITE_ID) }}} ...which isn't as transparent (and doesn't affect CurrentSiteManager) but it doesn't mess with settings.

I had and was unsatisfied with several similar solutions to that in the past few months. The above solution just doesn't feel Pythonic-enough to me. Why should a Manager need to know anything about Request? Not to mention that the above solution can't be used with standard generic views; you have to wrap them in a special view to build your QuerySet? from the request context, which isn't very DRY having to wrap every single view you call in some view wrapper. When that is the case it is usually a sign to start looking to middleware (or context processors) to perform that task, and hence the decision that I came to that a middleware would be the preferred approach.

Replying to Max Battcher <me@worldmaker.net>:

Replying to SmileyChris:

We don't ever change settings so I'm not sure this is an accepted way to handle this problem.

Is there any specific reason for this policy? Is it spelled out explicitly anywhere? I have to admit, this is the first time I've heard it put that way, and I wouldn't know where to search for anything like that in the documentation. I'd appreciate a link if you have one...

http://www.djangoproject.com/documentation/settings/#altering-settings-at-runtime

Replying to SmileyChris:

http://www.djangoproject.com/documentation/settings/#altering-settings-at-runtime

Thanks.

I still think that this is enough of an edge case to warrant bending the advice there. It does say "should not" rather than "must not". I would assume this process_request middleware is a fine exception, particularly for a setting that is used by a contrib app, rather than a core setting.

Well we've entered the design decision stage, take the discussion to the developers group.

The ticket system is a really bad place to talk about hypothetical features. Please start a thread on django-developers about this, as Chris mentions in the previous comment.

I'm going to close this as invalid for now, becuase although the problem itself is perfectly valid, you are proposing a particular solution that has a few problems and can probably be solved in other ways. Let's talk about the problem and possible solutions on the mailing list and then.

Please, do not let this middleware lie forgotten somewhere, i think it should be added to the django code

djangosnippets.org is a good place for stuff like this.

I'm reopening because my patch is a valid solution without the problems of changing settings.

Malcom's note to take this to the mailing list still applies.