id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
15089	contrib.sites and multitenancy	legutierr	Florian Apolloner	"With reference to [http://groups.google.com/group/django-developers/browse_thread/thread/e23c3bf69efab94a/01bb76f20e8d25ef?lnk=gst&q=Sites#01bb76f20e8d25ef this thread]:

Recent changes to django trunk made in [13980] create a new site-retrieval function, `get_current_site()`, which supplants `Site.objects.get_current()`.  However, in spite of the fact that `get_current_site()` takes a request object as an argument, that request object is not being used to retrieve the current site; only the SITE_ID setting is used.  Furthermore, there is a need to allow users to register their own site-retrieval functions, should they desire different functionality .

In this change, however, backwards compatibility must be maintained:

 * if the SITE_ID setting is implemented, then that SITE_ID must be used to retrieve the site record in all cases where contrib.sites is installed.
 * when contrib.sites is not installed, a !RequestSite object should be returned

Specifically, the modification should contain the following elements:

 * add a deprication warning to `Site.objects.get_current_site()`
 * add a method `get_site_for_request()` to Site.objects; this method will inspect the request, using `request.get_host()`, and will then return the site object matching the request.
 * add a method `get_site_for_id()` to Site.objects, which method can be used by `get_current_site()` in the case of SITE_ID being populated
 * modify get_current_site() to handle four cases:
  1. If SITE_CALLBACK (a new setting) is defined, return the result of passing the request into that callable
  2. Else if contrib.sites is not installed, return a !RequestSite
  3. Else if SITE_ID is defined, use `Site.objects.get_site_for_id()` to get the site conforming to SITE_ID
  4. Otherwise, use `Site.objects.get_site_for_request()` to retrieve the site that conforms to the request.
 * add new tests to sites.tests
 * modify the contrib.sites documentation to reflect the new approach and the new setting, SITE_CALLBACK

In addition, I would like to suggest two additional changes that are not documented in the above-referenced django-developers group thread:

 1. Move the `get_current_site()` method out of the models.py file, and into `__init__.py`.  The thinking behind this is that referencing settings inside a models.py file has a bit of a code smell, and that `get_current_site()`, now being the key control point of the library, should exist at a dependency level above the other modules.
 2. Add an additional keyword argument to get_current_site(), specifically `default_to_request_site`, with default value `False`.  In the event that `default_to_request_site` is false, an error would be raised if Sites is not installed.  The thinking behind this change is that third-party apps, the primary potential users of multitenancy implemented by contrib.sites, will most likely link their models to the Site object via a ForeignKey.  As a result, !RequestSite objects will produce errors if they are used, and additional logic will have to be implemented to special-case the handling of !RequestSite objects in such a situation.

These changes, if pursued, would also require modifications in the other contrib apps that use !RequestSite."	New feature	closed	contrib.sites		Normal	fixed		django@… James Lecker Jr Jari Pennanen linovia NicoEchaniz dcwatson@… hvdklauw@… tgecho fernando.sanchez@… florian+django@… krzysiumed@… tom@… net147 charette.s@… w2lkm2n@… simonkagwe riccardo.magliocchetti@… Giacomo Graziosi	Accepted	1	0	0	0	0	0