[1.5.x] Fixed broken links, round 4. refs #19516

Backport of 067505a from master

docs/howto/auth-remote-user.txt

@@ -27,6 +27,8 @@ use of the ``REMOTE_USER`` value using the ``RemoteUserMiddleware`` and
 Configuration
 =============
 
+.. class:: django.contrib.auth.middleware.RemoteUserMiddleware
+
 First, you must add the
 :class:`django.contrib.auth.middleware.RemoteUserMiddleware` to the
 :setting:`MIDDLEWARE_CLASSES` setting **after** the

docs/howto/custom-management-commands.txt

@@ -2,6 +2,8 @@
 Writing custom django-admin commands
 ====================================
 
+.. module:: django.core.management
+
 Applications can register their own actions with ``manage.py``. For example,
 you might want to add a ``manage.py`` action for a Django app that you're
 distributing. In this document, we will be building a custom ``closepoll``
@@ -261,6 +263,13 @@ the :meth:`~BaseCommand.handle` method must be implemented.
 
     The actual logic of the command. Subclasses must implement this method.
 
+.. method:: BaseCommand.validate(app=None, display_num_errors=False)
+
+    Validates the given app, raising :class:`CommandError` for any errors.
+
+    If ``app`` is None, then all installed apps are validated.
+
+
 .. _ref-basecommand-subclasses:
 
 BaseCommand subclasses

docs/howto/custom-model-fields.txt

@@ -153,8 +153,8 @@ class, from which everything is descended.
 
 Initializing your new field is a matter of separating out any arguments that are
 specific to your case from the common arguments and passing the latter to the
-:meth:`~django.db.models.Field.__init__` method of
-:class:`~django.db.models.Field` (or your parent class).
+``__init__()`` method of :class:`~django.db.models.Field` (or your parent
+class).
 
 In our example, we'll call our field ``HandField``. (It's a good idea to call
 your :class:`~django.db.models.Field` subclass ``<Something>Field``, so it's
@@ -602,11 +602,11 @@ Returns the default form field to use when this field is displayed in a model.
 This method is called by the :class:`~django.forms.ModelForm` helper.
 
 All of the ``kwargs`` dictionary is passed directly to the form field's
-:meth:`~django.forms.Field__init__` method. Normally, all you need to do is
-set up a good default for the ``form_class`` argument and then delegate further
-handling to the parent class. This might require you to write a custom form
-field (and even a form widget). See the :doc:`forms documentation
-</topics/forms/index>` for information about this, and take a look at the code in
+``__init__()`` method. Normally, all you need to do is set up a good default
+for the ``form_class`` argument and then delegate further handling to the
+parent class. This might require you to write a custom form field (and even a
+form widget). See the :doc:`forms documentation </topics/forms/index>` for
+information about this, and take a look at the code in
 :mod:`django.contrib.localflavor` for some examples of custom widgets.
 
 Continuing our ongoing example, we can write the :meth:`.formfield` method as::
@@ -668,7 +668,7 @@ Converting field data for serialization
 .. method:: Field.value_to_string(self, obj)
 
 This method is used by the serializers to convert the field into a string for
-output. Calling :meth:`Field._get_val_from_obj(obj)` is the best way to get the
+output. Calling ``Field._get_val_from_obj(obj)`` is the best way to get the
 value to serialize. For example, since our ``HandField`` uses strings for its
 data storage anyway, we can reuse some existing conversion code::
 
@@ -692,12 +692,12 @@ smoothly:
    a field that's similar to what you want and extend it a little bit,
    instead of creating an entirely new field from scratch.
 
-2. Put a :meth:`__str__` or :meth:`__unicode__` method on the class you're
+2. Put a ``__str__()`` or ``__unicode__()`` method on the class you're
    wrapping up as a field. There are a lot of places where the default
    behavior of the field code is to call
    :func:`~django.utils.encoding.force_text` on the value. (In our
    examples in this document, ``value`` would be a ``Hand`` instance, not a
-   ``HandField``). So if your :meth:`__unicode__` method automatically
+   ``HandField``). So if your ``__unicode__()`` method automatically
    converts to the string form of your Python object, you can save yourself
    a lot of work.
 

docs/internals/deprecation.txt

@@ -20,7 +20,7 @@ these changes.
 * The old imports for CSRF functionality (``django.contrib.csrf.*``),
   which moved to core in 1.2, will be removed.
 
-* The :mod:`django.contrib.gis.db.backend` module will be removed in favor
+* The ``django.contrib.gis.db.backend`` module will be removed in favor
   of the specific backends.
 
 * ``SMTPConnection`` will be removed in favor of a generic Email backend API.
@@ -122,23 +122,23 @@ these changes.
   The :attr:`~django.test.client.Response.templates` attribute should be
   used instead.
 
-* The :class:`~django.test.simple.DjangoTestRunner` will be removed.
+* The ``django.test.simple.DjangoTestRunner`` will be removed.
   Instead use a unittest-native class.  The features of the
-  :class:`django.test.simple.DjangoTestRunner` (including fail-fast and
+  ``django.test.simple.DjangoTestRunner`` (including fail-fast and
   Ctrl-C test termination) can currently be provided by the unittest-native
-  :class:`TextTestRunner`.
+  :class:`~unittest.TextTestRunner`.
 
 * The undocumented function
-  :func:`django.contrib.formtools.utils.security_hash` will be removed,
-  instead use :func:`django.contrib.formtools.utils.form_hmac`
+  ``django.contrib.formtools.utils.security_hash`` will be removed,
+  instead use ``django.contrib.formtools.utils.form_hmac``
 
 * The function-based generic view modules will be removed in favor of their
   class-based equivalents, outlined :doc:`here
   </topics/class-based-views/index>`.
 
-* The :class:`~django.core.servers.basehttp.AdminMediaHandler` will be
+* The ``django.core.servers.basehttp.AdminMediaHandler`` will be
   removed.  In its place use
-  :class:`~django.contrib.staticfiles.handlers.StaticFilesHandler`.
+  ``django.contrib.staticfiles.handlers.StaticFilesHandler``.
 
 * The template tags library ``adminmedia`` and the template tag ``{%
   admin_media_prefix %}`` will be removed in favor of the generic static files
@@ -150,8 +150,7 @@ these changes.
   an implied string. In 1.4, this behavior is provided by a version of the tag
   in the ``future`` template tag library.
 
-* The :djadmin:`reset` and :djadmin:`sqlreset` management commands
-  will be removed.
+* The ``reset`` and ``sqlreset`` management commands will be removed.
 
 * Authentication backends will need to support an inactive user
   being passed to all methods dealing with permissions.
@@ -162,11 +161,11 @@ these changes.
   a :class:`~django.contrib.gis.geos.GEOSException` when called
   on a geometry with no SRID value.
 
-* :class:`~django.http.CompatCookie` will be removed in favor of
-  :class:`~django.http.SimpleCookie`.
+* ``django.http.CompatCookie`` will be removed in favor of
+  ``django.http.SimpleCookie``.
 
-* :class:`django.core.context_processors.PermWrapper` and
-  :class:`django.core.context_processors.PermLookupDict` will be removed in
+* ``django.core.context_processors.PermWrapper`` and
+  ``django.core.context_processors.PermLookupDict`` will be removed in
   favor of the corresponding
   :class:`django.contrib.auth.context_processors.PermWrapper` and
   :class:`django.contrib.auth.context_processors.PermLookupDict`,
@@ -213,8 +212,7 @@ these changes.
   ``django.utils.itercompat.all`` and ``django.utils.itercompat.any`` will
   be removed. The Python builtin versions should be used instead.
 
-* The :func:`~django.views.decorators.csrf.csrf_response_exempt` and
-  :func:`~django.views.decorators.csrf.csrf_view_exempt` decorators will
+* The ``csrf_response_exempt`` and ``csrf_view_exempt`` decorators will
   be removed. Since 1.4 ``csrf_response_exempt`` has been a no-op (it
   returns the same function), and ``csrf_view_exempt`` has been a
   synonym for ``django.views.decorators.csrf.csrf_exempt``, which should

docs/ref/contrib/auth.txt

@@ -349,7 +349,7 @@ Login and logout signals
 The auth framework uses two :doc:`signals </topics/signals>` that can be used
 for notification when a user logs in or out.
 
-.. function:: django.contrib.auth.signals.user_logged_in
+.. function:: user_logged_in
 
     Sent when a user logs in successfully.
 
@@ -364,7 +364,7 @@ for notification when a user logs in or out.
     ``user``
         The user instance that just logged in.
 
-.. function:: django.contrib.auth.signals.user_logged_out
+.. function:: user_logged_out
 
     Sent when the logout method is called.
 
@@ -379,9 +379,9 @@ for notification when a user logs in or out.
         The user instance that just logged out or ``None`` if the
         user was not authenticated.
 
-.. function:: django.contrib.auth.signals.user_login_failed
+.. function:: user_login_failed
 
-.. versionadded:: 1.5
+    .. versionadded:: 1.5
 
     Sent when the user failed to login successfully
 

docs/ref/contrib/gis/testing.txt

@@ -140,6 +140,8 @@ with the rest of :ref:`Django's unit tests <running-unit-tests>`.
 Run only GeoDjango tests
 ------------------------
 
+.. class:: django.contrib.gis.tests.GeoDjangoTestSuiteRunner
+
 To run *only* the tests for GeoDjango, the :setting:`TEST_RUNNER`
 setting must be changed to use the
 :class:`~django.contrib.gis.tests.GeoDjangoTestSuiteRunner`::

docs/ref/contrib/messages.txt

@@ -149,6 +149,8 @@ tags for the levels you wish to override::
 Using messages in views and templates
 =====================================
 
+.. function:: add_message(request, level, message, extra_tags='', fail_silently=False)
+
 Adding a message
 ----------------
 

docs/ref/signals.txt

@@ -27,9 +27,8 @@ module system.
 .. warning::
 
     Many of these signals are sent by various model methods like
-    :meth:`~django.db.models.Model.__init__` or
-    :meth:`~django.db.models.Model.save` that you can overwrite in your own
-    code.
+    ``__init__()`` or :meth:`~django.db.models.Model.save` that you can
+    override in your own code.
 
     If you override these methods on your model, you must call the parent class'
     methods for this signals to be sent.
@@ -47,20 +46,18 @@ pre_init
 .. ^^^^^^^ this :module: hack keeps Sphinx from prepending the module.
 
 Whenever you instantiate a Django model, this signal is sent at the beginning
-of the model's :meth:`~django.db.models.Model.__init__` method.
+of the model's ``__init__()`` method.
 
 Arguments sent with this signal:
 
 ``sender``
     The model class that just had an instance created.
 
 ``args``
-    A list of positional arguments passed to
-    :meth:`~django.db.models.Model.__init__`:
+    A list of positional arguments passed to ``__init__()``:
 
 ``kwargs``
-    A dictionary of keyword arguments passed to
-    :meth:`~django.db.models.Model.__init__`:.
+    A dictionary of keyword arguments passed to ``__init__()``:
 
 For example, the :doc:`tutorial </intro/tutorial01>` has this line::
 
@@ -74,7 +71,7 @@ Argument    Value
 ``sender``  ``Poll`` (the class itself)
 
 ``args``    ``[]`` (an empty list because there were no positional
-            arguments passed to ``__init__``.)
+            arguments passed to ``__init__()``.)
 
 ``kwargs``  ``{'question': "What's up?", 'pub_date': datetime.now()}``
 ==========  ===============================================================
@@ -85,7 +82,7 @@ post_init
 .. data:: django.db.models.signals.post_init
    :module:
 
-Like pre_init, but this one is sent when the :meth:`~django.db.models.Model.__init__`: method finishes.
+Like pre_init, but this one is sent when the ``__init__()`` method finishes.
 
 Arguments sent with this signal:
 

docs/releases/1.0-porting-guide.txt

@@ -277,8 +277,9 @@ Handle uploaded files using the new API
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Replace use of uploaded files -- that is, entries in ``request.FILES`` -- as
-simple dictionaries with the new :class:`~django.core.files.UploadedFile`. The
-old dictionary syntax no longer works.
+simple dictionaries with the new
+:class:`~django.core.files.uploadedfile.UploadedFile`. The old dictionary
+syntax no longer works.
 
 Thus, in a view like::
 
@@ -410,7 +411,7 @@ U.S. local flavor
 ~~~~~~~~~~~~~~~~~
 
 ``django.contrib.localflavor.usa`` has been renamed to
-:mod:`django.contrib.localflavor.us`. This change was made to match the naming
+``django.contrib.localflavor.us``. This change was made to match the naming
 scheme of other local flavors. To migrate your code, all you need to do is
 change the imports.
 
@@ -642,8 +643,8 @@ The generic relation classes -- ``GenericForeignKey`` and ``GenericRelation``
 Testing
 -------
 
-:meth:`django.test.Client.login` has changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+:meth:`django.test.client.Client.login` has changed
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Old (0.96)::
 
@@ -721,7 +722,7 @@ To update your code:
 1. Use :class:`django.utils.datastructures.SortedDict` wherever you were
    using ``django.newforms.forms.SortedDictFromList``.
 
-2. Because :meth:`django.utils.datastructures.SortedDict.copy` doesn't
+2. Because ``django.utils.datastructures.SortedDict.copy`` doesn't
    return a deepcopy as ``SortedDictFromList.copy()`` did, you will need
    to update your code if you were relying on a deepcopy. Do this by using
    ``copy.deepcopy`` directly.

docs/releases/1.1-beta-1.txt

@@ -36,7 +36,7 @@ A number of features have been added to Django's model layer:
 You can now control whether or not Django creates database tables for a model
 using the :attr:`~Options.managed` model option. This defaults to ``True``,
 meaning that Django will create the appropriate database tables in
-:djadmin:`syncdb` and remove them as part of :djadmin:`reset` command. That
+:djadmin:`syncdb` and remove them as part of ``reset`` command. That
 is, Django *manages* the database table's lifecycle.
 
 If you set this to ``False``, however, no database table creating or deletion

docs/releases/1.1.txt

@@ -37,7 +37,7 @@ If you are using a 32-bit platform, you're off the hook; you'll observe no
 differences as a result of this change.
 
 However, **users on 64-bit platforms may experience some problems** using the
-:djadmin:`reset` management command. Prior to this change, 64-bit platforms
+``reset`` management command. Prior to this change, 64-bit platforms
 would generate a 64-bit, 16 character digest in the constraint name; for
 example::
 
@@ -48,14 +48,14 @@ Following this change, all platforms, regardless of word size, will generate a
 
     ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...
 
-As a result of this change, you will not be able to use the :djadmin:`reset`
+As a result of this change, you will not be able to use the ``reset``
 management command on any table made by a 64-bit machine. This is because the
 the new generated name will not match the historically generated name; as a
 result, the SQL constructed by the reset command will be invalid.
 
 If you need to reset an application that was created with 64-bit constraints,
 you will need to manually drop the old constraint prior to invoking
-:djadmin:`reset`.
+``reset``.
 
 Test cases are now run in a transaction
 ---------------------------------------
@@ -120,9 +120,8 @@ has been saved.
 Changes to how model formsets are saved
 ---------------------------------------
 
-.. currentmodule:: django.forms.models
-
-In Django 1.1, :class:`BaseModelFormSet` now calls :meth:`ModelForm.save()`.
+In Django 1.1, :class:`~django.forms.models.BaseModelFormSet` now calls
+``ModelForm.save()``.
 
 This is backwards-incompatible if you were modifying ``self.initial`` in a model
 formset's ``__init__``, or if you relied on the internal ``_total_form_count``
@@ -146,7 +145,7 @@ Permanent redirects and the ``redirect_to()`` generic view
 ----------------------------------------------------------
 
 Django 1.1 adds a ``permanent`` argument to the
-:func:`django.views.generic.simple.redirect_to()` view. This is technically
+``django.views.generic.simple.redirect_to()`` view. This is technically
 backwards-incompatible if you were using the ``redirect_to`` view with a
 format-string key called 'permanent', which is highly unlikely.
 
@@ -211,8 +210,8 @@ Query expressions
 
 Queries can now refer to a another field on the query and can traverse
 relationships to refer to fields on related models. This is implemented in the
-new :class:`F` object; for full details, including examples, consult the
-:ref:`documentation for F expressions <query-expressions>`.
+new :class:`~django.db.models.F` object; for full details, including examples,
+consult the :ref:`documentation for F expressions <query-expressions>`.
 
 Model improvements
 ------------------
@@ -225,7 +224,7 @@ A number of features have been added to Django's model layer:
 You can now control whether or not Django manages the life-cycle of the database
 tables for a model using the :attr:`~Options.managed` model option. This
 defaults to ``True``, meaning that Django will create the appropriate database
-tables in :djadmin:`syncdb` and remove them as part of the :djadmin:`reset`
+tables in :djadmin:`syncdb` and remove them as part of the ``reset``
 command. That is, Django *manages* the database table's lifecycle.
 
 If you set this to ``False``, however, no database table creating or deletion

docs/releases/1.2.4.txt

@@ -76,7 +76,7 @@ GeoDjango
 =========
 
 The function-based :setting:`TEST_RUNNER` previously used to execute
-the GeoDjango test suite, :func:`django.contrib.gis.tests.run_gis_tests`,
+the GeoDjango test suite, ``django.contrib.gis.tests.run_gis_tests``,
 was finally deprecated in favor of a class-based test runner,
 :class:`django.contrib.gis.tests.GeoDjangoTestSuiteRunner`, added in this
 release.