Django\u2019s sites system is a generic framework that lets you operate multiple Web sites from the same database and Django project. This is an abstract concept, and it can be tricky to understand, so we\u2019ll start with a couple of scenarios where it would be useful.<\/p>\n
Scenario 1: Reusing Data on Multiple Sites<\/strong> – As we explained in earlier chapter, the Django-powered sites LJWorld.com and Lawrence.com are operated by the same news organization: the Lawrence Journal-World newspaper in Lawrence, Kansas. LJWorld.com focuses on news, while Lawrence.com focuses on local entertainment. But sometimes editors want to publish an article on both sites.<\/p>\n The brain-dead way of solving the problem would be to use a separate database for each site and to require site producers to publish the same story twice: once for LJWorld.com and again for Lawrence.com. But that\u2019s inefficient for site producers, and it\u2019s redundant to store multiple copies of the same story in the database. The better solution? Both sites use the same article database, and an article is associated with one or more sites via a many-to-many relationship. The Django sites framework provides the database table to which articles can be related. It\u2019s a hook for associating data with one or more \u201csites.\u201d<\/p>\n Scenario 2: Storing Your Site Name\/Domain in One Place<\/strong> – LJWorld.com and Lawrence.com both have e-mail alert functionality, which lets readers sign up to get notifications when news happens. It\u2019s pretty basic: a reader signs up on a Web form, and he immediately gets an e-mail saying, \u201cThanks for your subscription.\u201d<\/p>\n It would be inefficient and redundant to implement this signup-processing code twice, so the sites use the same code behind the scenes. But the \u201cThank you for your subscription\u201d notice needs to be different for each site. By using Site objects, we can abstract the thank-you notice to use the values of the current site\u2019s name (e.g., ‘LJWorld.com’) and domain (e.g., ‘www.ljworld.com’). The Django sites framework provides a place for you to store the name and domain for each site in your Django project, which means you can reuse those values in a generic way.<\/p>\n How to Use the Sites Framework<\/strong> – The sites framework is more a series of conventions than a framework. The whole thing is based on two simple concepts:<\/p>\n How you use these two concepts is up to you, but Django uses them in a couple of ways automatically via simple conventions. To install the sites application, follow these steps:<\/p>\n The Sites Framework\u2019s Capabilities<\/strong> – The sections that follow describe the various things you can do with the sites framework.<\/p>\n Reusing Data on Multiple Sites<\/strong> – To reuse data on multiple sites, as explained in the first scenario, just create a ManyToManyField to Site in your models, for example:<\/p>\n from django.db import models That\u2019s the infrastructure you need to associate articles with multiple sites in your database. With that in place, you can reuse the same Django view code for multiple sites. Continuing the Article model example, here\u2019s what an article_detail view might look like:<\/p>\n from django.conf import settings This view function is reusable because it checks the article\u2019s site dynamically, according to the value of the SITE_ID setting. For example, say LJWorld.com\u2019s settings file has a SITE_ID set to 1, and Lawrence.com\u2019s settings file has a SITE_ID set to 2. If this view is called when LJWorld.com\u2019s settings file is active, then it will limit the article lookup to articles in which the list of sites includes LJWorld.com.<\/p>\n Associating Content with a Single Site<\/strong> – Similarly, you can associate a model to the Site model in a many-to-one relationship using ForeignKey. For example, if an article is allowed on only a single site, you could use a model like this:<\/p>\n from django.db import models This has the same benefits as described in the last section.<\/p>\n Hooking Into the Current Site from Views – On a lower level, you can use the sites framework in your Django views to do particular things based on the site in which the view is being called, for example:<\/p>\n from django.conf import settings<\/p>\n def my_view(request): Of course, it\u2019s ugly to hard-code the site IDs like that. A slightly cleaner way of accomplishing the same thing is to check the current site\u2019s domain:<\/p>\n from django.conf import settings def my_view(request): The idiom of retrieving the Site object for the value of settings.SITE_ID is quite common, so the Site model\u2019s manager (Site.objects) has a get_current() method. This example is equivalent to the previous one:<\/p>\n from django.contrib.sites.models import Site Note – In this final example, you don\u2019t have to import django.conf.settings.<\/p>\n Getting the Current Domain for Display<\/strong> – For a DRY (Don\u2019t Repeat Yourself) approach to storing your site\u2019s name and domain name, as explained in \u201cScenario 2: Storing Your Site Name\/Domain in One Place,\u201d just reference the name and domain of the current Site object. For example:<\/p>\n from django.contrib.sites.models import Site def register_for_newsletter(request): An even more flexible (but more heavyweight) way of doing this would be to use Django\u2019s template system. Assuming Lawrence.com and LJWorld.com have different template directories (TEMPLATE_DIRS), you could simply delegate to the template system like so:<\/p>\n from django.core.mail import send_mail def register_for_newsletter(request): In this case, you have to create subject.txt and message.txt templates in both the LJWorld.com and Lawrence.com template directories. As mentioned previously, that gives you more flexibility, but it\u2019s also more complex. It\u2019s a good idea to exploit the Site objects as much as possible to remove unneeded complexity and redundancy.<\/p>\n Getting the Current Domain for Full URLs<\/strong> – Django\u2019s get_absolute_url() convention is nice for getting your objects\u2019 URLs without the domain name, but in some cases you might want to display the full URL \u2014 with http:\/\/ and the domain and everything \u2014 for an object. To do this, you can use the sites framework. Here\u2019s a simple example:<\/p>\n >>> from django.contrib.sites.models import Site CurrentSiteManager<\/strong> – If Site“s play a key role in your application, consider using the helpful “CurrentSiteManager in your model(s). It\u2019s a model manager that automatically filters its queries to include only objects associated with the current Site. Use CurrentSiteManager by adding it to your model explicitly. For example:<\/p>\n from django.db import models class Photo(models.Model): With this model, Photo.objects.all() will return all Photo objects in the database, but Photo.on_site.all() will return only the Photo objects associated with the current site, according to the SITE_ID setting. In other words, these two statements are equivalent:<\/p>\n Photo.objects.filter(site=settings.SITE_ID) How did CurrentSiteManager know which field of Photo was the Site? It defaults to looking for a field called site. If your model has a ForeignKey or ManyToManyField called something other than site, you need to explicitly pass that as the parameter to CurrentSiteManager. The following model, which has a field called publish_on, demonstrates this:<\/p>\n from django.db import models class Photo(models.Model): If you attempt to use CurrentSiteManager and pass a field name that doesn\u2019t exist, Django will raise a ValueError.<\/p>\n Note – You\u2019ll probably want to keep a normal (non-site-specific) Manager on your model, even if you use CurrentSiteManager. As explained in Appendix B, if you define a manager manually, then Django won\u2019t create the automatic objects = models.Manager() manager for you. How Django Uses the Sites Framework<\/strong> – Although it\u2019s not required that you use the sites framework, it\u2019s strongly encouraged, because Django takes advantage of it in a few places. Even if your Django installation is powering only a single site, you should take a few seconds to create the site object with your domain and name, and point to its ID in your SITE_ID setting. Here\u2019s how Django uses the sites framework:<\/p>\n\n
\n
\nfrom django.contrib.sites.models import Site
\nclass Article(models.Model):
\nheadline = models.CharField(maxlength=200)
\n# …
\nsites = models.ManyToManyField(Site)<\/p>\n
\ndef article_detail(request, article_id):
\ntry:
\na = Article.objects.get(id=article_id, sites__id=settings.SITE_ID)
\nexcept Article.DoesNotExist:
\nraise Http404
\n# …<\/p>\n
\nfrom django.contrib.sites.models import Site
\nclass Article(models.Model):
\nheadline = models.CharField(maxlength=200)
\n# …
\nsite = models.ForeignKey(Site)<\/p>\n
\nif settings.SITE_ID == 3:
\n# Do something.
\nelse:
\n# Do something else.<\/p>\n
\nfrom django.contrib.sites.models import Site<\/p>\n
\ncurrent_site = Site.objects.get(id=settings.SITE_ID)
\nif current_site.domain == ‘foo.com’:
\n# Do something
\nelse:
\n# Do something else.<\/p>\n
\ndef my_view(request):
\ncurrent_site = Site.objects.get_current()
\nif current_site.domain == ‘foo.com’:
\n# Do something
\nelse:
\n# Do something else.<\/p>\n
\nfrom django.core.mail import send_mail<\/p>\n
\n# Check form values, etc., and subscribe the user.
\n# …
\ncurrent_site = Site.objects.get_current()
\nsend_mail(‘Thanks for subscribing to %s alerts’ % current_site.name,
\n‘Thanks for your subscription. We appreciate it.\\n\\n-The %s team.’ % current_site.name,
\n‘editor@%s’ % current_site.domain,
\n[user_email])
\n# …
\nContinuing our ongoing example of LJWorld.com and Lawrence.com, on Lawrence.com this e-mail has the subject line \u201cThanks for subscribing to lawrence.com alerts.\u201d On LJWorld.com, the e-mail has the subject line \u201cThanks for subscribing to LJWorld.com alerts.\u201d This same site-specific behavior is applied to the e-mails\u2019 message body.<\/p>\n
\nfrom django.template import loader, Context<\/p>\n
\n# Check form values, etc., and subscribe the user.
\n# …
\nsubject = loader.get_template(‘alerts\/subject.txt’).render(Context({}))
\nmessage = loader.get_template(‘alerts\/message.txt’).render(Context({}))
\nsend_mail(subject, message, ‘do-not-reply@example.com’, [user_email])
\n# …<\/p>\n
\n>>> obj = MyModel.objects.get(id=3)
\n>>> obj.get_absolute_url()
\n‘\/mymodel\/objects\/3\/’
\n>>> Site.objects.get_current().domain
\n‘example.com’
\n>>> ‘http:\/\/%s%s’ % (Site.objects.get_current().domain, obj.get_absolute_url())
\n‘http:\/\/example.com\/mymodel\/objects\/3\/’<\/p>\n
\nfrom django.contrib.sites.models import Site
\nfrom django.contrib.sites.managers import CurrentSiteManager<\/p>\n
\nphoto = models.FileField(upload_to=’\/home\/photos’)
\nphotographer_name = models.CharField(maxlength=100)
\npub_date = models.DateField()
\nsite = models.ForeignKey(Site)
\nobjects = models.Manager()
\non_site = CurrentSiteManager()<\/p>\n
\nPhoto.on_site.all()<\/p>\n
\nfrom django.contrib.sites.models import Site
\nfrom django.contrib.sites.managers import CurrentSiteManager<\/p>\n
\nphoto = models.FileField(upload_to=’\/home\/photos’)
\nphotographer_name = models.CharField(maxlength=100)
\npub_date = models.DateField()
\npublish_on = models.ForeignKey(Site)
\nobjects = models.Manager()
\non_site = CurrentSiteManager(‘publish_on’)<\/p>\n
\nAlso, certain parts of Django \u2014 namely, the Django admin site and generic views \u2014 use whichever manager is defined first in the model, so if you want your admin site to have access to all objects (not just site-specific ones), put objects = models.Manager() in your model, before you define CurrentSiteManager.<\/p>\n\n