# Documentation Django 6.0.7

# L’infrastructure des « sites »

Django est livré avec un système facultatif de « sites ». C’est un point d’extension pour associer des objets et des fonctionnalités à certains sites web, et c’est un lieu de regroupement pour les noms de domaine et les noms « explicites » de vos sites Django.

Utilisez-le si une seule installation de Django est utilisée pour plus d’un site Web et que vous avez besoin de différencier ces sites sur certains points.

L’infrastructure de sites est basée principalement sur ce modèle :

class models.Site

  Un modèle pour le stockage des attributs `domain` et `name` d’un site web.

  domain

    Le nom de domaine pleinement qualifié associé au site web. Par exemple, `www.example.com`.

  name

    Un nom lisible « explicite » pour le site web.

Le réglage `SITE_ID` indique l’identifiant de base de données de l’objet `Site` associé à ce fichier de réglages particulier. Si ce réglage est absent, la fonction `get_current_site()` essaie d’obtenir le site actuel en comparant le `domain` au nom d’hôte provenant de la méthode `request.get_host()`.

La manière de l’utiliser est à votre convenance, mais Django l’utilise automatiquement dans un certain nombre de situations à l’aide de quelques conventions.

## Exemple d’utilisation

Pourquoi auriez-vous besoin du système de sites ? Des exemples offrent la meilleure des explications.

### Association de contenu à plusieurs sites différents

Les sites LJWorld.com et Lawrence.com étaient exploités par la même agence de presse – le journal Lawrence Journal-World à Lawrence, Kansas. LJWorld.com se concentrait sur l’actualité, tandis que Lawrence.com mettait l’accent sur le divertissement local. Mais parfois, les éditeurs veulaient publier un article sur les deux sites.

La manière naïve de résoudre ce problème serait d’exiger de chaque rédacteur de site de publier la même histoire deux fois : une fois pour LJWorld.com et une autre fois pour Lawrence.com. Mais c’est vraiment inefficace pour les producteurs des sites, sans compter qu’il est redondant de stocker plusieurs copies de la même histoire dans la base de données.

Une meilleure solution évite la duplication de contenu : les deux sites utilisent le même article dans la base de données et chaque article est associé à un ou plusieurs sites. Dans la terminologie des modèles Django, ceci est représenté par un champ `ManyToManyField` dans le modèle `Article`:

    from django.contrib.sites.models import Site
    from django.db import models

    class Article(models.Model):
        headline = models.CharField(max_length=200)
        # ...
        sites = models.ManyToManyField(Site)

Ceci effectue plusieurs choses de manière élégante :

- Les producteurs de sites peuvent éditer tous les contenus, pour les deux sites, dans une même interface (l’administration de Django).

- La même histoire n’a pas besoin d’être publiée deux fois dans la base de données ; elle constitue un seul enregistrement de base de données.

- Les développeurs des sites peuvent utiliser le même code de vue Django pour les deux sites. Le code de vue qui affiche une histoire donnée vérifie que l’histoire demandée se trouve bien sur le site actuel. Cela donne quelque chose comme :

      from django.contrib.sites.shortcuts import get_current_site

      def article_detail(request, article_id):
          try:
              a = Article.objects.get(id=article_id, sites__id=get_current_site(request).id)
          except Article.DoesNotExist:
              raise Http404("Article does not exist on this site")
          # ...

### Association de contenu à un seul site

De même, vous pouvez associer un modèle au modèle `Site` par une relation plusieurs-à-un, avec une clé `ForeignKey`.

Par exemple, si un article ne doit apparaître que sur un seul site, vous pourriez utiliser un modèle tel que celui-ci :

    from django.contrib.sites.models import Site
    from django.db import models

    class Article(models.Model):
        headline = models.CharField(max_length=200)
        # ...
        site = models.ForeignKey(Site, on_delete=models.CASCADE)

Les bénéfices sont les mêmes que ceux de la section précédente.

### Interception du site actuel dans les vues

Vous pouvez exploiter l’infrastructure des sites dans les vues Django pour effectuer des opérations particulières sur la base du site pour lequel la vue est appelée. Par exemple :

    from django.conf import settings

    def my_view(request):
        if settings.SITE_ID == 3:
            # Do something.
            pass
        else:
            # Do something else.
            pass

Il est fragile de figer des identifiants de site de cette manière car ils peuvent changer. La façon propre de faire la même chose est de se baser sur le nom de domaine du site actuel :

    from django.contrib.sites.shortcuts import get_current_site

    def my_view(request):
        current_site = get_current_site(request)
        if current_site.domain == "foo.com":
            # Do something
            pass
        else:
            # Do something else.
            pass

Cela présente aussi l’avantage de vérifier si l’infrastructure des sites est installée et de renvoyer une instance `RequestSite` quand ce n’est pas le cas.

Si vous n’avez pas accès à l’objet de requête, vous pouvez utiliser la méthode `get_current()` du gestionnaire du modèle `Site`. Vous devez ensuite vous assurer que le fichier des réglages contient bien le réglage `SITE_ID`. Cet exemple est équivalent au précédent :

    from django.contrib.sites.models import Site

    def my_function_without_request():
        current_site = Site.objects.get_current()
        if current_site.domain == "foo.com":
            # Do something
            pass
        else:
            # Do something else.
            pass

### Accès au domaine actuel pour l’affichage

LJWorld.com et Lawrence.com ont tous deux une fonction d’alerte par courriel, ce qui permet aux lecteurs de s’inscrire pour recevoir des notifications lorsque des actualités apparaissent. C’est assez simple : un lecteur s’inscrit avec un formulaire web et reçoit immédiatement un courriel disant « Merci pour votre inscription ».

Il serait inefficace et redondant d’implémenter deux fois le code de ce processus d’inscription, ce qui fait que les sites utilisent le même code en arrière-plan. Mais le message « merci pour votre inscription » doit être différent pour chaque site. En utilisant des objets `Site`, il est possible d’abstraire le message « merci » afin d’utiliser les valeurs `name` et `domain` correspondant au site actuel.

Voici un exemple qui pourrait constituer le code de gestion du formulaire dans la vue :

    from django.contrib.sites.shortcuts import get_current_site
    from django.core.mail import send_mail

    def register_for_newsletter(request):
        # Check form values, etc., and subscribe the user.
        # ...

        current_site = get_current_site(request)
        send_mail(
            "Thanks for subscribing to %s alerts" % current_site.name,
            "Thanks for your subscription. We appreciate it.\n\n-The %s team."
            % (current_site.name,),
            "editor@%s" % current_site.domain,
            [user.email],
        )

        # ...

Pour Lawrence.com, l’objet du courriel correspond à « Thanks for subscribing to lawrence.com alerts. ». Pour LJWorld.com, l’objet du courriel correspond à « Thanks for subscribing to LJWorld.com alerts. ». De même pour les corps des courriels.

Notez qu’une manière encore plus souple (mais plus lourde) de faire cela serait d’utiliser le système des gabarits de Django. En supposant que les sites Lawrence.com et LJWorld.com ont des répertoires de gabarits différents (`DIRS`), il suffirait de confier la personnalisation des messages au système des gabarits, comme ceci :

    from django.core.mail import send_mail
    from django.template import loader

    def register_for_newsletter(request):
        # Check form values, etc., and subscribe the user.
        # ...

        subject = loader.get_template("alerts/subject.txt").render({})
        message = loader.get_template("alerts/message.txt").render({})
        send_mail(subject, message, "editor@ljworld.com", [user.email])

        # ...

Dans ce cas, il faudrait encore créer les fichiers de gabarit `subject.txt` et `message.txt` dans les deux répertoires de gabarits LJWorld.com et Lawrence.com. Cela apporte un maximum de flexibilité, mais est aussi plus complexe.

Il est recommandé d’exploiter au maximum les objets `Site` afin de supprimer de la complexité inutile et de la redondance.

### Accès au domaine actuel pour des URL complètes

La convention `get_absolute_url()` de Django est pratique pour obtenir les URL des objets sans le nom de domaine, mais dans certains cas, il peut être souhaitable d’afficher une URL complète d’un objet, avec `https://` et le domaine. Pour cela, vous pouvez utiliser l’infrastructure des sites. Un exemple :

    >>> from django.contrib.sites.models import Site
    >>> obj = MyModel.objects.get(id=3)
    >>> obj.get_absolute_url()
    '/mymodel/objects/3/'
    >>> Site.objects.get_current().domain
    'example.com'
    >>> "https://%s%s" % (Site.objects.get_current().domain, obj.get_absolute_url())
    'https://example.com/mymodel/objects/3/'

## Activation de l’infrastructure des sites

Pour activer l’infrastructure des sites, suivez ces étapes :

1. Ajoutez `'django.contrib.sites'` à votre réglage `INSTALLED_APPS`.

2. Définissez un réglage `SITE_ID`:

       SITE_ID = 1

3. Exécutez `migrate`.

`django.contrib.sites` inscrit un gestionnaire de signal `post_migrate` qui crée un site par défaut nommé `example.com` avec le domaine `example.com`. Ce site est aussi créé à la suite de la création de la base de données de test par Django. Pour définir le nom et le domaine corrects pour votre projet, vous pouvez utiliser une migration de données.

Afin de servir différents sites en production, il s’agit de créer un fichier de réglages différent pour chacun avec un `SITE_ID` spécifique (en important peut-être d’un fichier de réglages commun pour éviter de dupliquer les réglages partagés), puis de définir la valeur `DJANGO_SETTINGS_MODULE` appropriée pour chaque site.

## Mise en cache de l’objet `Site` actuel

Comme le site actuel est stocké en base de données, chaque appel à `Site.objects.get_current()` pourrait aboutir à une requête de base de données. Mais Django est un peu plus malin que cela : lors de la première requête, le site actuel est mis en cache et tout appel subséquent à cette méthode renvoie les données en cache plutôt que de recourir à la base de données.

Si pour une raison quelconque vous souhaitez forcer une nouvelle requête à la base de données, vous pouvez demander à Django d’effacer le contenu en cache en utilisant `Site.objects.clear_cache()`:

    # First call; current site fetched from database.
    current_site = Site.objects.get_current()
    # ...

    # Second call; current site fetched from cache.
    current_site = Site.objects.get_current()
    # ...

    # Force a database query for the third call.
    Site.objects.clear_cache()
    current_site = Site.objects.get_current()

## Le gestionnaire `CurrentSiteManager`

class managers.CurrentSiteManager

Si `Site` joue un rôle majeur dans votre application, considérer l’utilisation du gestionnaire `CurrentSiteManager` dans vos modèles. Il s’agit d’un gestionnaire de modèle qui filtre automatiquement ses requêtes pour n’inclure que les objets associés au `Site` actuel.

`SITE_ID` obligatoire

`CurrentSiteManager` n’est utilisable qu’à la condition que le réglage `SITE_ID` soit défini dans vos réglages.

Utilisez `CurrentSiteManager` en l’ajoutant explicitement à vos modèles. Par exemple :

    from django.contrib.sites.models import Site
    from django.contrib.sites.managers import CurrentSiteManager
    from django.db import models

    class Photo(models.Model):
        photo = models.FileField(upload_to="photos")
        photographer_name = models.CharField(max_length=100)
        pub_date = models.DateField()
        site = models.ForeignKey(Site, on_delete=models.CASCADE)
        objects = models.Manager()
        on_site = CurrentSiteManager()

Avec ce modèle, `Photo.objects.all()` renvoie tous les objets `Photo` de la base de données, mais `Photo.on_site.all()` ne renvoie que les objets `Photo` associés au site actuel, en fonction du réglage `SITE_ID`.

Autrement dit, ces deux instructions sont équivalentes :

    Photo.objects.filter(site=settings.SITE_ID)
    Photo.on_site.all()

How did `CurrentSiteManager` know which field of `Photo` was the `Site`? By default, `CurrentSiteManager` looks for either a `ForeignKey` called `site` or a `ManyToManyField` called `sites` to filter on. If you use a field named something other than `site` or `sites` to identify which `Site` objects your object is related to, then you need to explicitly pass the custom field name as a parameter to `CurrentSiteManager` on your model. The following model, which has a field called `publish_on`, demonstrates this:

    from django.contrib.sites.models import Site
    from django.contrib.sites.managers import CurrentSiteManager
    from django.db import models

    class Photo(models.Model):
        photo = models.FileField(upload_to="photos")
        photographer_name = models.CharField(max_length=100)
        pub_date = models.DateField()
        publish_on = models.ForeignKey(Site, on_delete=models.CASCADE)
        objects = models.Manager()
        on_site = CurrentSiteManager("publish_on")

Si vous essayez d’utiliser `CurrentSiteManager` et que vous lui indiquez un nom de champ qui n’existe pas, Django génère une exception `ValueError`.

Finalement, notez qu’il est recommandé de conserver un `Manager` normal (non lié aux sites) pour vos modèles, même si vous utilisez `CurrentSiteManager`. Comme expliqué dans la documentation des gestionnaires, si vous définissez manuellement un gestionnaire, Django ne crée pas le gestionnaire automatique `objects = models.Manager()` à votre place. Sachez également que certaines parties de Django, particulièrement le site d’administration et les vues génériques, utilisent le premier gestionnaire défini pour un modèle, donc si vous voulez que le site d’administration puisse accéder à tous les objets (et pas seulement ceux d’un site particulier), ajoutez `objects = models.Manager()` dans vos modèles avant de définir `CurrentSiteManager`.

## Intergiciel de site

Si vous utilisez fréquemment ce motif :

    from django.contrib.sites.models import Site

    def my_view(request):
        site = Site.objects.get_current()
        ...

Pour éviter les répétitions, ajoutez `django.contrib.sites.middleware.CurrentSiteMiddleware` à `MIDDLEWARE`. Cet intergiciel définit l’attribut `site` pour chaque objet de requête, ce qui permet d’appeler `request.site` pour accéder au site actuel.

## Utilisation de l’infrastructure des sites par Django

Même s’il n’est pas obligatoire d’utiliser l’infrastructure des sites, elle est fortement encouragée car Django en tire profit à plusieurs endroits. Même si votre installation de Django n’est utilisée que par un seul site, prenez les quelques secondes nécessaires à la définition de l’objet site avec les bonnes valeurs `domain` et `name`, puis faites pointer le réglage `SITE_ID` vers l’identifiant de cet objet.

Voici comment Django utilise l’infrastructure des sites :

- Dans l’`application de redirection`, chaque objet de redirection est associé à un site particulier. Lorsque Django recherche une redirection, il prend en compte le site actuel.

- Dans l’`application des pages statiques`, chaque page statique est associée à un site particulier. Lorsqu’une page statique est créée, il faut indiquer le `Site`, et l’intergiciel `FlatpageFallbackMiddleware` vérifie le site actuel lorsqu’il recherche des pages statiques à afficher.

- Dans l’`infrastructure de syndication`, les gabarits pour `title` et `description` ont automatiquement accès à une variable `{{ site }}`, qui est l’objet `Site` représentant le site actuel. De même, le point d’entrée pour fournir les URL des éléments utilisent l’attribut `domain` de l’objet `Site` actuel si vous n’indiquez pas un domaine pleinement qualifié.

- Dans l’`infrastructure d'authentification`, la vue `django.contrib.auth.views.LoginView` passe le nom de l’objet `Site` actuel au gabarit sous forme de `{{ site_name }}`.

- La vue de raccourci (`django.contrib.contenttypes.views.shortcut`) utilise le domaine de l’objet `Site` actuel lors de la construction de l’URL d’un objet.

- Dans le site d’administration, le lien « voir sur le site » utilise l’objet `Site` actuel pour connaître le domaine du site vers lequel la redirection s’opère.

## Les objets `RequestSite`

Certaines applications django.contrib s’appuient sur l’infrastructure des sites mais sont conçues pour ne pas dépendre de l’installation de l’application sites dans la base de données. (Certaines personnes ne souhaitent pas ou n’ont simplement pas la possibilité d’installer la table de base de données supplémentaire que demande l’infrastructure des sites.) Pour ces situations, l’application fournit une classe `django.contrib.sites.requests.RequestSite` qui peut être utilisée comme solution de repli lorsque le complément en base de données de l’infrastructure des sites n’est pas disponible.

class requests.RequestSite

  Une classe qui partage l’interface principale de `Site` (c’est-à-dire qu’elle possède les attributs `domain` et `name`), mais qui reçoit ses données à partir d’un objet `HttpRequest` de Django plutôt qu’à partir de la base de données.

  __init__(request)

    Définit les attributs `name` et `domain` selon les valeurs obtenues de `get_host()`.

Un objet `RequestSite` possède une interface similaire à un objet `Site` normal, sauf que sa méthode `__init__()` accepte un objet `HttpRequest`. Il est capable d’en déduire le domaine et le nom en examinant le domaine de la requête. Il possède des méthodes `save()` et `delete()` pour refléter l’interface de `Site`, mais ces méthodes générent l’exception `NotImplementedError`.

## Le raccourci `get_current_site`

Finalement, pour éviter du code redondant, le système fournit une fonction `django.contrib.sites.shortcuts.get_current_site()`.

shortcuts.get_current_site(request)

  Une fonction qui vérifie si `django.contrib.sites` est installé et qui renvoie soit l’objet `Site` en cours, soit un objet `RequestSite` défini à partir de la requête. Il détermine le site actuel sur la base de `request.get_host()` si le réglage `SITE_ID` n’est pas défini.

  `request.get_host()` peut renvoyer à la fois un domaine et un port lorsque l’en-tête `Host` contient un numéro de port explicite, par exemple `example.com:80`. Dans de tels cas, si la recherche échoue parce que l’hôte ne correspond pas à un enregistrement dans la base de données, le port est enlevé et la recherche est relancée uniquement avec la partie du domaine. Ceci ne concerne pas `RequestSite` qui utilise toujours l’hôte non modifié.