[1.5.x] Fixed #19516 - Fixed remaining broken links.

Added -n to sphinx builds to catch issues going forward.

Backport of 9b5f64cc6e from master.

16 files changed, 224 insertions, 201 deletions

diff --git a/docs/topics/auth/passwords.txt b/docs/topics/auth/passwords.txt
index e6345aab2e..b19c024a72 100644
--- a/docs/topics/auth/passwords.txt
+++ b/docs/topics/auth/passwords.txt
@@ -184,10 +184,10 @@ Manually managing a user's password
 
     If you'd like to manually authenticate a user by comparing a plain-text
     password to the hashed password in the database, use the convenience
-    function :func:`django.contrib.auth.hashers.check_password`. It takes two
-    arguments: the plain-text password to check, and the full value of a
-    user's ``password`` field in the database to check against, and returns
-    ``True`` if they match, ``False`` otherwise.
+    function :func:`check_password`. It takes two arguments: the plain-text
+    password to check, and the full value of a user's ``password`` field in the
+    database to check against, and returns ``True`` if they match, ``False``
+    otherwise.
 
 .. function:: make_password(password[, salt, hashers])
 
@@ -202,11 +202,11 @@ Manually managing a user's password
     ``'unsalted_md5'`` (only for backward compatibility) and ``'crypt'``
     if you have the ``crypt`` library installed. If the password argument is
     ``None``, an unusable password is returned (a one that will be never
-    accepted by :func:`django.contrib.auth.hashers.check_password`).
+    accepted by :func:`check_password`).
 
 .. function:: is_password_usable(encoded_password)
 
    .. versionadded:: 1.4
 
    Checks if the given string is a hashed password that has a chance
-   of being verified against :func:`django.contrib.auth.hashers.check_password`.
+   of being verified against :func:`check_password`.
diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt
index 2f95c33dd5..223d9ae9e7 100644
--- a/docs/topics/cache.txt
+++ b/docs/topics/cache.txt
@@ -666,6 +666,8 @@ pickling.)
 Accessing the cache
 -------------------
 
+.. function:: django.core.cache.get_cache(backend, **kwargs)
+
 The cache module, ``django.core.cache``, has a ``cache`` object that's
 automatically created from the ``'default'`` entry in the :setting:`CACHES`
 setting::
@@ -678,7 +680,7 @@ If you have multiple caches defined in :setting:`CACHES`, then you can use
     >>> from django.core.cache import get_cache
     >>> cache = get_cache('alternate')
 
-If the named key does not exist, :exc:`InvalidCacheBackendError` will be raised.
+If the named key does not exist, ``InvalidCacheBackendError`` will be raised.
 
 
 Basic usage
@@ -836,7 +838,7 @@ key version to set or get. For example::
     'hello world!'
 
 The version of a specific key can be incremented and decremented using
-the :func:`incr_version()` and :func:`decr_version()` methods. This
+the ``incr_version()`` and ``decr_version()`` methods. This
 enables specific keys to be bumped to a new version, leaving other
 keys unaffected. Continuing our previous example::
 
@@ -871,7 +873,7 @@ parts), you can provide a custom key function.
 
 The :setting:`KEY_FUNCTION <CACHES-KEY_FUNCTION>` cache setting
 specifies a dotted-path to a function matching the prototype of
-:func:`make_key()` above. If provided, this custom key function will
+``make_key()`` above. If provided, this custom key function will
 be used instead of the default key combining function.
 
 Cache key warnings
diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt
index 10279c0f63..dac45c8843 100644
--- a/docs/topics/class-based-views/generic-display.txt
+++ b/docs/topics/class-based-views/generic-display.txt
@@ -257,9 +257,9 @@ Specifying ``model = Publisher`` is really just shorthand for saying
 ``queryset = Publisher.objects.all()``. However, by using ``queryset``
 to define a filtered list of objects you can be more specific about the
 objects that will be visible in the view (see :doc:`/topics/db/queries`
-for more information about :class:`QuerySet` objects, and see the
-:doc:`class-based views reference </ref/class-based-views/index>` for the
-complete details).
+for more information about :class:`~django.db.models.query.QuerySet` objects,
+and see the :doc:`class-based views reference </ref/class-based-views/index>`
+for the complete details).
 
 To pick a simple example, we might want to order a list of books by
 publication date, with the most recent first::
@@ -312,9 +312,9 @@ what if we wanted to write a view that displayed all the books by some arbitrary
 publisher?
 
 Handily, the ``ListView`` has a
-:meth:`~django.views.generic.detail.ListView.get_queryset` method we can
-override. Previously, it has just been returning the value of the ``queryset``
-attribute, but now we can add more logic.
+:meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset` method we
+can override. Previously, it has just been returning the value of the
+``queryset`` attribute, but now we can add more logic.
 
 The key part to making this work is that when class-based views are called,
 various useful things are stored on ``self``; as well as the request
diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt
index 7d12184705..2f8b8b0711 100644
--- a/docs/topics/class-based-views/generic-editing.txt
+++ b/docs/topics/class-based-views/generic-editing.txt
@@ -7,10 +7,10 @@ Form processing generally has 3 paths:
 * POST with invalid data (typically redisplay form with errors)
 * POST with valid data (process the data and typically redirect)
 
-Implementing this yourself often results in a lot of repeated
-boilerplate code (see :ref:`Using a form in a
-view<using-a-form-in-a-view>`). To help avoid this, Django provides a
-collection of generic class-based views for form processing.
+Implementing this yourself often results in a lot of repeated boilerplate code
+(see :ref:`Using a form in a view<using-a-form-in-a-view>`). To help avoid
+this, Django provides a collection of generic class-based views for form
+processing.
 
 Basic Forms
 -----------
@@ -28,7 +28,7 @@ Given a simple contact form::
             # send email using the self.cleaned_data dictionary
             pass
 
-The view can be constructed using a FormView::
+The view can be constructed using a ``FormView``::
 
     # views.py
     from myapp.forms import ContactForm
@@ -50,42 +50,46 @@ Notes:
 * FormView inherits
   :class:`~django.views.generic.base.TemplateResponseMixin` so
   :attr:`~django.views.generic.base.TemplateResponseMixin.template_name`
-  can be used here
+  can be used here.
 * The default implementation for
-  :meth:`~django.views.generic.edit.FormView.form_valid` simply
-  redirects to the :attr:`success_url`
+  :meth:`~django.views.generic.edit.FormMixin.form_valid` simply
+  redirects to the :attr:`~django.views.generic.edit.FormMixin.success_url`.
 
 Model Forms
 -----------
 
 Generic views really shine when working with models.  These generic
-views will automatically create a :class:`ModelForm`, so long as they
-can work out which model class to use:
+views will automatically create a :class:`~django.forms.ModelForm`, so long as
+they can work out which model class to use:
 
-* If the :attr:`model` attribute is given, that model class will be used
-* If :meth:`get_object()` returns an object, the class of that object
-  will be used
-* If a :attr:`queryset` is given, the model for that queryset will be used
+* If the :attr:`~django.views.generic.edit.ModelFormMixin.model` attribute is
+  given, that model class will be used.
+* If :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
+  returns an object, the class of that object will be used.
+* If a :attr:`~django.views.generic.detail.SingleObjectMixin.queryset` is
+  given, the model for that queryset will be used.
 
-Model form views provide a :meth:`form_valid()` implementation that
-saves the model automatically.  You can override this if you have any
+Model form views provide a
+:meth:`~django.views.generic.edit.ModelFormMixin.form_valid()` implementation
+that saves the model automatically.  You can override this if you have any
 special requirements; see below for examples.
 
-You don't even need to provide a attr:`success_url` for
+You don't even need to provide a ``success_url`` for
 :class:`~django.views.generic.edit.CreateView` or
 :class:`~django.views.generic.edit.UpdateView` - they will use
-:meth:`get_absolute_url()` on the model object if available.
+:meth:`~django.db.models.Model.get_absolute_url()` on the model object if available.
 
-If you want to use a custom :class:`ModelForm` (for instance to add
-extra validation) simply set
+If you want to use a custom :class:`~django.forms.ModelForm` (for instance to
+add extra validation) simply set
 :attr:`~django.views.generic.edit.FormMixin.form_class` on your view.
 
 .. note::
     When specifying a custom form class, you must still specify the model,
-    even though the :attr:`form_class` may be a :class:`ModelForm`.
+    even though the :attr:`~django.views.generic.edit.FormMixin.form_class` may
+    be a :class:`~django.forms.ModelForm`.
 
-First we need to add :meth:`get_absolute_url()` to our :class:`Author`
-class:
+First we need to add :meth:`~django.db.models.Model.get_absolute_url()` to our
+``Author`` class:
 
 .. code-block:: python
 
@@ -137,8 +141,10 @@ Finally, we hook these new views into the URLconf::
 
 .. note::
 
-    These views inherit :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`
-    which uses :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_prefix`
+    These views inherit
+    :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`
+    which uses
+    :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
     to construct the
     :attr:`~django.views.generic.base.TemplateResponseMixin.template_name`
     based on the model.
@@ -149,15 +155,17 @@ Finally, we hook these new views into the URLconf::
     * :class:`DeleteView` uses ``myapp/author_confirm_delete.html``
 
     If you wish to have separate templates for :class:`CreateView` and
-    :class:1UpdateView`, you can set either :attr:`template_name` or
-    :attr:`template_name_suffix` on your view class.
+    :class:`UpdateView`, you can set either
+    :attr:`~django.views.generic.base.TemplateResponseMixin.template_name` or
+    :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
+    on your view class.
 
 Models and request.user
 -----------------------
 
 To track the user that created an object using a :class:`CreateView`,
-you can use a custom :class:`ModelForm` to do this. First, add the
-foreign key relation to the model::
+you can use a custom :class:`~django.forms.ModelForm` to do this. First, add
+the foreign key relation to the model::
 
     # models.py
     from django.contrib.auth import User
@@ -169,7 +177,7 @@ foreign key relation to the model::
 
         # ...
 
-Create a custom :class:`ModelForm` in order to exclude the
+Create a custom :class:`~django.forms.ModelForm` in order to exclude the
 ``created_by`` field and prevent the user from editing it:
 
 .. code-block:: python
@@ -183,8 +191,10 @@ Create a custom :class:`ModelForm` in order to exclude the
             model = Author
             exclude = ('created_by',)
 
-In the view, use the custom :attr:`form_class` and override
-:meth:`form_valid()` to add the user::
+In the view, use the custom
+:attr:`~django.views.generic.edit.FormMixin.form_class` and override
+:meth:`~django.views.generic.edit.ModelFormMixin.form_valid()` to add the
+user::
 
     # views.py
     from django.views.generic.edit import CreateView
@@ -202,7 +212,8 @@ In the view, use the custom :attr:`form_class` and override
 Note that you'll need to :ref:`decorate this
 view<decorating-class-based-views>` using
 :func:`~django.contrib.auth.decorators.login_required`, or
-alternatively handle unauthorised users in the :meth:`form_valid()`.
+alternatively handle unauthorized users in the
+:meth:`~django.views.generic.edit.ModelFormMixin.form_valid()`.
 
 AJAX example
 ------------
diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index 923b877cc5..4941ea9755 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -32,13 +32,14 @@ Two central mixins are provided that help in providing a consistent
 interface to working with templates in class-based views.
 
 :class:`~django.views.generic.base.TemplateResponseMixin`
+
     Every built in view which returns a
     :class:`~django.template.response.TemplateResponse` will call the
     :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
-    method that :class:`TemplateResponseMixin` provides. Most of the time this
+    method that ``TemplateResponseMixin`` provides. Most of the time this
     will be called for you (for instance, it is called by the ``get()`` method
     implemented by both :class:`~django.views.generic.base.TemplateView` and
-    :class:`~django.views.generic.base.DetailView`); similarly, it's unlikely
+    :class:`~django.views.generic.detail.DetailView`); similarly, it's unlikely
     that you'll need to override it, although if you want your response to
     return something not rendered via a Django template then you'll want to do
     it. For an example of this, see the :ref:`JSONResponseMixin example
@@ -59,10 +60,10 @@ interface to working with templates in class-based views.
 
 :class:`~django.views.generic.base.ContextMixin`
     Every built in view which needs context data, such as for rendering a
-    template (including :class:`TemplateResponseMixin` above), should call
+    template (including ``TemplateResponseMixin`` above), should call
     :meth:`~django.views.generic.base.ContextMixin.get_context_data` passing
     any data they want to ensure is in there as keyword arguments.
-    ``get_context_data`` returns a dictionary; in :class:`ContextMixin` it
+    ``get_context_data`` returns a dictionary; in ``ContextMixin`` it
     simply returns its keyword arguments, but it is common to override this to
     add more members to the dictionary.
 
@@ -106,7 +107,7 @@ URLConf, and looks the object up either from the
 :attr:`~django.views.generic.detail.SingleObjectMixin.model` attribute
 on the view, or the
 :attr:`~django.views.generic.detail.SingleObjectMixin.queryset`
-attribute if that's provided). :class:`SingleObjectMixin` also overrides
+attribute if that's provided). ``SingleObjectMixin`` also overrides
 :meth:`~django.views.generic.base.ContextMixin.get_context_data`,
 which is used across all Django's built in class-based views to supply
 context data for template renders.
@@ -115,10 +116,12 @@ To then make a :class:`~django.template.response.TemplateResponse`,
 :class:`DetailView` uses
 :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`,
 which extends :class:`~django.views.generic.base.TemplateResponseMixin`,
-overriding :meth:`get_template_names()` as discussed above. It actually
-provides a fairly sophisticated set of options, but the main one that most
-people are going to use is ``<app_label>/<object_name>_detail.html``. The
-``_detail`` part can be changed by setting
+overriding
+:meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names()`
+as discussed above. It actually provides a fairly sophisticated set of options,
+but the main one that most people are going to use is
+``<app_label>/<object_name>_detail.html``. The ``_detail`` part can be changed
+by setting
 :attr:`~django.views.generic.detail.SingleObjectTemplateResponseMixin.template_name_suffix`
 on a subclass to something else. (For instance, the :doc:`generic edit
 views<generic-editing>` use ``_form`` for create and update views, and
@@ -128,9 +131,10 @@ ListView: working with many Django objects
 ------------------------------------------
 
 Lists of objects follow roughly the same pattern: we need a (possibly
-paginated) list of objects, typically a :class:`QuerySet`, and then we need
-to make a :class:`TemplateResponse` with a suitable template using
-that list of objects.
+paginated) list of objects, typically a
+:class:`~django.db.models.query.QuerySet`, and then we need to make a
+:class:`~django.template.response.TemplateResponse` with a suitable template
+using that list of objects.
 
 To get the objects, :class:`~django.views.generic.list.ListView` uses
 :class:`~django.views.generic.list.MultipleObjectMixin`, which
@@ -138,9 +142,9 @@ provides both
 :meth:`~django.views.generic.list.MultipleObjectMixin.get_queryset`
 and
 :meth:`~django.views.generic.list.MultipleObjectMixin.paginate_queryset`. Unlike
-with :class:`SingleObjectMixin`, there's no need to key off parts of
-the URL to figure out the queryset to work with, so the default just
-uses the
+with :class:`~django.views.generic.detail.SingleObjectMixin`, there's no need
+to key off parts of the URL to figure out the queryset to work with, so the
+default just uses the
 :attr:`~django.views.generic.list.MultipleObjectMixin.queryset` or
 :attr:`~django.views.generic.list.MultipleObjectMixin.model` attribute
 on the view class. A common reason to override
@@ -148,19 +152,19 @@ on the view class. A common reason to override
 here would be to dynamically vary the objects, such as depending on
 the current user or to exclude posts in the future for a blog.
 
-:class:`MultipleObjectMixin` also overrides
+:class:`~django.views.generic.list.MultipleObjectMixin` also overrides
 :meth:`~django.views.generic.base.ContextMixin.get_context_data` to
 include appropriate context variables for pagination (providing
 dummies if pagination is disabled). It relies on ``object_list`` being
 passed in as a keyword argument, which :class:`ListView` arranges for
 it.
 
-To make a :class:`TemplateResponse`, :class:`ListView` then uses
+To make a :class:`~django.template.response.TemplateResponse`,
+:class:`ListView` then uses
 :class:`~django.views.generic.list.MultipleObjectTemplateResponseMixin`;
-as with :class:`SingleObjectTemplateResponseMixin` above, this
-overrides :meth:`get_template_names()` to provide :meth:`a range of
-options
-<~django.views.generic.list.MultipleObjectTempalteResponseMixin>`,
+as with :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`
+above, this overrides ``get_template_names()`` to provide :meth:`a range of
+options <django.views.generic.list.MultipleObjectTemplateResponseMixin>`,
 with the most commonly-used being
 ``<app_label>/<object_name>_list.html``, with the ``_list`` part again
 being taken from the
@@ -197,13 +201,13 @@ the box.
 
     If in doubt, it's often better to back off and base your work on
     :class:`View` or :class:`TemplateView`, perhaps with
-    :class:`SimpleObjectMixin` and
-    :class:`MultipleObjectMixin`. Although you will probably end up
-    writing more code, it is more likely to be clearly understandable
-    to someone else coming to it later, and with fewer interactions to
-    worry about you will save yourself some thinking. (Of course, you
-    can always dip into Django's implementation of the generic class
-    based views for inspiration on how to tackle problems.)
+    :class:`~django.views.generic.detail.SingleObjectMixin` and
+    :class:`~django.views.generic.list.MultipleObjectMixin`. Although you
+    will probably end up writing more code, it is more likely to be clearly
+    understandable to someone else coming to it later, and with fewer
+    interactions to worry about you will save yourself some thinking. (Of
+    course, you can always dip into Django's implementation of the generic
+    class based views for inspiration on how to tackle problems.)
 
 .. _method resolution order: http://www.python.org/download/releases/2.3/mro/
 
@@ -247,9 +251,9 @@ We'll demonstrate this with the publisher modelling we used in the
 In practice you'd probably want to record the interest in a key-value
 store rather than in a relational database, so we've left that bit
 out. The only bit of the view that needs to worry about using
-:class:`SingleObjectMixin` is where we want to look up the author
-we're interested in, which it just does with a simple call to
-``self.get_object()``. Everything else is taken care of for us by the
+:class:`~django.views.generic.detail.SingleObjectMixin` is where we want to
+look up the author we're interested in, which it just does with a simple call
+to ``self.get_object()``. Everything else is taken care of for us by the
 mixin.
 
 We can hook this into our URLs easily enough::
@@ -265,7 +269,8 @@ We can hook this into our URLs easily enough::
 Note the ``pk`` named group, which
 :meth:`~django.views.generic.detail.SingleObjectMixin.get_object` uses
 to look up the ``Author`` instance. You could also use a slug, or
-any of the other features of :class:`SingleObjectMixin`.
+any of the other features of
+:class:`~django.views.generic.detail.SingleObjectMixin`.
 
 Using SingleObjectMixin with ListView
 -------------------------------------
@@ -277,23 +282,24 @@ example, you might want to paginate through all the books by a
 particular publisher.
 
 One way to do this is to combine :class:`ListView` with
-:class:`SingleObjectMixin`, so that the queryset for the paginated
-list of books can hang off the publisher found as the single
+:class:`~django.views.generic.detail.SingleObjectMixin`, so that the queryset
+for the paginated list of books can hang off the publisher found as the single
 object. In order to do this, we need to have two different querysets:
 
 **Publisher queryset for use in get_object**
-    We'll set that up directly when we call :meth:`get_object()`.
+    We'll set that up directly when we call ``get_object()``.
 
 **Book queryset for use by ListView**
-    We'll figure that out ourselves in :meth:`get_queryset()` so we
-    can take into account the Publisher we're looking at.
+    We'll figure that out ourselves in ``get_queryset()`` so we
+    can take into account the ``Publisher`` we're looking at.
 
 .. note::
 
-    We have to think carefully about :meth:`get_context_data()`.
-    Since both :class:`SingleObjectMixin` and :class:`ListView` will
+    We have to think carefully about ``get_context_data()``.
+    Since both :class:`~django.views.generic.detail.SingleObjectMixin` and
+    :class:`ListView` will
     put things in the context data under the value of
-    :attr:`context_object_name` if it's set, we'll instead explictly
+    ``context_object_name`` if it's set, we'll instead explictly
     ensure the Publisher is in the context data. :class:`ListView`
     will add in the suitable ``page_obj`` and ``paginator`` for us
     providing we remember to call ``super()``.
@@ -316,13 +322,14 @@ Now we can write a new ``PublisherDetail``::
             self.object = self.get_object(Publisher.objects.all())
             return self.object.book_set.all()
 
-Notice how we set ``self.object`` within :meth:`get_queryset` so we
-can use it again later in :meth:`get_context_data`. If you don't set
-:attr:`template_name`, the template will default to the normal
+Notice how we set ``self.object`` within ``get_queryset()`` so we
+can use it again later in ``get_context_data()``. If you don't set
+``template_name``, the template will default to the normal
 :class:`ListView` choice, which in this case would be
 ``"books/book_list.html"`` because it's a list of books;
-:class:`ListView` knows nothing about :class:`SingleObjectMixin`, so
-it doesn't have any clue this view is anything to do with a Publisher.
+:class:`ListView` knows nothing about
+:class:`~django.views.generic.detail.SingleObjectMixin`, so it doesn't have
+any clue this view is anything to do with a Publisher.
 
 .. highlightlang:: html+django
 
@@ -365,7 +372,7 @@ Generally you can use
 :class:`~django.views.generic.base.TemplateResponseMixin` and
 :class:`~django.views.generic.detail.SingleObjectMixin` when you need
 their functionality. As shown above, with a bit of care you can even
-combine :class:`SingleObjectMixin` with
+combine ``SingleObjectMixin`` with
 :class:`~django.views.generic.list.ListView`. However things get
 increasingly complex as you try to do so, and a good rule of thumb is:
 
@@ -376,48 +383,48 @@ increasingly complex as you try to do so, and a good rule of thumb is:
     list<generic-display>`, :doc:`editing<generic-editing>` and
     date. For example it's fine to combine
     :class:`TemplateView` (built in view) with
-    :class:`MultipleObjectMixin` (generic list), but you're likely to
-    have problems combining :class:`SingleObjectMixin` (generic
-    detail) with :class:`MultipleObjectMixin` (generic list).
+    :class:`~django.views.generic.list.MultipleObjectMixin` (generic list), but
+    you're likely to have problems combining ``SingleObjectMixin`` (generic
+    detail) with ``MultipleObjectMixin`` (generic list).
 
 To show what happens when you try to get more sophisticated, we show
 an example that sacrifices readability and maintainability when there
 is a simpler solution. First, let's look at a naive attempt to combine
 :class:`~django.views.generic.detail.DetailView` with
 :class:`~django.views.generic.edit.FormMixin` to enable use to
-``POST`` a Django :class:`Form` to the same URL as we're displaying an
-object using :class:`DetailView`.
+``POST`` a Django :class:`~django.forms.Form` to the same URL as we're
+displaying an object using :class:`DetailView`.
 
 Using FormMixin with DetailView
 -------------------------------
 
 Think back to our earlier example of using :class:`View` and
-:class:`SingleObjectMixin` together. We were recording a user's
-interest in a particular author; say now that we want to let them
-leave a message saying why they like them. Again, let's assume we're
+:class:`~django.views.generic.detail.SingleObjectMixin` together. We were
+recording a user's interest in a particular author; say now that we want to
+let them leave a message saying why they like them. Again, let's assume we're
 not going to store this in a relational database but instead in
 something more esoteric that we won't worry about here.
 
-At this point it's natural to reach for a :class:`Form` to encapsulate
-the information sent from the user's browser to Django. Say also that
-we're heavily invested in `REST`_, so we want to use the same URL for
+At this point it's natural to reach for a :class:`~django.forms.Form` to
+encapsulate the information sent from the user's browser to Django. Say also
+that we're heavily invested in `REST`_, so we want to use the same URL for
 displaying the author as for capturing the message from the
 user. Let's rewrite our ``AuthorDetailView`` to do that.
 
 .. _REST: http://en.wikipedia.org/wiki/Representational_state_transfer
 
 We'll keep the ``GET`` handling from :class:`DetailView`, although
-we'll have to add a :class:`Form` into the context data so we can
+we'll have to add a :class:`~django.forms.Form` into the context data so we can
 render it in the template. We'll also want to pull in form processing
 from :class:`~django.views.generic.edit.FormMixin`, and write a bit of
 code so that on ``POST`` the form gets called appropriately.
 
 .. note::
 
-    We use :class:`FormMixin` and implement :meth:`post()` ourselves
-    rather than try to mix :class:`DetailView` with :class:`FormView`
-    (which provides a suitable :meth:`post()` already) because both of
-    the views implement :meth:`get()`, and things would get much more
+    We use :class:`~django.views.generic.edit.FormMixin` and implement
+    ``post()`` ourselves rather than try to mix :class:`DetailView` with
+    :class:`FormView` (which provides a suitable ``post()`` already) because
+    both of the views implement ``get()``, and things would get much more
     confusing.
 
 .. highlightlang:: python
@@ -472,24 +479,24 @@ Our new ``AuthorDetail`` looks like this::
             # record the interest using the message in form.cleaned_data
             return super(AuthorDetail, self).form_valid(form)
 
-:meth:`get_success_url()` is just providing somewhere to redirect to,
+``get_success_url()`` is just providing somewhere to redirect to,
 which gets used in the default implementation of
-:meth:`form_valid()`. We have to provide our own :meth:`post()` as
-noted earlier, and override :meth:`get_context_data()` to make the
-:class:`Form` available in the context data.
+``form_valid()``. We have to provide our own ``post()`` as
+noted earlier, and override ``get_context_data()`` to make the
+:class:`~django.forms.Form` available in the context data.
 
 A better solution
 -----------------
 
 It should be obvious that the number of subtle interactions between
-:class:`FormMixin` and :class:`DetailView` is already testing our
-ability to manage things. It's unlikely you'd want to write this kind
-of class yourself.
+:class:`~django.views.generic.edit.FormMixin` and :class:`DetailView` is
+already testing our ability to manage things. It's unlikely you'd want to
+write this kind of class yourself.
 
-In this case, it would be fairly easy to just write the :meth:`post()`
+In this case, it would be fairly easy to just write the ``post()``
 method yourself, keeping :class:`DetailView` as the only generic
-functionality, although writing :class:`Form` handling code involves a
-lot of duplication.
+functionality, although writing :class:`~django.forms.Form` handling code
+involves a lot of duplication.
 
 Alternatively, it would still be easier than the above approach to
 have a separate view for processing the form, which could use
@@ -502,15 +509,15 @@ An alternative better solution
 What we're really trying to do here is to use two different class
 based views from the same URL. So why not do just that? We have a very
 clear division here: ``GET`` requests should get the
-:class:`DetailView` (with the :class:`Form` added to the context
+:class:`DetailView` (with the :class:`~django.forms.Form` added to the context
 data), and ``POST`` requests should get the :class:`FormView`. Let's
 set up those views first.
 
 The ``AuthorDisplay`` view is almost the same as :ref:`when we
 first introduced AuthorDetail<generic-views-extra-work>`; we have to
-write our own :meth:`get_context_data()` to make the
+write our own ``get_context_data()`` to make the
 ``AuthorInterestForm`` available to the template. We'll skip the
-:meth:`get_object()` override from before for clarity.
+``get_object()`` override from before for clarity.
 
 .. code-block:: python
 
@@ -533,9 +540,9 @@ write our own :meth:`get_context_data()` to make the
             return super(AuthorDisplay, self).get_context_data(**context)
 
 Then the ``AuthorInterest`` is a simple :class:`FormView`, but we
-have to bring in :class:`SingleObjectMixin` so we can find the author
-we're talking about, and we have to remember to set
-:attr:`template_name` to ensure that form errors will render the same
+have to bring in :class:`~django.views.generic.detail.SingleObjectMixin` so we
+can find the author we're talking about, and we have to remember to set
+``template_name`` to ensure that form errors will render the same
 template as ``AuthorDisplay`` is using on ``GET``.
 
 .. code-block:: python
@@ -568,14 +575,14 @@ template as ``AuthorDisplay`` is using on ``GET``.
             return super(AuthorInterest, self).form_valid(form)
 
 Finally we bring this together in a new ``AuthorDetail`` view. We
-already know that calling :meth:`as_view()` on a class-based view
-gives us something that behaves exactly like a function based view, so
-we can do that at the point we choose between the two subviews.
+already know that calling :meth:`~django.views.generic.base.View.as_view()` on
+a class-based view gives us something that behaves exactly like a function
+based view, so we can do that at the point we choose between the two subviews.
 
-You can of course pass through keyword arguments to :meth:`as_view()`
-in the same way you would in your URLconf, such as if you wanted the
-``AuthorInterest`` behaviour to also appear at another URL but
-using a different template.
+You can of course pass through keyword arguments to
+:meth:`~django.views.generic.base.View.as_view()` in the same way you
+would in your URLconf, such as if you wanted the ``AuthorInterest`` behavior
+to also appear at another URL but using a different template.
 
 .. code-block:: python
 
@@ -646,8 +653,8 @@ Now we mix this into the base TemplateView::
 
 Equally we could use our mixin with one of the generic views. We can make our
 own version of :class:`~django.views.generic.detail.DetailView` by mixing
-:class:`JSONResponseMixin` with the
-:class:`~django.views.generic.detail.BaseDetailView` -- (the
+``JSONResponseMixin`` with the
+``django.views.generic.detail.BaseDetailView`` -- (the
 :class:`~django.views.generic.detail.DetailView` before template
 rendering behavior has been mixed in)::
 
@@ -662,11 +669,12 @@ If you want to be really adventurous, you could even mix a
 :class:`~django.views.generic.detail.DetailView` subclass that is able
 to return *both* HTML and JSON content, depending on some property of
 the HTTP request, such as a query argument or a HTTP header. Just mix
-in both the :class:`JSONResponseMixin` and a
+in both the ``JSONResponseMixin`` and a
 :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`,
-and override the implementation of :func:`render_to_response()` to defer
-to the appropriate subclass depending on the type of response that the user
-requested::
+and override the implementation of
+:func:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
+to defer to the appropriate subclass depending on the type of response that the
+user requested::
 
     class HybridDetailView(JSONResponseMixin, SingleObjectTemplateResponseMixin, BaseDetailView):
         def render_to_response(self, context):
@@ -678,5 +686,5 @@ requested::
 
 Because of the way that Python resolves method overloading, the local
 ``render_to_response()`` implementation will override the versions provided by
-:class:`JSONResponseMixin` and
+``JSONResponseMixin`` and
 :class:`~django.views.generic.detail.SingleObjectTemplateResponseMixin`.
diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt
index 310dcb5ae6..6cc174a248 100644
--- a/docs/topics/db/sql.txt
+++ b/docs/topics/db/sql.txt
@@ -24,9 +24,8 @@ return model instances:
 .. method:: Manager.raw(raw_query, params=None, translations=None)
 
 This method method takes a raw SQL query, executes it, and returns a
-:class:`~django.db.models.query.RawQuerySet` instance. This
-:class:`~django.db.models.query.RawQuerySet` instance can be iterated
-over just like an normal QuerySet to provide object instances.
+``django.db.models.query.RawQuerySet`` instance. This ``RawQuerySet`` instance
+can be iterated over just like an normal QuerySet to provide object instances.
 
 This is best illustrated with an example. Suppose you've got the following model::
 
diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt
index e3c2cadf6d..d9b846bbf0 100644
--- a/docs/topics/db/transactions.txt
+++ b/docs/topics/db/transactions.txt
@@ -48,10 +48,9 @@ you use the session middleware after the transaction middleware, session
 creation will be part of the transaction.
 
 The various cache middlewares are an exception:
-:class:`~django.middleware.cache.CacheMiddleware`,
-:class:`~django.middleware.cache.UpdateCacheMiddleware`, and
-:class:`~django.middleware.cache.FetchFromCacheMiddleware` are never affected.
-Even when using database caching, Django's cache backend uses its own
+``CacheMiddleware``, :class:`~django.middleware.cache.UpdateCacheMiddleware`,
+and :class:`~django.middleware.cache.FetchFromCacheMiddleware` are never
+affected. Even when using database caching, Django's cache backend uses its own
 database cursor (which is mapped to its own database connection internally).
 
 .. note::
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 76849c8e23..c07e2200d4 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -3,6 +3,8 @@
 Formsets
 ========
 
+.. class:: django.forms.formset.BaseFormSet
+
 A formset is a layer of abstraction to working with multiple forms on the same
 page. It can be best compared to a data grid. Let's say you have the following
 form::
diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt
index b3a830c25e..53499359e3 100644
--- a/docs/topics/http/file-uploads.txt
+++ b/docs/topics/http/file-uploads.txt
@@ -227,8 +227,8 @@ field in the model::
 ``UploadedFile`` objects
 ========================
 
-In addition to those inherited from :class:`File`, all ``UploadedFile`` objects
-define the following methods/attributes:
+In addition to those inherited from :class:`~django.core.files.File`, all
+``UploadedFile`` objects define the following methods/attributes:
 
 .. attribute:: UploadedFile.content_type
 
diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt
index caa2882f37..79d702e045 100644
--- a/docs/topics/http/views.txt
+++ b/docs/topics/http/views.txt
@@ -132,6 +132,8 @@ Customizing error views
 The 404 (page not found) view
 -----------------------------
 
+.. function:: django.views.defaults.page_not_found(request, template_name='404.html')
+
 When you raise an ``Http404`` exception, Django loads a special view devoted
 to handling 404 errors. By default, it's the view
 ``django.views.defaults.page_not_found``, which either produces a very simple
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index cefc1667ad..f72eabe977 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -312,7 +312,7 @@ time zone is unset, the default time zone applies.
 get_current_timezone
 ~~~~~~~~~~~~~~~~~~~~
 
-When the :func:`django.core.context_processors.tz` context processor is
+When the ``django.core.context_processors.tz`` context processor is
 enabled -- by default, it is -- each :class:`~django.template.RequestContext`
 contains a ``TIME_ZONE`` variable that provides the name of the current time
 zone.
@@ -661,7 +661,7 @@ Usage
        datetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=<DstTzInfo 'Europe/Helsinki' EET+2:00:00 STD>)
 
    Note that ``localize`` is a pytz extension to the :class:`~datetime.tzinfo`
-   API. Also, you may want to catch :exc:`~pytz.InvalidTimeError`. The
+   API. Also, you may want to catch ``pytz.InvalidTimeError``. The
    documentation of pytz contains `more examples`_. You should review it
    before attempting to manipulate aware datetimes.
 
diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt
index d016b59969..e2ce82f103 100644
--- a/docs/topics/logging.txt
+++ b/docs/topics/logging.txt
@@ -141,7 +141,7 @@ error log record will be written.
 Naming loggers
 --------------
 
-The call to :meth:`logging.getLogger()` obtains (creating, if
+The call to :func:`logging.getLogger()` obtains (creating, if
 necessary) an instance of a logger. The logger instance is identified
 by a name. This name is used to identify the logger for configuration
 purposes.
@@ -242,7 +242,7 @@ An example
 The full documentation for `dictConfig format`_ is the best source of
 information about logging configuration dictionaries. However, to give
 you a taste of what is possible, here is an example of a fairly
-complex logging setup, configured using :meth:`logging.dictConfig`::
+complex logging setup, configured using :func:`logging.config.dictConfig`::
 
     LOGGING = {
         'version': 1,
@@ -317,12 +317,12 @@ This logging configuration does the following things:
     message, plus the time, process, thread and module that
     generate the log message.
 
-* Defines one filter -- :class:`project.logging.SpecialFilter`,
+* Defines one filter -- ``project.logging.SpecialFilter``,
   using the alias ``special``. If this filter required additional
   arguments at time of construction, they can be provided as
   additional keys in the filter configuration dictionary. In this
   case, the argument ``foo`` will be given a value of ``bar`` when
-  instantiating the :class:`SpecialFilter`.
+  instantiating the ``SpecialFilter``.
 
 * Defines three handlers:
 
@@ -365,7 +365,7 @@ logger, you can specify your own configuration scheme.
 
 The :setting:`LOGGING_CONFIG` setting defines the callable that will
 be used to configure Django's loggers. By default, it points at
-Python's :meth:`logging.dictConfig()` method. However, if you want to
+Python's :func:`logging.config.dictConfig()` function. However, if you want to
 use a different configuration process, you can use any other callable
 that takes a single argument. The contents of :setting:`LOGGING` will
 be provided as the value of that argument when logging is configured.
@@ -494,7 +494,7 @@ logging module.
    through the filter. Handling of that record will not proceed if the callback
    returns False.
 
-   For instance, to filter out :class:`~django.http.UnreadablePostError`
+   For instance, to filter out :exc:`~django.http.UnreadablePostError`
    (raised when a user cancels an upload) from the admin emails, you would
    create a filter function::
 
diff --git a/docs/topics/python3.txt b/docs/topics/python3.txt
index e1d78a10e6..b44c180d7f 100644
--- a/docs/topics/python3.txt
+++ b/docs/topics/python3.txt
@@ -78,8 +78,8 @@ wherever possible and avoid the ``b`` prefixes.
 String handling
 ---------------
 
-Python 2's :class:`unicode` type was renamed :class:`str` in Python 3,
-:class:`str` was renamed :class:`bytes`, and :class:`basestring` disappeared.
+Python 2's :func:`unicode` type was renamed :func:`str` in Python 3,
+:func:`str` was renamed ``bytes()``, and :func:`basestring` disappeared.
 six_ provides :ref:`tools <string-handling-with-six>` to deal with these
 changes.
 
@@ -131,35 +131,36 @@ and ``SafeText`` respectively.
 
 For forwards compatibility, the new names work as of Django 1.4.2.
 
-:meth:`__str__` and :meth:`__unicode__` methods
------------------------------------------------
+:meth:`~object.__str__` and :meth:`~object.__unicode__` methods
+---------------------------------------------------------------
 
-In Python 2, the object model specifies :meth:`__str__` and
-:meth:`__unicode__` methods. If these methods exist, they must return
-:class:`str` (bytes) and :class:`unicode` (text) respectively.
+In Python 2, the object model specifies :meth:`~object.__str__` and
+:meth:`~object.__unicode__` methods. If these methods exist, they must return
+``str`` (bytes) and ``unicode`` (text) respectively.
 
-The ``print`` statement and the :func:`str` built-in call :meth:`__str__` to
-determine the human-readable representation of an object. The :func:`unicode`
-built-in calls :meth:`__unicode__` if it exists, and otherwise falls back to
-:meth:`__str__` and decodes the result with the system encoding. Conversely,
-the :class:`~django.db.models.Model` base class automatically derives
-:meth:`__str__` from :meth:`__unicode__` by encoding to UTF-8.
+The ``print`` statement and the :func:`str` built-in call
+:meth:`~object.__str__` to determine the human-readable representation of an
+object. The :func:`unicode` built-in calls :meth:`~object.__unicode__` if it
+exists, and otherwise falls back to :meth:`~object.__str__` and decodes the
+result with the system encoding. Conversely, the
+:class:`~django.db.models.Model` base class automatically derives
+:meth:`~object.__str__` from :meth:`~object.__unicode__` by encoding to UTF-8.
 
-In Python 3, there's simply :meth:`__str__`, which must return :class:`str`
+In Python 3, there's simply :meth:`~object.__str__`, which must return ``str``
 (text).
 
-(It is also possible to define :meth:`__bytes__`, but Django application have
+(It is also possible to define ``__bytes__()``, but Django application have
 little use for that method, because they hardly ever deal with
-:class:`bytes`.)
+``bytes``.)
 
-Django provides a simple way to define :meth:`__str__` and :meth:`__unicode__`
-methods that work on Python 2 and 3: you must define a :meth:`__str__` method
-returning text and to apply the
+Django provides a simple way to define :meth:`~object.__str__` and
+:meth:`~object.__unicode__` methods that work on Python 2 and 3: you must
+define a :meth:`~object.__str__` method returning text and to apply the
 :func:`~django.utils.encoding.python_2_unicode_compatible` decorator.
 
 On Python 3, the decorator is a no-op. On Python 2, it defines appropriate
-:meth:`__unicode__` and :meth:`__str__` methods (replacing the original
-:meth:`__str__` method in the process). Here's an example::
+:meth:`~object.__unicode__` and :meth:`~object.__str__` methods (replacing the
+original :meth:`~object.__str__` method in the process). Here's an example::
 
     from __future__ import unicode_literals
     from django.utils.encoding import python_2_unicode_compatible
@@ -173,8 +174,8 @@ This technique is the best match for Django's porting philosophy.
 
 For forwards compatibility, this decorator is available as of Django 1.4.2.
 
-Finally, note that :meth:`__repr__` must return a :class:`str` on all versions
-of Python.
+Finally, note that :meth:`~object.__repr__` must return a ``str`` on all
+versions of Python.
 
 :class:`dict` and :class:`dict`-like classes
 --------------------------------------------
@@ -187,19 +188,19 @@ behave likewise in Python 3.
 six_ provides compatibility functions to work around this change:
 :func:`~six.iterkeys`, :func:`~six.iteritems`, and :func:`~six.itervalues`.
 Django's bundled version adds :func:`~django.utils.six.iterlists` for
-:class:`~django.utils.datastructures.MultiValueDict` and its subclasses.
+``django.utils.datastructures.MultiValueDict`` and its subclasses.
 
 :class:`~django.http.HttpRequest` and :class:`~django.http.HttpResponse` objects
 --------------------------------------------------------------------------------
 
 According to :pep:`3333`:
 
-- headers are always :class:`str` objects,
-- input and output streams are always :class:`bytes` objects.
+- headers are always ``str`` objects,
+- input and output streams are always ``bytes`` objects.
 
 Specifically, :attr:`HttpResponse.content <django.http.HttpResponse.content>`
-contains :class:`bytes`, which may become an issue if you compare it with a
-:class:`str` in your tests. The preferred solution is to rely on
+contains ``bytes``, which may become an issue if you compare it with a
+``str`` in your tests. The preferred solution is to rely on
 :meth:`~django.test.TestCase.assertContains` and
 :meth:`~django.test.TestCase.assertNotContains`. These methods accept a
 response and a unicode string as arguments.
@@ -236,11 +237,10 @@ under Python 3, use the :func:`str` builtin::
 
     str('my string')
 
-In Python 3, there aren't any automatic conversions between :class:`str` and
-:class:`bytes`, and the :mod:`codecs` module became more strict.
-:meth:`str.decode` always returns :class:`bytes`, and :meth:`bytes.decode`
-always returns :class:`str`. As a consequence, the following pattern is
-sometimes necessary::
+In Python 3, there aren't any automatic conversions between ``str`` and
+``bytes``, and the :mod:`codecs` module became more strict. :meth:`str.decode`
+always returns ``bytes``, and ``bytes.decode`` always returns ``str``. As a
+consequence, the following pattern is sometimes necessary::
 
     value = value.encode('ascii', 'ignore').decode('ascii')
 
@@ -395,11 +395,8 @@ The version of six bundled with Django includes one extra function:
 
 .. function:: iterlists(MultiValueDict)
 
-    Returns an iterator over the lists of values of a
-    :class:`~django.utils.datastructures.MultiValueDict`. This replaces
-    :meth:`~django.utils.datastructures.MultiValueDict.iterlists()` on Python
-    2 and :meth:`~django.utils.datastructures.MultiValueDict.lists()` on
-    Python 3.
+    Returns an iterator over the lists of values of a ``MultiValueDict``. This
+    replaces ``iterlists()`` on Python 2 and ``lists()`` on Python 3.
 
 .. function:: assertRaisesRegex(testcase, *args, **kwargs)
 
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index e36c7587d1..2af0584a61 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -26,6 +26,8 @@ to (see `Serialization formats`_) and a
 argument can be any iterator that yields Django model instances, but it'll
 almost always be a QuerySet).
 
+.. function:: django.core.serializers.get_serializer(format)
+
 You can also use a serializer object directly::
 
     XMLSerializer = serializers.get_serializer("xml")
@@ -43,7 +45,7 @@ This is useful if you want to serialize data directly to a file-like object
 
     Calling :func:`~django.core.serializers.get_serializer` with an unknown
     :ref:`format <serialization-formats>` will raise a
-    :class:`~django.core.serializers.SerializerDoesNotExist` exception.
+    ``django.core.serializers.SerializerDoesNotExist`` exception.
 
 Subset of fields
 ~~~~~~~~~~~~~~~~
diff --git a/docs/topics/settings.txt b/docs/topics/settings.txt
index 88fa7b6864..fa26297988 100644
--- a/docs/topics/settings.txt
+++ b/docs/topics/settings.txt
@@ -32,6 +32,8 @@ Because a settings file is a Python module, the following apply:
 Designating the settings
 ========================
 
+.. envvar:: DJANGO_SETTINGS_MODULE
+
 When you use Django, you have to tell it which settings you're using. Do this
 by using an environment variable, ``DJANGO_SETTINGS_MODULE``.
 
@@ -260,4 +262,3 @@ It boils down to this: Use exactly one of either ``configure()`` or
 ``DJANGO_SETTINGS_MODULE``. Not both, and not neither.
 
 .. _@login_required: ../authentication/#the-login-required-decorator
-
diff --git a/docs/topics/testing/overview.txt b/docs/topics/testing/overview.txt
index 128d730a1d..7528ae141f 100644
--- a/docs/topics/testing/overview.txt
+++ b/docs/topics/testing/overview.txt
@@ -28,7 +28,7 @@ module defines tests in class-based approach.
     backported for Python 2.5 compatibility.
 
     To access this library, Django provides the
-    :mod:`django.utils.unittest` module alias. If you are using Python
+    ``django.utils.unittest`` module alias. If you are using Python
     2.7, or you have installed unittest2 locally, Django will map the
     alias to the installed version of the unittest library. Otherwise,
     Django will use its own bundled version of unittest2.
@@ -851,7 +851,7 @@ Normal Python unit test classes extend a base class of
    Hierarchy of Django unit testing classes
 
 Regardless of the version of Python you're using, if you've installed
-``unittest2``, :mod:`django.utils.unittest` will point to that library.
+``unittest2``, ``django.utils.unittest`` will point to that library.
 
 SimpleTestCase
 ~~~~~~~~~~~~~~
@@ -882,7 +882,7 @@ features like:
 then you should use :class:`~django.test.TransactionTestCase` or
 :class:`~django.test.TestCase` instead.
 
-``SimpleTestCase`` inherits from :class:`django.utils.unittest.TestCase`.
+``SimpleTestCase`` inherits from ``django.utils.unittest.TestCase``.
 
 TransactionTestCase
 ~~~~~~~~~~~~~~~~~~~
@@ -1745,7 +1745,7 @@ test if the database doesn't support a specific named feature.
 
 The decorators use a string identifier to describe database features.
 This string corresponds to attributes of the database connection
-features class. See :class:`~django.db.backends.BaseDatabaseFeatures`
+features class. See ``django.db.backends.BaseDatabaseFeatures``
 class for a full list of database features that can be used as a basis
 for skipping tests.