  * In the :mod:`flatpages framework <django.contrib.flatpages>`, each
    flatpage is associated with a particular site. When a flatpage is created,
    you specify its :class:`~django.contrib.sites.models.Site`, and the
    :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`
    checks the current :setting:`SITE_ID` in retrieving flatpages to display.
  
  * In the :mod:`syndication framework <django.contrib.syndication>`, the
    templates for ``title`` and ``description`` automatically have access to a
    variable ``{{ site }}``, which is the
    :class:`~django.contrib.sites.models.Site` object representing the current
 
</s> remove   :class:`~django.contrib.sites.models.Site` is set to the current
  :setting:`SITE_ID`, and when comments are listed via the appropriate
  template tag, only the comments for the current site are displayed.
 </s> add   :class:`~django.contrib.sites.models.Site` is set to the current site,
  and when comments are listed via the appropriate template tag, only the
  comments for the current site are displayed. </s> remove   for a redirect, it takes into account the current :setting:`SITE_ID`.
 </s> add   for a redirect, it takes into account the current site. </s> remove The idiom of retrieving the :class:`~django.contrib.sites.models.Site` object
for the value of :setting:`settings.SITE_ID <SITE_ID>` is quite common, so
the :class:`~django.contrib.sites.models.Site` model's manager has a
``get_current()`` method. This example is equivalent to the previous one::
 </s> add This has also the advantage of checking if the sites framework is installed, and
return a :class:`RequestSite` instance if it is not.

If you don't have access to the request object, you can use the
``get_current()`` method of the :class:`~django.contrib.sites.models.Site`
model's manager. You should then ensure that your settings file does contain
the :setting:`SITE_ID` setting. This example is equivalent to the previous one:: </s> remove For code which relies on getting the current domain but cannot be certain
that the sites framework will be installed for any given project, there is a
utility function :func:`~django.contrib.sites.models.get_current_site` that
takes a request object as an argument and returns either a Site instance (if
the sites framework is installed) or a RequestSite instance (if it is not).
This allows loose coupling with the sites framework and provides a usable
fallback for cases where it is not installed.

.. function:: get_current_site(request)

    Checks if contrib.sites is installed and returns either the current
    :class:`~django.contrib.sites.models.Site` object or a
    :class:`~django.contrib.sites.models.RequestSite` object based on
    the request.

 </s> add  </s> remove       from django.conf import settings
 </s> add       from django.contrib.sites.models import get_current_site
  checks the current site in retrieving flatpages to display.
  * In the :mod:`flatpages framework <django.contrib.flatpages>`, each
    flatpage is associated with a particular site. When a flatpage is created,
    you specify its :class:`~django.contrib.sites.models.Site`, and the
    :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware`
  checks the current site in retrieving flatpages to display.
  
  * In the :mod:`syndication framework <django.contrib.syndication>`, the
    templates for ``title`` and ``description`` automatically have access to a
    variable ``{{ site }}``, which is the
    :class:`~django.contrib.sites.models.Site` object representing the current
keep keep keep keep replace keep keep keep keep keep
 Made more extensive use of get_current_site

Refs #15089 
docs/ref/contrib/sites.txt