[1.9.x] Fixed #26020 -- Normalized header stylings in docs.

Backport of bca9faae95db2a92e540fbd08505c134639916fe from master
author: Elif T. Kus <elifkus@gmail.com> 2016-01-03 12:56:22 +0200
committer: Tim Graham <timograham@gmail.com> 2016-01-22 12:18:24 -0500
commit: 5dceb1f07807d76f163ce1929e9f1dc1b2da6289 (patch)
tree: 21057f127c428fd95dc35badefd67560a3d2c100 /docs
parent: 647ce33e86807bcc75977a34871e1ee08230d9a5 (diff)
131 files changed, 1468 insertions, 1424 deletions
diff --git a/docs/contents.txt b/docs/contents.txt
index 736e1f62bf..137b308921 100644
--- a/docs/contents.txt
+++ b/docs/contents.txt
@@ -1,5 +1,3 @@
-.. _contents:
-
 =============================
 Django documentation contents
 =============================
@@ -27,4 +25,4 @@ Indices, glossary and tables
 
 * :ref:`genindex`
 * :ref:`modindex`
-* :ref:`glossary`
+* :doc:`glossary`
diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt
index ce89203c76..a1d42099f9 100644
--- a/docs/faq/admin.txt
+++ b/docs/faq/admin.txt
@@ -1,8 +1,9 @@
+==============
 FAQ: The admin
 ==============
 
 I can't log in. When I enter a valid username and password, it just brings up the login page again, with no error messages.
----------------------------------------------------------------------------------------------------------------------------
+===========================================================================================================================
 
 The login cookie isn't being set correctly, because the domain of the cookie
 sent out by Django doesn't match the domain in your browser. Try these two
@@ -14,7 +15,7 @@ things:
   should set :setting:`SESSION_COOKIE_DOMAIN` = 'www.example.com'.
 
 I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
------------------------------------------------------------------------------------------------------------------------------------------------------------
+===========================================================================================================================================================
 
 If you're sure your username and password are correct, make sure your user
 account has :attr:`~django.contrib.auth.models.User.is_active` and
@@ -22,7 +23,7 @@ account has :attr:`~django.contrib.auth.models.User.is_active` and
 only allows access to users with those two fields both set to True.
 
 How do I automatically set a field's value to the user who last edited the object in the admin?
------------------------------------------------------------------------------------------------
+===============================================================================================
 
 The :class:`~django.contrib.admin.ModelAdmin` class provides customization hooks
 that allow you to transform an object as it saved, using details from the
@@ -32,7 +33,7 @@ object to reflect the user that edited it. See :ref:`the documentation on
 ModelAdmin methods <model-admin-methods>` for an example.
 
 How do I limit admin access so that objects can only be edited by the users who created them?
----------------------------------------------------------------------------------------------
+=============================================================================================
 
 The :class:`~django.contrib.admin.ModelAdmin` class also provides customization
 hooks that allow you to control the visibility and editability of objects in the
@@ -42,13 +43,13 @@ admin. Using the same trick of extracting the user from the request, the
 control the visibility and editability of objects in the admin.
 
 My admin-site CSS and images showed up fine using the development server, but they're not displaying when using mod_wsgi.
----------------------------------------------------------------------------------------------------------------------------
+=========================================================================================================================
 
 See :ref:`serving the admin files <serving-the-admin-files>`
 in the "How to use Django with mod_wsgi" documentation.
 
 My "list_filter" contains a ManyToManyField, but the filter doesn't display.
-----------------------------------------------------------------------------
+============================================================================
 
 Django won't bother displaying the filter for a ``ManyToManyField`` if there
 are fewer than two related objects.
@@ -59,7 +60,7 @@ database, it won't display a "Site" filter. In that case, filtering by site
 would be meaningless.
 
 Some objects aren't appearing in the admin.
--------------------------------------------
+===========================================
 
 Inconsistent row counts may be caused by missing foreign key values or a
 foreign key field incorrectly set to :attr:`null=False
@@ -71,7 +72,7 @@ shown in the admin changelist because the Django model is declaring an
 integrity constraint that is not implemented at the database level.
 
 How can I customize the functionality of the admin interface?
--------------------------------------------------------------
+=============================================================
 
 You've got several options. If you want to piggyback on top of an add/change
 form that Django automatically generates, you can attach arbitrary JavaScript
@@ -89,7 +90,7 @@ If you want to customize the look-and-feel of the admin interface, read the
 next question.
 
 The dynamically-generated admin site is ugly! How can I change it?
-------------------------------------------------------------------
+==================================================================
 
 We like it, but if you don't agree, you can modify the admin site's
 presentation by editing the CSS stylesheet and/or associated image files. The
@@ -97,7 +98,7 @@ site is built using semantic HTML and plenty of CSS hooks, so any changes you'd
 like to make should be possible by editing the stylesheet.
 
 What browsers are supported for using the admin?
-------------------------------------------------
+================================================
 
 The admin provides a fully-functional experience to `YUI's A-grade`_ browsers,
 with the notable exception of IE6, which is not supported.
diff --git a/docs/faq/contributing.txt b/docs/faq/contributing.txt
index cdf2b6c6ca..079a789197 100644
--- a/docs/faq/contributing.txt
+++ b/docs/faq/contributing.txt
@@ -1,14 +1,15 @@
+======================
 FAQ: Contributing code
 ======================
 
 How can I get started contributing code to Django?
---------------------------------------------------
+==================================================
 
 Thanks for asking! We've written an entire document devoted to this question.
 It's titled :doc:`Contributing to Django </internals/contributing/index>`.
 
 I submitted a bug fix in the ticket system several weeks ago. Why are you ignoring my patch?
---------------------------------------------------------------------------------------------
+============================================================================================
 
 Don't worry: We're not ignoring you!
 
@@ -43,7 +44,7 @@ we'll just close the ticket. So if your ticket is still open, it doesn't mean
 we're ignoring you; it just means we haven't had time to look at it yet.
 
 When and how might I remind the core team of a patch I care about?
-------------------------------------------------------------------
+==================================================================
 
 A polite, well-timed message to the mailing list is one way to get attention.
 To determine the right time, you need to keep an eye on the schedule. If you
@@ -70,7 +71,7 @@ additional attention -- certainly not the attention that you need in order to
 get your pet bug addressed.
 
 But I've reminded you several times and you keep ignoring my patch!
--------------------------------------------------------------------
+===================================================================
 
 Seriously - we're not ignoring you. If your patch stands no chance of
 inclusion in Django, we'll close the ticket. For all the other tickets, we
diff --git a/docs/faq/general.txt b/docs/faq/general.txt
index 4bc8e6dfe3..cb31e8b6ab 100644
--- a/docs/faq/general.txt
+++ b/docs/faq/general.txt
@@ -1,8 +1,9 @@
+============
 FAQ: General
 ============
 
 Why does this project exist?
-----------------------------
+============================
 
 Django grew from a very practical need: World Online, a newspaper Web
 operation, is responsible for building intensive Web applications on journalism
@@ -29,7 +30,7 @@ thrilled to be able to give something back to the open-source community.
 .. _PostgreSQL: http://www.postgresql.org/
 
 What does "Django" mean, and how do you pronounce it?
------------------------------------------------------
+=====================================================
 
 Django is named after `Django Reinhardt`_, a gypsy jazz guitarist from the 1930s
 to early 1950s. To this day, he's considered one of the best guitarists of all time.
@@ -44,14 +45,14 @@ We've also recorded an `audio clip of the pronunciation`_.
 .. _audio clip of the pronunciation: http://red-bean.com/~adrian/django_pronunciation.mp3
 
 Is Django stable?
------------------
+=================
 
 Yes, it's quite stable. Companies like Disqus, Instagram, Pinterest, and
 Mozilla have been using Django for many years. Sites built on Django have
 weathered traffic spikes of over 50 thousand hits per second.
 
 Does Django scale?
-------------------
+==================
 
 Yes. Compared to development time, hardware is cheap, and so Django is
 designed to take advantage of as much hardware as you can throw at it.
@@ -64,14 +65,14 @@ application layer. And it ships with a simple-yet-powerful
 :doc:`cache framework </topics/cache>`.
 
 Who's behind this?
-------------------
+==================
 
 Django was originally developed at World Online, the Web department of a
 newspaper in Lawrence, Kansas, USA. Django's now run by an international
 :doc:`team of volunteers </internals/team>`.
 
 Which sites use Django?
------------------------
+=======================
 
 `DjangoSites.org`_ features a constantly growing list of Django-powered sites.
 
@@ -80,7 +81,7 @@ Which sites use Django?
 .. _faq-mtv:
 
 Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?
------------------------------------------------------------------------------------------------------------------------------------------------------
+=====================================================================================================================================================
 
 Well, the standard names are debatable.
 
@@ -110,7 +111,7 @@ regardless of how things are named, Django gets stuff done in a way that's most
 logical to us.
 
 <Framework X> does <feature Y> -- why doesn't Django?
------------------------------------------------------
+=====================================================
 
 We're well aware that there are other awesome Web frameworks out there, and
 we're not averse to borrowing ideas where appropriate. However, Django was
@@ -119,7 +120,7 @@ aware that "because <Framework X> does it" is not going to be sufficient reason
 to add a given feature to Django.
 
 Why did you write all of Django from scratch, instead of using other Python libraries?
---------------------------------------------------------------------------------------
+======================================================================================
 
 When Django was originally written a couple of years ago, Adrian and Simon
 spent quite a bit of time exploring the various Python Web frameworks
@@ -145,7 +146,7 @@ We've documented our philosophies on the
 :doc:`design philosophies page </misc/design-philosophies>`.
 
 Is Django a content-management-system (CMS)?
---------------------------------------------
+============================================
 
 No, Django is not a CMS, or any sort of "turnkey product" in and of itself.
 It's a Web framework; it's a programming tool that lets you build websites.
@@ -162,7 +163,7 @@ means!).
 .. _Drupal: https://drupal.org/
 
 How can I download the Django documentation to read it offline?
----------------------------------------------------------------
+===============================================================
 
 The Django docs are available in the ``docs`` directory of each Django tarball
 release. These docs are in reST (reStructuredText) format, and each text file
@@ -178,7 +179,7 @@ information than the docs that come with the latest Django release.
 .. _stored in revision control: https://github.com/django/django/tree/master/docs/
 
 Where can I find Django developers for hire?
---------------------------------------------
+============================================
 
 Consult our `developers for hire page`_ for a list of Django developers who
 would be happy to help you.
@@ -190,7 +191,7 @@ https://people.djangoproject.com/ .
 .. _developers for hire page: https://code.djangoproject.com/wiki/DevelopersForHire
 
 How do I cite Django?
----------------------
+=====================
 
 It's difficult to give an official citation format, for two reasons: citation
 formats can vary wildly between publications, and citation standards for
diff --git a/docs/faq/help.txt b/docs/faq/help.txt
index cdc68d40bf..6cc3ca68c7 100644
--- a/docs/faq/help.txt
+++ b/docs/faq/help.txt
@@ -1,8 +1,9 @@
+=================
 FAQ: Getting Help
 =================
 
 How do I do X? Why doesn't Y work? Where can I go to get help?
---------------------------------------------------------------
+==============================================================
 
 If this FAQ doesn't contain an answer to your question, you might want to
 try the |django-users| mailing list. Feel free to ask any question related
@@ -16,7 +17,7 @@ active community of helpful individuals who may be able to solve your problem.
 .. _message-does-not-appear-on-django-users:
 
 Why hasn't my message appeared on django-users?
------------------------------------------------
+===============================================
 
 |django-users| has a lot of subscribers. This is good for the community, as
 it means many people are available to contribute answers to questions.
@@ -30,7 +31,7 @@ list might take a little longer to get answered. We apologize for any
 inconvenience that this policy may cause.
 
 Nobody on django-users answered my question! What should I do?
---------------------------------------------------------------
+==============================================================
 
 Try making your question more specific, or provide a better example of your
 problem.
@@ -48,13 +49,13 @@ for discussion of the development of Django itself. Asking a tech support
 question there is considered quite impolite.
 
 I think I've found a bug! What should I do?
--------------------------------------------
+===========================================
 
 Detailed instructions on how to handle a potential bug can be found in our
 :ref:`Guide to contributing to Django <reporting-bugs>`.
 
 I think I've found a security problem! What should I do?
---------------------------------------------------------
+========================================================
 
 If you think you've found a security problem with Django, please send a message
 to security@djangoproject.com. This is a private list only open to long-time,
diff --git a/docs/faq/install.txt b/docs/faq/install.txt
index d4e7f28310..5564955a69 100644
--- a/docs/faq/install.txt
+++ b/docs/faq/install.txt
@@ -1,8 +1,9 @@
+=================
 FAQ: Installation
 =================
 
 How do I get started?
----------------------
+=====================
 
 #. `Download the code`_.
 #. Install Django (read the :doc:`installation guide </intro/install>`).
@@ -14,7 +15,7 @@ How do I get started?
 .. _ask questions: https://www.djangoproject.com/community/
 
 What are Django's prerequisites?
---------------------------------
+================================
 
 Django requires Python. See the table in the next question for the versions of
 Python that work with each version of Django. Other Python libraries may be
@@ -40,7 +41,7 @@ PostgreSQL fans, and MySQL_, `SQLite 3`_, and Oracle_ are also supported.
 .. _faq-python-version-support:
 
 What Python version can I use with Django?
-------------------------------------------
+==========================================
 
 ============== ===============
 Django version Python versions
@@ -60,7 +61,7 @@ version of Python ends. For example, Python 3.3 security support ends September
 is the last version to support Python 3.3.
 
 What Python version should I use with Django?
----------------------------------------------
+=============================================
 
 As of Django 1.6, Python 3 support is considered stable and you can safely use
 it in production. See also :doc:`/topics/python3`. However, the community is
@@ -81,7 +82,7 @@ Third-party applications for use with Django are, of course, free to set their
 own version requirements.
 
 Should I use the stable version or development version?
--------------------------------------------------------
+=======================================================
 
 Generally, if you're using code in production, you should be using a
 stable release. The Django project publishes a full stable release
diff --git a/docs/faq/models.txt b/docs/faq/models.txt
index 982b806c78..c6a7f28e23 100644
--- a/docs/faq/models.txt
+++ b/docs/faq/models.txt
@@ -1,10 +1,11 @@
+=========================
 FAQ: Databases and models
 =========================
 
 .. _faq-see-raw-sql-queries:
 
 How can I see the raw SQL queries Django is running?
-----------------------------------------------------
+====================================================
 
 Make sure your Django :setting:`DEBUG` setting is set to ``True``.
 Then, just do this::
@@ -37,12 +38,12 @@ just call ``reset_queries()``, like this::
     reset_queries()
 
 Can I use Django with a pre-existing database?
-----------------------------------------------
+==============================================
 
 Yes. See :doc:`Integrating with a legacy database </howto/legacy-databases>`.
 
 If I make changes to a model, how do I update the database?
------------------------------------------------------------
+===========================================================
 
 Take a look at Django's support for :mod:`schema migrations
 <django.db.migrations>`.
@@ -52,7 +53,7 @@ If you don't mind clearing data, your project's ``manage.py`` utility has a
 immediately after :djadmin:`migrate` was executed.
 
 Do Django models support multiple-column primary keys?
-------------------------------------------------------
+======================================================
 
 No. Only single-column primary keys are supported.
 
@@ -64,7 +65,7 @@ as the admin interface to work; e.g., you need a simple way of being able to
 specify an object to edit or delete.
 
 Does Django support NoSQL databases?
-------------------------------------
+====================================
 
 NoSQL databases are not officially supported by Django itself. There are,
 however, a number of side project and forks which allow NoSQL functionality in
@@ -76,7 +77,7 @@ You can also take a look on `the wiki page`_ which discusses some alternatives.
 .. _`the wiki page`: https://code.djangoproject.com/wiki/NoSqlSupport
 
 How do I add database-specific options to my CREATE TABLE statements, such as specifying MyISAM as the table type?
-------------------------------------------------------------------------------------------------------------------
+==================================================================================================================
 
 We try to avoid adding special cases in the Django code to accommodate all the
 database-specific options such as table type, etc. If you'd like to use any of
diff --git a/docs/faq/usage.txt b/docs/faq/usage.txt
index bd1c250896..9c659bd711 100644
--- a/docs/faq/usage.txt
+++ b/docs/faq/usage.txt
@@ -1,8 +1,9 @@
+=================
 FAQ: Using Django
 =================
 
 Why do I get an error about importing DJANGO_SETTINGS_MODULE?
--------------------------------------------------------------
+=============================================================
 
 Make sure that:
 
@@ -14,7 +15,7 @@ Make sure that:
 * The module doesn't contain syntax errors (of course).
 
 I can't stand your template language. Do I have to use it?
-----------------------------------------------------------
+==========================================================
 
 We happen to think our template engine is the best thing since chunky bacon,
 but we recognize that choosing a template language runs close to religion.
@@ -22,7 +23,7 @@ There's nothing about Django that requires using the template language, so
 if you're attached to Jinja2, Mako, or whatever, feel free to use those.
 
 Do I have to use your model/database layer?
--------------------------------------------
+===========================================
 
 Nope. Just like the template system, the model/database layer is decoupled from
 the rest of the framework.
@@ -32,7 +33,7 @@ use Django's automatically-generated admin site. That app is coupled to the
 Django database layer.
 
 How do I use image and file fields?
------------------------------------
+===================================
 
 Using a :class:`~django.db.models.FileField` or an
 :class:`~django.db.models.ImageField` in a model takes a few steps:
@@ -58,7 +59,7 @@ Using a :class:`~django.db.models.FileField` or an
    ``{{ object.mug_shot.url }}``.
 
 How do I make a variable available to all my templates?
--------------------------------------------------------
+=======================================================
 
 Sometimes your templates just all need the same thing. A common example would
 be dynamically-generated menus. At first glance, it seems logical to simply
diff --git a/docs/glossary.txt b/docs/glossary.txt
index c7a16e6b3d..f24a33e81d 100644
--- a/docs/glossary.txt
+++ b/docs/glossary.txt
@@ -1,5 +1,3 @@
-.. _glossary:
-
 ========
 Glossary
 ========
diff --git a/docs/howto/custom-file-storage.txt b/docs/howto/custom-file-storage.txt
index 5140911591..3d5e357395 100644
--- a/docs/howto/custom-file-storage.txt
+++ b/docs/howto/custom-file-storage.txt
@@ -1,3 +1,4 @@
+===============================
 Writing a custom storage system
 ===============================
 
diff --git a/docs/howto/custom-lookups.txt b/docs/howto/custom-lookups.txt
index a795326c21..87a388283a 100644
--- a/docs/howto/custom-lookups.txt
+++ b/docs/howto/custom-lookups.txt
@@ -10,7 +10,7 @@ explains how to write custom lookups and how to alter the working of existing
 lookups. For the API references of lookups, see the :doc:`/ref/models/lookups`.
 
 A simple lookup example
-~~~~~~~~~~~~~~~~~~~~~~~
+=======================
 
 Let's start with a simple custom lookup. We will write a custom lookup ``ne``
 which works opposite to ``exact``. ``Author.objects.filter(name__ne='Jack')``
@@ -97,7 +97,7 @@ the parameters for the query. We then return a tuple containing the generated
 SQL string and the parameters.
 
 A simple transformer example
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+============================
 
 The custom lookup above is great, but in some cases you may want to be able to
 chain lookups together. For example, let's suppose we are building an
@@ -163,8 +163,8 @@ be done by adding an ``output_field`` attribute to the transform::
 This ensures that further lookups like ``abs__lte`` behave as they would for
 a ``FloatField``.
 
-Writing an efficient abs__lt lookup
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Writing an efficient ``abs__lt`` lookup
+=======================================
 
 When using the above written ``abs`` lookup, the SQL produced will not use
 indexes efficiently in some cases. In particular, when we use
@@ -215,7 +215,7 @@ transformations in Python.
     be very efficient.
 
 A bilateral transformer example
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+===============================
 
 The ``AbsoluteValue`` example we discussed previously is a transformation which
 applies to the left-hand side of the lookup. There may be some cases where you
@@ -252,7 +252,7 @@ insensitive query like this::
     SELECT ... WHERE UPPER("author"."name") = UPPER('doe')
 
 Writing alternative implementations for existing lookups
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+========================================================
 
 Sometimes different database vendors require different SQL for the same
 operation. For this example we will rewrite a custom implementation for
@@ -280,7 +280,7 @@ methods, and then falls back to ``as_sql``. The vendor names for the in-built
 backends are ``sqlite``, ``postgresql``, ``oracle`` and ``mysql``.
 
 How Django determines the lookups and transforms which are used
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+===============================================================
 
 In some cases you may wish to dynamically change which ``Transform`` or
 ``Lookup`` is returned based on the name passed in, rather than fixing it. As
diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt
index 5beed7637e..08e666d86c 100644
--- a/docs/howto/custom-template-tags.txt
+++ b/docs/howto/custom-template-tags.txt
@@ -11,7 +11,7 @@ defining custom tags and filters using Python, and then make them
 available to your templates using the :ttag:`{% load %}<load>` tag.
 
 Code layout
------------
+===========
 
 The most common place to specify custom template tags and filters is inside
 a Django app. If they relate to an existing app, it makes sense to bundle them
@@ -89,7 +89,7 @@ an application.
 .. _howto-writing-custom-template-filters:
 
 Writing custom template filters
--------------------------------
+===============================
 
 Custom filters are just Python functions that take one or two arguments:
 
@@ -127,7 +127,7 @@ your function. Example::
         return value.lower()
 
 Registering custom filters
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 .. method:: django.template.Library.filter()
 
@@ -162,7 +162,7 @@ are described in :ref:`filters and auto-escaping <filters-auto-escaping>` and
 :ref:`filters and time zones <filters-timezones>` below.
 
 Template filters that expect strings
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
 
 .. method:: django.template.defaultfilters.stringfilter()
 
@@ -187,7 +187,7 @@ methods).
 .. _filters-auto-escaping:
 
 Filters and auto-escaping
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 When writing a custom filter, give some thought to how the filter will interact
 with Django's auto-escaping behavior. Note that three types of strings can be
@@ -378,7 +378,7 @@ Template filter code falls into one of two situations:
 .. _filters-timezones:
 
 Filters and time zones
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 If you write a custom filter that operates on :class:`~datetime.datetime`
 objects, you'll usually register it with the ``expects_localtime`` flag set to
@@ -399,7 +399,7 @@ conversions in templates <time-zones-in-templates>`.
 .. _howto-writing-custom-template-tags:
 
 Writing custom template tags
-----------------------------
+============================
 
 Tags are more complex than filters, because tags can do anything. Django
 provides a number of shortcuts that make writing most types of tags easier.
@@ -409,7 +409,7 @@ scratch for those cases when the shortcuts aren't powerful enough.
 .. _howto-custom-template-tags-simple-tags:
 
 Simple tags
-~~~~~~~~~~~
+-----------
 
 .. method:: django.template.Library.simple_tag()
 
@@ -516,7 +516,7 @@ you see fit:
 .. _howto-custom-template-tags-inclusion-tags:
 
 Inclusion tags
-~~~~~~~~~~~~~~
+--------------
 
 .. method:: django.template.Library.inclusion_tag()
 
@@ -650,7 +650,7 @@ positional arguments. For example:
     {% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
 
 Assignment tags
-~~~~~~~~~~~~~~~
+---------------
 
 .. method:: django.template.Library.assignment_tag()
 
@@ -679,14 +679,14 @@ followed by the variable name, and output it yourself where you see fit:
     <p>The time is {{ the_time }}.</p>
 
 Advanced custom template tags
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 Sometimes the basic features for custom template tag creation aren't enough.
 Don't worry, Django gives you complete access to the internals required to build
 a template tag from the ground up.
 
 A quick overview
-~~~~~~~~~~~~~~~~
+----------------
 
 The template system works in a two-step process: compiling and rendering. To
 define a custom template tag, you specify how the compilation works and how
@@ -704,7 +704,7 @@ converted into a ``Node`` (the compilation function), and what the node's
 ``render()`` method does.
 
 Writing the compilation function
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 For each template tag the template parser encounters, it calls a Python
 function with the tag contents and the parser object itself. This function is
@@ -774,7 +774,7 @@ Notes:
   engine too slow. It's low-level because that's fastest.
 
 Writing the renderer
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 The second step in writing custom tags is to define a ``Node`` subclass that
 has a ``render()`` method.
@@ -813,7 +813,7 @@ without having to be parsed multiple times.
 .. _tags-auto-escaping:
 
 Auto-escaping considerations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 The output from template tags is **not** automatically run through the
 auto-escaping filters (with the exception of
@@ -864,7 +864,7 @@ tag is used inside a :ttag:`{% autoescape off %}<autoescape>` block.
 .. _template_tag_thread_safety:
 
 Thread-safety considerations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Once a node is parsed, its ``render`` method may be called any number of times.
 Since Django is sometimes run in multi-threaded environments, a single node may
@@ -947,7 +947,7 @@ like the current iteration of the ``CycleNode``, should be stored in the
     variables, make ``render_context[self]`` a dictionary.
 
 Registering the tag
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 Finally, register the tag with your module's ``Library`` instance, as explained
 in :ref:`writing custom template filters<howto-writing-custom-template-tags>`
@@ -976,7 +976,7 @@ If you leave off the ``name`` argument, as in the second example above, Django
 will use the function's name as the tag name.
 
 Passing template variables to the tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Although you can pass any number of arguments to a template tag using
 ``token.split_contents()``, the arguments are all unpacked as
@@ -1043,7 +1043,7 @@ Variable resolution will throw a ``VariableDoesNotExist`` exception if it
 cannot resolve the string passed to it in the current context of the page.
 
 Setting a variable in the context
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The above examples simply output a value. Generally, it's more flexible if your
 template tags set template variables instead of outputting values. That way,
@@ -1134,7 +1134,7 @@ context-updating template tag, consider using the
 the tag results to a template variable.
 
 Parsing until another block tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Template tags can work in tandem. For instance, the standard
 :ttag:`{% comment %}<comment>` tag hides everything until ``{% endcomment %}``.
@@ -1178,7 +1178,7 @@ After ``parser.parse()`` is called, the parser hasn't yet "consumed" the
 ``{% comment %}`` and ``{% endcomment %}`` is ignored.
 
 Parsing until another block tag, and saving contents
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 In the previous example, ``do_comment()`` discarded everything between
 ``{% comment %}`` and ``{% endcomment %}``. Instead of doing that, it's
diff --git a/docs/howto/deployment/index.txt b/docs/howto/deployment/index.txt
index 4acde03699..8ffda2cf63 100644
--- a/docs/howto/deployment/index.txt
+++ b/docs/howto/deployment/index.txt
@@ -1,3 +1,4 @@
+================
 Deploying Django
 ================
 
diff --git a/docs/howto/deployment/wsgi/index.txt b/docs/howto/deployment/wsgi/index.txt
index 27243e248c..2579df0c6a 100644
--- a/docs/howto/deployment/wsgi/index.txt
+++ b/docs/howto/deployment/wsgi/index.txt
@@ -22,7 +22,7 @@ Django includes getting-started documentation for the following WSGI servers:
    uwsgi
 
 The ``application`` object
---------------------------
+==========================
 
 The key concept of deploying with WSGI is the ``application`` callable which
 the application server uses to communicate with your code. It's commonly
@@ -42,7 +42,7 @@ set to ``<project_name>.wsgi.application``, which points to the ``application``
 callable in :file:`<project_name>/wsgi.py`.
 
 Configuring the settings module
--------------------------------
+===============================
 
 When the WSGI server loads your application, Django needs to import the
 settings module — that's where your entire application is defined.
@@ -68,7 +68,7 @@ If this variable isn't set, the default :file:`wsgi.py` sets it to
 
 
 Applying WSGI middleware
-------------------------
+========================
 
 To apply `WSGI middleware`_ you can simply wrap the application object. For
 instance you could add these lines at the bottom of :file:`wsgi.py`::
diff --git a/docs/howto/error-reporting.txt b/docs/howto/error-reporting.txt
index d27f734398..fc043375d4 100644
--- a/docs/howto/error-reporting.txt
+++ b/docs/howto/error-reporting.txt
@@ -1,3 +1,4 @@
+===============
 Error reporting
 ===============
 
@@ -12,10 +13,10 @@ You need to keep track of errors that occur in deployed sites, so Django can be
 configured to create reports with details about those errors.
 
 Email reports
--------------
+=============
 
 Server errors
-~~~~~~~~~~~~~
+-------------
 
 When :setting:`DEBUG` is ``False``, Django will email the users listed in the
 :setting:`ADMINS` setting whenever your code raises an unhandled exception and
@@ -49,7 +50,7 @@ To activate this behavior, put the email addresses of the recipients in the
     </topics/logging>`.
 
 404 errors
-~~~~~~~~~~
+----------
 
 Django can also be configured to email errors about broken links (404 "page
 not found" errors). Django sends emails about 404 errors when:
@@ -119,7 +120,7 @@ and override its methods.
 .. _filtering-error-reports:
 
 Filtering error reports
------------------------
+=======================
 
 .. warning::
 
@@ -130,7 +131,7 @@ Filtering error reports
     through email).
 
 Filtering sensitive information
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 .. currentmodule:: django.views.decorators.debug
 
@@ -231,7 +232,7 @@ production environment (that is, where :setting:`DEBUG` is set to ``False``):
 .. _custom-error-reports:
 
 Custom error reports
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 All :func:`sensitive_variables` and :func:`sensitive_post_parameters` do is,
 respectively, annotate the decorated function with the names of sensitive
diff --git a/docs/howto/index.txt b/docs/howto/index.txt
index f06cd6b627..89e3192810 100644
--- a/docs/howto/index.txt
+++ b/docs/howto/index.txt
@@ -1,3 +1,4 @@
+===============
 "How-to" guides
 ===============
 
diff --git a/docs/howto/outputting-csv.txt b/docs/howto/outputting-csv.txt
index f341482167..2d9fded5c2 100644
--- a/docs/howto/outputting-csv.txt
+++ b/docs/howto/outputting-csv.txt
@@ -76,7 +76,7 @@ mention:
 .. _streaming-csv-files:
 
 Streaming large CSV files
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 When dealing with views that generate very large responses, you might want to
 consider using Django's :class:`~django.http.StreamingHttpResponse` instead.
diff --git a/docs/howto/writing-migrations.txt b/docs/howto/writing-migrations.txt
index 5527302fa8..096b5e3b15 100644
--- a/docs/howto/writing-migrations.txt
+++ b/docs/howto/writing-migrations.txt
@@ -9,7 +9,7 @@ migrations, see :doc:`the topic guide </topics/migrations>`.
 .. _data-migrations-and-multiple-databases:
 
 Data migrations and multiple databases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+======================================
 
 When using multiple databases, you may need to figure out whether or not to
 run a migration against a particular database. For example, you may want to
@@ -74,7 +74,7 @@ practice to pass ``model_name`` as a hint to make it as transparent as possible
 to the router. This is especially important for reusable and third-party apps.
 
 Migrations that add unique fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+=================================
 
 Applying a "plain" migration that adds a unique non-nullable field to a table
 with existing rows will raise an error because the value used to populate
@@ -187,7 +187,7 @@ the respective field according to your needs.
   ``RunPython`` will have their original ``uuid``’s overwritten.
 
 Controlling the order of migrations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+===================================
 
 Django determines the order in which migrations should be applied not by the
 filename of each migration, but by building a graph using two properties on the
diff --git a/docs/index.txt b/docs/index.txt
index eee8c680f0..1a2bc2667e 100644
--- a/docs/index.txt
+++ b/docs/index.txt
@@ -1,6 +1,3 @@
-
-.. _index:
-
 ====================
 Django documentation
 ====================
diff --git a/docs/internals/contributing/bugs-and-features.txt b/docs/internals/contributing/bugs-and-features.txt
index c6b3d494ff..5f44c467b5 100644
--- a/docs/internals/contributing/bugs-and-features.txt
+++ b/docs/internals/contributing/bugs-and-features.txt
@@ -32,7 +32,7 @@ general points:
 .. _reporting-bugs:
 
 Reporting bugs
---------------
+==============
 
 Well-written bug reports are *incredibly* helpful. However, there's a certain
 amount of overhead involved in working with any bug tracking system so your
@@ -61,7 +61,7 @@ To understand the lifecycle of your ticket once you have created it, refer to
 :doc:`triaging-tickets`.
 
 Reporting user interface bugs and features
-------------------------------------------
+==========================================
 
 If your bug or feature request touches on anything visual in nature, there
 are a few additional guidelines to follow:
@@ -87,7 +87,7 @@ are a few additional guidelines to follow:
   find your ticket.
 
 Requesting features
--------------------
+===================
 
 We're always trying to make Django better, and your feature requests are a key
 part of that. Here are some tips on how to make a request most effectively:
@@ -128,7 +128,7 @@ See also: :ref:`documenting-new-features`.
 .. _how-we-make-decisions:
 
 How we make decisions
----------------------
+=====================
 
 Whenever possible, we strive for a rough consensus. To that end, we'll often
 have informal votes on |django-developers| about a feature. In these votes we
diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index d2e415d986..211bdf011f 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -10,7 +10,7 @@ who wants to contribute code to Django, have a look at
 .. _handling-pull-requests:
 
 Handling pull requests
-----------------------
+======================
 
 Since Django is now hosted at GitHub, most patches are provided in the form of
 pull requests.
@@ -101,7 +101,7 @@ community, getting work done, and having a usable commit history.
 .. _committing-guidelines:
 
 Committing guidelines
----------------------
+=====================
 
 In addition, please follow the following guidelines when committing code to
 Django's Git repository:
@@ -200,7 +200,7 @@ Django's Git repository:
   to automate this.
 
 Reverting commits
------------------
+=================
 
 Nobody's perfect; mistakes will be committed.
 
diff --git a/docs/internals/contributing/localizing.txt b/docs/internals/contributing/localizing.txt
index e59286784f..e3df902549 100644
--- a/docs/internals/contributing/localizing.txt
+++ b/docs/internals/contributing/localizing.txt
@@ -9,7 +9,7 @@ and localization infrastructure available to Django applications, described in
 the :doc:`i18n documentation </topics/i18n/index>`.
 
 Translations
-------------
+============
 
 Translations are contributed by Django users worldwide. The translation work is
 coordinated at `Transifex`_.
@@ -53,11 +53,11 @@ translation manager's availability. So don't miss the string freeze period
 to complete and fix the translations for your language!
 
 Formats
--------
+=======
 
 You can also review ``conf/locale/<locale>/formats.py``. This file describes
 the date, time and numbers formatting particularities of your locale. See
-:ref:`format-localization` for details.
+:doc:`/topics/i18n/formatting` for details.
 
 The format files aren't managed by the use of Transifex. To change them, you
 must :doc:`create a patch<writing-code/submitting-patches>` against the
@@ -75,7 +75,7 @@ Django source tree, as for any code change:
 .. _translating-documentation:
 
 Documentation
--------------
+=============
 
 There is also an opportunity to translate the documentation, though this is a
 huge undertaking to complete entirely (you have been warned!). We use the same
diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index 8a59ecd20e..a52e524f57 100644
--- a/docs/internals/contributing/new-contributors.txt
+++ b/docs/internals/contributing/new-contributors.txt
@@ -11,7 +11,7 @@ to get started? This is the section for you.
     tutorial will give you an introduction to the tools and the workflow.
 
 First steps
------------
+===========
 
 Start with these easy tasks to discover Django's development process.
 
@@ -70,7 +70,7 @@ Start with these easy tasks to discover Django's development process.
 
 
 Guidelines
-----------
+==========
 
 As a newcomer on a large project, it's easy to experience frustration. Here's
 some advice to make your work on Django more useful and rewarding.
@@ -138,7 +138,7 @@ some advice to make your work on Django more useful and rewarding.
 .. _new-contributors-faq:
 
 FAQ
----
+===
 
 1. **This ticket I care about has been ignored for days/weeks/months! What can
    I do to get it committed?**
diff --git a/docs/internals/contributing/triaging-tickets.txt b/docs/internals/contributing/triaging-tickets.txt
index c3a8e1d765..c121e86b26 100644
--- a/docs/internals/contributing/triaging-tickets.txt
+++ b/docs/internals/contributing/triaging-tickets.txt
@@ -32,7 +32,7 @@ Django is a community project, and every contribution helps. We can't do this
 without **you**!
 
 Triage workflow
----------------
+===============
 
 Unfortunately, not all bug reports and feature requests in the ticket tracker
 provide all the :doc:`required details<bugs-and-features>`. A number of
@@ -96,20 +96,20 @@ require much much more.
 .. _triage-stages:
 
 Triage stages
--------------
+=============
 
 Below we describe in more detail the various stages that a ticket may flow
 through during its lifetime.
 
 Unreviewed
-~~~~~~~~~~
+----------
 
 The ticket has not been reviewed by anyone who felt qualified to make a
 judgment about whether the ticket contained a valid issue, a viable feature,
 or ought to be closed for any of the various reasons.
 
 Accepted
-~~~~~~~~
+--------
 
 The big gray area! The absolute meaning of "accepted" is that the issue
 described in the ticket is valid and is in some stage of being worked on.
@@ -142,7 +142,7 @@ Beyond that there are several considerations:
   explaining what is needed to improve the code.
 
 Ready For Checkin
-~~~~~~~~~~~~~~~~~
+-----------------
 
 The ticket was reviewed by any member of the community other than the person
 who supplied the patch and found to meet all the requirements for a
@@ -152,7 +152,7 @@ review prior to being committed. See the
 RFC forever! What should I do?"
 
 Someday/Maybe
-~~~~~~~~~~~~~
+-------------
 
 This stage isn't shown on the diagram. It's only used by core developers to
 keep track of high-level ideas or long term feature requests.
@@ -163,12 +163,12 @@ consider adding someday to the framework if an excellent patch is submitted.
 They are not a high priority.
 
 Other triage attributes
------------------------
+=======================
 
 A number of flags, appearing as checkboxes in Trac, can be set on a ticket:
 
 Has patch
-~~~~~~~~~
+---------
 
 This means the ticket has an associated
 :doc:`patch<writing-code/submitting-patches>`. These will be reviewed
@@ -178,20 +178,20 @@ The following three fields (Needs documentation, Needs tests,
 Patch needs improvement) apply only if a patch has been supplied.
 
 Needs documentation
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 This flag is used for tickets with patches that need associated
 documentation. Complete documentation of features is a prerequisite
 before we can check them into the codebase.
 
 Needs tests
-~~~~~~~~~~~
+-----------
 
 This flags the patch as needing associated unit tests. Again, this
 is a required part of a valid patch.
 
 Patch needs improvement
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 This flag means that although the ticket *has* a patch, it's not quite
 ready for checkin. This could mean the patch no longer applies
@@ -199,12 +199,12 @@ cleanly, there is a flaw in the implementation, or that the code
 doesn't meet our standards.
 
 Easy pickings
-~~~~~~~~~~~~~
+-------------
 
 Tickets that would require small, easy, patches.
 
 Type
-~~~~
+----
 
 Tickets should be categorized by *type* between:
 
@@ -219,14 +219,14 @@ Tickets should be categorized by *type* between:
     better, faster, stronger.
 
 Component
-~~~~~~~~~
+---------
 
 Tickets should be classified into *components* indicating which area of
 the Django codebase they belong to. This makes tickets better organized and
 easier to find.
 
 Severity
-~~~~~~~~
+--------
 
 The *severity* attribute is used to identify blockers, that is, issues which
 should get fixed before releasing the next version of Django. Typically those
@@ -235,26 +235,26 @@ causing severe data losses. This attribute is quite rarely used and the vast
 majority of tickets have a severity of "Normal".
 
 Version
-~~~~~~~
+-------
 
 It is possible to use the *version* attribute to indicate in which
 version the reported bug was identified.
 
 UI/UX
-~~~~~
+-----
 
 This flag is used for tickets that relate to User Interface and User
 Experiences questions. For example, this flag would be appropriate for
 user-facing features in forms or the admin interface.
 
 Cc
-~~
+--
 
 You may add your username or email address to this field to be notified when
 new contributions are made to the ticket.
 
 Keywords
-~~~~~~~~
+--------
 
 With this field you may label a ticket with multiple keywords. This can be
 useful, for example, to group several tickets of a same theme. Keywords can
@@ -266,7 +266,7 @@ as "formset", "modelformset", and "ManagementForm".
 .. _closing-tickets:
 
 Closing Tickets
----------------
+===============
 
 When a ticket has completed its useful lifecycle, it's time for it to be
 closed. Closing a ticket is a big responsibility, though. You have to be sure
@@ -338,7 +338,7 @@ developers and bring the issue to |django-developers| instead.
 .. _how-can-i-help-with-triaging:
 
 How can I help with triaging?
------------------------------
+=============================
 
 The triage process is primarily driven by community members. Really,
 **ANYONE** can help.
@@ -422,7 +422,7 @@ the ticket database:
 .. _password reset page: https://www.djangoproject.com/accounts/password/reset/
 
 Bisecting a regression
-----------------------
+======================
 
 .. highlight:: console
 
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt
index bdf1c4bb45..7c74c00bdf 100644
--- a/docs/internals/contributing/writing-code/coding-style.txt
+++ b/docs/internals/contributing/writing-code/coding-style.txt
@@ -5,7 +5,7 @@ Coding style
 Please follow these coding standards when writing code for inclusion in Django.
 
 Python style
-------------
+============
 
 * Please conform to the indentation style dictated in the ``.editorconfig``
   file. We recommend using a text editor with `EditorConfig`_ support to avoid
@@ -52,7 +52,7 @@ Python style
   to use regular expression matching.
 
 Imports
--------
+=======
 
 * Use `isort <https://github.com/timothycrosley/isort#readme>`_ to automate
   import sorting using the guidelines below.
@@ -132,7 +132,7 @@ Imports
       from django.views.generic.base import View
 
 Template style
---------------
+==============
 
 * In Django template code, put one (and only one) space between the curly
   brackets and the tag contents.
@@ -150,7 +150,7 @@ Template style
       {{foo}}
 
 View style
-----------
+==========
 
 * In Django views, the first parameter in a view function should be called
   ``request``.
@@ -166,7 +166,7 @@ View style
           # ...
 
 Model style
------------
+===========
 
 * Field names should be all lowercase, using underscores instead of
   camelCase.
@@ -240,7 +240,7 @@ Model style
         )
 
 Use of ``django.conf.settings``
--------------------------------
+===============================
 
 Modules should not in general use settings stored in ``django.conf.settings``
 at the top level (i.e. evaluated when the module is imported). The explanation
@@ -276,7 +276,7 @@ such as ``django.utils.functional.LazyObject``,
 ``django.utils.functional.lazy()`` or ``lambda``.
 
 Miscellaneous
--------------
+=============
 
 * Mark all strings for internationalization; see the :doc:`i18n
   documentation </topics/i18n/index>` for details.
@@ -299,7 +299,7 @@ Miscellaneous
   single trivial change.
 
 JavaScript style
-----------------
+================
 
 For details about the JavaScript code style used by Django, see
 :doc:`javascript`.
diff --git a/docs/internals/contributing/writing-code/javascript.txt b/docs/internals/contributing/writing-code/javascript.txt
index a3b34c564e..8b8534e384 100644
--- a/docs/internals/contributing/writing-code/javascript.txt
+++ b/docs/internals/contributing/writing-code/javascript.txt
@@ -9,7 +9,7 @@ Please follow these coding standards when writing JavaScript code for inclusion
 in Django.
 
 Code style
-----------
+==========
 
 * Please conform to the indentation style dictated in the ``.editorconfig``
   file. We recommend using a text editor with `EditorConfig`_ support to avoid
@@ -27,7 +27,7 @@ Code style
 .. _javascript-patches:
 
 JavaScript patches
-------------------
+==================
 
 Django's admin system leverages the jQuery framework to increase the
 capabilities of the admin interface. In conjunction, there is an emphasis on
@@ -41,7 +41,7 @@ production use (e.g. ``foo.min.js``). Any links to the file in the codebase
 should point to the compressed version.
 
 Compressing JavaScript
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 To simplify the process of providing optimized JavaScript code, Django
 includes a handy Python script which should be used to create a "minified"
@@ -61,13 +61,13 @@ Please don't forget to run ``compress.py`` and include the ``diff`` of the
 minified scripts when submitting patches for Django's JavaScript.
 
 JavaScript tests
-----------------
+================
 
 Django's JavaScript tests can be run in a browser or from the command line.
 The tests are located in a top level ``js_tests`` directory.
 
 Writing tests
-~~~~~~~~~~~~~
+-------------
 
 Django's JavaScript tests use `QUnit`_. Here is an example test module:
 
@@ -101,12 +101,12 @@ Please consult the QUnit documentation for information on the types of
 `assertions supported by QUnit <https://api.qunitjs.com/category/assert/>`_.
 
 Running tests
-~~~~~~~~~~~~~
+-------------
 
 The JavaScript tests may be run from a web browser or from the command line.
 
 Testing from a web browser
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To run the tests from a web browser, open up ``js_tests/tests.html`` in your
 browser.
@@ -119,7 +119,7 @@ over HTTP. To view code coverage:
 * Open http://localhost:8000/js_tests/tests.html in your web browser.
 
 Testing from the command line
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 To run the tests from the command line, you need to have `Node.js`_ installed.
 
diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt
index d90f010926..471c2812a2 100644
--- a/docs/internals/contributing/writing-code/submitting-patches.txt
+++ b/docs/internals/contributing/writing-code/submitting-patches.txt
@@ -7,7 +7,7 @@ with associated patches will get fixed *far* more quickly than those
 without patches.
 
 Typo fixes and trivial documentation changes
---------------------------------------------
+============================================
 
 If you are fixing a really trivial issue, for example changing a word in the
 documentation, the preferred way to provide the patch is using GitHub pull
@@ -16,7 +16,7 @@ requests without a Trac ticket.
 See the :doc:`working-with-git` for more details on how to use pull requests.
 
 "Claiming" tickets
-------------------
+==================
 
 In an open-source project with hundreds of contributors around the world, it's
 important to manage communication efficiently so that work doesn't get
@@ -62,7 +62,7 @@ and time availability), claim it by following these steps:
 .. _Contributor License Agreement: https://www.djangoproject.com/foundation/cla/
 
 Ticket claimers' responsibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Once you've claimed a ticket, you have a responsibility to work on that ticket
 in a reasonably timely fashion. If you don't have time to work on it, either
@@ -80,7 +80,7 @@ your claim on the ticket may be revoked.
 As always, more communication is better than less communication!
 
 Which tickets should be claimed?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Of course, going through the steps of claiming tickets is overkill in some
 cases.
@@ -96,7 +96,7 @@ or not, to submit patches to a ticket if you happen to have a patch ready.
 .. _patch-style:
 
 Patch style
------------
+===========
 
 Make sure that any contribution you do fulfills at least the following
 requirements:
@@ -143,7 +143,7 @@ Regardless of the way you submit your work, follow these steps.
 .. _Development dashboard: https://dashboard.djangoproject.com/
 
 Non-trivial patches
--------------------
+===================
 
 A "non-trivial" patch is one that is more than a simple bug fix. It's a patch
 that introduces Django functionality and makes some sort of design decision.
@@ -157,7 +157,7 @@ ask.
 .. _deprecating-a-feature:
 
 Deprecating a feature
----------------------
+=====================
 
 There are a couple reasons that code in Django might be deprecated:
 
@@ -239,7 +239,7 @@ In each :term:`feature release`, all ``RemovedInDjangoXXWarning``\s matching
 the new version are removed.
 
 JavaScript patches
-------------------
+==================
 
 For information on JavaScript patches, see the :ref:`javascript-patches`
 documentation.
@@ -247,7 +247,7 @@ documentation.
 .. _patch-review-checklist:
 
 Patch review checklist
-----------------------
+======================
 
 Use this checklist to review a pull request. If you are reviewing a pull
 request that is not your own and it passes all the criteria below, please set
@@ -266,7 +266,7 @@ Looking to get your patch reviewed? Ensure the Trac flags on the ticket are
 set so that the ticket appears in that queue.
 
 Documentation
-~~~~~~~~~~~~~
+-------------
 
 * Does the documentation build without any errors (``make html``, or
   ``make.bat html`` on Windows, from the ``docs`` directory)?
@@ -275,13 +275,13 @@ Documentation
 * Are there any :ref:`spelling errors <documentation-spelling-check>`?
 
 Bugs
-~~~~
+----
 
 * Is there a proper regression test (the test should fail before the fix
   is applied)?
 
 New Features
-~~~~~~~~~~~~
+------------
 
 * Are there tests to "exercise" all of the new code?
 * Is there a release note in ``docs/releases/A.B.txt``?
@@ -290,12 +290,12 @@ New Features
   ``.. versionadded:: A.B`` or ``.. versionchanged:: A.B``?
 
 Deprecating a feature
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 See the :ref:`deprecating-a-feature` guide.
 
 All code changes
-~~~~~~~~~~~~~~~~
+----------------
 
 * Does the :doc:`coding style
   </internals/contributing/writing-code/coding-style>` conform to our
@@ -306,7 +306,7 @@ All code changes
   to build the pull request against our continuous integration server.
 
 All tickets
-~~~~~~~~~~~
+-----------
 
 * Is the pull request a single squashed commit with a message that follows our
   :ref:`commit message format <committing-guidelines>`?
diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt
index 6cb0900211..9aa4db2864 100644
--- a/docs/internals/contributing/writing-code/unit-tests.txt
+++ b/docs/internals/contributing/writing-code/unit-tests.txt
@@ -16,10 +16,10 @@ how to write new tests.
 .. _running-unit-tests:
 
 Running the unit tests
-----------------------
+======================
 
 Quickstart
-~~~~~~~~~~
+----------
 
 If you are on Python 2, you'll first need to install a backport of the
 ``unittest.mock`` module that's available in Python 3. See
@@ -48,7 +48,7 @@ Having problems? See :ref:`troubleshooting-unit-tests` for some common issues.
 .. _running-unit-tests-settings:
 
 Using another ``settings`` module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The included settings module allows you to run the test suite using
 SQLite. If you want to test behavior using a different database (and
@@ -92,7 +92,7 @@ test settings dictionary for the applicable database.
 .. _runtests-specifying-labels:
 
 Running only some of the tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 Django's entire test suite takes a while to run, and running every single test
 could be redundant if, say, you just added a test to Django that you want to
@@ -119,7 +119,7 @@ Going beyond that, you can specify an individual test method like this::
    $ ./runtests.py --settings=path.to.settings i18n.tests.TranslationTests.test_lazy_objects
 
 Running the Selenium tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Some tests require Selenium and a Web browser (Firefox, Google Chrome, or
 Internet Explorer). To allow those tests to be run rather than skipped, you must
@@ -131,7 +131,7 @@ install the selenium_ package into your Python path and run the tests with the
 .. _running-unit-tests-dependencies:
 
 Running all the tests
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 If you want to run the full suite of tests, you'll need to install a number of
 dependencies:
@@ -186,7 +186,7 @@ associated tests will be skipped.
 .. _pip requirements files: https://pip.pypa.io/en/latest/user_guide.html#requirements-files
 
 Code coverage
-~~~~~~~~~~~~~
+-------------
 
 Contributors are encouraged to run coverage on the test suite to identify areas
 that need additional tests. The coverage tool installation and use is described
@@ -209,7 +209,7 @@ and also excludes several directories not relevant to the results
 .. _contrib-apps:
 
 Contrib apps
-------------
+============
 
 Tests for contrib apps can be found in the ``tests/`` directory, typically
 under ``<app_name>_tests``. For example, tests for ``contrib.auth`` are located
@@ -218,10 +218,10 @@ in ``tests/auth_tests``.
 .. _troubleshooting-unit-tests:
 
 Troubleshooting
----------------
+===============
 
 Many test failures with ``UnicodeEncodeError``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 If the ``locales`` package is not installed, some tests will fail with a
 ``UnicodeEncodeError``.
@@ -232,7 +232,7 @@ You can resolve this on Debian-based systems, for example, by running::
     $ dpkg-reconfigure locales
 
 Tests that only fail in combination
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 In case a test passes when run in isolation but fails within the whole suite,
 we have some tools to help analyze the problem.
@@ -277,7 +277,7 @@ cause any trouble::
     $ ./runtests.py basic --reverse
 
 Seeing the SQL queries run during a test
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 If you wish to examine the SQL being run in failing tests, you can turn on
 :ref:`SQL logging <django-db-logger>` using the ``--debug-sql`` option. If you
@@ -290,7 +290,7 @@ combine this with ``--verbosity=2``, all SQL queries will be output::
     The ``--reverse`` and ``--debug-sql`` options were added.
 
 Seeing the full traceback of a test failure
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 By default tests are run in parallel with one process per core. When the tests
 are run in parallel, however, you'll only see a truncated traceback for any
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index c7d551f24d..a7588361f2 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -1,3 +1,4 @@
+===========================
 Working with Git and GitHub
 ===========================
 
@@ -14,7 +15,7 @@ You could also upload a traditional patch to Trac, but it's less practical for
 reviews.
 
 Installing Git
---------------
+==============
 
 Django uses `Git`_ for its source control. You can `download
 <http://git-scm.com/download>`_ Git, but it's often easier to install with
@@ -38,7 +39,7 @@ used to associate your commits with your GitHub account.
 .. _GitHub: https://github.com/
 
 Setting up local repository
----------------------------
+===========================
 
 When you have created your GitHub account, with the nick "GitHub_nick", and
 forked Django's repository, create a local copy of your fork::
@@ -64,7 +65,7 @@ You can add other remotes similarly, for example::
     git remote add akaariai git@github.com:akaariai/django.git
 
 Working on a ticket
--------------------
+===================
 
 When working on a ticket create a new branch for the work, and base that work
 on upstream/master::
@@ -94,7 +95,7 @@ necessary::
     git commit -m 'Added two more tests for edge cases'
 
 Publishing work
-~~~~~~~~~~~~~~~
+---------------
 
 You can publish your work on GitHub just by doing::
 
@@ -143,7 +144,7 @@ ready for merging -- or sufficiently close that a committer will finish it
 himself.
 
 Rebasing branches
-~~~~~~~~~~~~~~~~~
+-----------------
 
 In the example above you created two commits, the "Fixed ticket_xxxxx" commit
 and "Added two more tests" commit.
@@ -189,7 +190,7 @@ commit hashes do not match any more. This is acceptable, as the branch is merely
 a topic branch, and nobody should be basing their work on it.
 
 After upstream has changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 When upstream (django/django) has changed, you should rebase your work. To
 do this, use::
@@ -215,7 +216,7 @@ This way your branch will contain only commits related to its topic, which
 makes squashing easier.
 
 After review
-~~~~~~~~~~~~
+------------
 
 It is unusual to get any non-trivial amount of code into core without changes
 requested by reviewers. In this case, it is often a good idea to add the
@@ -247,7 +248,7 @@ Note that the committer is likely to squash the review commit into the previous
 commit when committing the code.
 
 Working on a patch
-------------------
+==================
 
 One of the ways that developers can contribute to Django is by reviewing
 patches. Those patches will typically exist as pull requests on GitHub and
@@ -264,7 +265,7 @@ For more detail on working with pull requests see the
 :ref:`guidelines for committers <handling-pull-requests>`.
 
 Summary
--------
+=======
 
 * Work on GitHub if you can.
 * Announce your work on the Trac ticket by linking to your GitHub branch.
diff --git a/docs/internals/contributing/writing-documentation.txt b/docs/internals/contributing/writing-documentation.txt
index 13bfe88290..b07a3984dd 100644
--- a/docs/internals/contributing/writing-documentation.txt
+++ b/docs/internals/contributing/writing-documentation.txt
@@ -19,7 +19,7 @@ This section explains how writers can craft their documentation changes
 in the most useful and least error-prone ways.
 
 Getting the raw documentation
------------------------------
+=============================
 
 Though Django's documentation is intended to be read as HTML at
 https://docs.djangoproject.com/, we edit it as a collection of text files for
@@ -36,7 +36,7 @@ to have the docs for the last release be up-to-date and correct (see
 :ref:`differences-between-doc-versions`).
 
 Getting started with Sphinx
----------------------------
+===========================
 
 Django's documentation uses the Sphinx__ documentation system, which in turn
 is based on docutils__. The basic idea is that lightly-formatted plain-text
@@ -66,7 +66,7 @@ Primer <sphinx:rst-primer>`. After that, you'll want to read about the
 metadata, indexing, and cross-references.
 
 How the documentation is organized
-----------------------------------
+==================================
 
 The documentation is organized into several categories:
 
@@ -117,7 +117,7 @@ The documentation is organized into several categories:
   repeat the same material.
 
 Writing style
--------------
+=============
 
 When using pronouns in reference to a hypothetical person, such as "a user with
 a session cookie", gender neutral pronouns (they/their/them) should be used.
@@ -130,7 +130,7 @@ Instead of:
 * himself or herself... use themselves.
 
 Commonly used terms
--------------------
+===================
 
 Here are some style guidelines on commonly used terms throughout the
 documentation:
@@ -160,7 +160,7 @@ documentation:
 * **website** -- use one word, without capitalization.
 
 Django-specific terminology
----------------------------
+===========================
 
 * **model** -- it's not capitalized.
 
@@ -172,7 +172,7 @@ Django-specific terminology
 * **view** -- it's not capitalized.
 
 Guidelines for reStructuredText files
--------------------------------------
+=====================================
 
 These guidelines regulate the format of our reST (reStructuredText)
 documentation:
@@ -199,8 +199,26 @@ documentation:
 * Use :mod:`~sphinx.ext.intersphinx` to reference Python's and Sphinx'
   documentation.
 
+* Use these heading styles::
+
+    ===
+    One
+    ===
+
+    Two
+    ===
+
+    Three
+    -----
+
+    Four
+    ~~~~
+
+    Five
+    ^^^^
+
 Django-specific markup
-----------------------
+======================
 
 Besides the `Sphinx built-in markup`__, Django's docs defines some extra
 description units:
@@ -250,7 +268,7 @@ __ http://sphinx-doc.org/markup/
 .. _documenting-new-features:
 
 Documenting new features
-------------------------
+========================
 
 Our policy for new features is:
 
@@ -308,7 +326,7 @@ We can simply remove the ``.. versionadded:: A.B`` annotation without any
 indentation changes when the time comes.
 
 Minimizing images
------------------
+=================
 
 Optimize image compression where possible. For PNG files, use OptiPNG and
 AdvanceCOMP's ``advpng``:
@@ -323,7 +341,7 @@ This is based on OptiPNG version 0.7.5. Older versions may complain about the
 ``--strip all`` option being lossy.
 
 An example
-----------
+==========
 
 For a quick example of how it all fits together, consider this hypothetical
 example:
@@ -376,7 +394,7 @@ example:
     .. setting:: ADMINS
 
     ADMINS
-    ------
+    ======
 
     Default: ``[]`` (Empty list)
 
@@ -399,7 +417,7 @@ That's basically how everything fits together.
 .. _improving-the-documentation:
 
 Improving the documentation
----------------------------
+===========================
 
 A few small improvements can be made to make the documentation read and
 look better:
@@ -450,7 +468,7 @@ look better:
 .. _documentation-spelling-check:
 
 Spelling check
---------------
+==============
 
 Before you commit your docs, it's a good idea to run the spelling checker.
 You'll need to install a couple packages first:
@@ -474,7 +492,7 @@ one of the following:
   to ``docs/spelling_wordlist`` (please keep the list in alphabetical order).
 
 Translating documentation
--------------------------
+=========================
 
 See :ref:`Localizing the Django documentation <translating-documentation>` if
 you'd like to help translate the documentation into another language.
@@ -482,7 +500,7 @@ you'd like to help translate the documentation into another language.
 .. _django-admin-manpage:
 
 ``django-admin`` man page
--------------------------
+=========================
 
 Sphinx can generate a manual page for the
 :doc:`django-admin </ref/django-admin>` command. This is configured in
diff --git a/docs/internals/index.txt b/docs/internals/index.txt
index 415e6bfeb5..e9c32fe304 100644
--- a/docs/internals/index.txt
+++ b/docs/internals/index.txt
@@ -1,3 +1,4 @@
+================
 Django internals
 ================
 
diff --git a/docs/internals/mailing-lists.txt b/docs/internals/mailing-lists.txt
index fc2fa320f0..1ca979fe93 100644
--- a/docs/internals/mailing-lists.txt
+++ b/docs/internals/mailing-lists.txt
@@ -16,7 +16,7 @@ anyone.
 .. _django-users-mailing-list:
 
 ``django-users``
-----------------
+================
 
 This is the right place if you are looking to ask any question regarding the
 installation, usage, or debugging of Django.
@@ -38,7 +38,7 @@ installation, usage, or debugging of Django.
 .. _django-core-mentorship-mailing-list:
 
 ``django-core-mentorship``
---------------------------
+==========================
 
 The Django Core Mentorship list is intended to provide a welcoming
 introductory environment for community members interested in contributing to
@@ -55,7 +55,7 @@ the Django Project.
 .. _django-developers-mailing-list:
 
 ``django-developers``
----------------------
+=====================
 
 The discussion about the development of Django itself takes place here.
 
@@ -76,7 +76,7 @@ The discussion about the development of Django itself takes place here.
 .. _django-i18n-mailing-list:
 
 ``django-i18n``
----------------
+===============
 
 This is the place to discuss the internationalization and localization of
 Django's components.
@@ -92,7 +92,7 @@ Django's components.
 .. _django-announce-mailing-list:
 
 ``django-announce``
--------------------
+===================
 
 A (very) low-traffic list for announcing new releases of Django and important
 bugfixes.
@@ -108,7 +108,7 @@ bugfixes.
 .. _django-updates-mailing-list:
 
 ``django-updates``
-------------------
+==================
 
 All the ticket updates are mailed automatically to this list, which is tracked
 by developers and interested community members.
diff --git a/docs/internals/security.txt b/docs/internals/security.txt
index fe5c02bac5..7107a105eb 100644
--- a/docs/internals/security.txt
+++ b/docs/internals/security.txt
@@ -1,5 +1,3 @@
-.. _internals-security:
-
 ==========================
 Django's security policies
 ==========================
diff --git a/docs/intro/index.txt b/docs/intro/index.txt
index d063fec047..ab4ae21469 100644
--- a/docs/intro/index.txt
+++ b/docs/intro/index.txt
@@ -1,3 +1,4 @@
+===============
 Getting started
 ===============
 
diff --git a/docs/intro/install.txt b/docs/intro/install.txt
index ae6e4bb7a0..c1348fbe62 100644
--- a/docs/intro/install.txt
+++ b/docs/intro/install.txt
@@ -1,3 +1,4 @@
+===================
 Quick install guide
 ===================
 
@@ -7,7 +8,7 @@ possibilities; this guide will guide you to a simple, minimal installation
 that'll work while you walk through the introduction.
 
 Install Python
---------------
+==============
 
 Being a Python Web framework, Django requires Python. See
 :ref:`faq-python-version-support` for details. Python includes a lightweight
@@ -34,21 +35,21 @@ you should see something like::
     >>>
 
 Set up a database
------------------
+=================
 
 This step is only necessary if you'd like to work with a "large" database engine
 like PostgreSQL, MySQL, or Oracle. To install such a database, consult the
 :ref:`database installation information <database-installation>`.
 
 Remove any old versions of Django
----------------------------------
+=================================
 
 If you are upgrading your installation of Django from a previous version, you
 will need to :ref:`uninstall the old Django version before installing the new
 version <removing-old-versions-of-django>`.
 
 Install Django
---------------
+==============
 
 You've got three easy options to install Django:
 
@@ -77,7 +78,7 @@ You've got three easy options to install Django:
 
 
 Verifying
----------
+=========
 
 To verify that Django can be seen by Python, type ``python`` from your shell.
 Then at the Python prompt, try to import Django:
@@ -91,6 +92,6 @@ Then at the Python prompt, try to import Django:
 You may have another version of Django installed.
 
 That's it!
-----------
+==========
 
 That's it -- you can now :doc:`move onto the tutorial </intro/tutorial01>`.
diff --git a/docs/misc/index.txt b/docs/misc/index.txt
index fb5c026a4d..6232a26e37 100644
--- a/docs/misc/index.txt
+++ b/docs/misc/index.txt
@@ -1,3 +1,4 @@
+=================================
 Meta-documentation and miscellany
 =================================
 
diff --git a/docs/ref/class-based-views/base.txt b/docs/ref/class-based-views/base.txt
index e477fd1ea4..ed2cd690ba 100644
--- a/docs/ref/class-based-views/base.txt
+++ b/docs/ref/class-based-views/base.txt
@@ -14,7 +14,7 @@ ancestor classes are  documented under the section title of **Ancestors (MRO)**.
 MRO is an acronym for Method Resolution Order.
 
 View
-----
+====
 
 .. class:: django.views.generic.base.View
 
@@ -98,7 +98,7 @@ View
         list of the allowed HTTP method names for the view.
 
 TemplateView
-------------
+============
 
 .. class:: django.views.generic.base.TemplateView
 
@@ -150,7 +150,7 @@ TemplateView
       the keyword arguments captured from the URL pattern that served the view.
 
 RedirectView
-------------
+============
 
 .. class:: django.views.generic.base.RedirectView
 
diff --git a/docs/ref/class-based-views/flattened-index.txt b/docs/ref/class-based-views/flattened-index.txt
index 9107d43d8b..d549cd4245 100644
--- a/docs/ref/class-based-views/flattened-index.txt
+++ b/docs/ref/class-based-views/flattened-index.txt
@@ -9,10 +9,10 @@ documentation organized by the class which defines the behavior, see
 :doc:`Class-based views</ref/class-based-views/index>`
 
 Simple generic views
---------------------
+====================
 
 View
-~~~~
+----
 .. class:: View()
 
 **Attributes** (with optional accessor):
@@ -27,7 +27,7 @@ View
 * :meth:`~django.views.generic.base.View.http_method_not_allowed`
 
 TemplateView
-~~~~~~~~~~~~
+------------
 .. class:: TemplateView()
 
 **Attributes** (with optional accessor):
@@ -49,7 +49,7 @@ TemplateView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 RedirectView
-~~~~~~~~~~~~
+------------
 .. class:: RedirectView()
 
 **Attributes** (with optional accessor):
@@ -73,10 +73,10 @@ RedirectView
 * ``put()``
 
 Detail Views
-------------
+============
 
 DetailView
-~~~~~~~~~~
+----------
 .. class:: DetailView()
 
 **Attributes** (with optional accessor):
@@ -107,10 +107,10 @@ DetailView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 List Views
-----------
+==========
 
 ListView
-~~~~~~~~
+--------
 .. class:: ListView()
 
 **Attributes** (with optional accessor):
@@ -143,10 +143,10 @@ ListView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 Editing views
--------------
+=============
 
 FormView
-~~~~~~~~
+--------
 .. class:: FormView()
 
 **Attributes** (with optional accessor):
@@ -176,7 +176,7 @@ FormView
 * :meth:`~django.views.generic.edit.ProcessFormView.put`
 
 CreateView
-~~~~~~~~~~
+----------
 .. class:: CreateView()
 
 **Attributes** (with optional accessor):
@@ -218,7 +218,7 @@ CreateView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 UpdateView
-~~~~~~~~~~
+----------
 .. class:: UpdateView()
 
 **Attributes** (with optional accessor):
@@ -260,7 +260,7 @@ UpdateView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 DeleteView
-~~~~~~~~~~
+----------
 .. class:: DeleteView()
 
 **Attributes** (with optional accessor):
@@ -294,10 +294,10 @@ DeleteView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 Date-based views
-----------------
+================
 
 ArchiveIndexView
-~~~~~~~~~~~~~~~~
+----------------
 .. class:: ArchiveIndexView()
 
 **Attributes** (with optional accessor):
@@ -335,7 +335,7 @@ ArchiveIndexView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 YearArchiveView
-~~~~~~~~~~~~~~~
+---------------
 .. class:: YearArchiveView()
 
 **Attributes** (with optional accessor):
@@ -376,7 +376,7 @@ YearArchiveView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 MonthArchiveView
-~~~~~~~~~~~~~~~~
+----------------
 .. class:: MonthArchiveView()
 
 **Attributes** (with optional accessor):
@@ -420,7 +420,7 @@ MonthArchiveView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 WeekArchiveView
-~~~~~~~~~~~~~~~
+---------------
 .. class:: WeekArchiveView()
 
 **Attributes** (with optional accessor):
@@ -462,7 +462,7 @@ WeekArchiveView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 DayArchiveView
-~~~~~~~~~~~~~~
+--------------
 .. class:: DayArchiveView()
 
 **Attributes** (with optional accessor):
@@ -510,7 +510,7 @@ DayArchiveView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 TodayArchiveView
-~~~~~~~~~~~~~~~~
+----------------
 .. class:: TodayArchiveView()
 
 **Attributes** (with optional accessor):
@@ -558,7 +558,7 @@ TodayArchiveView
 * :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
 
 DateDetailView
-~~~~~~~~~~~~~~
+--------------
 .. class:: DateDetailView()
 
 **Attributes** (with optional accessor):
diff --git a/docs/ref/class-based-views/generic-date-based.txt b/docs/ref/class-based-views/generic-date-based.txt
index d8b7933138..696c64ca9e 100644
--- a/docs/ref/class-based-views/generic-date-based.txt
+++ b/docs/ref/class-based-views/generic-date-based.txt
@@ -23,7 +23,7 @@ views for displaying drilldown pages for date-based data.
                 return reverse('article-detail', kwargs={'pk': self.pk})
 
 ArchiveIndexView
-----------------
+================
 
 .. class:: ArchiveIndexView
 
@@ -87,7 +87,7 @@ ArchiveIndexView
     This will output all articles.
 
 YearArchiveView
----------------
+===============
 
 .. class:: YearArchiveView
 
@@ -192,7 +192,7 @@ YearArchiveView
         </div>
 
 MonthArchiveView
-----------------
+================
 
 .. class:: MonthArchiveView
 
@@ -289,7 +289,7 @@ MonthArchiveView
         </p>
 
 WeekArchiveView
----------------
+===============
 
 .. class:: WeekArchiveView
 
@@ -392,7 +392,7 @@ WeekArchiveView
     filter ``'%U'`` outputs the number of seconds since the Unix epoch.
 
 DayArchiveView
---------------
+==============
 
 .. class:: DayArchiveView
 
@@ -494,7 +494,7 @@ DayArchiveView
         </p>
 
 TodayArchiveView
-----------------
+================
 
 .. class:: TodayArchiveView
 
@@ -551,7 +551,7 @@ TodayArchiveView
         name of the new template.
 
 DateDetailView
---------------
+==============
 
 .. class:: DateDetailView
 
diff --git a/docs/ref/class-based-views/generic-display.txt b/docs/ref/class-based-views/generic-display.txt
index 5dc0391319..8f45ce654b 100644
--- a/docs/ref/class-based-views/generic-display.txt
+++ b/docs/ref/class-based-views/generic-display.txt
@@ -6,7 +6,7 @@ The two following generic class-based views are designed to display data. On
 many projects they are typically the most commonly used views.
 
 DetailView
-----------
+==========
 
 .. class:: django.views.generic.detail.DetailView
 
@@ -73,7 +73,7 @@ DetailView
         <p>Date: {{ now|date }}</p>
 
 ListView
---------
+========
 
 .. class:: django.views.generic.list.ListView
 
diff --git a/docs/ref/class-based-views/generic-editing.txt b/docs/ref/class-based-views/generic-editing.txt
index bb83fa597e..c861232e5a 100644
--- a/docs/ref/class-based-views/generic-editing.txt
+++ b/docs/ref/class-based-views/generic-editing.txt
@@ -25,7 +25,7 @@ editing content:
                 return reverse('author-detail', kwargs={'pk': self.pk})
 
 FormView
---------
+========
 
 .. class:: django.views.generic.edit.FormView
 
@@ -81,7 +81,7 @@ FormView
 
 
 CreateView
-----------
+==========
 
 .. class:: django.views.generic.edit.CreateView
 
@@ -136,7 +136,7 @@ CreateView
         </form>
 
 UpdateView
-----------
+==========
 
 .. class:: django.views.generic.edit.UpdateView
 
@@ -193,7 +193,7 @@ UpdateView
         </form>
 
 DeleteView
-----------
+==========
 
 .. class:: django.views.generic.edit.DeleteView
 
diff --git a/docs/ref/class-based-views/index.txt b/docs/ref/class-based-views/index.txt
index b5ba62dbc3..5670849562 100644
--- a/docs/ref/class-based-views/index.txt
+++ b/docs/ref/class-based-views/index.txt
@@ -16,7 +16,7 @@ Class-based views API reference. For introductory material, see the
    flattened-index
 
 Specification
--------------
+=============
 
 Each request served by a class-based view has an independent state; therefore,
 it is safe to store state variables on the instance (i.e., ``self.foo = 3`` is
@@ -44,7 +44,7 @@ previous example, this means that every request on ``MyView`` is able to use
 the class (return ``True`` on a ``hasattr`` check).
 
 Base vs Generic views
----------------------
+=====================
 
 Base class-based views can be thought of as *parent* views, which can be
 used by themselves or inherited from. They may not provide all the
diff --git a/docs/ref/class-based-views/mixins-date-based.txt b/docs/ref/class-based-views/mixins-date-based.txt
index 020fc918b8..921d3dee0d 100644
--- a/docs/ref/class-based-views/mixins-date-based.txt
+++ b/docs/ref/class-based-views/mixins-date-based.txt
@@ -11,7 +11,7 @@ Date-based mixins
     characters from the :ttag:`now` template tag as they are not compatible.
 
 YearMixin
----------
+=========
 
 .. class:: YearMixin
 
@@ -63,7 +63,7 @@ YearMixin
         :attr:`~DateMixin.allow_future`.
 
 MonthMixin
-----------
+==========
 
 .. class:: MonthMixin
 
@@ -115,7 +115,7 @@ MonthMixin
         :attr:`~DateMixin.allow_future`.
 
 DayMixin
---------
+========
 
 .. class:: DayMixin
 
@@ -167,7 +167,7 @@ DayMixin
         :attr:`~DateMixin.allow_future`.
 
 WeekMixin
----------
+=========
 
 .. class:: WeekMixin
 
@@ -220,7 +220,7 @@ WeekMixin
         :attr:`~DateMixin.allow_future`.
 
 DateMixin
----------
+=========
 
 .. class:: DateMixin
 
@@ -266,7 +266,7 @@ DateMixin
         :attr:`~DateMixin.allow_future` by default.
 
 BaseDateListView
-----------------
+================
 
 .. class:: BaseDateListView
 
diff --git a/docs/ref/class-based-views/mixins-editing.txt b/docs/ref/class-based-views/mixins-editing.txt
index 5456215cf1..a0cdaf311f 100644
--- a/docs/ref/class-based-views/mixins-editing.txt
+++ b/docs/ref/class-based-views/mixins-editing.txt
@@ -15,7 +15,7 @@ The following mixins are used to construct Django's editing views:
     the documentation on :doc:`/ref/class-based-views/generic-editing`.
 
 FormMixin
----------
+=========
 
 .. class:: django.views.generic.edit.FormMixin
 
@@ -99,7 +99,7 @@ FormMixin
         name 'form'.
 
 ModelFormMixin
---------------
+==============
 
 .. class:: django.views.generic.edit.ModelFormMixin
 
@@ -201,7 +201,7 @@ ModelFormMixin
 
 
 ProcessFormView
----------------
+===============
 
 .. class:: django.views.generic.edit.ProcessFormView
 
@@ -241,7 +241,7 @@ ProcessFormView
 
 
 DeletionMixin
--------------
+=============
 
 .. class:: django.views.generic.edit.DeletionMixin
 
diff --git a/docs/ref/class-based-views/mixins-multiple-object.txt b/docs/ref/class-based-views/mixins-multiple-object.txt
index 8d64604841..29680abb60 100644
--- a/docs/ref/class-based-views/mixins-multiple-object.txt
+++ b/docs/ref/class-based-views/mixins-multiple-object.txt
@@ -3,7 +3,7 @@ Multiple object mixins
 ======================
 
 MultipleObjectMixin
--------------------
+===================
 
 .. class:: django.views.generic.list.MultipleObjectMixin
 
@@ -197,7 +197,7 @@ MultipleObjectMixin
 
 
 MultipleObjectTemplateResponseMixin
------------------------------------
+===================================
 
 .. class:: django.views.generic.list.MultipleObjectTemplateResponseMixin
 
diff --git a/docs/ref/class-based-views/mixins-simple.txt b/docs/ref/class-based-views/mixins-simple.txt
index ba18a1325b..39e49bdace 100644
--- a/docs/ref/class-based-views/mixins-simple.txt
+++ b/docs/ref/class-based-views/mixins-simple.txt
@@ -3,7 +3,7 @@ Simple mixins
 =============
 
 ContextMixin
-------------
+============
 
 .. class:: django.views.generic.base.ContextMixin
 
@@ -32,7 +32,7 @@ ContextMixin
             <alters-data-description>`.
 
 TemplateResponseMixin
----------------------
+=====================
 
 .. class:: django.views.generic.base.TemplateResponseMixin
 
diff --git a/docs/ref/class-based-views/mixins-single-object.txt b/docs/ref/class-based-views/mixins-single-object.txt
index af9acbfaa7..e23664488b 100644
--- a/docs/ref/class-based-views/mixins-single-object.txt
+++ b/docs/ref/class-based-views/mixins-single-object.txt
@@ -3,7 +3,7 @@ Single object mixins
 ====================
 
 SingleObjectMixin
------------------
+=================
 
 .. class:: django.views.generic.detail.SingleObjectMixin
 
@@ -136,7 +136,7 @@ SingleObjectMixin
 
 
 SingleObjectTemplateResponseMixin
----------------------------------
+=================================
 
 .. class:: django.views.generic.detail.SingleObjectTemplateResponseMixin
 
diff --git a/docs/ref/clickjacking.txt b/docs/ref/clickjacking.txt
index ed51b5ea8f..5f8f5a21d4 100644
--- a/docs/ref/clickjacking.txt
+++ b/docs/ref/clickjacking.txt
@@ -52,7 +52,7 @@ How to use it
 =============
 
 Setting X-Frame-Options for all responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 To set the same ``X-Frame-Options`` value for all responses in your site, put
 ``'django.middleware.clickjacking.XFrameOptionsMiddleware'`` to
@@ -86,7 +86,7 @@ that tells the middleware not to set the header::
 
 
 Setting X-Frame-Options per view
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 To set the ``X-Frame-Options`` header on a per view basis, Django provides these
 decorators::
@@ -114,7 +114,7 @@ modern browser. Older browsers will quietly ignore the header and need `other
 clickjacking prevention techniques`_.
 
 Browsers that support X-Frame-Options
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 * Internet Explorer 8+
 * Firefox 3.6.9+
@@ -123,7 +123,7 @@ Browsers that support X-Frame-Options
 * Chrome 4.1+
 
 See also
-~~~~~~~~
+--------
 
 A `complete list`_ of browsers supporting ``X-Frame-Options``.
 
diff --git a/docs/ref/contrib/auth.txt b/docs/ref/contrib/auth.txt
index bf50e73d99..1c0f7d466f 100644
--- a/docs/ref/contrib/auth.txt
+++ b/docs/ref/contrib/auth.txt
@@ -1,3 +1,4 @@
+=======================
 ``django.contrib.auth``
 =======================
 
diff --git a/docs/ref/contrib/gis/forms-api.txt b/docs/ref/contrib/gis/forms-api.txt
index b9c0c1dbe4..c2593acba6 100644
--- a/docs/ref/contrib/gis/forms-api.txt
+++ b/docs/ref/contrib/gis/forms-api.txt
@@ -18,7 +18,7 @@ In addition to the regular :ref:`form field arguments <core-field-arguments>`,
 GeoDjango form fields take the following optional arguments.
 
 ``srid``
-~~~~~~~~
+--------
 
 .. attribute:: Field.srid
 
@@ -28,7 +28,7 @@ GeoDjango form fields take the following optional arguments.
     input values into that SRID.
 
 ``geom_type``
-~~~~~~~~~~~~~
+-------------
 
 .. attribute:: Field.geom_type
 
@@ -40,42 +40,42 @@ Form field classes
 ==================
 
 ``GeometryField``
-~~~~~~~~~~~~~~~~~
+-----------------
 
 .. class:: GeometryField
 
 ``PointField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: PointField
 
 ``LineStringField``
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. class:: LineStringField
 
 ``PolygonField``
-~~~~~~~~~~~~~~~~
+----------------
 
 .. class:: PolygonField
 
 ``MultiPointField``
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. class:: MultiPointField
 
 ``MultiLineStringField``
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 .. class:: MultiLineStringField
 
 ``MultiPolygonField``
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 .. class:: MultiPolygonField
 
 ``GeometryCollectionField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 .. class:: GeometryCollectionField
 
@@ -91,7 +91,7 @@ Note that none of the currently available widgets supports 3D geometries, hence
 geometry fields will fallback using a simple ``Textarea`` widget for such data.
 
 Widget attributes
-~~~~~~~~~~~~~~~~~
+-----------------
 
 GeoDjango widgets are template-based, so their attributes are mostly different
 from other Django widget attributes.
@@ -134,7 +134,7 @@ widget. For example::
             forms.OSMWidget(attrs={'map_width': 800, 'map_height': 500}))
 
 Widget classes
-~~~~~~~~~~~~~~
+--------------
 
 ``BaseGeometryWidget``
 
diff --git a/docs/ref/contrib/gis/functions.txt b/docs/ref/contrib/gis/functions.txt
index 8095a1b1f1..4495f1d95c 100644
--- a/docs/ref/contrib/gis/functions.txt
+++ b/docs/ref/contrib/gis/functions.txt
@@ -36,7 +36,7 @@ Measurement         Relationships             Operations              Editors
 ==================  =======================   ======================  ===================  ==================  =====================
 
 Area
-----
+====
 
 .. class:: Area(expression, **extra)
 
@@ -48,7 +48,7 @@ float value is returned, as it's not possible to automatically determine the
 unit of the field.
 
 AsGeoJSON
----------
+=========
 
 .. class:: AsGeoJSON(expression, bbox=False, crs=False, precision=8, **extra)
 
@@ -80,7 +80,7 @@ Keyword Argument       Description
 =====================  =====================================================
 
 AsGML
------
+=====
 
 .. class:: AsGML(expression, version=2, precision=8, **extra)
 
@@ -111,7 +111,7 @@ Keyword Argument       Description
 __ https://en.wikipedia.org/wiki/Geography_Markup_Language
 
 AsKML
------
+=====
 
 .. class:: AsKML(expression, precision=8, **extra)
 
@@ -138,7 +138,7 @@ Keyword Argument       Description
 __ https://developers.google.com/kml/documentation/
 
 AsSVG
------
+=====
 
 .. class:: AsSVG(expression, relative=False, precision=8, **extra)
 
@@ -162,7 +162,7 @@ Keyword Argument       Description
 __ http://www.w3.org/Graphics/SVG/
 
 BoundingCircle
---------------
+==============
 
 .. class:: BoundingCircle(expression, num_seg=48, **extra)
 
@@ -172,7 +172,7 @@ Accepts a single geographic field or expression and returns the smallest circle
 polygon that can fully contain the geometry.
 
 Centroid
---------
+========
 
 .. class:: Centroid(expression, **extra)
 
@@ -182,7 +182,7 @@ Accepts a single geographic field or expression and returns the ``centroid``
 value of the geometry.
 
 Difference
-----------
+==========
 
 .. class:: Difference(expr1, expr2, **extra)
 
@@ -193,7 +193,7 @@ difference, that is the part of geometry A that does not intersect with
 geometry B.
 
 Distance
---------
+========
 
 .. class:: Distance(expr1, expr2, spheroid=None, **extra)
 
@@ -237,7 +237,7 @@ queryset is calculated::
     :ref:`supported_units`.
 
 Envelope
---------
+========
 
 .. class:: Envelope(expression, **extra)
 
@@ -247,7 +247,7 @@ Accepts a single geographic field or expression and returns the geometry
 representing the bounding box of the geometry.
 
 ForceRHR
---------
+========
 
 .. class:: ForceRHR(expression, **extra)
 
@@ -258,7 +258,7 @@ of the polygon/multipolygon in which all of the vertices follow the
 right-hand rule.
 
 GeoHash
--------
+=======
 
 .. class:: GeoHash(expression, **extra)
 
@@ -270,7 +270,7 @@ representation of the geometry.
 __ https://en.wikipedia.org/wiki/Geohash
 
 Intersection
-------------
+============
 
 .. class:: Intersection(expr1, expr2, **extra)
 
@@ -280,7 +280,7 @@ Accepts two geographic fields or expressions and returns the geometric
 intersection between them.
 
 Length
-------
+======
 
 .. class:: Length(expression, spheroid=True, **extra)
 
@@ -297,7 +297,7 @@ accurate, less resource-intensive) or on a spheroid (more accurate, more
 resource-intensive) with the ``spheroid`` keyword argument.
 
 MemSize
--------
+=======
 
 .. class:: MemSize(expression, **extra)
 
@@ -307,7 +307,7 @@ Accepts a single geographic field or expression and returns the memory size
 (number of bytes) that the geometry field takes.
 
 NumGeometries
--------------
+=============
 
 .. class:: NumGeometries(expression, **extra)
 
@@ -318,7 +318,7 @@ geometries if the geometry field is a collection (e.g., a ``GEOMETRYCOLLECTION``
 or ``MULTI*`` field); otherwise returns ``None``.
 
 NumPoints
----------
+=========
 
 .. class:: NumPoints(expression, **extra)
 
@@ -328,7 +328,7 @@ Accepts a single geographic field or expression and returns the number of points
 in the first linestring in the geometry field; otherwise returns ``None``.
 
 Perimeter
----------
+=========
 
 .. class:: Perimeter(expression, **extra)
 
@@ -340,7 +340,7 @@ MySQL, a raw float value is returned, as it's not possible to automatically
 determine the unit of the field.
 
 PointOnSurface
---------------
+==============
 
 .. class:: PointOnSurface(expression, **extra)
 
@@ -350,7 +350,7 @@ Accepts a single geographic field or expression and returns a ``Point`` geometry
 guaranteed to lie on the surface of the field; otherwise returns ``None``.
 
 Reverse
--------
+=======
 
 .. class:: Reverse(expression, **extra)
 
@@ -360,7 +360,7 @@ Accepts a single geographic field or expression and returns a geometry with
 reversed coordinates.
 
 Scale
------
+=====
 
 .. class:: Scale(expression, x, y, z=0.0, **extra)
 
@@ -371,7 +371,7 @@ scaled coordinates by multiplying them with the ``x``, ``y``, and optionally
 ``z`` parameters.
 
 SnapToGrid
-----------
+==========
 
 .. class:: SnapToGrid(expression, *args, **extra)
 
@@ -391,7 +391,7 @@ Number of Arguments  Description
 ===================  =====================================================
 
 SymDifference
--------------
+=============
 
 .. class:: SymDifference(expr1, expr2, **extra)
 
@@ -402,7 +402,7 @@ symmetric difference (union without the intersection) between the given
 parameters.
 
 Transform
----------
+=========
 
 .. class:: Transform(expression, srid, **extra)
 
@@ -419,7 +419,7 @@ the transformed geometry to the spatial reference system specified by the
     are not necessarily the same as those used by PostGIS.
 
 Translate
----------
+=========
 
 .. class:: Translate(expression, x, y, z=0.0, **extra)
 
@@ -430,7 +430,7 @@ its coordinates offset by the ``x``, ``y``, and optionally ``z`` numeric
 parameters.
 
 Union
------
+=====
 
 .. class:: Union(expr1, expr2, **extra)
 
diff --git a/docs/ref/contrib/gis/install/geolibs.txt b/docs/ref/contrib/gis/install/geolibs.txt
index 83fc438ba4..174f86a63d 100644
--- a/docs/ref/contrib/gis/install/geolibs.txt
+++ b/docs/ref/contrib/gis/install/geolibs.txt
@@ -122,10 +122,10 @@ script, compile, and install::
     $ cd ..
 
 Troubleshooting
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~
 
 Can't find GEOS library
-~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^
 
 When GeoDjango can't find GEOS, this error is raised:
 
@@ -141,7 +141,7 @@ If using a binary package of GEOS (e.g., on Ubuntu), you may need to :ref:`binut
 .. _geoslibrarypath:
 
 ``GEOS_LIBRARY_PATH``
-~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^
 
 If your GEOS library is in a non-standard location, or you don't want to
 modify the system's library path then the :setting:`GEOS_LIBRARY_PATH`
@@ -224,10 +224,10 @@ __ https://trac.osgeo.org/gdal/wiki/GdalOgrInPython
 .. _gdaltrouble:
 
 Troubleshooting
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~
 
 Can't find GDAL library
-~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^
 
 When GeoDjango can't find the GDAL library, the ``HAS_GDAL`` flag
 will be false:
@@ -244,7 +244,7 @@ The solution is to properly configure your :ref:`libsettings` *or* set
 .. _gdallibrarypath:
 
 ``GDAL_LIBRARY_PATH``
-~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^
 
 If your GDAL library is in a non-standard location, or you don't want to
 modify the system's library path then the :setting:`GDAL_LIBRARY_PATH`
diff --git a/docs/ref/contrib/gis/install/index.txt b/docs/ref/contrib/gis/install/index.txt
index f85ad2f080..0bb476c41c 100644
--- a/docs/ref/contrib/gis/install/index.txt
+++ b/docs/ref/contrib/gis/install/index.txt
@@ -129,7 +129,7 @@ an environment variable, or by configuring the library path for the entire
 system.
 
 ``LD_LIBRARY_PATH`` environment variable
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A user may set this environment variable to customize the library paths
 they want to use.  The typical library directory for software
@@ -140,7 +140,7 @@ could place the following in their bash profile::
     export LD_LIBRARY_PATH=/usr/local/lib
 
 Setting system library path
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 On GNU/Linux systems, there is typically a file in ``/etc/ld.so.conf``, which may include
 additional paths from files in another directory, such as ``/etc/ld.so.conf.d``.
@@ -160,7 +160,7 @@ modifying the system library path::
 .. _binutils:
 
 Install ``binutils``
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 GeoDjango uses the ``find_library`` function (from the ``ctypes.util`` Python
 module) to discover libraries.  The ``find_library`` routine uses a program
@@ -203,7 +203,7 @@ Foundation, however, this is not required.
 .. _macosx_python:
 
 Python
-^^^^^^
+~~~~~~
 
 Although OS X comes with Python installed, users can use `framework
 installers`__ provided by the Python Software Foundation.  An advantage to
@@ -223,7 +223,7 @@ __ https://www.python.org/ftp/python/
 .. _postgresapp:
 
 Postgres.app
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 `Postgres.app <http://postgresapp.com/>`_ is a standalone PostgreSQL server
 that includes the PostGIS extension. You will also need to install ``gdal`` and
@@ -243,7 +243,7 @@ terminal prompt.
 .. _homebrew:
 
 Homebrew
-^^^^^^^^
+~~~~~~~~
 
 `Homebrew`__ provides "recipes" for building binaries and packages from source.
 It provides recipes for the GeoDjango prerequisites on Macintosh computers
@@ -263,7 +263,7 @@ __ http://brew.sh/
 .. _kyngchaos:
 
 KyngChaos packages
-^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~
 
 William Kyngesburye provides a number of `geospatial library binary packages`__
 that make it simple to get GeoDjango installed on OS X without compiling
@@ -306,7 +306,7 @@ __ http://www.kyngchaos.com/software/postgres
 .. _psycopg2_kyngchaos:
 
 psycopg2
-~~~~~~~~
+^^^^^^^^
 
 After you've installed the KyngChaos binaries and modified your ``PATH``, as
 described above, ``psycopg2`` may be installed using the following command::
@@ -334,7 +334,7 @@ __ http://pdb.finkproject.org/pdb/browse.php?summary=django-gis
 .. _macports:
 
 MacPorts
-^^^^^^^^
+~~~~~~~~
 
 `MacPorts`__ may be used to install GeoDjango prerequisites on Macintosh
 computers running OS X.  Because MacPorts still builds the software from source,
@@ -379,7 +379,7 @@ GeoDjango on Windows.
     GEOS and GDAL, are not yet provided by the :ref:`OSGeo4W` installer.
 
 Python
-^^^^^^
+~~~~~~
 
 First, download the latest `Python 2.7 installer`__ from the Python website.
 Next, run the installer and keep the defaults -- for example, keep
@@ -395,7 +395,7 @@ Next, run the installer and keep the defaults -- for example, keep
 __ https://python.org/download/
 
 PostgreSQL
-^^^^^^^^^^
+~~~~~~~~~~
 
 First, download the latest `PostgreSQL 9.x installer`__ from the
 `EnterpriseDB`__ website.  After downloading, simply run the installer,
@@ -427,7 +427,7 @@ __ http://www.enterprisedb.com
 .. _postgisasb:
 
 PostGIS
-^^^^^^^
+~~~~~~~
 
 From within the Application Stack Builder (to run outside of the installer,
 :menuselection:`Start --> Programs --> PostgreSQL 9.x`), select
@@ -446,7 +446,7 @@ default PostGIS database).
     password in the 'Database Connection Information' dialog.
 
 psycopg2
-^^^^^^^^
+~~~~~~~~
 
 The ``psycopg2`` Python module provides the interface between Python and the
 PostgreSQL database.  Download the latest `Windows installer`__ for your version
@@ -457,7 +457,7 @@ __ http://www.stickpeople.com/projects/python/win-psycopg/
 .. _osgeo4w:
 
 OSGeo4W
-^^^^^^^
+~~~~~~~
 
 The `OSGeo4W installer`_ makes it simple to install the PROJ.4, GDAL, and GEOS
 libraries required by GeoDjango.  First, download the `OSGeo4W installer`_,
@@ -471,7 +471,7 @@ installer.
 .. _OSGeo4W installer: https://trac.osgeo.org/osgeo4w/
 
 Modify Windows environment
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In order to use GeoDjango, you will need to add your Python and OSGeo4W
 directories to your Windows system ``Path``, as well as create ``GDAL_DATA``
@@ -506,7 +506,7 @@ script, :download:`geodjango_setup.bat`.
     variables accordingly.
 
 Install Django and set up database
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Finally, :ref:`install Django <installing-official-release>` on your system.
 
diff --git a/docs/ref/contrib/gis/install/spatialite.txt b/docs/ref/contrib/gis/install/spatialite.txt
index 7950c178db..ba17999413 100644
--- a/docs/ref/contrib/gis/install/spatialite.txt
+++ b/docs/ref/contrib/gis/install/spatialite.txt
@@ -20,13 +20,13 @@ __ http://www.gaia-gis.it/gaia-sins/
 .. _spatialite_source:
 
 Installing from source
-~~~~~~~~~~~~~~~~~~~~~~
+======================
 
 :doc:`GEOS and PROJ.4</ref/contrib/gis/install/geolibs>` should be installed
 prior to building SpatiaLite.
 
 SQLite
-^^^^^^
+------
 
 Check first if SQLite is compiled with the `R*Tree module`__. Run the sqlite3
 command line interface and enter the following query::
@@ -57,7 +57,7 @@ __ https://www.sqlite.org/download.html
 .. _spatialitebuild:
 
 SpatiaLite library (``libspatialite``)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------------------------------
 
 Get the latest SpatiaLite library source bundle from the
 `download page`__::
@@ -81,13 +81,13 @@ __ http://www.gaia-gis.it/gaia-sins/libspatialite-sources/
 .. _spatialite_macosx:
 
 Mac OS X-specific instructions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+==============================
 
 To install the SpatiaLite library and tools, Mac OS X users can choose between
 :ref:`kyngchaos` and `Homebrew`_.
 
 KyngChaos
-^^^^^^^^^
+---------
 
 First, follow the instructions in the :ref:`kyngchaos` section.
 
@@ -109,7 +109,7 @@ add the following to your ``settings.py``::
 __ http://www.gaia-gis.it/spatialite-2.3.1/binaries.html
 
 Homebrew
-^^^^^^^^
+--------
 
 `Homebrew`_ handles all the SpatiaLite related packages on your behalf,
 including SQLite3, SpatiaLite, PROJ, and GEOS. Install them like this::
@@ -128,7 +128,7 @@ following to your ``settings.py``::
 .. _create_spatialite_db:
 
 Creating a spatial database for SpatiaLite
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+==========================================
 
 When running ``manage.py migrate`` with a SQLite or SpatiaLite database, the
 database file will be automatically created if it doesn't exist. Django will
diff --git a/docs/ref/contrib/gis/model-api.txt b/docs/ref/contrib/gis/model-api.txt
index fccbdce35f..d5fe84ebd6 100644
--- a/docs/ref/contrib/gis/model-api.txt
+++ b/docs/ref/contrib/gis/model-api.txt
@@ -104,7 +104,7 @@ __ https://en.wikipedia.org/wiki/WGS84
 .. _selecting-an-srid:
 
 Selecting an SRID
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 Choosing an appropriate SRID for your model is an important decision that the
 developer should consider carefully.  The SRID is an integer specifier that
@@ -213,7 +213,7 @@ details.
 .. _geography-type:
 
 Geography Type
-^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~
 
 The geography type provides native support for spatial features represented
 with geographic coordinates (e.g., WGS84 longitude/latitude). [#fngeography]_
diff --git a/docs/ref/contrib/gis/testing.txt b/docs/ref/contrib/gis/testing.txt
index 456f9c32b3..b50f276522 100644
--- a/docs/ref/contrib/gis/testing.txt
+++ b/docs/ref/contrib/gis/testing.txt
@@ -20,7 +20,7 @@ Settings
 .. setting:: POSTGIS_VERSION
 
 ``POSTGIS_VERSION``
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 When GeoDjango's spatial backend initializes on PostGIS, it has to perform
 an SQL query to determine the version in order to figure out what
@@ -43,7 +43,7 @@ only needs to have the ability to create databases. In other configurations,
 you may be required to use a database superuser.
 
 Create database user
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 To make a database user with the ability to create databases, use the
 following command::
@@ -59,7 +59,7 @@ Alternatively, you may alter an existing user's role from the SQL shell
     postgres# ALTER ROLE <user_name> CREATEDB NOSUPERUSER NOCREATEROLE;
 
 Create database superuser
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This may be done at the time the user is created, for example::
 
diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt
index 2247d5248e..9c0ba050f4 100644
--- a/docs/ref/contrib/gis/tutorial.txt
+++ b/docs/ref/contrib/gis/tutorial.txt
@@ -697,7 +697,7 @@ GeoDjango extends :doc:`Django's admin application </ref/contrib/admin/index>`
 with support for editing geometry fields.
 
 Basics
-^^^^^^
+~~~~~~
 
 GeoDjango also supplements the Django admin by allowing users to create
 and modify geometries on a JavaScript slippy map (powered by `OpenLayers`_).
@@ -744,7 +744,7 @@ position.
 .. _osmgeoadmin-intro:
 
 ``OSMGeoAdmin``
-^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~
 
 With the :class:`~django.contrib.gis.admin.OSMGeoAdmin`, GeoDjango uses
 a `Open Street Map`_ layer in the admin.
diff --git a/docs/ref/contrib/humanize.txt b/docs/ref/contrib/humanize.txt
index 8accfe326e..66b15d70f3 100644
--- a/docs/ref/contrib/humanize.txt
+++ b/docs/ref/contrib/humanize.txt
@@ -16,7 +16,7 @@ filters.
 .. templatefilter:: apnumber
 
 apnumber
---------
+========
 
 For numbers 1-9, returns the number spelled out. Otherwise, returns the
 number. This follows Associated Press style.
@@ -32,7 +32,7 @@ You can pass in either an integer or a string representation of an integer.
 .. templatefilter:: intcomma
 
 intcomma
---------
+========
 
 Converts an integer to a string containing commas every three digits.
 
@@ -43,7 +43,7 @@ Examples:
 * ``450000`` becomes ``450,000``.
 * ``4500000`` becomes ``4,500,000``.
 
-:ref:`Format localization <format-localization>` will be respected if enabled,
+:doc:`/topics/i18n/formatting` will be respected if enabled,
 e.g. with the ``'de'`` language:
 
 * ``45000`` becomes ``'45.000'``.
@@ -54,7 +54,7 @@ You can pass in either an integer or a string representation of an integer.
 .. templatefilter:: intword
 
 intword
--------
+=======
 
 Converts a large integer to a friendly text representation. Works best for
 numbers over 1 million.
@@ -67,7 +67,7 @@ Examples:
 
 Values up to 10^100 (Googol) are supported.
 
-:ref:`Format localization <format-localization>` will be respected if enabled,
+:doc:`/topics/i18n/formatting` will be respected if enabled,
 e.g. with the ``'de'`` language:
 
 * ``1000000`` becomes ``'1,0 Million'``.
@@ -79,7 +79,7 @@ You can pass in either an integer or a string representation of an integer.
 .. templatefilter:: naturalday
 
 naturalday
-----------
+==========
 
 For dates that are the current day or within one day, return "today",
 "tomorrow" or "yesterday", as appropriate. Otherwise, format the date using
@@ -98,7 +98,7 @@ Examples (when 'today' is 17 Feb 2007):
 .. templatefilter:: naturaltime
 
 naturaltime
------------
+===========
 
 For datetime values, returns a string representing how many seconds,
 minutes or hours ago it was -- falling back to the :tfilter:`timesince`
@@ -130,7 +130,7 @@ Examples (when 'now' is 17 Feb 2007 16:30:00):
 .. templatefilter:: ordinal
 
 ordinal
--------
+=======
 
 Converts an integer to its ordinal as a string.
 
diff --git a/docs/ref/contrib/postgres/aggregates.txt b/docs/ref/contrib/postgres/aggregates.txt
index d4c5f028f6..f9d222c930 100644
--- a/docs/ref/contrib/postgres/aggregates.txt
+++ b/docs/ref/contrib/postgres/aggregates.txt
@@ -19,17 +19,17 @@ These functions are described in more detail in the `PostgreSQL docs
         {'arr': [0, 1, 2]}
 
 General-purpose aggregation functions
--------------------------------------
+=====================================
 
 ArrayAgg
-~~~~~~~~
+--------
 
 .. class:: ArrayAgg(expression, **extra)
 
     Returns a list of values, including nulls, concatenated into an array.
 
 BitAnd
-~~~~~~
+------
 
 .. class:: BitAnd(expression, **extra)
 
@@ -37,7 +37,7 @@ BitAnd
     ``None`` if all values are null.
 
 BitOr
-~~~~~
+-----
 
 .. class:: BitOr(expression, **extra)
 
@@ -45,7 +45,7 @@ BitOr
     ``None`` if all values are null.
 
 BoolAnd
-~~~~~~~~
+-------
 
 .. class:: BoolAnd(expression, **extra)
 
@@ -53,7 +53,7 @@ BoolAnd
     null or if there are no values, otherwise ``False`` .
 
 BoolOr
-~~~~~~
+------
 
 .. class:: BoolOr(expression, **extra)
 
@@ -61,7 +61,7 @@ BoolOr
     values are null or if there are no values, otherwise ``False``.
 
 StringAgg
-~~~~~~~~~
+---------
 
 .. class:: StringAgg(expression, delimiter)
 
@@ -73,16 +73,16 @@ StringAgg
         Required argument. Needs to be a string.
 
 Aggregate functions for statistics
-----------------------------------
+==================================
 
 ``y`` and ``x``
-~~~~~~~~~~~~~~~
+---------------
 
 The arguments ``y`` and ``x`` for all these functions can be the name of a
 field or an expression returning a numeric data. Both are required.
 
 Corr
-~~~~
+----
 
 .. class:: Corr(y, x)
 
@@ -90,7 +90,7 @@ Corr
     aren't any matching rows.
 
 CovarPop
-~~~~~~~~
+--------
 
 .. class:: CovarPop(y, x, sample=False)
 
@@ -106,7 +106,7 @@ CovarPop
         population covariance.
 
 RegrAvgX
-~~~~~~~~
+--------
 
 .. class:: RegrAvgX(y, x)
 
@@ -114,7 +114,7 @@ RegrAvgX
     ``float``, or ``None`` if there aren't any matching rows.
 
 RegrAvgY
-~~~~~~~~
+--------
 
 .. class:: RegrAvgY(y, x)
 
@@ -122,7 +122,7 @@ RegrAvgY
     ``float``, or ``None`` if there aren't any matching rows.
 
 RegrCount
-~~~~~~~~~
+---------
 
 .. class:: RegrCount(y, x)
 
@@ -130,7 +130,7 @@ RegrCount
     are not null.
 
 RegrIntercept
-~~~~~~~~~~~~~
+-------------
 
 .. class:: RegrIntercept(y, x)
 
@@ -139,7 +139,7 @@ RegrIntercept
     matching rows.
 
 RegrR2
-~~~~~~
+------
 
 .. class:: RegrR2(y, x)
 
@@ -147,7 +147,7 @@ RegrR2
     ``None`` if there aren't any matching rows.
 
 RegrSlope
-~~~~~~~~~
+---------
 
 .. class:: RegrSlope(y, x)
 
@@ -156,7 +156,7 @@ RegrSlope
     matching rows.
 
 RegrSXX
-~~~~~~~
+-------
 
 .. class:: RegrSXX(y, x)
 
@@ -164,7 +164,7 @@ RegrSXX
     variable) as a ``float``, or ``None`` if there aren't any matching rows.
 
 RegrSXY
-~~~~~~~
+-------
 
 .. class:: RegrSXY(y, x)
 
@@ -173,7 +173,7 @@ RegrSXY
     matching rows.
 
 RegrSYY
-~~~~~~~
+-------
 
 .. class:: RegrSYY(y, x)
 
@@ -181,7 +181,7 @@ RegrSYY
     variable)  as a ``float``, or ``None`` if there aren't any matching rows.
 
 Usage examples
---------------
+==============
 
 We will use this example table::
 
diff --git a/docs/ref/contrib/postgres/fields.txt b/docs/ref/contrib/postgres/fields.txt
index 65af8f936f..cb3ed99d87 100644
--- a/docs/ref/contrib/postgres/fields.txt
+++ b/docs/ref/contrib/postgres/fields.txt
@@ -1,3 +1,4 @@
+================================
 PostgreSQL specific model fields
 ================================
 
@@ -7,7 +8,7 @@ module.
 .. currentmodule:: django.contrib.postgres.fields
 
 ArrayField
-----------
+==========
 
 .. class:: ArrayField(base_field, size=None, **options)
 
@@ -91,7 +92,7 @@ ArrayField
     nullable and the values padded with ``None``.
 
 Querying ArrayField
-^^^^^^^^^^^^^^^^^^^
+-------------------
 
 There are a number of custom lookups and transforms for :class:`ArrayField`.
 We will use the following example model::
@@ -242,7 +243,7 @@ lookups available after the transform do not change. For example::
     fashion by Django.
 
 Indexing ArrayField
-^^^^^^^^^^^^^^^^^^^
+-------------------
 
 At present using :attr:`~django.db.models.Field.db_index` will create a
 ``btree`` index. This does not offer particularly significant help to querying.
@@ -250,7 +251,7 @@ A more useful index is a ``GIN`` index, which you should create using a
 :class:`~django.db.migrations.operations.RunSQL` operation.
 
 HStoreField
------------
+===========
 
 .. class:: HStoreField(**options)
 
@@ -292,7 +293,7 @@ HStoreField
     :class:`~django.contrib.postgres.validators.KeysValidator`.
 
 Querying HStoreField
-^^^^^^^^^^^^^^^^^^^^
+--------------------
 
 In addition to the ability to query by key, there are a number of custom
 lookups available for ``HStoreField``.
@@ -457,7 +458,7 @@ using in conjunction with lookups on
     [<Dog: Meg>]
 
 JSONField
----------
+=========
 
 .. versionadded:: 1.9
 
@@ -492,7 +493,7 @@ JSONField
     **As a result, this field requires PostgreSQL ≥ 9.4 and Psycopg2 ≥ 2.5.4**.
 
 Querying JSONField
-^^^^^^^^^^^^^^^^^^
+------------------
 
 We will use the following example model::
 
@@ -575,7 +576,7 @@ containment and keys with :class:`~django.contrib.postgres.fields.HStoreField`.
 .. _range-fields:
 
 Range Fields
-------------
+============
 
 There are five range field types, corresponding to the built-in range types in
 PostgreSQL. These fields are used to store a range of values; for example the
@@ -588,7 +589,7 @@ information is necessary. The default is lower bound included, upper bound
 excluded.
 
 IntegerRangeField
-^^^^^^^^^^^^^^^^^
+-----------------
 
 .. class:: IntegerRangeField(**options)
 
@@ -598,7 +599,7 @@ IntegerRangeField
     Python.
 
 BigIntegerRangeField
-^^^^^^^^^^^^^^^^^^^^
+--------------------
 
 .. class:: BigIntegerRangeField(**options)
 
@@ -608,7 +609,7 @@ BigIntegerRangeField
     Python.
 
 FloatRangeField
-^^^^^^^^^^^^^^^
+---------------
 
 .. class:: FloatRangeField(**options)
 
@@ -617,7 +618,7 @@ FloatRangeField
     database and a :class:`~psycopg2:psycopg2.extras.NumericRange` in Python.
 
 DateTimeRangeField
-^^^^^^^^^^^^^^^^^^
+------------------
 
 .. class:: DateTimeRangeField(**options)
 
@@ -627,7 +628,7 @@ DateTimeRangeField
     Python.
 
 DateRangeField
-^^^^^^^^^^^^^^
+--------------
 
 .. class:: DateRangeField(**options)
 
@@ -636,7 +637,7 @@ DateRangeField
     database and a :class:`~psycopg2:psycopg2.extras.DateRange` in Python.
 
 Querying Range Fields
-^^^^^^^^^^^^^^^^^^^^^
+---------------------
 
 There are a number of custom lookups and transforms for range fields. They are
 available on all the above fields, but we will use the following example
@@ -675,7 +676,7 @@ operators ``@>``, ``<@``, and ``&&`` respectively.
 .. fieldlookup:: rangefield.contains
 
 contains
-''''''''
+^^^^^^^^
 
     >>> Event.objects.filter(ages__contains=NumericRange(4, 5))
     [<Event: Soft play>]
@@ -683,7 +684,7 @@ contains
 .. fieldlookup:: rangefield.contained_by
 
 contained_by
-''''''''''''
+^^^^^^^^^^^^
 
     >>> Event.objects.filter(ages__contained_by=NumericRange(0, 15))
     [<Event: Soft play>]
@@ -707,7 +708,7 @@ contained_by
 .. fieldlookup:: rangefield.overlap
 
 overlap
-'''''''
+^^^^^^^
 
     >>> Event.objects.filter(ages__overlap=NumericRange(8, 12))
     [<Event: Soft play>]
@@ -724,7 +725,7 @@ the specific range comparison operators.
 .. fieldlookup:: rangefield.fully_lt
 
 fully_lt
-''''''''
+^^^^^^^^
 
 The returned ranges are strictly less than the passed range. In other words,
 all the points in the returned range are less than all those in the passed
@@ -736,7 +737,7 @@ range.
 .. fieldlookup:: rangefield.fully_gt
 
 fully_gt
-''''''''
+^^^^^^^^
 
 The returned ranges are strictly greater than the passed range. In other words,
 the all the points in the returned range are greater than all those in the
@@ -748,7 +749,7 @@ passed range.
 .. fieldlookup:: rangefield.not_lt
 
 not_lt
-''''''
+^^^^^^
 
 The returned ranges do not contain any points less than the passed range, that
 is the lower bound of the returned range is at least the lower bound of the
@@ -760,7 +761,7 @@ passed range.
 .. fieldlookup:: rangefield.not_gt
 
 not_gt
-''''''
+^^^^^^
 
 The returned ranges do not contain any points greater than the passed range, that
 is the upper bound of the returned range is at most the upper bound of the
@@ -772,7 +773,7 @@ passed range.
 .. fieldlookup:: rangefield.adjacent_to
 
 adjacent_to
-'''''''''''
+^^^^^^^^^^^
 
 The returned ranges share a bound with the passed range.
 
@@ -788,7 +789,7 @@ lower or upper bound, or query based on emptiness.
 .. fieldlookup:: rangefield.startswith
 
 startswith
-''''''''''
+^^^^^^^^^^
 
 Returned objects have the given lower bound. Can be chained to valid lookups
 for the base field.
@@ -799,7 +800,7 @@ for the base field.
 .. fieldlookup:: rangefield.endswith
 
 endswith
-''''''''
+^^^^^^^^
 
 Returned objects have the given upper bound. Can be chained to valid lookups
 for the base field.
@@ -810,7 +811,7 @@ for the base field.
 .. fieldlookup:: rangefield.isempty
 
 isempty
-'''''''
+^^^^^^^
 
 Returned objects are empty ranges. Can be chained to valid lookups for a
 :class:`~django.db.models.BooleanField`.
diff --git a/docs/ref/contrib/postgres/forms.txt b/docs/ref/contrib/postgres/forms.txt
index 431cf9c802..288c826f93 100644
--- a/docs/ref/contrib/postgres/forms.txt
+++ b/docs/ref/contrib/postgres/forms.txt
@@ -1,3 +1,4 @@
+===========================================
 PostgreSQL specific form fields and widgets
 ===========================================
 
@@ -6,6 +7,9 @@ All of these fields and widgets are available from the
 
 .. currentmodule:: django.contrib.postgres.forms
 
+Fields
+======
+
 SimpleArrayField
 ----------------
 
@@ -217,10 +221,10 @@ DateRangeField
     :class:`~django.contrib.postgres.fields.DateRangeField`.
 
 Widgets
--------
+=======
 
 RangeWidget
-~~~~~~~~~~~
+-----------
 
 .. class:: RangeWidget(base_widget, attrs=None)
 
diff --git a/docs/ref/contrib/postgres/functions.txt b/docs/ref/contrib/postgres/functions.txt
index c97af99bfb..0a7d9340ec 100644
--- a/docs/ref/contrib/postgres/functions.txt
+++ b/docs/ref/contrib/postgres/functions.txt
@@ -1,3 +1,4 @@
+======================================
 PostgreSQL specific database functions
 ======================================
 
@@ -7,7 +8,7 @@ All of these functions are available from the
 .. currentmodule:: django.contrib.postgres.functions
 
 TransactionNow
---------------
+==============
 
 .. class:: TransactionNow()
 
diff --git a/docs/ref/contrib/postgres/index.txt b/docs/ref/contrib/postgres/index.txt
index cc453aff65..4d1e88d43c 100644
--- a/docs/ref/contrib/postgres/index.txt
+++ b/docs/ref/contrib/postgres/index.txt
@@ -1,3 +1,4 @@
+===========================
 ``django.contrib.postgres``
 ===========================
 
diff --git a/docs/ref/contrib/postgres/operations.txt b/docs/ref/contrib/postgres/operations.txt
index 79c2021c39..81ecb6acb2 100644
--- a/docs/ref/contrib/postgres/operations.txt
+++ b/docs/ref/contrib/postgres/operations.txt
@@ -1,3 +1,4 @@
+=============================
 Database migration operations
 =============================
 
@@ -7,7 +8,7 @@ the ``django.contrib.postgres.operations`` module.
 .. currentmodule:: django.contrib.postgres.operations
 
 CreateExtension
----------------
+===============
 
 .. class:: CreateExtension(name)
 
@@ -18,7 +19,7 @@ CreateExtension
         This is a required argument. The name of the extension to be installed.
 
 HStoreExtension
----------------
+===============
 
 .. class:: HStoreExtension()
 
@@ -27,7 +28,7 @@ HStoreExtension
     connection to interpret hstore data.
 
 UnaccentExtension
------------------
+=================
 
 .. class:: UnaccentExtension()
 
diff --git a/docs/ref/contrib/postgres/validators.txt b/docs/ref/contrib/postgres/validators.txt
index f35a40dd27..21a1935f55 100644
--- a/docs/ref/contrib/postgres/validators.txt
+++ b/docs/ref/contrib/postgres/validators.txt
@@ -5,7 +5,7 @@ Validators
 .. module:: django.contrib.postgres.validators
 
 ``KeysValidator``
------------------
+=================
 
 .. class:: KeysValidator(keys, strict=False, messages=None)
 
@@ -20,7 +20,7 @@ Validators
         the value of a key is non-empty.
 
 Range validators
-----------------
+================
 
 .. class:: RangeMaxValueValidator(limit_value, message=None)
 
diff --git a/docs/ref/files/file.txt b/docs/ref/files/file.txt
index 14efb83fe6..9c3bb59405 100644
--- a/docs/ref/files/file.txt
+++ b/docs/ref/files/file.txt
@@ -1,3 +1,4 @@
+===================
 The ``File`` object
 ===================
 
@@ -7,7 +8,7 @@ for basic file handling in Django.
 .. currentmodule:: django.core.files
 
 The ``File`` Class
-------------------
+==================
 
 .. class:: File(file_object)
 
@@ -99,7 +100,7 @@ The ``File`` Class
 .. currentmodule:: django.core.files.base
 
 The ``ContentFile`` Class
--------------------------
+=========================
 
 .. class:: ContentFile(File)
 
@@ -116,7 +117,7 @@ The ``ContentFile`` Class
 .. currentmodule:: django.core.files.images
 
 The ``ImageFile`` Class
------------------------
+=======================
 
 .. class:: ImageFile(file_object)
 
@@ -136,7 +137,7 @@ The ``ImageFile`` Class
 .. currentmodule:: django.core.files
 
 Additional methods on files attached to objects
------------------------------------------------
+===============================================
 
 Any :class:`File` that is associated with an object (as with ``Car.photo``,
 below) will also have a couple of extra methods:
diff --git a/docs/ref/files/storage.txt b/docs/ref/files/storage.txt
index 8dd700484d..fa6ced491d 100644
--- a/docs/ref/files/storage.txt
+++ b/docs/ref/files/storage.txt
@@ -1,10 +1,11 @@
+================
 File storage API
 ================
 
 .. module:: django.core.files.storage
 
 Getting the current storage class
----------------------------------
+=================================
 
 Django provides two convenient ways to access the current storage class:
 
@@ -27,7 +28,7 @@ Django provides two convenient ways to access the current storage class:
     raised if the import is unsuccessful.
 
 The FileSystemStorage Class
----------------------------
+===========================
 
 .. class:: FileSystemStorage(location=None, base_url=None, file_permissions_mode=None, directory_permissions_mode=None)
 
@@ -62,7 +63,7 @@ The FileSystemStorage Class
         an exception if the given file name does not exist.
 
 The Storage Class
------------------
+=================
 
 .. class:: Storage
 
diff --git a/docs/ref/files/uploads.txt b/docs/ref/files/uploads.txt
index daf2b8e90c..7fd5cecb87 100644
--- a/docs/ref/files/uploads.txt
+++ b/docs/ref/files/uploads.txt
@@ -141,7 +141,7 @@ All file upload handlers should be subclasses of
 handlers wherever you wish.
 
 Required methods
-~~~~~~~~~~~~~~~~
+----------------
 
 Custom file upload handlers **must** define the following methods:
 
@@ -175,7 +175,7 @@ Custom file upload handlers **must** define the following methods:
     the ``UploadedFile`` object should come from subsequent upload handlers.
 
 Optional methods
-~~~~~~~~~~~~~~~~
+----------------
 
 Custom upload handlers may also define any of the following optional methods or
 attributes:
diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt
index a8d2fa77ff..072525ff53 100644
--- a/docs/ref/forms/api.txt
+++ b/docs/ref/forms/api.txt
@@ -13,7 +13,7 @@ The Forms API
 .. _ref-forms-api-bound-unbound:
 
 Bound and unbound forms
------------------------
+=======================
 
 A :class:`Form` instance is either **bound** to a set of data, or **unbound**.
 
@@ -69,7 +69,7 @@ another :class:`Form` instance. There is no way to change data in a
 should consider its data immutable, whether it has data or not.
 
 Using forms to validate data
-----------------------------
+============================
 
 .. method:: Form.clean()
 
@@ -203,7 +203,7 @@ This includes ``ValidationError``\s that are raised in :meth:`Form.clean()
 "...") <django.forms.Form.add_error>`.
 
 Behavior of unbound forms
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 It's meaningless to validate a form with no data, but, for the record, here's
 what happens with unbound forms::
@@ -215,7 +215,7 @@ what happens with unbound forms::
     {}
 
 Dynamic initial values
-----------------------
+======================
 
 .. attribute:: Form.initial
 
@@ -251,7 +251,7 @@ precedence::
     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
 
 Checking which form data has changed
-------------------------------------
+====================================
 
 .. method:: Form.has_changed()
 
@@ -288,7 +288,7 @@ provided in :attr:`~Form.initial`. It returns an empty list if no data differs.
     ...     print("The following fields changed: %s" % ", ".join(f.changed_data))
 
 Accessing the fields from the form
-----------------------------------
+==================================
 
 .. attribute:: Form.fields
 
@@ -322,7 +322,7 @@ process::
     '<tr><th>Username:</th><td><input name="name" type="text" value="class" /></td></tr>'
 
 Accessing "clean" data
-----------------------
+======================
 
 .. attribute:: Form.cleaned_data
 
@@ -416,7 +416,7 @@ fields). More information about this is in :doc:`/ref/forms/validation`.
 .. _ref-forms-api-outputting-html:
 
 Outputting forms as HTML
-------------------------
+========================
 
 The second task of a ``Form`` object is to render itself as HTML. To do so,
 simply ``print`` it::
@@ -478,7 +478,7 @@ form, other output styles are available. Each style is available as a method on
 a form object, and each rendering method returns a Unicode object.
 
 ``as_p()``
-~~~~~~~~~~
+----------
 
 .. method:: Form.as_p()
 
@@ -495,7 +495,7 @@ containing one field::
     <p><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></p>
 
 ``as_ul()``
-~~~~~~~~~~~
+-----------
 
 .. method:: Form.as_ul()
 
@@ -514,7 +514,7 @@ flexibility::
     <li><label for="id_cc_myself">Cc myself:</label> <input type="checkbox" name="cc_myself" id="id_cc_myself" /></li>
 
 ``as_table()``
-~~~~~~~~~~~~~~
+--------------
 
 .. method:: Form.as_table()
 
@@ -534,7 +534,7 @@ it calls its ``as_table()`` method behind the scenes::
 .. _ref-forms-api-styling-form-rows:
 
 Styling required or erroneous form rows
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 .. attribute:: Form.error_css_class
 .. attribute:: Form.required_css_class
@@ -578,7 +578,7 @@ classes, as needed. The HTML will look something like::
 .. _ref-forms-api-configuring-label:
 
 Configuring form elements' HTML ``id`` attributes and ``<label>`` tags
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------
 
 .. attribute:: Form.auto_id
 
@@ -702,7 +702,7 @@ using the ``label_suffix`` parameter to
 :meth:`~django.forms.BoundField.label_tag`.
 
 Notes on field ordering
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 In the ``as_p()``, ``as_ul()`` and ``as_table()`` shortcuts, the fields are
 displayed in the order in which you define them in your form class. For
@@ -736,7 +736,7 @@ You may rearrange the fields any time using ``order_fields()`` with a list of
 field names as in :attr:`~django.forms.Form.field_order`.
 
 How errors are displayed
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 If you render a bound ``Form`` object, the act of rendering will automatically
 run the form's validation if it hasn't already happened, and the HTML output
@@ -770,7 +770,7 @@ method you're using::
 .. _ref-forms-error-list-format:
 
 Customizing the error list format
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 By default, forms use ``django.forms.utils.ErrorList`` to format validation
 errors. If you'd like to use an alternate class for displaying errors, you can
@@ -794,7 +794,7 @@ Python 2)::
     <p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
 
 More granular output
---------------------
+====================
 
 The ``as_p()``, ``as_ul()``, and ``as_table()`` methods are simply shortcuts --
 they're not the only way a form object can be displayed.
@@ -833,7 +833,7 @@ The field-specific output honors the form object's ``auto_id`` setting::
     <input type="text" name="message" id="id_message" />
 
 Attributes of ``BoundField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 .. attribute:: BoundField.data
 
@@ -931,7 +931,7 @@ Attributes of ``BoundField``
         message
 
 Methods of ``BoundField``
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 .. method:: BoundField.as_hidden(attrs=None, **kwargs)
 
@@ -1008,7 +1008,7 @@ Methods of ``BoundField``
         hi
 
 Customizing ``BoundField``
---------------------------
+==========================
 
 .. versionadded:: 1.9
 
@@ -1052,7 +1052,7 @@ Now you can access the country in a template with
 .. _binding-uploaded-files:
 
 Binding uploaded files to a form
---------------------------------
+================================
 
 Dealing with forms that have ``FileField`` and ``ImageField`` fields
 is a little more complicated than a normal form.
@@ -1093,7 +1093,7 @@ form data *and* file data::
     >>> f = ContactFormWithMugshot()
 
 Testing for multipart forms
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 .. method:: Form.is_multipart()
 
@@ -1116,7 +1116,7 @@ Here's an example of how you might use this in a template::
     </form>
 
 Subclassing forms
------------------
+=================
 
 If you have multiple ``Form`` classes that share fields, you can use
 subclassing to remove redundancy.
@@ -1177,7 +1177,7 @@ by setting the name of the field to ``None`` on the subclass. For example::
 .. _form-prefix:
 
 Prefixes for forms
-------------------
+==================
 
 .. attribute:: Form.prefix
 
diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt
index bdc90f09e0..ef27f692b9 100644
--- a/docs/ref/forms/fields.txt
+++ b/docs/ref/forms/fields.txt
@@ -33,14 +33,14 @@ exception or returns the clean value::
 .. _core-field-arguments:
 
 Core field arguments
---------------------
+====================
 
 Each ``Field`` class constructor takes at least these arguments. Some
 ``Field`` classes take additional, field-specific arguments, but the following
 should *always* be accepted:
 
 ``required``
-~~~~~~~~~~~~
+------------
 
 .. attribute:: Field.required
 
@@ -93,7 +93,7 @@ For other ``Field`` classes, it might be ``None``. (This varies from field to
 field.)
 
 ``label``
-~~~~~~~~~
+---------
 
 .. attribute:: Field.label
 
@@ -120,7 +120,7 @@ We've specified ``auto_id=False`` to simplify the output::
     <tr><th>Comment:</th><td><input type="text" name="comment" /></td></tr>
 
 ``label_suffix``
-~~~~~~~~~~~~~~~~
+----------------
 
 .. attribute:: Field.label_suffix
 
@@ -140,7 +140,7 @@ The ``label_suffix`` argument lets you override the form's
     <p><label for="id_captcha_answer">2 + 2 =</label> <input id="id_captcha_answer" name="captcha_answer" type="number" /></p>
 
 ``initial``
-~~~~~~~~~~~
+-----------
 
 .. attribute:: Field.initial
 
@@ -208,7 +208,7 @@ Instead of a constant, you can also pass any callable::
 The callable will be evaluated only when the unbound form is displayed, not when it is defined.
 
 ``widget``
-~~~~~~~~~~
+----------
 
 .. attribute:: Field.widget
 
@@ -216,7 +216,7 @@ The ``widget`` argument lets you specify a ``Widget`` class to use when
 rendering this ``Field``. See :doc:`/ref/forms/widgets` for more information.
 
 ``help_text``
-~~~~~~~~~~~~~
+-------------
 
 .. attribute:: Field.help_text
 
@@ -255,7 +255,7 @@ fields. We've specified ``auto_id=False`` to simplify the output::
     <p>Cc myself: <input type="checkbox" name="cc_myself" /></p>
 
 ``error_messages``
-~~~~~~~~~~~~~~~~~~
+------------------
 
 .. attribute:: Field.error_messages
 
@@ -282,7 +282,7 @@ In the `built-in Field classes`_ section below, each ``Field`` defines the
 error message keys it uses.
 
 ``validators``
-~~~~~~~~~~~~~~
+--------------
 
 .. attribute:: Field.validators
 
@@ -292,18 +292,18 @@ for this field.
 See the :doc:`validators documentation </ref/validators>` for more information.
 
 ``localize``
-~~~~~~~~~~~~
+------------
 
 .. attribute:: Field.localize
 
 The ``localize`` argument enables the localization of form data input, as well
 as the rendered output.
 
-See the :ref:`format localization <format-localization>` documentation for
+See the :doc:`format localization </topics/i18n/formatting>` documentation for
 more information.
 
 ``disabled``
-~~~~~~~~~~~~
+------------
 
 .. attribute:: Field.disabled
 
@@ -315,10 +315,10 @@ Even if a user tampers with the field's value submitted to the server, it will
 be ignored in favor of the value from the form's initial data.
 
 Checking if the field data has changed
---------------------------------------
+======================================
 
 ``has_changed()``
-~~~~~~~~~~~~~~~~~~
+-----------------
 
 .. method:: Field.has_changed()
 
@@ -334,7 +334,7 @@ See the :class:`Form.has_changed()` documentation for more information.
 .. _built-in-fields:
 
 Built-in ``Field`` classes
---------------------------
+==========================
 
 Naturally, the ``forms`` library comes with a set of ``Field`` classes that
 represent common validation needs. This section documents each built-in field.
@@ -344,7 +344,7 @@ For each field, we describe the default widget used if you don't specify
 (see the section on ``required`` above to understand what that means).
 
 ``BooleanField``
-~~~~~~~~~~~~~~~~
+----------------
 
 .. class:: BooleanField(**kwargs)
 
@@ -364,7 +364,7 @@ For each field, we describe the default widget used if you don't specify
         creating the ``BooleanField``.
 
 ``CharField``
-~~~~~~~~~~~~~
+-------------
 
 .. class:: CharField(**kwargs)
 
@@ -391,7 +391,7 @@ For each field, we describe the default widget used if you don't specify
        trailing whitespace.
 
 ``ChoiceField``
-~~~~~~~~~~~~~~~
+---------------
 
 .. class:: ChoiceField(**kwargs)
 
@@ -420,7 +420,7 @@ For each field, we describe the default widget used if you don't specify
             The ability to pass a callable to ``choices`` was added.
 
 ``TypedChoiceField``
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 .. class:: TypedChoiceField(**kwargs)
 
@@ -452,7 +452,7 @@ For each field, we describe the default widget used if you don't specify
         accordingly.
 
 ``DateField``
-~~~~~~~~~~~~~
+-------------
 
 .. class:: DateField(**kwargs)
 
@@ -488,10 +488,10 @@ For each field, we describe the default widget used if you don't specify
          '%d %B %Y',      # '25 October 2006'
          '%d %B, %Y']     # '25 October, 2006'
 
-    See also :ref:`format localization <format-localization>`.
+    See also :doc:`format localization </topics/i18n/formatting>`.
 
 ``DateTimeField``
-~~~~~~~~~~~~~~~~~
+-----------------
 
 .. class:: DateTimeField(**kwargs)
 
@@ -521,10 +521,10 @@ For each field, we describe the default widget used if you don't specify
          '%m/%d/%y %H:%M',       # '10/25/06 14:30'
          '%m/%d/%y']             # '10/25/06'
 
-    See also :ref:`format localization <format-localization>`.
+    See also :doc:`format localization </topics/i18n/formatting>`.
 
 ``DecimalField``
-~~~~~~~~~~~~~~~~
+----------------
 
 .. class:: DecimalField(**kwargs)
 
@@ -562,7 +562,7 @@ For each field, we describe the default widget used if you don't specify
         The maximum number of decimal places permitted.
 
 ``DurationField``
-~~~~~~~~~~~~~~~~~
+-----------------
 
 .. versionadded:: 1.8
 
@@ -579,7 +579,7 @@ For each field, we describe the default widget used if you don't specify
     :func:`~django.utils.dateparse.parse_duration`.
 
 ``EmailField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: EmailField(**kwargs)
 
@@ -595,7 +595,7 @@ For each field, we describe the default widget used if you don't specify
     given length.
 
 ``FileField``
-~~~~~~~~~~~~~
+-------------
 
 .. class:: FileField(**kwargs)
 
@@ -623,7 +623,7 @@ For each field, we describe the default widget used if you don't specify
     length and ``%(length)d`` will be replaced with the current filename length.
 
 ``FilePathField``
-~~~~~~~~~~~~~~~~~
+-----------------
 
 .. class:: FilePathField(**kwargs)
 
@@ -666,7 +666,7 @@ For each field, we describe the default widget used if you don't specify
 
 
 ``FloatField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: FloatField(**kwargs)
 
@@ -683,7 +683,7 @@ For each field, we describe the default widget used if you don't specify
     These control the range of values permitted in the field.
 
 ``ImageField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: ImageField(**kwargs)
 
@@ -720,7 +720,7 @@ For each field, we describe the default widget used if you don't specify
 .. _Image: https://pillow.readthedocs.org/en/latest/reference/Image.html
 
 ``IntegerField``
-~~~~~~~~~~~~~~~~
+----------------
 
 .. class:: IntegerField(**kwargs)
 
@@ -744,7 +744,7 @@ For each field, we describe the default widget used if you don't specify
     These control the range of values permitted in the field.
 
 ``GenericIPAddressField``
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 .. class:: GenericIPAddressField(**kwargs)
 
@@ -779,7 +779,7 @@ For each field, we describe the default widget used if you don't specify
         when ``protocol`` is set to ``'both'``.
 
 ``MultipleChoiceField``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 .. class:: MultipleChoiceField(**kwargs)
 
@@ -796,7 +796,7 @@ For each field, we describe the default widget used if you don't specify
     Takes one extra required argument, ``choices``, as for :class:`ChoiceField`.
 
 ``TypedMultipleChoiceField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 .. class:: TypedMultipleChoiceField(**kwargs)
 
@@ -818,7 +818,7 @@ For each field, we describe the default widget used if you don't specify
     :class:`TypedChoiceField`.
 
 ``NullBooleanField``
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 .. class:: NullBooleanField(**kwargs)
 
@@ -828,7 +828,7 @@ For each field, we describe the default widget used if you don't specify
     * Validates nothing (i.e., it never raises a ``ValidationError``).
 
 ``RegexField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: RegexField(**kwargs)
 
@@ -865,7 +865,7 @@ For each field, we describe the default widget used if you don't specify
         message as the value.
 
 ``SlugField``
-~~~~~~~~~~~~~
+-------------
 
 .. class:: SlugField(**kwargs)
 
@@ -889,7 +889,7 @@ For each field, we describe the default widget used if you don't specify
        to ASCII letters. Defaults to ``False``.
 
 ``TimeField``
-~~~~~~~~~~~~~
+-------------
 
 .. class:: TimeField(**kwargs)
 
@@ -913,7 +913,7 @@ For each field, we describe the default widget used if you don't specify
         '%H:%M',        # '14:30'
 
 ``URLField``
-~~~~~~~~~~~~
+------------
 
 .. class:: URLField(**kwargs)
 
@@ -931,7 +931,7 @@ For each field, we describe the default widget used if you don't specify
     These are the same as ``CharField.max_length`` and ``CharField.min_length``.
 
 ``UUIDField``
-~~~~~~~~~~~~~
+-------------
 
 .. versionadded:: 1.8
 
@@ -946,10 +946,10 @@ For each field, we describe the default widget used if you don't specify
     to the :class:`~python:uuid.UUID` constructor.
 
 Slightly complex built-in ``Field`` classes
--------------------------------------------
+===========================================
 
 ``ComboField``
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: ComboField(**kwargs)
 
@@ -977,7 +977,7 @@ Slightly complex built-in ``Field`` classes
             ValidationError: ['Ensure this value has at most 20 characters (it has 28).']
 
 ``MultiValueField``
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. class:: MultiValueField(fields=(), **kwargs)
 
@@ -1060,7 +1060,7 @@ Slightly complex built-in ``Field`` classes
         This method must be implemented in the subclasses.
 
 ``SplitDateTimeField``
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 .. class:: SplitDateTimeField(**kwargs)
 
@@ -1091,7 +1091,7 @@ Slightly complex built-in ``Field`` classes
     for :class:`TimeField` are used.
 
 Fields which handle relationships
----------------------------------
+=================================
 
 Two fields are available for representing relationships between
 models: :class:`ModelChoiceField` and
@@ -1114,7 +1114,7 @@ method::
             self.fields['foo_select'].queryset = ...
 
 ``ModelChoiceField``
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 .. class:: ModelChoiceField(**kwargs)
 
@@ -1207,7 +1207,7 @@ method::
                 return "My Object #%i" % obj.id
 
 ``ModelMultipleChoiceField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 .. class:: ModelMultipleChoiceField(**kwargs)
 
@@ -1235,7 +1235,7 @@ method::
         user's selection.
 
 Creating custom fields
-----------------------
+======================
 
 If the built-in ``Field`` classes don't meet your needs, you can easily create
 custom ``Field`` classes. To do this, just create a subclass of
diff --git a/docs/ref/forms/formsets.txt b/docs/ref/forms/formsets.txt
index 704a9bb198..144140c62e 100644
--- a/docs/ref/forms/formsets.txt
+++ b/docs/ref/forms/formsets.txt
@@ -12,4 +12,4 @@ Formset API reference. For introductory material about formsets, see the
 
     Returns a ``FormSet`` class for the given ``form`` class.
 
-    See :ref:`formsets` for example usage.
+    See :doc:`formsets </topics/forms/formsets>` for example usage.
diff --git a/docs/ref/forms/models.txt b/docs/ref/forms/models.txt
index bdf6ba1d89..f39d238aa7 100644
--- a/docs/ref/forms/models.txt
+++ b/docs/ref/forms/models.txt
@@ -66,8 +66,8 @@ Model Form API reference. For introductory material about model forms, see the
 
     Arguments ``formset``, ``extra``, ``max_num``, ``can_order``,
     ``can_delete`` and ``validate_max`` are passed through to
-    :func:`~django.forms.formsets.formset_factory`. See :ref:`formsets` for
-    details.
+    :func:`~django.forms.formsets.formset_factory`. See :doc:`formsets
+    </topics/forms/formsets>` for details.
 
     See :ref:`model-formsets` for example usage.
 
diff --git a/docs/ref/forms/validation.txt b/docs/ref/forms/validation.txt
index 7f334f4361..bb9a928c1a 100644
--- a/docs/ref/forms/validation.txt
+++ b/docs/ref/forms/validation.txt
@@ -1,10 +1,9 @@
-.. currentmodule:: django.forms
-
-.. _form-and-field-validation:
-
+=========================
 Form and field validation
 =========================
 
+.. currentmodule:: django.forms
+
 Form validation happens when the data is cleaned. If you want to customize
 this process, there are various places to make changes, each one serving a
 different purpose. Three types of cleaning methods are run during form
@@ -112,7 +111,7 @@ for all remaining fields are still executed.
 .. _raising-validation-error:
 
 Raising ``ValidationError``
----------------------------
+===========================
 
 In order to make error messages flexible and easy to override, consider the
 following guidelines:
@@ -184,7 +183,7 @@ greatly benefit from fully featured ``ValidationError``\s (with a ``code`` name
 and a ``params`` dictionary).
 
 Raising multiple errors
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 If you detect multiple errors during a cleaning method and wish to signal all
 of them to the form submitter, it is possible to pass a list of errors to the
@@ -206,7 +205,7 @@ with ``code``\s and ``params`` but a list of strings will also work::
     ])
 
 Using validation in practice
-----------------------------
+============================
 
 The previous sections explained how validation works in general for forms.
 Since it can sometimes be easier to put things into place by seeing each
@@ -216,7 +215,7 @@ previous features.
 .. _validators:
 
 Using validators
-~~~~~~~~~~~~~~~~
+----------------
 
 Django's form (and model) fields support use of simple utility functions and
 classes known as validators. A validator is merely a callable object or
@@ -254,7 +253,7 @@ argument being the pattern: ``^[-a-zA-Z0-9_]+$``. See the section on
 available and for an example of how to write a validator.
 
 Form field default cleaning
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Let's first create a custom form field that validates its input is a string
 containing comma-separated email addresses. The full class looks like this::
@@ -300,7 +299,7 @@ method will be run as part of the cleaning process and it will, in turn, call
 the custom ``to_python()`` and ``validate()`` methods.
 
 Cleaning a specific field attribute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 Continuing on from the previous example, suppose that in our ``ContactForm``,
 we want to make sure that the ``recipients`` field always contains the address
@@ -326,7 +325,7 @@ write a cleaning method that operates on the ``recipients`` field, like so::
 .. _validating-fields-with-clean:
 
 Cleaning and validating fields that depend on each other
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 Suppose we add another requirement to our contact form: if the ``cc_myself``
 field is ``True``, the ``subject`` must contain the word ``"help"``. We are
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
index 5e51ec10b1..f5ca010d63 100644
--- a/docs/ref/forms/widgets.txt
+++ b/docs/ref/forms/widgets.txt
@@ -22,7 +22,7 @@ dictionary that corresponds to the widget.
 .. _widget-to-field:
 
 Specifying widgets
-------------------
+==================
 
 Whenever you specify a field on a form, Django will use a default widget
 that is appropriate to the type of data that is to be displayed. To find
@@ -43,9 +43,8 @@ example::
 This would specify a form with a comment that uses a larger :class:`Textarea`
 widget, rather than the default :class:`TextInput` widget.
 
-
 Setting arguments for widgets
------------------------------
+=============================
 
 Many widgets have optional extra arguments; they can be set when defining the
 widget on the field. In the following example, the
@@ -69,9 +68,8 @@ widget on the field. In the following example, the
 See the :ref:`built-in widgets` for more information about which widgets
 are available and which arguments they accept.
 
-
 Widgets inheriting from the Select widget
------------------------------------------
+=========================================
 
 Widgets inheriting from the :class:`Select` widget deal with choices. They
 present the user with a list of options to choose from. The different widgets
@@ -96,14 +94,13 @@ example::
     >>> choice_field.widget.choices
     [('1', 'First and only')]
 
-
 Widgets which offer a :attr:`~Select.choices` attribute can however be used
 with fields which are not based on choice -- such as a :class:`CharField` --
 but it is recommended to use a :class:`ChoiceField`-based field when the
 choices are inherent to the model and not just the representational widget.
 
 Customizing widget instances
-----------------------------
+============================
 
 When Django renders a widget as HTML, it only renders very minimal markup -
 Django doesn't add class names, or any other widget-specific attributes. This
@@ -116,7 +113,7 @@ There are two ways to customize widgets: :ref:`per widget instance
 .. _styling-widget-instances:
 
 Styling widget instances
-^^^^^^^^^^^^^^^^^^^^^^^^
+------------------------
 
 If you want to make one widget instance look different from another, you will
 need to specify additional attributes at the time when the widget object is
@@ -167,7 +164,7 @@ You can also set the HTML ``id`` using :attr:`~Widget.attrs`. See
 .. _styling-widget-classes:
 
 Styling widget classes
-^^^^^^^^^^^^^^^^^^^^^^
+----------------------
 
 With widgets, it is possible to add assets (``css`` and ``javascript``)
 and more deeply customize their appearance and behavior.
@@ -181,13 +178,16 @@ detail in the :doc:`Form Assets </topics/forms/media>` topic guide.
 
 .. _base-widget-classes:
 
-Base Widget classes
--------------------
+Base widget classes
+===================
 
 Base widget classes :class:`Widget` and :class:`MultiWidget` are subclassed by
 all the :ref:`built-in widgets <built-in widgets>` and may serve as a
 foundation for custom widgets.
 
+``Widget``
+----------
+
 .. class:: Widget(attrs=None)
 
     This abstract class cannot be rendered, but provides the basic attribute
@@ -259,6 +259,9 @@ foundation for custom widgets.
         customize it and add expensive processing, you should implement some
         caching mechanism yourself.
 
+``MultiWidget``
+---------------
+
 .. class:: MultiWidget(widgets, attrs=None)
 
     A widget that is composed of multiple widgets.
@@ -412,7 +415,7 @@ foundation for custom widgets.
 .. _built-in widgets:
 
 Built-in widgets
-----------------
+================
 
 Django provides a representation of all the basic HTML widgets, plus some
 commonly used groups of widgets in the ``django.forms.widgets`` module,
@@ -423,7 +426,7 @@ and :ref:`handling of multi-valued input <composite-widgets>`.
 .. _text-widgets:
 
 Widgets handling input of text
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+------------------------------
 
 These widgets make use of the HTML elements ``input`` and ``textarea``.
 
@@ -498,7 +501,7 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
 
     If no ``format`` argument is provided, the default format is the first
     format found in :setting:`DATE_INPUT_FORMATS` and respects
-    :ref:`format-localization`.
+    :doc:`/topics/i18n/formatting`.
 
 ``DateTimeInput``
 ~~~~~~~~~~~~~~~~~
@@ -515,7 +518,7 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
 
     If no ``format`` argument is provided, the default format is the first
     format found in :setting:`DATETIME_INPUT_FORMATS` and respects
-    :ref:`format-localization`.
+    :doc:`/topics/i18n/formatting`.
 
     By default, the microseconds part of the time value is always set to ``0``.
     If microseconds are required, use a subclass with the
@@ -536,7 +539,7 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
 
     If no ``format`` argument is provided, the default format is the first
     format found in :setting:`TIME_INPUT_FORMATS` and respects
-    :ref:`format-localization`.
+    :doc:`/topics/i18n/formatting`.
 
     For the treatment of microseconds, see :class:`DateTimeInput`.
 
@@ -550,7 +553,7 @@ These widgets make use of the HTML elements ``input`` and ``textarea``.
 .. _selector-widgets:
 
 Selector and checkbox widgets
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------
 
 ``CheckboxInput``
 ~~~~~~~~~~~~~~~~~
@@ -714,7 +717,7 @@ When looping over the checkboxes, the ``label`` and ``input`` tags include
 .. _file-upload-widgets:
 
 File upload widgets
-^^^^^^^^^^^^^^^^^^^
+-------------------
 
 ``FileInput``
 ~~~~~~~~~~~~~
@@ -735,7 +738,7 @@ File upload widgets
 .. _composite-widgets:
 
 Composite widgets
-^^^^^^^^^^^^^^^^^
+-----------------
 
 ``MultipleHiddenInput``
 ~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/docs/ref/models/database-functions.txt b/docs/ref/models/database-functions.txt
index dd0bd59379..b76ccb425f 100644
--- a/docs/ref/models/database-functions.txt
+++ b/docs/ref/models/database-functions.txt
@@ -26,7 +26,7 @@ allows the field to have two "empty values", but it's important for the
 ``Coalesce`` example below.
 
 Coalesce
---------
+========
 
 .. class:: Coalesce(*expressions, **extra)
 
@@ -67,7 +67,7 @@ Usage examples::
     >>> Coalesce('updated', now_sql)
 
 Concat
-------
+======
 
 .. class:: Concat(*expressions, **extra)
 
@@ -94,7 +94,7 @@ Usage example::
     Margaret Smith (Maggie)
 
 Greatest
---------
+========
 
 .. class:: Greatest(*expressions, **extra)
 
@@ -138,7 +138,7 @@ and ``comment.modified``.
     a sensible minimum value to provide as a default.
 
 Least
------
+=====
 
 .. class:: Least(*expressions, **extra)
 
@@ -162,7 +162,7 @@ will result in a database error.
     a sensible maximum value to provide as a default.
 
 Length
-------
+======
 
 .. class:: Length(expression, **extra)
 
@@ -193,7 +193,7 @@ It can also be registered as a transform. For example::
     The ability to register the function as a transform was added.
 
 Lower
-------
+=====
 
 .. class:: Lower(expression, **extra)
 
@@ -215,7 +215,7 @@ Usage example::
     The ability to register the function as a transform was added.
 
 Now
----
+===
 
 .. class:: Now()
 
@@ -238,7 +238,7 @@ Usage example::
     timestamp, use :class:`django.contrib.postgres.functions.TransactionNow`.
 
 Substr
-------
+======
 
 .. class:: Substr(expression, pos, length=None, **extra)
 
@@ -257,7 +257,7 @@ Usage example::
     marga
 
 Upper
-------
+=====
 
 .. class:: Upper(expression, **extra)
 
diff --git a/docs/ref/models/lookups.txt b/docs/ref/models/lookups.txt
index 58e6e35bbf..54ec332e92 100644
--- a/docs/ref/models/lookups.txt
+++ b/docs/ref/models/lookups.txt
@@ -31,7 +31,7 @@ A lookup expression consists of three parts:
 .. _lookup-registration-api:
 
 Registration API
-~~~~~~~~~~~~~~~~
+================
 
 Django uses :class:`~lookups.RegisterLookupMixin` to give a class the interface to
 register lookups on itself. The two prominent examples are
@@ -75,7 +75,7 @@ follow this API.
 .. _query-expression:
 
 The Query Expression API
-~~~~~~~~~~~~~~~~~~~~~~~~
+========================
 
 The query expression API is a common set of methods that classes define to be
 usable in query expressions to translate themselves into SQL expressions. Direct
@@ -118,7 +118,7 @@ following methods:
     be a :class:`~django.db.models.Field` instance.
 
 Transform reference
-~~~~~~~~~~~~~~~~~~~
+===================
 
 .. class:: Transform
 
@@ -165,7 +165,7 @@ Transform reference
         its ``lhs.output_field``.
 
 Lookup reference
-~~~~~~~~~~~~~~~~
+================
 
 .. class:: Lookup
 
diff --git a/docs/ref/models/meta.txt b/docs/ref/models/meta.txt
index e92cd9b971..b0868d341c 100644
--- a/docs/ref/models/meta.txt
+++ b/docs/ref/models/meta.txt
@@ -33,7 +33,7 @@ Field access API
 ================
 
 Retrieving a single field instance of a model by name
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------
 
 .. method:: Options.get_field(field_name)
 
@@ -83,7 +83,7 @@ Retrieving a single field instance of a model by name
         attribute after calling ``get_field()``.
 
 Retrieving all field instances of a model
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 .. method:: Options.get_fields(include_parents=True, include_hidden=False)
 
diff --git a/docs/ref/models/relations.txt b/docs/ref/models/relations.txt
index 1cec3e87c0..faa268daef 100644
--- a/docs/ref/models/relations.txt
+++ b/docs/ref/models/relations.txt
@@ -180,7 +180,7 @@ Related objects reference
 .. _direct-assignment:
 
 Direct Assignment
------------------
+=================
 
 A related object set can be replaced in bulk with one operation by assigning a
 new iterable of objects to it::
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index ea1c5e11a6..a64280593c 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -10,14 +10,14 @@ documentation for any custom tags or filters installed.
 .. _ref-templates-builtins-tags:
 
 Built-in tag reference
-----------------------
+======================
 
 .. highlight:: html+django
 
 .. templatetag:: autoescape
 
 autoescape
-^^^^^^^^^^
+----------
 
 Controls the current auto-escaping behavior. This tag takes either ``on`` or
 ``off`` as an argument and that determines whether auto-escaping is in effect
@@ -41,7 +41,7 @@ Sample usage::
 .. templatetag:: block
 
 block
-^^^^^
+-----
 
 Defines a block that can be overridden by child templates. See
 :ref:`Template inheritance <template-inheritance>` for more information.
@@ -49,7 +49,7 @@ Defines a block that can be overridden by child templates. See
 .. templatetag:: comment
 
 comment
-^^^^^^^
+-------
 
 Ignores everything between ``{% comment %}`` and ``{% endcomment %}``.
 An optional note may be inserted in the first tag. For example, this is
@@ -67,7 +67,7 @@ Sample usage::
 .. templatetag:: csrf_token
 
 csrf_token
-^^^^^^^^^^
+----------
 
 This tag is used for CSRF protection, as described in the documentation for
 :doc:`Cross Site Request Forgeries </ref/csrf>`.
@@ -75,7 +75,7 @@ This tag is used for CSRF protection, as described in the documentation for
 .. templatetag:: cycle
 
 cycle
-^^^^^
+-----
 
 Produces one of its arguments each time this tag is encountered. The first
 argument is produced on the first encounter, the second argument on the second
@@ -200,7 +200,7 @@ call to ``{% cycle %}`` doesn't specify ``silent``::
 .. templatetag:: debug
 
 debug
-^^^^^
+-----
 
 Outputs a whole load of debugging information, including the current context
 and imported modules.
@@ -208,7 +208,7 @@ and imported modules.
 .. templatetag:: extends
 
 extends
-^^^^^^^
+-------
 
 Signals that this template extends a parent template.
 
@@ -227,7 +227,7 @@ See :ref:`template-inheritance` for more information.
 .. templatetag:: filter
 
 filter
-^^^^^^
+------
 
 Filters the contents of the block through one or more filters. Multiple
 filters can be specified with pipes and filters can have arguments, just as
@@ -251,7 +251,7 @@ Sample usage::
 .. templatetag:: firstof
 
 firstof
-^^^^^^^
+-------
 
 Outputs the first argument variable that is not ``False``. Outputs nothing if
 all the passed variables are ``False``.
@@ -295,7 +295,7 @@ output inside a variable.
 .. templatetag:: for
 
 for
-^^^
+---
 
 Loops over each item in an array, making the item available in a context
 variable. For example, to display a list of athletes provided in
@@ -353,7 +353,7 @@ Variable                    Description
 ==========================  ===============================================
 
 for ... empty
-^^^^^^^^^^^^^
+-------------
 
 The ``for`` tag can take an optional ``{% empty %}`` clause whose text is
 displayed if the given array is empty or could not be found::
@@ -382,7 +382,7 @@ than -- the following::
 .. templatetag:: if
 
 if
-^^
+--
 
 The ``{% if %}`` tag evaluates a variable, and if that variable is "true" (i.e.
 exists, is not empty, and is not a false boolean value) the contents of the
@@ -404,7 +404,7 @@ clauses, as well as an ``{% else %}`` clause that will be displayed if all
 previous conditions fail. These clauses are optional.
 
 Boolean operators
-"""""""""""""""""
+~~~~~~~~~~~~~~~~~
 
 :ttag:`if` tags may use ``and``, ``or`` or ``not`` to test a number of
 variables or to negate a given variable::
@@ -447,7 +447,7 @@ them to indicate precedence, you should use nested :ttag:`if` tags.
 ``<=``, ``>=`` and ``in`` which work as follows:
 
 ``==`` operator
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 Equality. Example::
 
@@ -456,7 +456,7 @@ Equality. Example::
     {% endif %}
 
 ``!=`` operator
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 Inequality. Example::
 
@@ -466,7 +466,7 @@ Inequality. Example::
     {% endif %}
 
 ``<`` operator
-~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^
 
 Less than. Example::
 
@@ -475,7 +475,7 @@ Less than. Example::
     {% endif %}
 
 ``>`` operator
-~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^
 
 Greater than. Example::
 
@@ -484,7 +484,7 @@ Greater than. Example::
     {% endif %}
 
 ``<=`` operator
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 Less than or equal to. Example::
 
@@ -493,7 +493,7 @@ Less than or equal to. Example::
     {% endif %}
 
 ``>=`` operator
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 Greater than or equal to. Example::
 
@@ -502,7 +502,7 @@ Greater than or equal to. Example::
     {% endif %}
 
 ``in`` operator
-~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^
 
 Contained within. This operator is supported by many Python containers to test
 whether the given value is in the container. The following are some examples
@@ -523,7 +523,7 @@ of how ``x in y`` will be interpreted::
     {% endif %}
 
 ``not in`` operator
-~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^
 
 Not contained within. This is the negation of the ``in`` operator.
 
@@ -537,7 +537,7 @@ you should use::
     {% if a > b and b > c %}
 
 Filters
-"""""""
+~~~~~~~
 
 You can also use filters in the :ttag:`if` expression. For example::
 
@@ -546,7 +546,7 @@ You can also use filters in the :ttag:`if` expression. For example::
     {% endif %}
 
 Complex expressions
-"""""""""""""""""""
+~~~~~~~~~~~~~~~~~~~
 
 All of the above can be combined to form complex expressions. For such
 expressions, it can be important to know how the operators are grouped when the
@@ -575,7 +575,7 @@ Sometimes that is better for clarity anyway, for the sake of those who do not
 know the precedence rules.
 
 ``ifequal`` and ``ifnotequal``
-""""""""""""""""""""""""""""""
+------------------------------
 
 ``{% ifequal a b %} ... {% endifequal %}`` is an obsolete way to write
 ``{% if a == b %} ... {% endif %}``. Likewise, ``{% ifnotequal a b %} ...
@@ -585,7 +585,7 @@ The ``ifequal`` and ``ifnotequal`` tags will be deprecated in a future release.
 .. templatetag:: ifchanged
 
 ifchanged
-^^^^^^^^^
+---------
 
 Check if a value has changed from the last iteration of a loop.
 
@@ -630,7 +630,7 @@ will be displayed if the value has not changed::
 .. templatetag:: include
 
 include
-^^^^^^^
+-------
 
 Loads a template and renders it with the current context. This is a way of
 "including" other templates within a template.
@@ -703,7 +703,7 @@ and returns an empty string.
 .. templatetag:: load
 
 load
-^^^^
+----
 
 Loads a custom template tag set.
 
@@ -725,7 +725,7 @@ more information.
 .. templatetag:: lorem
 
 lorem
-^^^^^
+-----
 
 .. versionadded:: 1.8
 
@@ -763,7 +763,7 @@ Examples:
 .. templatetag:: now
 
 now
-^^^
+---
 
 Displays the current date and/or time, using a format according to the given
 string. Such string can contain format specifiers characters as described
@@ -788,7 +788,7 @@ This would display as "It is the 4th of September".
     :setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`,
     :setting:`SHORT_DATE_FORMAT` or :setting:`SHORT_DATETIME_FORMAT`.
     The predefined formats may vary depending on the current locale and
-    if :ref:`format-localization` is enabled, e.g.::
+    if :doc:`/topics/i18n/formatting` is enabled, e.g.::
 
         It is {% now "SHORT_DATETIME_FORMAT" %}
 
@@ -806,7 +806,7 @@ The ability to use the "as" syntax was added.
 .. templatetag:: regroup
 
 regroup
-^^^^^^^
+-------
 
 Regroups a list of alike objects by a common attribute.
 
@@ -920,7 +920,7 @@ Another solution is to sort the data in the template using the
     {% regroup cities|dictsort:"country" by country as country_list %}
 
 Grouping on other properties
-""""""""""""""""""""""""""""
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Any valid template lookup is a legal grouping attribute for the regroup
 tag, including methods, attributes, dictionary keys and list items. For
@@ -942,7 +942,7 @@ attribute, allowing  you to group on the display string rather than the
 .. templatetag:: spaceless
 
 spaceless
-^^^^^^^^^
+---------
 
 Removes whitespace between HTML tags. This includes tab
 characters and newlines.
@@ -971,7 +971,7 @@ this example, the space around ``Hello`` won't be stripped::
 .. templatetag:: ssi
 
 ssi
-^^^
+---
 
 .. deprecated:: 1.8
 
@@ -1010,7 +1010,7 @@ See also: :ttag:`{% include %}<include>`.
 .. templatetag:: templatetag
 
 templatetag
-^^^^^^^^^^^
+-----------
 
 Outputs one of the syntax characters used to compose template tags.
 
@@ -1039,7 +1039,7 @@ Sample usage::
 .. templatetag:: url
 
 url
-^^^
+---
 
 Returns an absolute path reference (a URL without the domain name) matching a
 given view and optional parameters. Any special characters in the resulting
@@ -1127,7 +1127,7 @@ by the context as to the current application.
 .. templatetag:: verbatim
 
 verbatim
-^^^^^^^^
+--------
 
 Stops the template engine from rendering the contents of this block tag.
 
@@ -1148,7 +1148,7 @@ You can also designate a specific closing tag, allowing the use of
 .. templatetag:: widthratio
 
 widthratio
-^^^^^^^^^^
+----------
 
 For creating bar charts and such, this tag calculates the ratio of a given
 value to a maximum value, and then applies that ratio to a constant.
@@ -1171,7 +1171,7 @@ variable. It can be useful, for instance, in a :ttag:`blocktrans` like this::
 .. templatetag:: with
 
 with
-^^^^
+----
 
 Caches a complex variable under a simpler name. This is useful when accessing
 an "expensive" method (e.g., one that hits the database) multiple times.
@@ -1197,12 +1197,12 @@ You can assign more than one context variable::
 .. _ref-templates-builtins-filters:
 
 Built-in filter reference
--------------------------
+=========================
 
 .. templatefilter:: add
 
 add
-^^^
+---
 
 Adds the argument to the value.
 
@@ -1232,7 +1232,7 @@ output will be ``[1, 2, 3, 4, 5, 6]``.
 .. templatefilter:: addslashes
 
 addslashes
-^^^^^^^^^^
+----------
 
 Adds slashes before quotes. Useful for escaping strings in CSV, for example.
 
@@ -1246,7 +1246,7 @@ If ``value`` is ``"I'm using Django"``, the output will be
 .. templatefilter:: capfirst
 
 capfirst
-^^^^^^^^
+--------
 
 Capitalizes the first character of the value. If the first character is not
 a letter, this filter has no effect.
@@ -1260,7 +1260,7 @@ If ``value`` is ``"django"``, the output will be ``"Django"``.
 .. templatefilter:: center
 
 center
-^^^^^^
+------
 
 Centers the value in a field of a given width.
 
@@ -1273,7 +1273,7 @@ If ``value`` is ``"Django"``, the output will be ``"     Django    "``.
 .. templatefilter:: cut
 
 cut
-^^^
+---
 
 Removes all values of arg from the given string.
 
@@ -1287,7 +1287,7 @@ If ``value`` is ``"String with spaces"``, the output will be
 .. templatefilter:: date
 
 date
-^^^^
+----
 
 Formats a date according to the given format.
 
@@ -1416,7 +1416,7 @@ representation of a ``datetime`` value. E.g.::
 .. templatefilter:: default
 
 default
-^^^^^^^
+-------
 
 If value evaluates to ``False``, uses the given default. Otherwise, uses the
 value.
@@ -1430,7 +1430,7 @@ If ``value`` is ``""`` (the empty string), the output will be ``nothing``.
 .. templatefilter:: default_if_none
 
 default_if_none
-^^^^^^^^^^^^^^^
+---------------
 
 If (and only if) value is ``None``, uses the given default. Otherwise, uses the
 value.
@@ -1447,7 +1447,7 @@ If ``value`` is ``None``, the output will be the string ``"nothing"``.
 .. templatefilter:: dictsort
 
 dictsort
-^^^^^^^^
+--------
 
 Takes a list of dictionaries and returns that list sorted by the key given in
 the argument.
@@ -1501,7 +1501,7 @@ then the output would be::
 .. templatefilter:: dictsortreversed
 
 dictsortreversed
-^^^^^^^^^^^^^^^^
+----------------
 
 Takes a list of dictionaries and returns that list sorted in reverse order by
 the key given in the argument. This works exactly the same as the above filter,
@@ -1510,7 +1510,7 @@ but the returned value will be in reverse order.
 .. templatefilter:: divisibleby
 
 divisibleby
-^^^^^^^^^^^
+-----------
 
 Returns ``True`` if the value is divisible by the argument.
 
@@ -1523,7 +1523,7 @@ If ``value`` is ``21``, the output would be ``True``.
 .. templatefilter:: escape
 
 escape
-^^^^^^
+------
 
 Escapes a string's HTML. Specifically, it makes these replacements:
 
@@ -1552,7 +1552,7 @@ For example, you can apply ``escape`` to fields when :ttag:`autoescape` is off::
 .. templatefilter:: escapejs
 
 escapejs
-^^^^^^^^
+--------
 
 Escapes characters for use in JavaScript strings. This does *not* make the
 string safe for use in HTML, but does protect you from syntax errors when using
@@ -1568,7 +1568,7 @@ the output will be ``"testing\\u000D\\u000Ajavascript \\u0027string\\u0022 \\u00
 .. templatefilter:: filesizeformat
 
 filesizeformat
-^^^^^^^^^^^^^^
+--------------
 
 Formats the value like a 'human-readable' file size (i.e. ``'13 KB'``,
 ``'4.1 MB'``, ``'102 bytes'``, etc.).
@@ -1590,7 +1590,7 @@ If ``value`` is 123456789, the output would be ``117.7 MB``.
 .. templatefilter:: first
 
 first
-^^^^^
+-----
 
 Returns the first item in a list.
 
@@ -1603,7 +1603,7 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be ``'a'``.
 .. templatefilter:: floatformat
 
 floatformat
-^^^^^^^^^^^
+-----------
 
 When used without an argument, rounds a floating-point number to one decimal
 place -- but only if there's a decimal part to be displayed. For example:
@@ -1656,7 +1656,7 @@ with an argument of ``-1``.
 .. templatefilter:: force_escape
 
 force_escape
-^^^^^^^^^^^^
+------------
 
 Applies HTML escaping to a string (see the :tfilter:`escape` filter for
 details). This filter is applied *immediately* and returns a new, escaped
@@ -1674,7 +1674,7 @@ the :tfilter:`linebreaks` filter::
 .. templatefilter:: get_digit
 
 get_digit
-^^^^^^^^^
+---------
 
 Given a whole number, returns the requested digit, where 1 is the right-most
 digit, 2 is the second-right-most digit, etc. Returns the original value for
@@ -1690,7 +1690,7 @@ If ``value`` is ``123456789``, the output will be ``8``.
 .. templatefilter:: iriencode
 
 iriencode
-^^^^^^^^^
+---------
 
 Converts an IRI (Internationalized Resource Identifier) to a string that is
 suitable for including in a URL. This is necessary if you're trying to use
@@ -1708,7 +1708,7 @@ If ``value`` is ``"?test=1&me=2"``, the output will be ``"?test=1&amp;me=2"``.
 .. templatefilter:: join
 
 join
-^^^^
+----
 
 Joins a list with a string, like Python's ``str.join(list)``
 
@@ -1722,7 +1722,7 @@ If ``value`` is the list ``['a', 'b', 'c']``, the output will be the string
 .. templatefilter:: last
 
 last
-^^^^
+----
 
 Returns the last item in a list.
 
@@ -1736,7 +1736,7 @@ string ``"d"``.
 .. templatefilter:: length
 
 length
-^^^^^^
+------
 
 Returns the length of the value. This works for both strings and lists.
 
@@ -1755,7 +1755,7 @@ If ``value`` is ``['a', 'b', 'c', 'd']`` or ``"abcd"``, the output will be
 .. templatefilter:: length_is
 
 length_is
-^^^^^^^^^
+---------
 
 Returns ``True`` if the value's length is the argument, or ``False`` otherwise.
 
@@ -1769,7 +1769,7 @@ If ``value`` is ``['a', 'b', 'c', 'd']`` or ``"abcd"``, the output will be
 .. templatefilter:: linebreaks
 
 linebreaks
-^^^^^^^^^^
+----------
 
 Replaces line breaks in plain text with appropriate HTML; a single
 newline becomes an HTML line break (``<br />``) and a new line
@@ -1785,7 +1785,7 @@ slug</p>``.
 .. templatefilter:: linebreaksbr
 
 linebreaksbr
-^^^^^^^^^^^^
+------------
 
 Converts all newlines in a piece of plain text to HTML line breaks
 (``<br />``).
@@ -1800,7 +1800,7 @@ slug``.
 .. templatefilter:: linenumbers
 
 linenumbers
-^^^^^^^^^^^
+-----------
 
 Displays text with line numbers.
 
@@ -1823,7 +1823,7 @@ the output will be::
 .. templatefilter:: ljust
 
 ljust
-^^^^^
+-----
 
 Left-aligns the value in a field of a given width.
 
@@ -1838,7 +1838,7 @@ If ``value`` is ``Django``, the output will be ``"Django    "``.
 .. templatefilter:: lower
 
 lower
-^^^^^
+-----
 
 Converts a string into all lowercase.
 
@@ -1852,7 +1852,7 @@ If ``value`` is ``Totally LOVING this Album!``, the output will be
 .. templatefilter:: make_list
 
 make_list
-^^^^^^^^^
+---------
 
 Returns the value turned into a list. For a string, it's a list of characters.
 For an integer, the argument is cast into an unicode string before creating a
@@ -1869,7 +1869,7 @@ list ``['1', '2', '3']``.
 .. templatefilter:: phone2numeric
 
 phone2numeric
-^^^^^^^^^^^^^
+-------------
 
 Converts a phone number (possibly containing letters) to its numerical
 equivalent.
@@ -1886,7 +1886,7 @@ If ``value`` is ``800-COLLECT``, the output will be ``800-2655328``.
 .. templatefilter:: pluralize
 
 pluralize
-^^^^^^^^^
+---------
 
 Returns a plural suffix if the value is not 1. By default, this suffix is
 ``'s'``.
@@ -1917,14 +1917,14 @@ Example::
 .. templatefilter:: pprint
 
 pprint
-^^^^^^
+------
 
 A wrapper around :func:`pprint.pprint` -- for debugging, really.
 
 .. templatefilter:: random
 
 random
-^^^^^^
+------
 
 Returns a random item from the given list.
 
@@ -1937,7 +1937,7 @@ If ``value`` is the list ``['a', 'b', 'c', 'd']``, the output could be ``"b"``.
 .. templatefilter:: removetags
 
 removetags
-^^^^^^^^^^
+----------
 
 .. deprecated:: 1.8
 
@@ -1973,7 +1973,7 @@ unescaped output will be ``"<B>Joel</B> <button>is</button> a slug"``.
 .. templatefilter:: rjust
 
 rjust
-^^^^^
+-----
 
 Right-aligns the value in a field of a given width.
 
@@ -1988,7 +1988,7 @@ If ``value`` is ``Django``, the output will be ``"    Django"``.
 .. templatefilter:: safe
 
 safe
-^^^^
+----
 
 Marks a string as not requiring further HTML escaping prior to output. When
 autoescaping is off, this filter has no effect.
@@ -2004,7 +2004,7 @@ autoescaping is off, this filter has no effect.
 .. templatefilter:: safeseq
 
 safeseq
-^^^^^^^
+-------
 
 Applies the :tfilter:`safe` filter to each element of a sequence. Useful in
 conjunction with other filters that operate on sequences, such as
@@ -2019,7 +2019,7 @@ individual elements of the sequence.
 .. templatefilter:: slice
 
 slice
-^^^^^
+-----
 
 Returns a slice of the list.
 
@@ -2036,7 +2036,7 @@ If ``some_list`` is ``['a', 'b', 'c']``, the output will be ``['a', 'b']``.
 .. templatefilter:: slugify
 
 slugify
-^^^^^^^
+-------
 
 Converts to ASCII. Converts spaces to hyphens. Removes characters that aren't
 alphanumerics, underscores, or hyphens. Converts to lowercase. Also strips
@@ -2051,7 +2051,7 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``"joel-is-a-slug"``.
 .. templatefilter:: stringformat
 
 stringformat
-^^^^^^^^^^^^
+------------
 
 Formats the variable according to the argument, a string formatting specifier.
 This specifier uses Python string formatting syntax, with the exception that
@@ -2069,7 +2069,7 @@ If ``value`` is ``10``, the output will be ``1.000000E+01``.
 .. templatefilter:: striptags
 
 striptags
-^^^^^^^^^
+---------
 
 Makes all possible efforts to strip all [X]HTML tags.
 
@@ -2093,7 +2093,7 @@ output will be ``"Joel is a slug"``.
 .. templatefilter:: time
 
 time
-^^^^
+----
 
 Formats a time according to the given format.
 
@@ -2139,7 +2139,7 @@ used, without applying any localization.
 .. templatefilter:: timesince
 
 timesince
-^^^^^^^^^
+---------
 
 Formats a date as the time since that date (e.g., "4 days, 6 hours").
 
@@ -2159,7 +2159,7 @@ date that is in the future relative to the comparison point.
 .. templatefilter:: timeuntil
 
 timeuntil
-^^^^^^^^^
+---------
 
 Similar to ``timesince``, except that it measures the time from now until the
 given date or datetime. For example, if today is 1 June 2006 and
@@ -2180,7 +2180,7 @@ date that is in the past relative to the comparison point.
 .. templatefilter:: title
 
 title
-^^^^^
+-----
 
 Converts a string into titlecase by making words start with an uppercase
 character and the remaining characters lowercase. This tag makes no effort to
@@ -2195,7 +2195,7 @@ If ``value`` is ``"my FIRST post"``, the output will be ``"My First Post"``.
 .. templatefilter:: truncatechars
 
 truncatechars
-^^^^^^^^^^^^^
+-------------
 
 Truncates a string if it is longer than the specified number of characters.
 Truncated strings will end with a translatable ellipsis sequence ("...").
@@ -2211,7 +2211,7 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``"Joel i..."``.
 .. templatefilter:: truncatechars_html
 
 truncatechars_html
-^^^^^^^^^^^^^^^^^^
+------------------
 
 Similar to :tfilter:`truncatechars`, except that it is aware of HTML tags. Any
 tags that are opened in the string and not closed before the truncation point
@@ -2229,7 +2229,7 @@ Newlines in the HTML content will be preserved.
 .. templatefilter:: truncatewords
 
 truncatewords
-^^^^^^^^^^^^^
+-------------
 
 Truncates a string after a certain number of words.
 
@@ -2246,7 +2246,7 @@ Newlines within the string will be removed.
 .. templatefilter:: truncatewords_html
 
 truncatewords_html
-^^^^^^^^^^^^^^^^^^
+------------------
 
 Similar to :tfilter:`truncatewords`, except that it is aware of HTML tags. Any
 tags that are opened in the string and not closed before the truncation point,
@@ -2267,7 +2267,7 @@ Newlines in the HTML content will be preserved.
 .. templatefilter:: unordered_list
 
 unordered_list
-^^^^^^^^^^^^^^
+--------------
 
 Recursively takes a self-nested list and returns an HTML unordered list --
 WITHOUT opening and closing <ul> tags.
@@ -2297,7 +2297,7 @@ contains ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``, then
 .. templatefilter:: upper
 
 upper
-^^^^^
+-----
 
 Converts a string into all uppercase.
 
@@ -2310,7 +2310,7 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``"JOEL IS A SLUG"``.
 .. templatefilter:: urlencode
 
 urlencode
-^^^^^^^^^
+---------
 
 Escapes a value for use in a URL.
 
@@ -2335,7 +2335,7 @@ If ``value`` is ``"https://www.example.org/"``, the output will be
 .. templatefilter:: urlize
 
 urlize
-^^^^^^
+------
 
 Converts URLs and email addresses in text into clickable links.
 
@@ -2385,7 +2385,7 @@ Django's built-in :tfilter:`escape` filter. The default value for
 .. templatefilter:: urlizetrunc
 
 urlizetrunc
-^^^^^^^^^^^
+-----------
 
 Converts URLs and email addresses into clickable links just like urlize_, but
 truncates URLs longer than the given character limit.
@@ -2406,7 +2406,7 @@ As with urlize_, this filter should only be applied to plain text.
 .. templatefilter:: wordcount
 
 wordcount
-^^^^^^^^^
+---------
 
 Returns the number of words.
 
@@ -2419,7 +2419,7 @@ If ``value`` is ``"Joel is a slug"``, the output will be ``4``.
 .. templatefilter:: wordwrap
 
 wordwrap
-^^^^^^^^
+--------
 
 Wraps words at specified line length.
 
@@ -2438,7 +2438,7 @@ If ``value`` is ``Joel is a slug``, the output would be::
 .. templatefilter:: yesno
 
 yesno
-^^^^^
+-----
 
 Maps values for ``True``, ``False``, and (optionally) ``None``, to the strings
 "yes", "no", "maybe", or a custom mapping passed as a comma-separated list, and
@@ -2460,14 +2460,14 @@ Value       Argument                Outputs
 ==========  ======================  ===========================================
 
 Internationalization tags and filters
--------------------------------------
+=====================================
 
 Django provides template tags and filters to control each aspect of
 :doc:`internationalization </topics/i18n/index>` in templates. They allow for
 granular control of translations, formatting, and time zone conversions.
 
 i18n
-^^^^
+----
 
 This library allows specifying translatable text in templates.
 To enable it, set :setting:`USE_I18N` to ``True``, then load it with
@@ -2476,7 +2476,7 @@ To enable it, set :setting:`USE_I18N` to ``True``, then load it with
 See :ref:`specifying-translation-strings-in-template-code`.
 
 l10n
-^^^^
+----
 
 This library provides control over the localization of values in templates.
 You only need to load the library using ``{% load l10n %}``, but you'll often
@@ -2485,7 +2485,7 @@ set :setting:`USE_L10N` to ``True`` so that localization is active by default.
 See :ref:`topic-l10n-templates`.
 
 tz
-^^
+--
 
 This library provides control over time zone conversions in templates.
 Like ``l10n``, you only need to load the library using ``{% load tz %}``,
@@ -2495,25 +2495,25 @@ to local time happens by default.
 See :ref:`time-zones-in-templates`.
 
 Other tags and filters libraries
---------------------------------
+================================
 
 Django comes with a couple of other template-tag libraries that you have to
 enable explicitly in your :setting:`INSTALLED_APPS` setting and enable in your
 template with the :ttag:`{% load %}<load>` tag.
 
 django.contrib.humanize
-^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------
 
 A set of Django template filters useful for adding a "human touch" to data. See
 :doc:`/ref/contrib/humanize`.
 
 static
-^^^^^^
+------
 
 .. templatetag:: static
 
 static
-""""""
+~~~~~~
 
 To link to static files that are saved in :setting:`STATIC_ROOT` Django ships
 with a :ttag:`static` template tag. You can use this regardless if you're
@@ -2551,7 +2551,7 @@ slightly different call::
 .. templatetag:: get_static_prefix
 
 get_static_prefix
-"""""""""""""""""
+~~~~~~~~~~~~~~~~~
 
 You should prefer the :ttag:`static` template tag, but if you need more control
 over exactly where and how :setting:`STATIC_URL` is injected into the template,
@@ -2572,7 +2572,7 @@ the value multiple times::
 .. templatetag:: get_media_prefix
 
 get_media_prefix
-""""""""""""""""
+~~~~~~~~~~~~~~~~
 
 Similar to the :ttag:`get_static_prefix`, ``get_media_prefix`` populates a
 template variable with the media prefix :setting:`MEDIA_URL`, e.g.::
diff --git a/docs/ref/urlresolvers.txt b/docs/ref/urlresolvers.txt
index d7e1077d85..bdeb5472ad 100644
--- a/docs/ref/urlresolvers.txt
+++ b/docs/ref/urlresolvers.txt
@@ -5,7 +5,7 @@
 .. module:: django.core.urlresolvers
 
 reverse()
----------
+=========
 
 If you need to use something similar to the :ttag:`url` template tag in
 your code, Django provides the following function:
@@ -94,7 +94,7 @@ use for reversing. By default, the root URLconf for the current thread is used.
     results.
 
 reverse_lazy()
---------------
+==============
 
 A lazily evaluated version of `reverse()`_.
 
@@ -114,7 +114,7 @@ URLConf is loaded. Some common cases where this function is necessary are:
   signature.
 
 resolve()
----------
+=========
 
 The ``resolve()`` function can be used for resolving URL paths to the
 corresponding view functions. It has the following signature:
@@ -217,7 +217,7 @@ whether a view would raise a ``Http404`` error before redirecting to it::
         return response
 
 get_script_prefix()
--------------------
+===================
 
 .. function:: get_script_prefix()
 
diff --git a/docs/ref/urls.txt b/docs/ref/urls.txt
index 1d55ba05b6..168e2c09be 100644
--- a/docs/ref/urls.txt
+++ b/docs/ref/urls.txt
@@ -76,7 +76,7 @@ The ``optional_dictionary`` and ``optional_name`` parameters are described in
     at a time (the 255th argument is the initial prefix argument).
 
 static()
---------
+========
 
 .. function:: static.static(prefix, view=django.views.static.serve, **kwargs)
 
@@ -95,7 +95,7 @@ Helper function to return a URL pattern for serving files in debug mode::
     (``'django.views.static.serve'``) to the function.
 
 url()
------
+=====
 
 .. function:: url(regex, view, kwargs=None, name=None, prefix='')
 
@@ -126,7 +126,7 @@ parameter is useful.
     ``view`` parameter.
 
 include()
----------
+=========
 
 .. function:: include(module, namespace=None, app_name=None)
               include(pattern_list)
@@ -175,7 +175,7 @@ See :ref:`including-other-urlconfs` and :ref:`namespaces-and-include`.
     application namespace or remove the instance namespace.
 
 handler400
-----------
+==========
 
 .. data:: handler400
 
@@ -191,7 +191,7 @@ See the documentation about :ref:`the 400 (bad request) view
 <http_bad_request_view>` for more information.
 
 handler403
-----------
+==========
 
 .. data:: handler403
 
@@ -207,7 +207,7 @@ See the documentation about :ref:`the 403 (HTTP Forbidden) view
 <http_forbidden_view>` for more information.
 
 handler404
-----------
+==========
 
 .. data:: handler404
 
@@ -222,7 +222,7 @@ See the documentation about :ref:`the 404 (HTTP Not Found) view
 <http_not_found_view>` for more information.
 
 handler500
-----------
+==========
 
 .. data:: handler500
 
diff --git a/docs/releases/1.1.3.txt b/docs/releases/1.1.3.txt
index ffc0395199..270f495813 100644
--- a/docs/releases/1.1.3.txt
+++ b/docs/releases/1.1.3.txt
@@ -19,7 +19,7 @@ Backwards incompatible changes
 ==============================
 
 Restricted filters in admin interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 The Django administrative interface, django.contrib.admin, supports
 filtering of displayed lists of objects by fields on the corresponding
diff --git a/docs/releases/1.1.4.txt b/docs/releases/1.1.4.txt
index 1d16a8cb1c..4d3544cc35 100644
--- a/docs/releases/1.1.4.txt
+++ b/docs/releases/1.1.4.txt
@@ -19,7 +19,7 @@ Backwards incompatible changes
 ==============================
 
 CSRF exception for AJAX requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Django includes a CSRF-protection mechanism, which makes use of a
 token inserted into outgoing forms. Middleware then checks for the
diff --git a/docs/releases/1.2.4.txt b/docs/releases/1.2.4.txt
index ae15ea6f7c..86a018a55f 100644
--- a/docs/releases/1.2.4.txt
+++ b/docs/releases/1.2.4.txt
@@ -19,7 +19,7 @@ Backwards incompatible changes
 ==============================
 
 Restricted filters in admin interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 The Django administrative interface, django.contrib.admin, supports
 filtering of displayed lists of objects by fields on the corresponding
diff --git a/docs/releases/1.2.5.txt b/docs/releases/1.2.5.txt
index 5d3050a993..f5d452942d 100644
--- a/docs/releases/1.2.5.txt
+++ b/docs/releases/1.2.5.txt
@@ -19,7 +19,7 @@ Backwards incompatible changes
 ==============================
 
 CSRF exception for AJAX requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Django includes a CSRF-protection mechanism, which makes use of a
 token inserted into outgoing forms. Middleware then checks for the
@@ -68,7 +68,7 @@ documentation for your version of Django, as the exact code necessary
 is different for some older versions of Django.
 
 FileField no longer deletes files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 In earlier Django versions, when a model instance containing a
 :class:`~django.db.models.FileField` was deleted,
@@ -82,7 +82,7 @@ yourself (for instance, with a custom management command that can be run
 manually or scheduled to run periodically via e.g. cron).
 
 Use of custom SQL to load initial data in tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 Django provides a custom SQL hooks as a way to inject hand-crafted SQL
 into the database synchronization process. One of the possible uses
@@ -112,7 +112,7 @@ should either insert it using :ref:`test fixtures
 test case.
 
 ModelAdmin.lookup_allowed signature changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 Django 1.2.4 introduced a method ``lookup_allowed`` on ``ModelAdmin``, to cope
 with a security issue (changeset `[15033]
diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt
index bc25db5749..6d72f6021e 100644
--- a/docs/releases/1.2.txt
+++ b/docs/releases/1.2.txt
@@ -309,7 +309,7 @@ Django's :doc:`internationalization framework </topics/i18n/index>` has been exp
 with locale-aware formatting and form processing. That means, if enabled, dates
 and numbers on templates will be displayed using the format specified for the
 current locale. Django will also use localized formats when parsing data in
-forms. See :ref:`Format localization <format-localization>` for more details.
+forms. See :doc:`/topics/i18n/formatting` for more details.
 
 ``readonly_fields`` in ``ModelAdmin``
 -------------------------------------
@@ -1073,10 +1073,10 @@ to provide localizers the possibility to translate date and time formats. They
 were translatable :term:`translation strings <translation string>` that could
 be recognized because they were all upper case (for example
 :setting:`DATETIME_FORMAT`, :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`).
-They have been deprecated in favor of the new :ref:`Format localization
-<format-localization>` infrastructure that allows localizers to specify that
-information in a ``formats.py`` file in the corresponding
-``django/conf/locale/<locale name>/`` directory.
+They have been deprecated in favor of the new :doc:`/topics/i18n/formatting` 
+infrastructure that allows localizers to specify that information in a 
+``formats.py`` file in the corresponding ``django/conf/locale/<locale name>/`` 
+directory.
 
 GeoDjango
 ---------
@@ -1090,7 +1090,7 @@ following sections provide information on the most-popular APIs that
 were affected by these changes.
 
 ``SpatialBackend``
-^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~
 
 Prior to the creation of the separate spatial backends, the
 ``django.contrib.gis.db.backend.SpatialBackend`` object was
@@ -1118,7 +1118,7 @@ Would need to be changed::
     PostGISAdaptor = connection.ops.Adapter
 
 ``SpatialRefSys`` and ``GeometryColumns`` models
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In previous versions of GeoDjango, :mod:`django.contrib.gis.db.models`
 had ``SpatialRefSys`` and ``GeometryColumns`` models for querying
diff --git a/docs/releases/1.3.4.txt b/docs/releases/1.3.4.txt
index 3a174b3d44..54ca809ffc 100644
--- a/docs/releases/1.3.4.txt
+++ b/docs/releases/1.3.4.txt
@@ -7,7 +7,7 @@ Django 1.3.4 release notes
 This is the fourth release in the Django 1.3 series.
 
 Host header poisoning
----------------------
+=====================
 
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
diff --git a/docs/releases/1.3.5.txt b/docs/releases/1.3.5.txt
index f71758b0a4..7e40fa3c19 100644
--- a/docs/releases/1.3.5.txt
+++ b/docs/releases/1.3.5.txt
@@ -14,7 +14,7 @@ the other we've chosen to take further steps to tighten up Django's code in
 response to independent discovery of potential problems from multiple sources.
 
 Host header poisoning
----------------------
+=====================
 
 Several earlier Django security releases focused on the issue of poisoning the
 HTTP Host header, causing Django to generate URLs pointing to arbitrary,
@@ -35,7 +35,7 @@ Any deviation from this will now be rejected, raising the exception
 :exc:`django.core.exceptions.SuspiciousOperation`.
 
 Redirect poisoning
-------------------
+==================
 
 Also following up on a previous issue: in July of this year, we made changes to
 Django's HTTP redirect classes, performing additional validation of the scheme
diff --git a/docs/releases/1.3.6.txt b/docs/releases/1.3.6.txt
index d55199a882..9ed92bd6c2 100644
--- a/docs/releases/1.3.6.txt
+++ b/docs/releases/1.3.6.txt
@@ -11,7 +11,7 @@ This is the sixth bugfix/security release in the Django 1.3 series.
 
 
 Host header poisoning
----------------------
+=====================
 
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
@@ -36,7 +36,7 @@ This host validation is disabled when ``DEBUG`` is ``True`` or when running test
 
 
 XML deserialization
--------------------
+===================
 
 The XML parser in the Python standard library is vulnerable to a number of
 attacks via external entities and entity expansion. Django uses this parser for
@@ -57,7 +57,7 @@ management command, you will need to ensure they do not contain a DTD.
 
 
 Formset memory exhaustion
--------------------------
+=========================
 
 Previous versions of Django did not validate or limit the form-count data
 provided by the client in a formset's management form, making it possible to
@@ -70,7 +70,7 @@ factory argument).
 
 
 Admin history view information leakage
---------------------------------------
+======================================
 
 In previous versions of Django, an admin user without change permission on a
 model could still view the unicode representation of instances via their admin
diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt
index ecc98281fb..18f87fc0fd 100644
--- a/docs/releases/1.3.txt
+++ b/docs/releases/1.3.txt
@@ -68,7 +68,7 @@ What's new in Django 1.3
 ========================
 
 Class-based views
-~~~~~~~~~~~~~~~~~
+-----------------
 
 Django 1.3 adds a framework that allows you to use a class as a view.
 This means you can compose a view out of a collection of methods that
@@ -86,7 +86,7 @@ your function-based generic views to class-based
 views <https://docs.djangoproject.com/en/1.4/topics/generic-views-migration/>`_.
 
 Logging
-~~~~~~~
+-------
 
 Django 1.3 adds framework-level support for Python's ``logging``
 module.  This means you can now easily configure and control logging
@@ -97,7 +97,7 @@ handled as a logging activity. See :doc:`the documentation on Django's
 logging interface </topics/logging>` for more details.
 
 Extended static files handling
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 Django 1.3 ships with a new contrib app --
 ``django.contrib.staticfiles`` -- to help developers handle the static
@@ -118,7 +118,7 @@ for more details or learn how to :doc:`manage static files
 </howto/static-files/index>`.
 
 unittest2 support
-~~~~~~~~~~~~~~~~~
+-----------------
 
 Python 2.7 introduced some major changes to the ``unittest`` library,
 adding some extremely useful features. To ensure that every Django
@@ -146,7 +146,7 @@ you just won't get any of the nice new unittest2 features.
 .. _unittest2: https://pypi.python.org/pypi/unittest2
 
 Transaction context managers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Users of Python 2.5 and above may now use transaction management functions as
 `context managers`_. For example::
@@ -157,7 +157,7 @@ Users of Python 2.5 and above may now use transaction management functions as
 .. _context managers: https://docs.python.org/glossary.html#term-context-manager
 
 Configurable delete-cascade
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 :class:`~django.db.models.ForeignKey` and
 :class:`~django.db.models.OneToOneField` now accept an
@@ -170,7 +170,7 @@ For more information, see the :attr:`~django.db.models.ForeignKey.on_delete`
 documentation.
 
 Contextual markers and comments for translatable strings
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 For translation strings with ambiguous meaning, you can now
 use the ``pgettext`` function to specify the context of the string.
@@ -182,7 +182,7 @@ For more information, see :ref:`contextual-markers` and
 :ref:`translator-comments`.
 
 Improvements to built-in template tags
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 A number of improvements have been made to Django's built-in template tags:
 
@@ -199,7 +199,7 @@ A number of improvements have been made to Django's built-in template tags:
   you to load a single tag or filter from a library.
 
 TemplateResponse
-~~~~~~~~~~~~~~~~
+----------------
 
 It can sometimes be beneficial to allow decorators or middleware to
 modify a response *after* it has been constructed by the view. For
@@ -220,7 +220,7 @@ For more details, see the :doc:`documentation </ref/template-response>`
 on the :class:`~django.template.response.TemplateResponse` class.
 
 Caching changes
-~~~~~~~~~~~~~~~
+---------------
 
 Django 1.3 sees the introduction of several improvements to the
 Django's caching infrastructure.
@@ -247,7 +247,7 @@ caching in Django</topics/cache>`.
 .. _pylibmc: http://sendapatch.se/projects/pylibmc/
 
 Permissions for inactive users
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 If you provide a custom auth backend with ``supports_inactive_user``
 set to ``True``, an inactive ``User`` instance will check the backend
@@ -256,14 +256,14 @@ permission handling. See the :doc:`authentication docs </topics/auth/index>`
 for more details.
 
 GeoDjango
-~~~~~~~~~
+---------
 
 The GeoDjango test suite is now included when
 :ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
 when using :ref:`spatial database backends <spatial-backends>`.
 
 :setting:`MEDIA_URL` and :setting:`STATIC_URL` must end in a slash
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------
 
 Previously, the :setting:`MEDIA_URL` setting only required a trailing slash if
 it contained a suffix beyond the domain name.
@@ -279,7 +279,7 @@ In Django 1.4 this same condition will raise ``DeprecationWarning``,
 and in Django 1.5 will raise an ``ImproperlyConfigured`` exception.
 
 Everything else
-~~~~~~~~~~~~~~~
+---------------
 
 Django :doc:`1.1 <1.1>` and :doc:`1.2 <1.2>` added
 lots of big ticket items to Django, like multiple-database support,
@@ -335,7 +335,7 @@ Backwards-incompatible changes in 1.3
 =====================================
 
 CSRF validation now applies to AJAX requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 Prior to Django 1.2.5, Django's CSRF-prevention system exempted AJAX
 requests from CSRF verification; due to `security issues`_ reported to
@@ -347,7 +347,7 @@ AJAX requests.
 .. _security issues: https://www.djangoproject.com/weblog/2011/feb/08/security/
 
 Restricted filters in admin interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Prior to Django 1.2.5, the Django administrative interface allowed
 filtering on any model field or relation -- not just those specified
@@ -357,7 +357,7 @@ admin must be for fields or relations specified in ``list_filter`` or
 ``date_hierarchy``.
 
 Deleting a model doesn't delete associated files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 In earlier Django versions, when a model instance containing a
 :class:`~django.db.models.FileField` was deleted,
@@ -371,7 +371,7 @@ instance, with a custom management command that can be run manually or
 scheduled to run periodically via e.g. cron).
 
 PasswordInput default rendering behavior
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 The :class:`~django.forms.PasswordInput` form widget, intended for use
 with form fields which represent passwords, accepts a boolean keyword
@@ -394,7 +394,7 @@ explicitly indicate this. For example::
         password = forms.CharField(widget=forms.PasswordInput(render_value=True))
 
 Clearable default widget for FileField
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 Django 1.3 now includes a :class:`~django.forms.ClearableFileInput` form widget
 in addition to :class:`~django.forms.FileInput`. ``ClearableFileInput`` renders
@@ -420,7 +420,7 @@ To return to the previous rendering (without the ability to clear the
             widgets = {'document': forms.FileInput}
 
 New index on database session table
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 Prior to Django 1.3, the database table used by the database backend
 for the :doc:`sessions </topics/http/sessions>` app had no index on
@@ -437,7 +437,7 @@ index can be found by running the ``sqlindexes`` admin command::
     python manage.py sqlindexes sessions
 
 No more naughty words
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 Django has historically provided (and enforced) a list of profanities.
 The comments app has enforced this list of profanities, preventing people from
@@ -462,7 +462,7 @@ problem.
 .. _commit that implemented this change: https://code.djangoproject.com/changeset/13996
 
 Localflavor changes
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 Django 1.3 introduces the following backwards-incompatible changes to
 local flavors:
@@ -482,7 +482,7 @@ local flavors:
   ``USStateField`` not including them.
 
 FormSet updates
-~~~~~~~~~~~~~~~
+---------------
 
 In Django 1.3 ``FormSet`` creation behavior is modified slightly. Historically
 the class didn't make a distinction between not being passed data and being
@@ -511,7 +511,7 @@ if you need to instantiate an empty ``FormSet``, don't pass in the data or use
     >>> formset = ArticleFormSet(data=None)
 
 Callables in templates
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 Previously, a callable in a template would only be called automatically as part
 of the variable resolution process if it was retrieved via attribute
@@ -529,7 +529,7 @@ designed for web designers, and was never deliberately supported, it is possible
 that some templates may be broken by this change.
 
 Use of custom SQL to load initial data in tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 Django provides a custom SQL hooks as a way to inject hand-crafted SQL
 into the database synchronization process. One of the possible uses
@@ -559,7 +559,7 @@ should either insert it using :ref:`test fixtures
 test case.
 
 Changed priority of translation loading
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 Work has been done to simplify, rationalize and properly document the algorithm
 used by Django at runtime to build translations from the different translations
@@ -605,7 +605,7 @@ domain):
 .. _corresponding deprecated features section: loading_of_project_level_translations_
 
 Transaction management
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 When using managed transactions -- that is, anything but the default
 autocommit mode -- it is important when a transaction is marked as
@@ -639,14 +639,14 @@ the read operation that retrieves the ``MyObject`` instance leaves the
 transaction in a dirty state.
 
 No password reset for inactive users
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
 
 Prior to Django 1.3, inactive users were able to request a password reset email
 and reset their password. In Django 1.3 inactive users will receive the same
 message as a nonexistent account.
 
 Password reset view now accepts ``from_email``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 The :func:`django.contrib.auth.views.password_reset` view now accepts a
 ``from_email`` parameter, which is passed to the ``password_reset_form``’s
@@ -679,7 +679,7 @@ be removed entirely.
     </internals/deprecation>`.
 
 ``mod_python`` support
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 The ``mod_python`` library has not had a release since 2007 or a commit since
 2008. The Apache Foundation board voted to remove ``mod_python`` from the set
@@ -694,7 +694,7 @@ recommended by the Django project, but FastCGI is also supported. Support for
 ``mod_python`` deployment will be removed in Django 1.5.
 
 Function-based generic views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 As a result of the introduction of class-based generic views, the
 function-based generic views provided by Django have been deprecated.
@@ -706,7 +706,7 @@ The following modules and the views they contain have been deprecated:
 * ``django.views.generic.simple``
 
 Test client response ``template`` attribute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 Django's :ref:`test client <test-client>` returns
 :class:`~django.test.Response` objects annotated with extra testing
@@ -722,7 +722,7 @@ In Django 1.3 the ``template`` attribute is deprecated in favor of a new
 list, even if it has only a single element or no elements.
 
 ``DjangoTestRunner``
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 As a result of the introduction of support for unittest2, the features
 of ``django.test.simple.DjangoTestRunner`` (including fail-fast
@@ -732,6 +732,8 @@ class, and will be removed entirely in Django 1.5.
 
 Changes to :ttag:`url` and :ttag:`ssi`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Changes to ``url`` and ``ssi``
+------------------------------
 
 Most template tags will allow you to pass in either constants or
 variables as arguments -- for example::
@@ -772,7 +774,7 @@ templates should be modified to use the new ``future`` libraries and
 syntax.
 
 Changes to the login methods of the admin
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 In previous version the admin app defined login methods in multiple locations
 and ignored the almost identical implementation in the already used auth app.
@@ -789,7 +791,7 @@ attribute.
 .. _r12634: https://code.djangoproject.com/changeset/12634
 
 ``reset`` and ``sqlreset`` management commands
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Those commands have been deprecated. The ``flush`` and ``sqlflush`` commands
 can be used to delete everything. You can also use ALTER TABLE or DROP TABLE
@@ -797,7 +799,7 @@ statements manually.
 
 
 GeoDjango
-~~~~~~~~~
+---------
 
 * The function-based :setting:`TEST_RUNNER` previously used to execute
   the GeoDjango test suite, ``django.contrib.gis.tests.run_gis_tests``, was
@@ -813,7 +815,7 @@ GeoDjango
   called when the SRID of the geometry is less than 0 or ``None``.
 
 ``CZBirthNumberField.clean``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Previously this field's ``clean()`` method accepted a second, gender, argument
 which allowed stronger validation checks to be made, however since this
@@ -821,7 +823,7 @@ argument could never actually be passed from the Django form machinery it is
 now pending deprecation.
 
 ``CompatCookie``
-~~~~~~~~~~~~~~~~
+----------------
 
 Previously, ``django.http`` exposed an undocumented ``CompatCookie`` class,
 which was a bugfix wrapper around the standard library ``SimpleCookie``. As the
@@ -831,7 +833,7 @@ django.http import SimpleCookie`` instead.
 .. _loading_of_project_level_translations:
 
 Loading of *project-level* translations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 This release of Django starts the deprecation process for inclusion of
 translations located under the so-called *project path* in the translation
@@ -866,7 +868,7 @@ Rationale for this decision:
   inconsistency.
 
 ``PermWrapper`` moved to ``django.contrib.auth.context_processors``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 In Django 1.2, we began the process of changing the location of the
 ``auth`` context processor from ``django.core.context_processors`` to
@@ -878,7 +880,7 @@ moved to ``django.contrib.auth.context_processors``, along with the
 identical to their old versions; only the module location has changed.
 
 Removal of ``XMLField``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 When Django was first released, Django included an ``XMLField`` that performed
 automatic XML validation for any field input. However, this validation function
diff --git a/docs/releases/1.4.10.txt b/docs/releases/1.4.10.txt
index 7477ee5e41..323cdea3a7 100644
--- a/docs/releases/1.4.10.txt
+++ b/docs/releases/1.4.10.txt
@@ -7,7 +7,7 @@ Django 1.4.10 release notes
 Django 1.4.10 fixes a Python-compatibility bug in the 1.4 series.
 
 Python compatibility
---------------------
+====================
 
 Django 1.4.9 inadvertently introduced issues with Python 2.5 compatibility.
 Django 1.4.10 restores Python 2.5 compatibility. This was issue #21362 in
diff --git a/docs/releases/1.4.2.txt b/docs/releases/1.4.2.txt
index a6150f56c3..0f9d18744d 100644
--- a/docs/releases/1.4.2.txt
+++ b/docs/releases/1.4.2.txt
@@ -7,7 +7,7 @@ Django 1.4.2 release notes
 This is the second security release in the Django 1.4 series.
 
 Host header poisoning
----------------------
+=====================
 
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
diff --git a/docs/releases/1.4.3.txt b/docs/releases/1.4.3.txt
index f26bbe9214..8bf4b2fa79 100644
--- a/docs/releases/1.4.3.txt
+++ b/docs/releases/1.4.3.txt
@@ -14,7 +14,7 @@ the other we've chosen to take further steps to tighten up Django's code in
 response to independent discovery of potential problems from multiple sources.
 
 Host header poisoning
----------------------
+=====================
 
 Several earlier Django security releases focused on the issue of poisoning the
 HTTP Host header, causing Django to generate URLs pointing to arbitrary,
@@ -35,7 +35,7 @@ Any deviation from this will now be rejected, raising the exception
 :exc:`django.core.exceptions.SuspiciousOperation`.
 
 Redirect poisoning
-------------------
+==================
 
 Also following up on a previous issue: in July of this year, we made changes to
 Django's HTTP redirect classes, performing additional validation of the scheme
diff --git a/docs/releases/1.4.4.txt b/docs/releases/1.4.4.txt
index e501e4479a..c15c0e14c3 100644
--- a/docs/releases/1.4.4.txt
+++ b/docs/releases/1.4.4.txt
@@ -12,7 +12,7 @@ This is the fourth bugfix/security release in the Django 1.4 series.
 
 
 Host header poisoning
----------------------
+=====================
 
 Some parts of Django -- independent of end-user-written applications -- make
 use of full URLs, including domain name, which are generated from the HTTP Host
@@ -37,7 +37,7 @@ This host validation is disabled when ``DEBUG`` is ``True`` or when running test
 
 
 XML deserialization
--------------------
+===================
 
 The XML parser in the Python standard library is vulnerable to a number of
 attacks via external entities and entity expansion. Django uses this parser for
@@ -58,7 +58,7 @@ management command, you will need to ensure they do not contain a DTD.
 
 
 Formset memory exhaustion
--------------------------
+=========================
 
 Previous versions of Django did not validate or limit the form-count data
 provided by the client in a formset's management form, making it possible to
@@ -71,7 +71,7 @@ factory argument).
 
 
 Admin history view information leakage
---------------------------------------
+======================================
 
 In previous versions of Django, an admin user without change permission on a
 model could still view the unicode representation of instances via their admin
diff --git a/docs/releases/1.4.6.txt b/docs/releases/1.4.6.txt
index 9aaecb5241..39dc6f8dca 100644
--- a/docs/releases/1.4.6.txt
+++ b/docs/releases/1.4.6.txt
@@ -10,7 +10,7 @@ the 1.4 series, as well as one other bug.
 This is the sixth bugfix/security release in the Django 1.4 series.
 
 Mitigated possible XSS attack via user-supplied redirect URLs
--------------------------------------------------------------
+=============================================================
 
 Django relies on user input in some cases (e.g.
 :func:`django.contrib.auth.views.login`, ``django.contrib.comments``, and
diff --git a/docs/releases/1.4.7.txt b/docs/releases/1.4.7.txt
index 64d308894c..55a2f58f99 100644
--- a/docs/releases/1.4.7.txt
+++ b/docs/releases/1.4.7.txt
@@ -9,6 +9,8 @@ the 1.4 series.
 
 Directory traversal vulnerability in :ttag:`ssi` template tag
 -------------------------------------------------------------
+Directory traversal vulnerability in ``ssi`` template tag
+=========================================================
 
 In previous versions of Django it was possible to bypass the
 :setting:`ALLOWED_INCLUDE_ROOTS` setting used for security with the :ttag:`ssi`
diff --git a/docs/releases/1.4.8.txt b/docs/releases/1.4.8.txt
index 08dca4065e..40103d6086 100644
--- a/docs/releases/1.4.8.txt
+++ b/docs/releases/1.4.8.txt
@@ -8,7 +8,7 @@ Django 1.4.8 fixes two security issues present in previous Django releases in
 the 1.4 series.
 
 Denial-of-service via password hashers
---------------------------------------
+======================================
 
 In previous versions of Django, no limit was imposed on the plaintext
 length of a password. This allowed a denial-of-service attack through
@@ -21,7 +21,7 @@ limit on passwords and will fail authentication with any submitted
 password of greater length.
 
 Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
--------------------------------------------------------------------------------------------------------------------------
+=========================================================================================================================
 
 The decoration of the ``add_view`` and ``user_change_password`` user admin
 views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
diff --git a/docs/releases/1.4.9.txt b/docs/releases/1.4.9.txt
index 7fc4ecbbca..f582adec5c 100644
--- a/docs/releases/1.4.9.txt
+++ b/docs/releases/1.4.9.txt
@@ -8,7 +8,7 @@ Django 1.4.9 fixes a security-related bug in the 1.4 series and one other
 data corruption bug.
 
 Readdressed denial-of-service via password hashers
---------------------------------------------------
+==================================================
 
 Django 1.4.8 imposes a 4096-byte limit on passwords in order to mitigate a
 denial-of-service attack through submission of bogus but extremely large
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index db73d72d1e..c691fa391a 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -81,7 +81,7 @@ What's new in Django 1.4
 ========================
 
 Support for time zones
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 In previous versions, Django used "naive" date/times (that is, date/times
 without an associated time zone), leaving it up to each developer to interpret
@@ -108,7 +108,7 @@ project, read the :ref:`migration guide <time-zones-migration-guide>`. If you
 encounter problems, there's a helpful :ref:`FAQ <time-zones-faq>`.
 
 Support for in-browser testing frameworks
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 Django 1.4 supports integration with in-browser testing frameworks like
 Selenium_. The new :class:`django.test.LiveServerTestCase` base class lets you
@@ -120,7 +120,7 @@ concrete examples.
 .. _Selenium: http://seleniumhq.org/
 
 Updated default project layout and ``manage.py``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 Django 1.4 ships with an updated default project layout and ``manage.py`` file
 for the :djadmin:`startproject` management command. These fix some issues with
@@ -186,7 +186,7 @@ prefix, some places without it), the imports will need to be cleaned up when
 switching to the new ``manage.py``.
 
 Custom project and app templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 The :djadmin:`startapp` and :djadmin:`startproject` management commands
 now have a ``--template`` option for specifying a path or URL to a custom app
@@ -207,7 +207,7 @@ For more information, see the :djadmin:`startapp` and :djadmin:`startproject`
 documentation.
 
 Improved WSGI support
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 The :djadmin:`startproject` management command now adds a :file:`wsgi.py`
 module to the initial project layout, containing a simple WSGI application that
@@ -224,7 +224,7 @@ with the same WSGI configuration that is used for deployment. The new
 callable configured via :setting:`WSGI_APPLICATION`.)
 
 ``SELECT FOR UPDATE`` support
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 Django 1.4 includes a :meth:`QuerySet.select_for_update()
 <django.db.models.query.QuerySet.select_for_update>` method, which generates a
@@ -236,7 +236,7 @@ For more details, see the documentation for
 :meth:`~django.db.models.query.QuerySet.select_for_update`.
 
 ``Model.objects.bulk_create`` in the ORM
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 This method lets you create multiple objects more efficiently. It can result in
 significant performance increases if you have many objects.
@@ -248,7 +248,7 @@ See the :meth:`~django.db.models.query.QuerySet.bulk_create` docs for more
 information.
 
 ``QuerySet.prefetch_related``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 Similar to :meth:`~django.db.models.query.QuerySet.select_related` but with a
 different strategy and broader scope,
@@ -263,7 +263,7 @@ doing O(n) database queries (or worse) if objects on your primary ``QuerySet``
 each have many related objects that you also need to fetch.
 
 Improved password hashing
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 Django's auth system (``django.contrib.auth``) stores passwords using a one-way
 algorithm. Django 1.3 uses the SHA1_ algorithm, but increasing processor speeds
@@ -279,7 +279,7 @@ details, see :ref:`auth_password_storage`.
 .. _bcrypt: https://en.wikipedia.org/wiki/Bcrypt
 
 HTML5 doctype
-~~~~~~~~~~~~~
+-------------
 
 We've switched the admin and other bundled templates to use the HTML5
 doctype. While Django will be careful to maintain compatibility with older
@@ -288,7 +288,7 @@ admin pages without having to lose HTML validity or override the provided
 templates to change the doctype.
 
 List filters in admin interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Prior to Django 1.4, the :mod:`~django.contrib.admin` app let you specify
 change list filters by specifying a field lookup, but it didn't allow you to
@@ -297,7 +297,7 @@ used internally and known as "FilterSpec"). For more details, see the
 documentation for :attr:`~django.contrib.admin.ModelAdmin.list_filter`.
 
 Multiple sort in admin interface
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 The admin change list now supports sorting on multiple columns. It respects all
 elements of the :attr:`~django.contrib.admin.ModelAdmin.ordering` attribute, and
@@ -307,7 +307,7 @@ behavior of desktop GUIs. We also added a
 ordering dynamically (i.e., depending on the request).
 
 New ``ModelAdmin`` methods
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 We added a :meth:`~django.contrib.admin.ModelAdmin.save_related` method to
 :mod:`~django.contrib.admin.ModelAdmin` to ease customization of how
@@ -320,7 +320,7 @@ enable dynamic customization of fields and links displayed on the admin
 change list.
 
 Admin inlines respect user permissions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 Admin inlines now only allow those actions for which the user has
 permission. For ``ManyToMany`` relationships with an auto-created intermediate
@@ -329,7 +329,7 @@ related model determines if the user has the permission to add, change or
 delete relationships.
 
 Tools for cryptographic signing
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Django 1.4 adds both a low-level API for signing values and a high-level API
 for setting and reading signed cookies, one of the most common uses of
@@ -339,7 +339,7 @@ See the :doc:`cryptographic signing </topics/signing>` docs for more
 information.
 
 Cookie-based session backend
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Django 1.4 introduces a cookie-based session backend that uses the tools for
 :doc:`cryptographic signing </topics/signing>` to store the session data in
@@ -356,7 +356,7 @@ See the :ref:`cookie-based session backend <cookie-session-backend>` docs for
 more information.
 
 New form wizard
-~~~~~~~~~~~~~~~
+---------------
 
 The previous ``FormWizard`` from ``django.contrib.formtools`` has been
 replaced with a new implementation based on the class-based views
@@ -369,13 +369,13 @@ storage backend. The latter uses the tools for
 Django 1.4 to store the wizard's state in the user's cookies.
 
 ``reverse_lazy``
-~~~~~~~~~~~~~~~~
+----------------
 
 A lazily evaluated version of :func:`django.core.urlresolvers.reverse` was
 added to allow using URL reversals before the project's URLconf gets loaded.
 
 Translating URL patterns
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 Django can now look for a language prefix in the URLpattern when using the new
 :func:`~django.conf.urls.i18n.i18n_patterns` helper function.
@@ -385,7 +385,7 @@ It's also now possible to define translatable URL patterns using
 and how to internationalize URL patterns.
 
 Contextual translation support for ``{% trans %}`` and ``{% blocktrans %}``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------
 
 The :ref:`contextual translation<contextual-markers>` support introduced in
 Django 1.3 via the ``pgettext`` function has been extended to the
@@ -393,7 +393,7 @@ Django 1.3 via the ``pgettext`` function has been extended to the
 keyword.
 
 Customizable ``SingleObjectMixin`` URLConf kwargs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 Two new attributes,
 :attr:`pk_url_kwarg<django.views.generic.detail.SingleObjectMixin.pk_url_kwarg>`
@@ -404,14 +404,14 @@ enable the customization of URLconf keyword arguments used for single
 object generic views.
 
 Assignment template tags
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 A new ``assignment_tag`` helper function was added to ``template.Library`` to
 ease the creation of template tags that store data in a specified context
 variable.
 
 ``*args`` and ``**kwargs`` support for template tag helper functions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------------------
 
 The :ref:`simple_tag<howto-custom-template-tags-simple-tags>`,
 :ref:`inclusion_tag <howto-custom-template-tags-inclusion-tags>` and newly
@@ -433,7 +433,7 @@ For example:
     {% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
 
 No wrapping of exceptions in ``TEMPLATE_DEBUG`` mode
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 In previous versions of Django, whenever the ``TEMPLATE_DEBUG`` setting
 was ``True``, any exception raised during template rendering (even exceptions
@@ -448,7 +448,7 @@ exceptions from template rendering is now consistent regardless of the value of
 ``TemplateSyntaxError`` in order to catch other errors.
 
 ``truncatechars`` template filter
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 This new filter truncates a string to be no longer than the specified
 number of characters. Truncated strings end with a translatable ellipsis
@@ -456,7 +456,7 @@ sequence ("..."). See the documentation for :tfilter:`truncatechars` for
 more details.
 
 ``static`` template tag
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 The :mod:`staticfiles<django.contrib.staticfiles>` contrib app has a new
 :ttag:`static<staticfiles-static>` template tag to refer to files saved with
@@ -465,7 +465,7 @@ backend's ``url`` method and therefore supports advanced features such as
 :ref:`serving files from a cloud service<staticfiles-from-cdn>`.
 
 ``CachedStaticFilesStorage`` storage backend
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 The :mod:`staticfiles<django.contrib.staticfiles>` contrib app now has a
 :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage` backend
@@ -478,7 +478,7 @@ See the :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
 docs for more information.
 
 Simple clickjacking protection
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 We've added a middleware to provide easy protection against `clickjacking
 <https://en.wikipedia.org/wiki/Clickjacking>`_ using the ``X-Frame-Options``
@@ -487,7 +487,7 @@ you'll almost certainly want to :doc:`enable it </ref/clickjacking/>` to help
 plug that security hole for browsers that support the header.
 
 CSRF improvements
-~~~~~~~~~~~~~~~~~
+-----------------
 
 We've made various improvements to our CSRF features, including the
 :func:`~django.views.decorators.csrf.ensure_csrf_cookie` decorator, which can
@@ -497,7 +497,7 @@ improve the security and usefulness of CSRF protection. See the :doc:`CSRF
 docs </ref/csrf>` for more information.
 
 Error report filtering
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 We added two function decorators,
 :func:`~django.views.decorators.debug.sensitive_variables` and
@@ -516,7 +516,7 @@ filter<custom-error-reports>`. For more information see the docs on
 :ref:`Filtering error reports<filtering-error-reports>`.
 
 Extended IPv6 support
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 Django 1.4 can now better handle IPv6 addresses with the new
 :class:`~django.db.models.GenericIPAddressField` model field,
@@ -525,7 +525,7 @@ the validators :data:`~django.core.validators.validate_ipv46_address` and
 :data:`~django.core.validators.validate_ipv6_address`.
 
 HTML comparisons in tests
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 The base classes in :mod:`django.test` now have some helpers to
 compare HTML without tripping over irrelevant differences in whitespace,
@@ -540,10 +540,10 @@ client's response contains a given HTML fragment. See the :ref:`assertions
 documentation <assertions>` for more.
 
 Two new date format strings
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Two new :tfilter:`date` formats were added for use in template filters,
-template tags and :ref:`format-localization`:
+template tags and :doc:`/topics/i18n/formatting`:
 
 - ``e`` -- the name of the timezone of the given datetime object
 - ``o`` -- the ISO 8601 year number
@@ -562,7 +562,7 @@ But now it needs to also escape ``e`` and ``o``::
 For more information, see the :tfilter:`date` documentation.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 Django 1.4 also includes several smaller improvements worth noting:
 
@@ -667,7 +667,7 @@ Backwards incompatible changes in 1.4
 =====================================
 
 SECRET_KEY setting is required
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 Running Django with an empty or known :setting:`SECRET_KEY` disables many of
 Django's security protections and can lead to remote-code-execution
@@ -681,7 +681,7 @@ due to the severity of the consequences of running Django with no
 :setting:`SECRET_KEY`.
 
 django.contrib.admin
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 The included administration app ``django.contrib.admin`` has for a long time
 shipped with a default set of static files such as JavaScript, images and
@@ -716,7 +716,7 @@ If your ``ADMIN_MEDIA_PREFIX`` is set to an specific domain (e.g.
     :file:`django/contrib/admin/static/admin/`.
 
 Supported browsers for the admin
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Django hasn't had a clear policy on which browsers are supported by the
 admin app. Our new policy formalizes existing practices: `YUI's A-grade`_
@@ -734,7 +734,7 @@ any range of browsers.
 .. _YUI's A-grade: http://yuilibrary.com/yui/docs/tutorials/gbs/
 
 Removed admin icons
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 As part of an effort to improve the performance and usability of the admin's
 change-list sorting interface and :attr:`horizontal
@@ -752,7 +752,7 @@ If you used those icons to customize the admin, then you'll need to replace
 them with your own icons or get the files from a previous release.
 
 CSS class names in admin forms
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 To avoid conflicts with other common CSS class names (e.g. "button"), we added
 a prefix ("field-") to all CSS class names automatically generated from the
@@ -762,7 +762,7 @@ style sheets or JavaScript files if you previously used plain field names as
 selectors for custom styles or JavaScript transformations.
 
 Compatibility with old signed data
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Django 1.3 changed the cryptographic signing mechanisms used in a number of
 places in Django. While Django 1.3 kept fallbacks that would accept hashes
@@ -832,7 +832,7 @@ instance:
     password hashes.
 
 django.contrib.flatpages
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 Starting in 1.4, the
 :class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware` only
@@ -846,7 +846,7 @@ Also, redirects returned by flatpages are now permanent (with 301 status code),
 to match the behavior of :class:`~django.middleware.common.CommonMiddleware`.
 
 Serialization of :class:`~datetime.datetime` and :class:`~datetime.time`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------------
 
 As a consequence of time-zone support, and according to the ECMA-262
 specification, we made changes to the JSON serializer:
@@ -866,7 +866,7 @@ Though the serializers now use these new formats when creating fixtures, they
 can still load fixtures that use the old format.
 
 ``supports_timezone`` changed to ``False`` for SQLite
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------
 
 The database feature ``supports_timezone`` used to be ``True`` for SQLite.
 Indeed, if you saved an aware datetime object, SQLite stored a string that
@@ -879,7 +879,7 @@ datetimes are now stored without time-zone information in SQLite. When
 object, Django raises an exception.
 
 ``MySQLdb``-specific exceptions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 The MySQL backend historically has raised ``MySQLdb.OperationalError``
 when a query triggered an exception. We've fixed this bug, and we now raise
@@ -888,7 +888,7 @@ when a query triggered an exception. We've fixed this bug, and we now raise
 clauses.
 
 Database connection's thread-locality
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 ``DatabaseWrapper`` objects (i.e. the connection objects referenced by
 ``django.db.connection`` and ``django.db.connections["some_alias"]``) used to
@@ -914,7 +914,7 @@ Concurrency behavior is defined by the underlying backend implementation.
 Check their documentation for details.
 
 `COMMENTS_BANNED_USERS_GROUP` setting
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Django's comments has historically
 supported excluding the comments of a special user group, but we've never
@@ -951,7 +951,7 @@ Save this model manager in your custom comment app (e.g., in
         objects = BanningCommentManager()
 
 `IGNORABLE_404_STARTS` and `IGNORABLE_404_ENDS` settings
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 Until Django 1.3, it was possible to exclude some URLs from Django's
 :doc:`404 error reporting</howto/error-reporting>` by adding prefixes to
@@ -989,7 +989,7 @@ Don't forget to escape characters that have a special meaning in a regular
 expression, such as periods.
 
 CSRF protection extended to PUT and DELETE
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 Previously, Django's :doc:`CSRF protection </ref/csrf/>` provided
 protection only against POST requests. Since use of PUT and DELETE methods in
@@ -1001,7 +1001,7 @@ If you're using PUT or DELETE methods in AJAX applications, please see the
 :ref:`instructions about using AJAX and CSRF <csrf-ajax>`.
 
 Password reset view now accepts ``subject_template_name``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 The ``password_reset`` view in ``django.contrib.auth`` now accepts a
 ``subject_template_name`` parameter, which is passed to the password save form
@@ -1010,21 +1010,21 @@ form, then you will need to ensure your form's ``save()`` method accepts this
 keyword argument.
 
 ``django.core.template_loaders``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 This was an alias to ``django.template.loader`` since 2005, and we've removed it
 without emitting a warning due to the length of the deprecation. If your code
 still referenced this, please use ``django.template.loader`` instead.
 
 ``django.db.models.fields.URLField.verify_exists``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 This functionality has been removed due to intractable performance and
 security issues. Any existing usage of ``verify_exists`` should be
 removed.
 
 ``django.core.files.storage.Storage.open``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 The ``open`` method of the base Storage class used to take an obscure parameter
 ``mixin`` that allowed you to dynamically change the base classes of the
@@ -1050,7 +1050,7 @@ method, like this::
             return Spam(open(self.path(name), mode))
 
 YAML deserializer now uses ``yaml.safe_load``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 ``yaml.load`` is able to construct any Python object, which may trigger
 arbitrary code execution if you process a YAML document that comes from an
@@ -1060,7 +1060,7 @@ fixtures are trusted data, the YAML deserializer now uses ``yaml.safe_load``
 for additional security.
 
 Session cookies now have the ``httponly`` flag by default
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 Session cookies now include the ``httponly`` attribute by default to
 help reduce the impact of potential XSS attacks. As a consequence of
@@ -1070,7 +1070,7 @@ compatibility, use ``SESSION_COOKIE_HTTPONLY = False`` in your
 settings file.
 
 The :tfilter:`urlize` filter no longer escapes every URL
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 When a URL contains a ``%xx`` sequence, where ``xx`` are two hexadecimal
 digits, :tfilter:`urlize` now assumes that the URL is already escaped and
@@ -1079,7 +1079,7 @@ contains a ``%xx`` sequence, but such URLs are very unlikely to happen in the
 wild, because they would confuse browsers too.
 
 ``assertTemplateUsed`` and ``assertTemplateNotUsed`` as context manager
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------------
 
 It's now possible to check whether a template was used within a block of
 code with :meth:`~django.test.SimpleTestCase.assertTemplateUsed` and
@@ -1094,7 +1094,7 @@ can be used as a context manager::
 See the :ref:`assertion documentation<assertions>` for more.
 
 Database connections after running the test suite
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 The default test runner no longer restores the database connections after
 tests' execution. This prevents the production database from being exposed to
@@ -1107,7 +1107,7 @@ subclassing ``DjangoTestRunner`` and overriding its ``teardown_databases()``
 method.
 
 Output of :djadmin:`manage.py help <help>`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 :djadmin:`manage.py help <help>` now groups available commands by application.
 If you depended on the output of this command -- if you parsed it, for example
@@ -1116,7 +1116,7 @@ management commands in a script, use
 :djadmin:`manage.py help --commands <help>` instead.
 
 ``extends`` template tag
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 Previously, the :ttag:`extends` tag used a buggy method of parsing arguments,
 which could lead to it erroneously considering an argument as a string literal
@@ -1127,7 +1127,7 @@ interests of full disclosure, the ``ExtendsNode.__init__`` definition has
 changed, which may break any custom tags that use this class.
 
 Loading some incomplete fixtures no longer works
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 Prior to 1.4, a default value was inserted for fixture objects that were missing
 a specific date or datetime value when auto_now or auto_now_add was set for the
@@ -1136,7 +1136,7 @@ incomplete fixtures will fail. Because fixtures are a raw import, they should
 explicitly specify all field values, regardless of field options on the model.
 
 Development Server Multithreading
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The development server is now is multithreaded by default. Use the
 :djadminopt:`--nothreading` option to disable the use of threading in the
@@ -1145,7 +1145,7 @@ development server::
     django-admin.py runserver --nothreading
 
 Attributes disabled in markdown when safe mode set
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 Prior to Django 1.4, attributes were included in any markdown output regardless
 of safe mode setting of the filter. With version > 2.1 of the Python-Markdown
@@ -1156,7 +1156,7 @@ Python-Markdown library less than 2.1, a warning is issued that the output is
 insecure.
 
 FormMixin get_initial returns an instance-specific dictionary
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------
 
 In Django 1.3, the ``get_initial`` method of the
 :class:`django.views.generic.edit.FormMixin` class was returning the
@@ -1170,14 +1170,14 @@ Features deprecated in 1.4
 ==========================
 
 Old styles of calling ``cache_page`` decorator
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Some legacy ways of calling :func:`~django.views.decorators.cache.cache_page`
 have been deprecated. Please see the documentation for the correct way to use
 this decorator.
 
 Support for PostgreSQL versions older than 8.2
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Django 1.3 dropped support for PostgreSQL versions older than 8.0, and we
 suggested using a more recent version because of performance improvements
@@ -1188,7 +1188,7 @@ Django 1.4 takes that policy further and sets 8.2 as the minimum PostgreSQL
 version it officially supports.
 
 Request exceptions are now always logged
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 When we added :doc:`logging support </topics/logging/>` in Django in 1.3, the
 admin error email support was moved into the
@@ -1228,7 +1228,7 @@ The existence of any ``'filters'`` key under the ``'mail_admins'`` handler will
 disable this backward-compatibility shim and deprecation warning.
 
 ``django.conf.urls.defaults``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 Until Django 1.3, the functions :func:`~django.conf.urls.include`,
 :func:`~django.conf.urls.patterns` and :func:`~django.conf.urls.url` plus
@@ -1238,7 +1238,7 @@ were located in a ``django.conf.urls.defaults`` module.
 In Django 1.4, they live in :mod:`django.conf.urls`.
 
 ``django.contrib.databrowse``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 Databrowse has not seen active development for some time, and this does not show
 any sign of changing. There had been a suggestion for a `GSOC project`_ to
@@ -1253,7 +1253,7 @@ itself, so it's available to be adopted by an individual or group as
 a third-party project.
 
 ``django.core.management.setup_environ``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 This function temporarily modified ``sys.path`` in order to make the parent
 "project" directory importable under the old flat :djadmin:`startproject`
@@ -1266,7 +1266,7 @@ These uses should be replaced by setting the ``DJANGO_SETTINGS_MODULE``
 environment variable or using :func:`django.conf.settings.configure`.
 
 ``django.core.management.execute_manager``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 This function was previously used by ``manage.py`` to execute a management
 command. It is identical to
@@ -1277,7 +1277,7 @@ of these functions is documented as part of the public API, but a deprecation
 path is needed due to use in existing ``manage.py`` files.
 
 ``is_safe`` and ``needs_autoescape`` attributes of template filters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 Two flags, ``is_safe`` and ``needs_autoescape``, define how each template filter
 interacts with Django's auto-escaping behavior. They used to be attributes of
@@ -1300,7 +1300,7 @@ Now, the flags are keyword arguments of :meth:`@register.filter
 See :ref:`filters and auto-escaping <filters-auto-escaping>` for more information.
 
 Wildcard expansion of application names in `INSTALLED_APPS`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------
 
 Until Django 1.3, :setting:`INSTALLED_APPS` accepted wildcards in application
 names, like ``django.contrib.*``. The expansion was performed by a
@@ -1314,14 +1314,14 @@ settings file to list all your applications explicitly.
 .. _this can't be done reliably: https://docs.python.org/tutorial/modules.html#importing-from-a-package
 
 ``HttpRequest.raw_post_data`` renamed to ``HttpRequest.body``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------
 
 This attribute was confusingly named ``HttpRequest.raw_post_data``, but it
 actually provided the body of the HTTP request. It's been renamed to
 ``HttpRequest.body``, and ``HttpRequest.raw_post_data`` has been deprecated.
 
 ``django.contrib.sitemaps`` bug fix with potential performance implications
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------
 
 In previous versions, ``Paginator`` objects used in sitemap classes were
 cached, which could result in stale site maps. We've removed the caching, so
@@ -1333,7 +1333,7 @@ To mitigate the performance impact, consider using the :doc:`caching
 framework </topics/cache>` within your ``Sitemap`` subclass.
 
 Versions of Python-Markdown earlier than 2.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 Versions of Python-Markdown earlier than 2.1 do not support the option to
 disable attributes. As a security issue, earlier versions of this library will
diff --git a/docs/releases/1.5.2.txt b/docs/releases/1.5.2.txt
index 1e6a448948..22a415274a 100644
--- a/docs/releases/1.5.2.txt
+++ b/docs/releases/1.5.2.txt
@@ -7,7 +7,7 @@ Django 1.5.2 release notes
 This is Django 1.5.2, a bugfix and security release for Django 1.5.
 
 Mitigated possible XSS attack via user-supplied redirect URLs
--------------------------------------------------------------
+=============================================================
 
 Django relies on user input in some cases (e.g.
 :func:`django.contrib.auth.views.login`, ``django.contrib.comments``, and
@@ -21,7 +21,7 @@ Django currently, since we only put this URL into the ``Location`` response
 header and browsers seem to ignore JavaScript there.
 
 XSS vulnerability in :mod:`django.contrib.admin`
-------------------------------------------------
+================================================
 
 If a :class:`~django.db.models.URLField` is used in Django 1.5, it displays the
 current value of the field and a link to the target on the admin change page.
diff --git a/docs/releases/1.5.3.txt b/docs/releases/1.5.3.txt
index bdf68d5621..39b0deb1b2 100644
--- a/docs/releases/1.5.3.txt
+++ b/docs/releases/1.5.3.txt
@@ -10,6 +10,8 @@ of :mod:`django.contrib.sessions`.
 
 Directory traversal vulnerability in :ttag:`ssi` template tag
 -------------------------------------------------------------
+Directory traversal vulnerability in ``ssi`` template tag
+=========================================================
 
 In previous versions of Django it was possible to bypass the
 :setting:`ALLOWED_INCLUDE_ROOTS` setting used for security with the :ttag:`ssi`
@@ -26,7 +28,7 @@ author to put the :ttag:`ssi` file in a user-controlled variable, but it's
 possible in principle.
 
 Mitigating a remote-code execution vulnerability in :mod:`django.contrib.sessions`
-----------------------------------------------------------------------------------
+==================================================================================
 
 :mod:`django.contrib.sessions` currently uses :mod:`pickle` to serialize
 session data before storing it in the backend. If you're using the :ref:`signed
diff --git a/docs/releases/1.5.4.txt b/docs/releases/1.5.4.txt
index 68deeb5de0..48b27b25a7 100644
--- a/docs/releases/1.5.4.txt
+++ b/docs/releases/1.5.4.txt
@@ -8,7 +8,7 @@ This is Django 1.5.4, the fourth release in the Django 1.5 series. It addresses
 two security issues and one bug.
 
 Denial-of-service via password hashers
---------------------------------------
+======================================
 
 In previous versions of Django, no limit was imposed on the plaintext
 length of a password. This allowed a denial-of-service attack through
@@ -21,7 +21,7 @@ limit on passwords, and will fail authentication with any submitted
 password of greater length.
 
 Corrected usage of :func:`~django.views.decorators.debug.sensitive_post_parameters` in :mod:`django.contrib.auth`’s admin
--------------------------------------------------------------------------------------------------------------------------
+=========================================================================================================================
 
 The decoration of the ``add_view`` and ``user_change_password`` user admin
 views with :func:`~django.views.decorators.debug.sensitive_post_parameters`
diff --git a/docs/releases/1.5.5.txt b/docs/releases/1.5.5.txt
index a1f5ca45de..8dfd3d3834 100644
--- a/docs/releases/1.5.5.txt
+++ b/docs/releases/1.5.5.txt
@@ -8,7 +8,7 @@ Django 1.5.5 fixes a couple security-related bugs and several other bugs in the
 1.5 series.
 
 Readdressed denial-of-service via password hashers
---------------------------------------------------
+==================================================
 
 Django 1.5.4 imposes a 4096-byte limit on passwords in order to mitigate a
 denial-of-service attack through submission of bogus but extremely large
@@ -16,7 +16,7 @@ passwords. In Django 1.5.5, we've reverted this change and instead improved
 the speed of our PBKDF2 algorithm by not rehashing the key on every iteration.
 
 Properly rotate CSRF token on login
------------------------------------
+===================================
 
 This behavior introduced as a security hardening measure in Django 1.5.2 did
 not work properly and is now fixed.
diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt
index 2eaab0e486..a2505c5071 100644
--- a/docs/releases/1.5.txt
+++ b/docs/releases/1.5.txt
@@ -85,7 +85,7 @@ offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
 release.
 
 Python 3 support
-~~~~~~~~~~~~~~~~
+----------------
 
 Django 1.5 introduces support for Python 3 - specifically, Python
 3.2 and above. This comes in the form of a **single** codebase; you don't
@@ -122,7 +122,7 @@ What's new in Django 1.5
 ========================
 
 Configurable User model
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 In Django 1.5, you can now use your own model as the store for user-related
 data. If your project needs a username with more than 30 characters, or if
@@ -139,7 +139,7 @@ See the :ref:`documentation on custom User models <auth-custom-user>` for
 more details.
 
 Support for saving a subset of model's fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 The method :meth:`Model.save() <django.db.models.Model.save()>` has a new
 keyword argument ``update_fields``. By using this argument it is possible to
@@ -154,7 +154,7 @@ See the :meth:`Model.save() <django.db.models.Model.save()>` documentation for
 more details.
 
 Caching of related model instances
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 When traversing relations, the ORM will avoid re-fetching objects that were
 previously loaded. For example, with the tutorial's models::
@@ -174,7 +174,7 @@ is particularly helpful in combination with ``prefetch_related``.
 .. _explicit-streaming-responses:
 
 Explicit support for streaming responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 Before Django 1.5, it was possible to create a streaming response by passing
 an iterator to :class:`~django.http.HttpResponse`. But this was unreliable:
@@ -192,14 +192,14 @@ streaming responses and behave accordingly. See :ref:`response-middleware` for
 more information.
 
 ``{% verbatim %}`` template tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 To make it easier to deal with JavaScript templates which collide with Django's
 syntax, you can now use the :ttag:`verbatim` block tag to avoid parsing the
 tag's content.
 
 Retrieval of ``ContentType`` instances associated with proxy models
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
 and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
@@ -209,14 +209,14 @@ By passing ``False`` using this argument it is now possible to retrieve the
 associated with proxy models.
 
 New ``view`` variable in class-based views context
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 In all :doc:`generic class-based views </topics/class-based-views/index>`
 (or any class-based view inheriting from ``ContextMixin``), the context dictionary
 contains a ``view`` variable that points to the ``View`` instance.
 
 GeoDjango
-~~~~~~~~~
+---------
 
 * :class:`~django.contrib.gis.geos.LineString` and
   :class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
@@ -232,7 +232,7 @@ GeoDjango
   dropped.
 
 New tutorials
-~~~~~~~~~~~~~
+-------------
 
 Additions to the docs include a revamped :doc:`Tutorial 3</intro/tutorial03>`
 and a new :doc:`tutorial on testing</intro/tutorial05>`. A new section,
@@ -241,7 +241,7 @@ and a new :doc:`tutorial on testing</intro/tutorial05>`. A new section,
 :doc:`Writing your first patch for Django </intro/contributing>`.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 Django 1.5 also includes several smaller improvements worth noting:
 
@@ -361,7 +361,7 @@ Backwards incompatible changes in 1.5
     backwards incompatible change.
 
 ``ALLOWED_HOSTS`` required in production
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 The new :setting:`ALLOWED_HOSTS` setting validates the request's ``Host``
 header and protects against host-poisoning attacks. This setting is now
@@ -371,7 +371,7 @@ required whenever :setting:`DEBUG` is ``False``, or else
 :setting:`full documentation<ALLOWED_HOSTS>` for the new setting.
 
 Managers on abstract models
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Abstract models are able to define a custom manager, and that manager
 :ref:`will be inherited by any concrete models extending the abstract model
@@ -386,7 +386,7 @@ the abstract class, you should migrate that logic to a Python
 ``staticmethod`` or ``classmethod`` on the abstract class.
 
 Context in year archive class-based views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 For consistency with the other date-based generic views,
 :class:`~django.views.generic.dates.YearArchiveView` now passes ``year`` in
@@ -398,7 +398,7 @@ year|date:"Y" }}``.
 calculated according to ``allow_empty`` and ``allow_future``.
 
 Context in year and month archive class-based views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 :class:`~django.views.generic.dates.YearArchiveView` and
 :class:`~django.views.generic.dates.MonthArchiveView` were documented to
@@ -413,7 +413,7 @@ the documented order was restored. You may want to add (or remove) the
 ``date_list`` in descending order.
 
 Context in TemplateView
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 For consistency with the design of the other generic views,
 :class:`~django.views.generic.base.TemplateView` no longer passes a ``params``
@@ -421,7 +421,7 @@ dictionary into the context, instead passing the variables from the URLconf
 directly into the context.
 
 Non-form data in HTTP requests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 :attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
 posted via HTTP requests with non form-specific content-types in the header.
@@ -433,7 +433,7 @@ should use the :attr:`request.body <django.http.HttpRequest.body>` attribute
 instead.
 
 :data:`~django.core.signals.request_finished` signal
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 Django used to send the :data:`~django.core.signals.request_finished` signal
 as soon as the view function returned a response. This interacted badly with
@@ -454,7 +454,7 @@ consider using :doc:`middleware </topics/http/middleware>` instead.
     connections to database and memcache servers.
 
 OPTIONS, PUT and DELETE requests in the test client
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 Unlike GET and POST, these HTTP methods aren't implemented by web browsers.
 Rather, they're used in APIs, which transfer data in various formats such as
@@ -476,7 +476,7 @@ client and set the ``content_type`` argument.
 .. _simplejson-incompatibilities:
 
 System version of ``simplejson`` no longer used
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 :ref:`As explained below <simplejson-deprecation>`, Django 1.5 deprecates
 ``django.utils.simplejson`` in favor of Python 2.6's built-in :mod:`json`
@@ -522,7 +522,7 @@ They recommend to use it from now on.
 .. _ticket #18023: https://code.djangoproject.com/ticket/18023#comment:10
 
 String types of hasher method parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 If you have written a :ref:`custom password hasher <auth_password_storage>`,
 your ``encode()``, ``verify()`` or ``safe_summary()`` methods should accept
@@ -531,7 +531,7 @@ hashing methods need byte strings, you can use the
 :func:`~django.utils.encoding.force_bytes` utility to encode the strings.
 
 Validation of previous_page_number and next_page_number
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------
 
 When using :doc:`object pagination </topics/pagination>`,
 the ``previous_page_number()`` and ``next_page_number()`` methods of the
@@ -541,7 +541,7 @@ It does check it now and raises an :exc:`~django.core.paginator.InvalidPage`
 exception when the number is either too low or too high.
 
 Behavior of autocommit database option on PostgreSQL changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------
 
 PostgreSQL's autocommit option didn't work as advertised previously. It did
 work for single transaction block, but after the first block was left the
@@ -550,13 +550,13 @@ this is only a bug fix, it is worth checking your applications behavior if
 you are using PostgreSQL together with the autocommit option.
 
 Session not saved on 500 responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Django's session middleware will skip saving the session data if the
 response's status code is 500.
 
 Email checks on failed admin login
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Prior to Django 1.5, if you attempted to log into the admin interface and
 mistakenly used your email address instead of your username, the admin
@@ -568,13 +568,13 @@ affects the warning message that is displayed under one particular mode of
 login failure.
 
 Changes in tests execution
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Some changes have been introduced in the execution of tests that might be
 backward-incompatible for some testing setups:
 
 Database flushing in ``django.test.TransactionTestCase``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, the test database was truncated *before* each test run in a
 :class:`~django.test.TransactionTestCase`.
@@ -584,7 +584,7 @@ always isolated from each other, :class:`~django.test.TransactionTestCase` will
 now reset the database *after* each test run instead.
 
 No more implicit DB sequences reset
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :class:`~django.test.TransactionTestCase` tests used to reset primary key
 sequences automatically together with the database flushing actions described
@@ -599,7 +599,7 @@ be used to force the old behavior for :class:`~django.test.TransactionTestCase`
 that might need it.
 
 Ordering of tests
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 In order to make sure all ``TestCase`` code starts with a clean database,
 tests are now executed in the following order:
@@ -619,7 +619,7 @@ preserved after the execution of other tests. Such tests are already very
 fragile, and must now be changed to be able to run independently.
 
 `cleaned_data` dictionary kept for invalid forms
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 The :attr:`~django.forms.Form.cleaned_data` dictionary is now always present
 after form validation. When the form doesn't validate, it contains only the
@@ -629,7 +629,7 @@ presence or absence of the :attr:`~django.forms.Form.cleaned_data` attribute
 on the form.
 
 Behavior of ``syncdb`` with multiple databases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 ``syncdb`` now queries the database routers to determine if content
 types (when :mod:`~django.contrib.contenttypes` is enabled) and permissions
@@ -643,7 +643,7 @@ them. See the docs on the :ref:`behavior of contrib apps with multiple
 databases <contrib_app_multiple_databases>` for more information.
 
 XML deserializer will not parse documents with a DTD
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 In order to prevent exposure to denial-of-service attacks related to external
 entity references and entity expansion, the XML model deserializer now refuses
@@ -653,7 +653,7 @@ cases where custom-created XML documents are passed to Django's model
 deserializer.
 
 Formsets default ``max_num``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 A (default) value of ``None`` for the ``max_num`` argument to a formset factory
 no longer defaults to allowing any number of forms in the formset. Instead, in
@@ -662,7 +662,7 @@ forms. This limit can be raised by explicitly setting a higher value for
 ``max_num``.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * :class:`django.forms.ModelMultipleChoiceField` now returns an empty
   ``QuerySet`` as the empty value instead of an empty list.
@@ -721,7 +721,7 @@ Features deprecated in 1.5
 ==========================
 
 ``django.contrib.localflavor``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 The localflavor contrib app has been split into separate packages.
 ``django.contrib.localflavor`` itself will be removed in Django 1.6,
@@ -733,7 +733,7 @@ dozen countries at this time; similar to translations, maintenance
 will be handed over to interested members of the community.
 
 ``django.contrib.markup``
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 The markup contrib module has been deprecated and will follow an accelerated
 deprecation schedule. Direct use of Python markup libraries or 3rd party tag
@@ -741,7 +741,7 @@ libraries is preferred to Django maintaining this functionality in the
 framework.
 
 ``AUTH_PROFILE_MODULE``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 With the introduction of :ref:`custom User models <auth-custom-user>`, there is
 no longer any need for a built-in mechanism to store user profile data.
@@ -754,7 +754,7 @@ the ``AUTH_PROFILE_MODULE`` setting, and the
 the user profile model, should not be used any longer.
 
 Streaming behavior of :class:`~django.http.HttpResponse`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 Django 1.5 deprecates the ability to stream a response by passing an iterator
 to :class:`~django.http.HttpResponse`. If you rely on this behavior, switch to
@@ -767,7 +767,7 @@ In Django 1.7 and above, the iterator will be consumed immediately by
 .. _simplejson-deprecation:
 
 ``django.utils.simplejson``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Since Django 1.5 drops support for Python 2.5, we can now rely on the
 :mod:`json` module being available in Python's standard library, so we've
@@ -781,32 +781,32 @@ If you rely on features added to ``simplejson`` after it became Python's
 :mod:`json`, you should import ``simplejson`` explicitly.
 
 ``django.utils.encoding.StrAndUnicode``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 The ``django.utils.encoding.StrAndUnicode`` mix-in has been deprecated.
 Define a ``__str__`` method and apply the
 :func:`~django.utils.encoding.python_2_unicode_compatible` decorator instead.
 
 ``django.utils.itercompat.product``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 The ``django.utils.itercompat.product`` function has been deprecated. Use
 the built-in :func:`itertools.product` instead.
 
 ``cleanup`` management command
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 The ``cleanup`` management command has been deprecated and replaced by
 :djadmin:`clearsessions`.
 
 ``daily_cleanup.py`` script
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 The undocumented ``daily_cleanup.py`` script has been deprecated. Use the
 :djadmin:`clearsessions` management command instead.
 
 ``depth`` keyword argument in ``select_related``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 The ``depth`` keyword argument in
 :meth:`~django.db.models.query.QuerySet.select_related` has been deprecated.
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index 23de67ee76..177e1afa79 100644
--- a/docs/releases/1.6.txt
+++ b/docs/releases/1.6.txt
@@ -50,7 +50,7 @@ What's new in Django 1.6
 ========================
 
 Simplified default project and app templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 The default templates used by :djadmin:`startproject` and :djadmin:`startapp`
 have been simplified and modernized. The :doc:`admin
@@ -63,7 +63,7 @@ If the default templates don't suit your tastes, you can use :ref:`custom
 project and app templates <custom-app-and-project-templates>`.
 
 Improved transaction management
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Django's transaction management was overhauled. Database-level autocommit is
 now turned on by default. This makes transaction handling more explicit and
@@ -72,7 +72,7 @@ were introduced, as described in the :doc:`transaction management docs
 </topics/db/transactions>`.
 
 Persistent database connections
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Django now supports reusing the same database connection for several requests.
 This avoids the overhead of re-establishing a connection at the beginning of
@@ -80,7 +80,7 @@ each request. For backwards compatibility, this feature is disabled by
 default. See :ref:`persistent-database-connections` for details.
 
 Discovery of tests in any test module
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Django 1.6 ships with a new test runner that allows more flexibility in the
 location of tests. The previous runner
@@ -103,7 +103,7 @@ This change is backwards-incompatible; see the :ref:`backwards-incompatibility
 notes<new-test-runner>`.
 
 Time zone aware aggregation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 The support for :doc:`time zones </topics/i18n/timezones>` introduced in
 Django 1.4 didn't work well with :meth:`QuerySet.dates()
@@ -113,33 +113,33 @@ UTC. This limitation was lifted in Django 1.6. Use :meth:`QuerySet.datetimes()
 aggregation on a :class:`~django.db.models.DateTimeField`.
 
 Support for savepoints in SQLite
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Django 1.6 adds support for savepoints in SQLite, with some :ref:`limitations
 <savepoints-in-sqlite>`.
 
 ``BinaryField`` model field
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 A new :class:`django.db.models.BinaryField` model field allows storage of raw
 binary data in the database.
 
 GeoDjango form widgets
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 GeoDjango now provides :doc:`form fields and widgets </ref/contrib/gis/forms-api>`
 for its geo-specialized fields. They are OpenLayers-based by default, but they
 can be customized to use any other JS framework.
 
 ``check`` management command added for verifying compatibility
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------------
 
 A :djadmin:`check` management command was added, enabling you to verify if your
 current configuration (currently oriented at settings) is compatible with the
 current version of Django.
 
 :meth:`Model.save() <django.db.models.Model.save()>` algorithm changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------
 
 The :meth:`Model.save() <django.db.models.Model.save()>` method now
 tries to directly ``UPDATE`` the database if the instance has a primary
@@ -155,7 +155,7 @@ trigger which returns ``NULL``. In such cases it is possible to set
 use the old algorithm.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 * Authentication backends can raise ``PermissionDenied`` to immediately fail
   the authentication chain.
@@ -382,17 +382,17 @@ Backwards incompatible changes in 1.6
     backwards incompatible change.
 
 New transaction management model
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Behavior changes
-^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~
 
 Database-level autocommit is enabled by default in Django 1.6. While this
 doesn't change the general spirit of Django's transaction management, there
 are a few backwards-incompatibilities.
 
 Savepoints and ``assertNumQueries``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The changes in transaction management may result in additional statements to
 create, release or rollback savepoints. This is more likely to happen with
@@ -404,7 +404,7 @@ queries are related to savepoints, and adjust the expected number of queries
 accordingly.
 
 Autocommit option for PostgreSQL
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In previous versions, database-level autocommit was only an option for
 PostgreSQL, and it was disabled by default. This option is now ignored and can
@@ -413,7 +413,7 @@ be removed.
 .. _new-test-runner:
 
 New test runner
-~~~~~~~~~~~~~~~
+---------------
 
 In order to maintain greater consistency with Python's unittest module, the new
 test runner (``django.test.runner.DiscoverRunner``) does not automatically
@@ -439,7 +439,7 @@ but will not be removed from Django until version 1.8.
 .. _recommendations in the Python documentation: https://docs.python.org/library/doctest.html#unittest-api
 
 Removal of ``django.contrib.gis.tests.GeoDjangoTestSuiteRunner`` GeoDjango custom test runner
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------------------------
 
 This is for developers working on the GeoDjango application itself and related
 to the item above about changes in the test runners:
@@ -450,7 +450,7 @@ supported anymore. To run the GeoDjango tests simply use the new
 ``DiscoverRunner`` and specify the ``django.contrib.gis`` app.
 
 Custom User models in tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 The introduction of the new test runner has also slightly changed the way that
 test models are imported. As a result, any test that overrides ``AUTH_USER_MODEL``
@@ -473,7 +473,7 @@ error reporting::
     ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed
 
 Time zone-aware ``day``, ``month``, and ``week_day`` lookups
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------
 
 Django 1.6 introduces time zone support for :lookup:`day`, :lookup:`month`,
 and :lookup:`week_day` lookups when :setting:`USE_TZ` is ``True``. These
@@ -488,7 +488,7 @@ tables with `mysql_tzinfo_to_sql`_.
 .. _mysql_tzinfo_to_sql: https://dev.mysql.com/doc/refman/5.6/en/mysql-tzinfo-to-sql.html
 
 Addition of ``QuerySet.datetimes()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
 
 When the :doc:`time zone support </topics/i18n/timezones>` added in Django 1.4
 was active, :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>`
@@ -498,7 +498,7 @@ UTC. To fix this, Django 1.6 introduces a new API, :meth:`QuerySet.datetimes()
 your code.
 
 ``QuerySet.dates()`` returns ``date`` objects
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` now returns a
 list of :class:`~datetime.date`. It used to return a list of
@@ -508,7 +508,7 @@ list of :class:`~datetime.date`. It used to return a list of
 returns a list of :class:`~datetime.datetime`.
 
 ``QuerySet.dates()`` no longer usable on ``DateTimeField``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :meth:`QuerySet.dates() <django.db.models.query.QuerySet.dates>` raises an
 error if it's used on :class:`~django.db.models.DateTimeField` when time
@@ -516,7 +516,7 @@ zone support is active. Use :meth:`QuerySet.datetimes()
 <django.db.models.query.QuerySet.datetimes>` instead.
 
 ``date_hierarchy`` requires time zone definitions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The :attr:`~django.contrib.admin.ModelAdmin.date_hierarchy` feature of the
 admin now relies on :meth:`QuerySet.datetimes()
@@ -527,7 +527,7 @@ This requires time zone definitions in the database when :setting:`USE_TZ` is
 ``True``. :ref:`Learn more <database-time-zone-definitions>`.
 
 ``date_list`` in generic views requires time zone definitions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 For the same reason, accessing ``date_list`` in the context of a date-based
 generic view requires time zone definitions in the database when the view is
@@ -535,7 +535,7 @@ based on a :class:`~django.db.models.DateTimeField` and :setting:`USE_TZ` is
 ``True``. :ref:`Learn more <database-time-zone-definitions>`.
 
 New lookups may clash with model fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 Django 1.6 introduces ``hour``, ``minute``, and ``second`` lookups on
 :class:`~django.db.models.DateTimeField`. If you had model fields called
@@ -543,7 +543,7 @@ Django 1.6 introduces ``hour``, ``minute``, and ``second`` lookups on
 names. Append an explicit :lookup:`exact` lookup if this is an issue.
 
 ``BooleanField`` no longer defaults to ``False``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 When a :class:`~django.db.models.BooleanField` doesn't have an explicit
 :attr:`~django.db.models.Field.default`, the implicit default value is
@@ -557,10 +557,10 @@ either specify ``default=False`` in the field definition, or ensure the field
 is set to ``True`` or ``False`` before saving the object.
 
 Translations and comments in templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 Extraction of translations after comments
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Extraction of translatable literals from templates with the
 :djadmin:`makemessages` command now correctly detects i18n constructs when
@@ -571,7 +571,7 @@ they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.:
     {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}
 
 Location of translator comments
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` need to
 be at the end of a line. If they are not, the comments are ignored and
@@ -585,6 +585,8 @@ be at the end of a line. If they are not, the comments are ignored and
 
 Quoting in :func:`~django.core.urlresolvers.reverse`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Quoting in ``reverse()``
+------------------------
 
 When reversing URLs, Django didn't apply :func:`~django.utils.http.urlquote`
 to arguments before interpolating them in URL patterns. This bug is fixed in
@@ -595,7 +597,7 @@ your code. You will also have to replace special characters in URLs used in
 :func:`~django.test.SimpleTestCase.assertRedirects` with their encoded versions.
 
 Storage of IP addresses in the comments app
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 The comments app now uses a
 ``GenericIPAddressField`` for storing commenters' IP addresses, to support
@@ -622,7 +624,7 @@ addresses are silently truncated; on Oracle, an exception is generated. No
 database change is needed for SQLite or PostgreSQL databases.
 
 Percent literals in ``cursor.execute`` queries
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 When you are running raw SQL queries through the
 :ref:`cursor.execute <executing-custom-sql>` method, the rule about doubling
@@ -642,7 +644,7 @@ parameters. For example::
 .. _m2m-help_text:
 
 Help text of model form fields for ManyToManyField fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 HTML rendering of model form fields corresponding to
 :class:`~django.db.models.ManyToManyField` model fields used to get the
@@ -676,7 +678,7 @@ and :doc:`widgets </ref/forms/widgets>` aren't affected but need to be aware of
 what's described in :ref:`m2m-help_text-deprecation` below.
 
 QuerySet iteration
-~~~~~~~~~~~~~~~~~~
+------------------
 
 The ``QuerySet`` iteration was changed to immediately convert all fetched
 rows to ``Model`` objects. In Django 1.5 and earlier the fetched rows were
@@ -695,7 +697,7 @@ lazily by using the :meth:`~django.db.models.query.QuerySet.iterator()`
 method.
 
 :meth:`BoundField.label_tag<django.forms.BoundField.label_tag>` now includes the form's :attr:`~django.forms.Form.label_suffix`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------------------------------------------------------------------
 
 This is consistent with how methods like
 :meth:`Form.as_p<django.forms.Form.as_p>` and
@@ -728,7 +730,7 @@ customize the ``label_suffix`` on a per-field basis using the new
 ``label_suffix`` parameter on :meth:`~django.forms.BoundField.label_tag`.
 
 Admin views ``_changelist_filters`` GET parameter
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 To achieve preserving and restoring list view filters, admin views now
 pass around the `_changelist_filters` GET parameter. It's important that you
@@ -738,7 +740,7 @@ can set the
 :attr:`~django.contrib.admin.ModelAdmin.preserve_filters` attribute to ``False``.
 
 ``django.contrib.auth`` password reset uses base 64 encoding of ``User`` PK
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------
 
 Past versions of Django used base 36 encoding of the ``User`` primary key in
 the password reset views and URLs
@@ -791,7 +793,7 @@ You can remove this url pattern after your app has been deployed with Django
 1.6 for :setting:`PASSWORD_RESET_TIMEOUT_DAYS`.
 
 Default session serialization switched to JSON
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Historically, :mod:`django.contrib.sessions` used :mod:`pickle` to serialize
 session data before storing it in the backend. If you're using the :ref:`signed
@@ -825,7 +827,7 @@ serialization will work for your application:
 See the :ref:`session_serialization` documentation for more details.
 
 Object Relational Mapper changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Django 1.6 contains many changes to the ORM. These changes fall mostly in
 three categories:
@@ -850,7 +852,7 @@ neither Django 1.5 nor 1.6 produce correct results.
 Finally, there have been many changes to the ORM internal APIs.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more -
   it is only usable as a marker class for checking if
@@ -965,7 +967,7 @@ Features deprecated in 1.6
 ==========================
 
 Transaction management APIs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Transaction management was completely overhauled in Django 1.6, and the
 current APIs are deprecated:
@@ -977,7 +979,7 @@ current APIs are deprecated:
 - the ``TRANSACTIONS_MANAGED`` setting
 
 ``django.contrib.comments``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 Django's comment framework has been deprecated and is no longer supported. It
 will be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users
@@ -990,7 +992,7 @@ __ https://disqus.com/
 __ https://github.com/django/django-contrib-comments
 
 Support for PostgreSQL versions older than 8.4
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 The end of upstream support periods was reached in December 2011 for
 PostgreSQL 8.2 and in February 2013 for 8.3. As a consequence, Django 1.6 sets
@@ -1001,7 +1003,7 @@ available, because of performance improvements and to take advantage of the
 native streaming replication available in PostgreSQL 9.x.
 
 Changes to :ttag:`cycle` and :ttag:`firstof`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 The template system generally escapes all variables to avoid XSS attacks.
 However, due to an accident of history, the :ttag:`cycle` and :ttag:`firstof`
@@ -1029,7 +1031,7 @@ If necessary, you can temporarily disable auto-escaping with
 <autoescape>`.
 
 ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 ``CacheMiddleware`` and ``UpdateCacheMiddleware`` used to provide a way to
 cache requests only if they weren't made by a logged-in user. This mechanism
@@ -1047,7 +1049,7 @@ This makes the cache effectively work on a per-session basis regardless of the
 __ https://www.google.com/analytics/
 
 ``SEND_BROKEN_LINK_EMAILS`` setting
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 :class:`~django.middleware.common.CommonMiddleware` used to provide basic
 reporting of broken links by email when ``SEND_BROKEN_LINK_EMAILS`` is set to
@@ -1065,19 +1067,19 @@ If you're relying on this feature, you should add
 from your settings.
 
 ``_has_changed`` method on widgets
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 If you defined your own form widgets and defined the ``_has_changed`` method
 on a widget, you should now define this method on the form field itself.
 
 ``module_name`` model _meta attribute
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 ``Model._meta.module_name`` was renamed to ``model_name``. Despite being a
 private API, it will go through a regular deprecation path.
 
 ``get_(add|change|delete)_permission`` model _meta methods
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------
 
 ``Model._meta.get_(add|change|delete)_permission`` methods were deprecated.
 Even if they were not part of the public API they'll also go through
@@ -1086,7 +1088,7 @@ a regular deprecation path. You can replace them with
 ``'action'`` is ``'add'``, ``'change'``, or ``'delete'``.
 
 ``get_query_set`` and similar methods renamed to ``get_queryset``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------
 
 Methods that return a ``QuerySet`` such as ``Manager.get_query_set`` or
 ``ModelAdmin.queryset`` have been renamed to ``get_queryset``.
@@ -1140,7 +1142,7 @@ override either ``get_query_set`` or ``get_queryset``.
 
 
 ``shortcut`` view and URLconf
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 The ``shortcut`` view was moved from ``django.views.defaults`` to
 ``django.contrib.contenttypes.views`` shortly after the 1.0 release, but the
@@ -1157,7 +1159,7 @@ with::
     (r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$', 'django.contrib.contenttypes.views.shortcut'),
 
 ``ModelForm`` without ``fields`` or ``exclude``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 Previously, if you wanted a :class:`~django.forms.ModelForm` to use all fields on
 the model, you could simply omit the ``Meta.fields`` attribute, and all fields
@@ -1192,7 +1194,7 @@ functioning ``ModelForm``. This behavior also works for earlier Django
 versions.
 
 ``UpdateView`` and ``CreateView`` without explicit fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 The generic views :class:`~django.views.generic.edit.CreateView` and
 :class:`~django.views.generic.edit.UpdateView`, and anything else derived from
@@ -1211,7 +1213,7 @@ but without an explicit list of fields is deprecated.
 .. _m2m-help_text-deprecation:
 
 Munging of help text of model form fields for ``ManyToManyField`` fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------------
 
 All special handling of the ``help_text`` attribute of ``ManyToManyField`` model
 fields performed by standard model or model form fields as described in
diff --git a/docs/releases/1.7.txt b/docs/releases/1.7.txt
index 8816351fbb..875c5792fa 100644
--- a/docs/releases/1.7.txt
+++ b/docs/releases/1.7.txt
@@ -37,7 +37,7 @@ What's new in Django 1.7
 ========================
 
 Schema migrations
-~~~~~~~~~~~~~~~~~
+-----------------
 
 Django now has built-in support for schema migrations. It allows models
 to be updated, changed, and deleted by creating migration files that represent
@@ -87,7 +87,7 @@ but a few of the key features are:
 .. _app-loading-refactor-17-release-note:
 
 App-loading refactor
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 Historically, Django applications were tightly linked to models. A singleton
 known as the "app cache" dealt with both installed applications and models.
@@ -125,7 +125,7 @@ Improvements thus far include:
   make it easier to diagnose import issues such as import loops.
 
 New method on Field subclasses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 To help power both schema migrations and to enable easier addition of
 composite keys in future releases of Django, the
@@ -159,7 +159,7 @@ classes serializable, read the
 :ref:`migration serialization documentation <migration-serializing>`.
 
 Calling custom ``QuerySet`` methods from the ``Manager``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 Historically, the recommended way to make reusable model queries was to create
 methods on a custom ``Manager`` class. The problem with this approach was that
@@ -197,7 +197,7 @@ class method can now directly :ref:`create Manager with QuerySet methods
     Food.objects.pizzas().vegetarian()
 
 Using a custom manager when traversing reverse relations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 It is now possible to :ref:`specify a custom manager
 <using-custom-reverse-manager>` when traversing a reverse relationship::
@@ -215,7 +215,7 @@ It is now possible to :ref:`specify a custom manager
     b.entry_set(manager='entries').all()
 
 New system check framework
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 We've added a new :doc:`System check framework </ref/checks>` for
 detecting common problems (like invalid models) and providing hints for
@@ -226,7 +226,7 @@ To perform system checks, you use the :djadmin:`check` management command.
 This command replaces the older ``validate`` management command.
 
 New ``Prefetch`` object for advanced ``prefetch_related`` operations.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------
 
 The new :class:`~django.db.models.Prefetch` object allows customizing
 prefetch operations.
@@ -241,7 +241,7 @@ querysets. See :meth:`~django.db.models.query.QuerySet.prefetch_related()`
 for more details.
 
 Admin shortcuts support time zones
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 The "today" and "now" shortcuts next to date and time input widgets in the
 admin are now operating in the :ref:`current time zone
@@ -254,7 +254,7 @@ server time zone are different, to clarify how the value inserted in the field
 will be interpreted.
 
 Using database cursors as context managers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 Prior to Python 2.7, database cursors could be used as a context manager. The
 specific backend's cursor defined the behavior of the context manager. The
@@ -276,7 +276,7 @@ instead of::
         c.close()
 
 Custom lookups
-~~~~~~~~~~~~~~
+--------------
 
 It is now possible to write custom lookups and transforms for the ORM.
 Custom lookups work just like Django's built-in lookups (e.g. ``lte``,
@@ -297,10 +297,10 @@ For more information about both custom lookups and transforms refer to
 the :doc:`custom lookups </howto/custom-lookups>` documentation.
 
 Improvements to ``Form`` error handling
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 ``Form.add_error()``
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 Previously there were two main patterns for handling errors in forms:
 
@@ -328,7 +328,7 @@ See :ref:`validating-fields-with-clean` for an example using
 ``Form.add_error()``.
 
 Error metadata
-^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~
 
 The :exc:`~django.core.exceptions.ValidationError` constructor accepts metadata
 such as error ``code`` or ``params`` which are then available for interpolating
@@ -352,7 +352,7 @@ codes serialized as JSON. ``as_json()`` uses ``as_data()`` and gives an idea
 of how the new system could be extended.
 
 Error containers and backward compatibility
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Heavy changes to the various error containers were necessary in order
 to support the features above, specifically
@@ -365,10 +365,10 @@ using private APIs, some of the changes are backwards incompatible; see
 :ref:`validation-error-constructor-and-internal-storage` for more details.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 :mod:`django.contrib.admin`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * You can now implement :attr:`~django.contrib.admin.AdminSite.site_header`,
   :attr:`~django.contrib.admin.AdminSite.site_title`, and
@@ -415,7 +415,7 @@ Minor features
   overridden to define custom behavior for setting initial change form data.
 
 :mod:`django.contrib.auth`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Any ``**kwargs`` passed to
   :meth:`~django.contrib.auth.models.User.email_user()` are passed to the
@@ -442,14 +442,14 @@ Minor features
   including upgrade considerations when enabling this new middleware.
 
 ``django.contrib.formtools``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Calls to :meth:`WizardView.done()
   <formtools.wizard.views.WizardView.done>` now include a
   ``form_dict`` to allow easier access to forms by their step name.
 
 :mod:`django.contrib.gis`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The default OpenLayers library version included in widgets has been updated
   from 2.11 to 2.13.
@@ -459,7 +459,7 @@ Minor features
   installed.
 
 :mod:`django.contrib.messages`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The backends for :mod:`django.contrib.messages` that use cookies, will now
   follow the :setting:`SESSION_COOKIE_SECURE` and
@@ -473,7 +473,7 @@ Minor features
   message level.
 
 :mod:`django.contrib.redirects`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * :class:`~django.contrib.redirects.middleware.RedirectFallbackMiddleware`
   has two new attributes
@@ -484,14 +484,14 @@ Minor features
   middleware returns.
 
 :mod:`django.contrib.sessions`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The ``"django.contrib.sessions.backends.cached_db"`` session backend now
   respects :setting:`SESSION_CACHE_ALIAS`. In previous versions, it always used
   the `default` cache.
 
 :mod:`django.contrib.sitemaps`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
   :attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
@@ -500,13 +500,13 @@ Minor features
   conditional ``GET`` requests for sitemaps which set ``lastmod``.
 
 :mod:`django.contrib.sites`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The new :class:`django.contrib.sites.middleware.CurrentSiteMiddleware` allows
   setting the current site on each request.
 
 :mod:`django.contrib.staticfiles`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The :ref:`static files storage classes <staticfiles-storages>` may be
   subclassed to override the permissions that collected static files and
@@ -533,7 +533,7 @@ Minor features
   :djadmin:`findstatic` for example output.
 
 :mod:`django.contrib.syndication`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
   ``updated`` element now utilizes ``updateddate`` instead of ``pubdate``,
@@ -541,7 +541,7 @@ Minor features
   relies on ``pubdate``).
 
 Cache
-^^^^^
+~~~~~
 
 * Access to caches configured in :setting:`CACHES` is now available via
   :data:`django.core.cache.caches`. This dict-like object provides a different
@@ -558,13 +558,13 @@ Cache
   ``timeout=None`` to the cache backend's ``set()`` method.
 
 Cross Site Request Forgery
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The :setting:`CSRF_COOKIE_AGE` setting facilitates the use of session-based
   CSRF cookies.
 
 Email
-^^^^^
+~~~~~
 
 * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
   parameter for sending a multipart ``text/plain`` and ``text/html`` email.
@@ -572,7 +572,7 @@ Email
   ``timeout`` parameter.
 
 File Storage
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 * File locking on Windows previously depended on the PyWin32 package; if it
   wasn't installed, file locking failed silently. That dependency has been
@@ -580,7 +580,7 @@ File Storage
   and Unix.
 
 File Uploads
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 * The new :attr:`UploadedFile.content_type_extra
   <django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
@@ -607,7 +607,7 @@ File Uploads
   This change was also made in the 1.6.6, 1.5.9, and 1.4.14 security releases.
 
 Forms
-^^^^^
+~~~~~
 
 * The ``<label>`` and ``<input>`` tags rendered by
   :class:`~django.forms.RadioSelect` and
@@ -663,7 +663,7 @@ Forms
   <considerations-regarding-model-errormessages>` for more details.
 
 Internationalization
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 * The :attr:`django.middleware.locale.LocaleMiddleware.response_redirect_class`
   attribute allows you to customize the redirects issued by the middleware.
@@ -699,10 +699,10 @@ Internationalization
   :setting:`LANGUAGE_COOKIE_AGE`, :setting:`LANGUAGE_COOKIE_DOMAIN`
   and :setting:`LANGUAGE_COOKIE_PATH`.
 
-* Added :ref:`format definitions <format-localization>` for Esperanto.
+* Added :doc:`/topics/i18n/formatting` for Esperanto.
 
 Management Commands
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 * The :djadminopt:`--no-color` option for ``django-admin`` allows you to
   disable the colorization of management command output.
@@ -749,7 +749,7 @@ Management Commands
 .. _sqlparse: https://pypi.python.org/pypi/sqlparse
 
 Models
-^^^^^^
+~~~~~~
 
 * The :meth:`QuerySet.update_or_create()
   <django.db.models.query.QuerySet.update_or_create>` method was added.
@@ -809,7 +809,7 @@ Models
   a relation ``_id`` field by using its attribute name.
 
 Signals
-^^^^^^^
+~~~~~~~
 
 * The ``enter`` argument was added to the
   :data:`~django.test.signals.setting_changed` signal.
@@ -819,7 +819,7 @@ Signals
   reference their senders.
 
 Templates
-^^^^^^^^^
+~~~~~~~~~
 
 * The :meth:`Context.push() <django.template.Context.push>` method now returns
   a context manager which automatically calls :meth:`pop()
@@ -876,7 +876,7 @@ Templates
   longer than the specified number of characters, taking HTML into account.
 
 Requests and Responses
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 * The new :attr:`HttpRequest.scheme <django.http.HttpRequest.scheme>` attribute
   specifies the scheme of the request (``http`` or ``https`` normally).
@@ -889,7 +889,7 @@ Requests and Responses
   :class:`~django.http.HttpResponse` helps easily create JSON-encoded responses.
 
 Tests
-^^^^^
+~~~~~
 
 * :class:`~django.test.runner.DiscoverRunner` has two new attributes,
   :attr:`~django.test.runner.DiscoverRunner.test_suite` and
@@ -918,13 +918,13 @@ Tests
   named :setting:`TEST <DATABASE-TEST>`.
 
 Utilities
-^^^^^^^^^
+~~~~~~~~~
 
 * Improved :func:`~django.utils.html.strip_tags` accuracy (but it still cannot
   guarantee an HTML-safe result, as stated in the documentation).
 
 Validators
-^^^^^^^^^^
+~~~~~~~~~~
 
 * :class:`~django.core.validators.RegexValidator` now accepts the optional
   :attr:`~django.core.validators.RegexValidator.flags` and
@@ -955,7 +955,7 @@ Backwards incompatible changes in 1.7
     backwards incompatible change.
 
 ``allow_syncdb`` / ``allow_migrate``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
 
 While Django will still look at ``allow_syncdb`` methods even though they
 should be renamed to ``allow_migrate``, there is a subtle difference in which
@@ -967,7 +967,7 @@ without custom attributes, methods or managers. Make sure your ``allow_migrate``
 methods are only referring to fields or other items in ``model._meta``.
 
 initial_data
-~~~~~~~~~~~~
+------------
 
 Apps with migrations will not load ``initial_data`` fixtures when they have
 finished migrating. Apps without migrations will continue to load these fixtures
@@ -983,7 +983,7 @@ Additionally, like the rest of Django's old ``syncdb`` code, ``initial_data``
 has been started down the deprecation path and will be removed in Django 1.9.
 
 deconstruct() and serializability
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 Django now requires all Field classes and all of their constructor arguments
 to be serializable. If you modify the constructor signature in your custom
@@ -999,10 +999,10 @@ them as well <custom-deconstruct-method>`, though Django provides a handy
 class decorator that will work for most applications.
 
 App-loading changes
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 Start-up sequence
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 Django 1.7 loads application configurations and models as soon as it starts.
 While this behavior is more straightforward and is believed to be more robust,
@@ -1010,7 +1010,7 @@ regressions cannot be ruled out. See :ref:`applications-troubleshooting` for
 solutions to some problems you may encounter.
 
 Standalone scripts
-^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~
 
 If you're using Django in a plain Python script — rather than a management
 command — and you rely on the :envvar:`DJANGO_SETTINGS_MODULE` environment
@@ -1023,7 +1023,7 @@ script with::
 Otherwise, you will hit an ``AppRegistryNotReady`` exception.
 
 WSGI scripts
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 Until Django 1.3, the recommended way to create a WSGI application was::
 
@@ -1039,7 +1039,7 @@ If you're still using the former style in your WSGI script, you need to
 upgrade to the latter, or you will hit an ``AppRegistryNotReady`` exception.
 
 App registry consistency
-^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is no longer possible to have multiple installed applications with the same
 label. In previous versions of Django, this didn't always work correctly, but
@@ -1070,7 +1070,7 @@ Django will enforce these requirements as of version 1.9, after a deprecation
 period.
 
 Subclassing AppCommand
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 Subclasses of :class:`~django.core.management.AppCommand` must now implement a
 :meth:`~django.core.management.AppCommand.handle_app_config` method instead of
@@ -1078,7 +1078,7 @@ Subclasses of :class:`~django.core.management.AppCommand` must now implement a
 instance instead of a models module.
 
 Introspecting applications
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Since :setting:`INSTALLED_APPS` now supports application configuration classes
 in addition to application modules, you should review code that accesses this
@@ -1096,7 +1096,7 @@ following changes that take effect immediately:
   longer exists, nor does the ``seed_cache`` argument of ``get_model``.
 
 Management commands and order of :setting:`INSTALLED_APPS`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------
 
 When several applications provide management commands with the same name,
 Django loads the command from the application that comes first in
@@ -1110,7 +1110,7 @@ files, templates, and translations.
 .. _validation-error-constructor-and-internal-storage:
 
 ``ValidationError`` constructor and internal storage
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------
 
 The behavior of the ``ValidationError`` constructor has changed when it
 receives a container of errors as an argument (e.g. a ``list`` or an
@@ -1167,7 +1167,7 @@ workaround to convert any ``list`` into ``ErrorList``::
             self._errors[field] = self.error_class(error_list)
 
 Behavior of ``LocMemCache`` regarding pickle errors
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 An inconsistency existed in previous versions of Django regarding how pickle
 errors are handled by different cache backends.
@@ -1177,7 +1177,7 @@ cache-specific errors. This has been fixed in Django 1.7, see
 :ticket:`21200` for more details.
 
 Cache keys are now generated from the request's absolute URL
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------
 
 Previous versions of Django generated cache keys using a request's path and
 query string but not the scheme or host. If a Django application was serving
@@ -1190,7 +1190,7 @@ generated by older versions of Django. After upgrading to Django 1.7, the first
 request to any previously cached URL will be a cache miss.
 
 Passing ``None`` to ``Manager.db_manager()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 In previous versions of Django, it was possible to use
 ``db_manager(using=None)`` on a model manager instance to obtain a manager
@@ -1202,7 +1202,7 @@ the way routing information cascaded over joins. See :ticket:`13724` for more
 details.
 
 pytz may be required
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 If your project handles datetimes before 1970 or after 2037 and Django raises
 a :exc:`ValueError` when encountering them, you will have to install pytz_. You
@@ -1212,7 +1212,7 @@ formats or :mod:`django.contrib.syndication`.
 .. _pytz: https://pypi.python.org/pypi/pytz/
 
 ``remove()`` and ``clear()`` methods of related managers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 The ``remove()`` and ``clear()`` methods of the related managers created by
 ``ForeignKey``, ``GenericForeignKey``, and ``ManyToManyField`` suffered from a
@@ -1240,7 +1240,7 @@ Fixing the issues introduced some backward incompatible changes:
   See :ref:`this note <nested-queries-performance>` for more details.
 
 Admin login redirection strategy
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 Historically, the Django admin site passed the request from an unauthorized or
 unauthenticated user directly to the login view, without HTTP redirection. In
@@ -1254,7 +1254,7 @@ Note also that the admin login form has been updated to not contain the
 has been set to the more regular ``invalid_login`` key.
 
 ``select_for_update()`` requires a transaction
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Historically, queries that use
 :meth:`~django.db.models.query.QuerySet.select_for_update()` could be
@@ -1278,7 +1278,7 @@ in a test class which is a subclass of
 :class:`~django.test.TestCase`.
 
 Contrib middleware removed from default :setting:`MIDDLEWARE_CLASSES`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------
 
 The :ref:`app-loading refactor <app-loading-refactor-17-release-note>`
 deprecated using models from apps which are not part of the
@@ -1299,7 +1299,7 @@ project's needs. You should also check for any code that accesses
 ``django.conf.global_settings.MIDDLEWARE_CLASSES`` directly.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
   method is now passed an additional ``content_type_extra`` parameter. If you
@@ -1472,20 +1472,20 @@ Features deprecated in 1.7
 ==========================
 
 ``django.core.cache.get_cache``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 ``django.core.cache.get_cache`` has been supplanted by
 :data:`django.core.cache.caches`.
 
 ``django.utils.dictconfig``/``django.utils.importlib``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------
 
 ``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
 respectively :mod:`logging.config` and :mod:`importlib` provided for Python
 versions prior to 2.7. They have been deprecated.
 
 ``django.utils.module_loading.import_by_path``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 The current ``django.utils.module_loading.import_by_path`` function
 catches ``AttributeError``, ``ImportError``, and ``ValueError`` exceptions,
@@ -1496,7 +1496,7 @@ It has been deprecated in favor of
 :meth:`~django.utils.module_loading.import_string`.
 
 ``django.utils.tzinfo``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 ``django.utils.tzinfo`` provided two :class:`~datetime.tzinfo` subclasses,
 ``LocalTimezone`` and ``FixedOffset``. They've been deprecated in favor of
@@ -1505,7 +1505,7 @@ more correct alternatives provided by :mod:`django.utils.timezone`,
 :func:`django.utils.timezone.get_fixed_timezone`.
 
 ``django.utils.unittest``
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 ``django.utils.unittest`` provided uniform access to the ``unittest2`` library
 on all Python versions. Since ``unittest2`` became the standard library's
@@ -1514,7 +1514,7 @@ Python versions, this module isn't useful anymore. It has been deprecated. Use
 :mod:`unittest` instead.
 
 ``django.utils.datastructures.SortedDict``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 As :class:`~collections.OrderedDict` was added to the standard library in
 Python 2.7, ``SortedDict`` is no longer needed and has been deprecated.
@@ -1536,7 +1536,7 @@ for a particular form instance. For example (from Django itself)::
     )
 
 Custom SQL location for models package
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 Previously, if models were organized in a package (``myapp/models/``) rather
 than simply ``myapp/models.py``, Django would look for initial SQL data in
@@ -1547,7 +1547,7 @@ exists, the deprecation is irrelevant as the entire feature will be removed in
 Django 1.9.
 
 Reorganization of ``django.contrib.sites``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 ``django.contrib.sites`` provides reduced functionality when it isn't in
 :setting:`INSTALLED_APPS`. The app-loading refactor adds some constraints in
@@ -1560,7 +1560,7 @@ locations are deprecated:
   ``django.contrib.sites.shortcuts``.
 
 ``declared_fieldsets`` attribute on ``ModelAdmin``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 ``ModelAdmin.declared_fieldsets`` has been deprecated. Despite being a private
 API, it will go through a regular deprecation path. This attribute was mostly
@@ -1568,7 +1568,7 @@ used by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was
 considered a bug and has been addressed.
 
 Reorganization of ``django.contrib.contenttypes``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 Since ``django.contrib.contenttypes.generic`` defined both admin and model
 related objects, an import of this module could trigger unexpected side effects.
@@ -1587,14 +1587,14 @@ submodules and the ``django.contrib.contenttypes.generic`` module is deprecated:
   :mod:`~django.contrib.contenttypes.admin`.
 
 ``syncdb``
-~~~~~~~~~~
+----------
 
 The ``syncdb`` command has been deprecated in favor of the new :djadmin:`migrate`
 command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
 more, so it's safe to just change the name you're calling and nothing else.
 
 ``util`` modules renamed to ``utils``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 The following instances of ``util.py`` in the Django codebase have been renamed
 to ``utils.py`` in an effort to unify all util and utils references:
@@ -1605,14 +1605,14 @@ to ``utils.py`` in an effort to unify all util and utils references:
 * ``django.forms.util``
 
 ``get_formsets`` method on ``ModelAdmin``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 ``ModelAdmin.get_formsets`` has been deprecated in favor of the new
 :meth:`~django.contrib.admin.ModelAdmin.get_formsets_with_inlines`, in order to
 better handle the case of selectively showing inlines on a ``ModelAdmin``.
 
 ``IPAddressField``
-~~~~~~~~~~~~~~~~~~
+------------------
 
 The ``django.db.models.IPAddressField`` and ``django.forms.IPAddressField``
 fields have been deprecated in favor of
@@ -1620,14 +1620,14 @@ fields have been deprecated in favor of
 :class:`django.forms.GenericIPAddressField`.
 
 ``BaseMemcachedCache._get_memcache_timeout`` method
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 The ``BaseMemcachedCache._get_memcache_timeout()`` method has been renamed to
 ``get_backend_timeout()``. Despite being a private API, it will go through the
 normal deprecation.
 
 Natural key serialization options
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The ``--natural`` and ``-n`` options for :djadmin:`dumpdata` have been
 deprecated. Use :djadminopt:`--natural-foreign` instead.
@@ -1636,14 +1636,14 @@ Similarly, the ``use_natural_keys`` argument for ``serializers.serialize()``
 has been deprecated. Use ``use_natural_foreign_keys`` instead.
 
 Merging of ``POST`` and ``GET`` arguments into ``WSGIRequest.REQUEST``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------
 
 It was already strongly suggested that you use ``GET`` and ``POST`` instead of
 ``REQUEST``, because the former are more explicit. The property ``REQUEST`` is
 deprecated and will be removed in Django 1.9.
 
 ``django.utils.datastructures.MergeDict`` class
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 ``MergeDict`` exists primarily to support merging ``POST`` and ``GET``
 arguments into a ``REQUEST`` property on ``WSGIRequest``. To merge
@@ -1651,7 +1651,7 @@ dictionaries, use ``dict.update()`` instead. The class ``MergeDict`` is
 deprecated and will be removed in Django 1.9.
 
 Language codes ``zh-cn``, ``zh-tw`` and ``fy-nl``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 The currently used language codes for Simplified Chinese ``zh-cn``,
 Traditional Chinese ``zh-tw`` and (Western) Frysian ``fy-nl`` are deprecated
@@ -1661,7 +1661,7 @@ locale directories and update your settings to reflect these changes. The
 deprecated language codes will be removed in Django 1.9.
 
 ``django.utils.functional.memoize`` function
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 The function ``memoize`` is deprecated and should be replaced by the
 ``functools.lru_cache`` decorator (available from Python 3.2 onwards).
@@ -1671,13 +1671,13 @@ available at ``django.utils.lru_cache.lru_cache``. The deprecated function will
 be removed in Django 1.9.
 
 Geo Sitemaps
-~~~~~~~~~~~~
+------------
 
 Google has retired support for the Geo Sitemaps format. Hence Django support
 for Geo Sitemaps is deprecated and will be removed in Django 1.8.
 
 Passing callable arguments to queryset methods
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 Callable arguments for querysets were an undocumented feature that was
 unreliable. It's been deprecated and will be removed in Django 1.9.
@@ -1688,26 +1688,26 @@ evaluating arguments before passing them to queryset and created confusion that
 the arguments may have been evaluated at query time.
 
 ``ADMIN_FOR`` setting
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 The ``ADMIN_FOR`` feature, part of the admindocs, has been removed. You can
 remove the setting from your configuration at your convenience.
 
 ``SplitDateTimeWidget`` with ``DateTimeField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 ``SplitDateTimeWidget`` support in :class:`~django.forms.DateTimeField` is
 deprecated, use ``SplitDateTimeWidget`` with
 :class:`~django.forms.SplitDateTimeField` instead.
 
 ``validate``
-~~~~~~~~~~~~
+------------
 
 The ``validate`` management command is deprecated in favor of the
 :djadmin:`check` command.
 
 ``django.core.management.BaseCommand``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 ``requires_model_validation`` is deprecated in favor of a new
 ``requires_system_checks`` flag. If the latter flag is missing, then the
@@ -1717,7 +1717,7 @@ value of the former flag is used. Defining both ``requires_system_checks`` and
 The ``check()`` method has replaced the old ``validate()`` method.
 
 ``ModelAdmin`` validators
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 The ``ModelAdmin.validator_class`` and ``default_validator_class`` attributes
 are deprecated in favor of the new ``checks_class`` attribute.
@@ -1728,7 +1728,7 @@ The ``ModelAdmin.validate()`` method is deprecated in favor of
 The ``django.contrib.admin.validation`` module is deprecated.
 
 ``django.db.backends.DatabaseValidation.validate_field``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 This method is deprecated in favor of a new ``check_field`` method.
 The functionality required by ``check_field()`` is the same as that provided
@@ -1737,7 +1737,7 @@ backends needing this functionality should provide an implementation of
 ``check_field()``.
 
 Loading ``ssi`` and ``url`` template tags from ``future`` library
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------
 
 Django 1.3 introduced ``{% load ssi from future %}`` and
 ``{% load url from future %}`` syntax for forward compatibility of the
@@ -1746,7 +1746,7 @@ will be removed in Django 1.9. You can simply remove the
 ``{% load ... from future %}`` tags.
 
 ``django.utils.text.javascript_quote``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 ``javascript_quote()`` was an undocumented function present in ``django.utils.text``.
 It was used internally in the :ref:`javascript_catalog view <javascript_catalog-view>`
@@ -1758,7 +1758,7 @@ If all you need is to generate valid JavaScript strings, you can simply use
 ``json.dumps()``.
 
 ``fix_ampersands`` utils method and template filter
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 The ``django.utils.html.fix_ampersands`` method and the ``fix_ampersands``
 template filter are deprecated, as the escaping of ampersands is already taken care
@@ -1771,7 +1771,7 @@ As this is an accelerated deprecation, ``fix_ampersands`` and ``clean_html``
 will be removed in Django 1.8.
 
 Reorganization of database test settings
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 All database settings with a ``TEST_`` prefix have been deprecated in favor of
 entries in a :setting:`TEST <DATABASE-TEST>` dictionary in the database
@@ -1780,13 +1780,13 @@ compatibility with older versions of Django, you can define both versions of
 the settings as long as they match.
 
 FastCGI support
-~~~~~~~~~~~~~~~
+---------------
 
 FastCGI support via the ``runfcgi`` management command will be removed in
 Django 1.9. Please deploy your project using WSGI.
 
 Moved objects in ``contrib.sites``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Following the app-loading refactor, two objects in
 ``django.contrib.sites.models`` needed to be moved because they must be
@@ -1797,13 +1797,13 @@ available without importing ``django.contrib.sites.models`` when
 Django 1.9.
 
 ``django.forms.forms.get_declared_fields()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 Django no longer uses this functional internally. Even though it's a private
 API, it'll go through the normal deprecation cycle.
 
 Private Query Lookup APIs
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 Private APIs ``django.db.models.sql.where.WhereNode.make_atom()`` and
 ``django.db.models.sql.where.Constraint`` are deprecated in favor of the new
diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt
index fd536fb77b..6f991ff788 100644
--- a/docs/releases/1.8.txt
+++ b/docs/releases/1.8.txt
@@ -37,7 +37,7 @@ What's new in Django 1.8
 ========================
 
 ``Model._meta`` API
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 Django now has a formalized API for :doc:`Model._meta </ref/models/meta>`,
 providing an officially supported way to :ref:`retrieve fields
@@ -53,7 +53,7 @@ new official API have been deprecated and will eventually be removed. A
 <migrating-old-meta-api>` has been provided.
 
 Multiple template engines
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 Django 1.8 defines a stable API for integrating template backends. It includes
 built-in support for the Django template language and for
@@ -63,7 +63,7 @@ new features in the :doc:`topic guide </topics/templates>` and check the
 :doc:`upgrade instructions </ref/templates/upgrading>` for details.
 
 Security enhancements
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 Several features of the django-secure_ third-party library have been
 integrated into Django. :class:`django.middleware.security.SecurityMiddleware`
@@ -75,7 +75,7 @@ site.
 .. _django-secure: https://pypi.python.org/pypi/django-secure
 
 New PostgreSQL specific functionality
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Django now has a module with extensions for PostgreSQL specific features, such
 as :class:`~django.contrib.postgres.fields.ArrayField`,
@@ -84,7 +84,7 @@ as :class:`~django.contrib.postgres.fields.ArrayField`,
 :doc:`in the documentation </ref/contrib/postgres/index>`.
 
 New data types
-~~~~~~~~~~~~~~
+--------------
 
 * Django now has a :class:`~django.db.models.UUIDField` for storing
   universally unique identifiers. It is stored as the native ``uuid`` data type
@@ -100,7 +100,7 @@ New data types
   <django.forms.DurationField>`.
 
 Query Expressions, Conditional Expressions, and Database Functions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------
 
 :doc:`Query Expressions </ref/models/expressions>` allow you to create,
 customize, and compose complex SQL expressions. This has enabled annotate
@@ -120,7 +120,7 @@ also included with functionality such as
 :class:`~django.db.models.functions.Substr`.
 
 ``TestCase`` data setup
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 :class:`~django.test.TestCase` has been refactored to allow for data
 initialization at the class level using transactions and savepoints. Database
@@ -139,10 +139,10 @@ for each test.
   ``TestCase``.
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 :mod:`django.contrib.admin`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * :class:`~django.contrib.admin.ModelAdmin` now has a
   :meth:`~django.contrib.admin.ModelAdmin.has_module_permission`
@@ -187,12 +187,12 @@ Minor features
   objects using a popup.
 
 :mod:`django.contrib.admindocs`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * reStructuredText is now parsed in model docstrings.
 
 :mod:`django.contrib.auth`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Authorization backends can now raise
   :class:`~django.core.exceptions.PermissionDenied` in
@@ -217,7 +217,7 @@ Minor features
   change the default value.
 
 :mod:`django.contrib.gis`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * A new :doc:`GeoJSON serializer </ref/contrib/gis/serializers>` is now
   available.
@@ -243,19 +243,19 @@ Minor features
   used any longer.
 
 :mod:`django.contrib.sessions`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Session cookie is now deleted after
   :meth:`~django.contrib.sessions.backends.base.SessionBase.flush()` is called.
 
 :mod:`django.contrib.sitemaps`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The new :attr:`Sitemap.i18n <django.contrib.sitemaps.Sitemap.i18n>` attribute
   allows you to generate a sitemap based on the :setting:`LANGUAGES` setting.
 
 :mod:`django.contrib.sites`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * :func:`~django.contrib.sites.shortcuts.get_current_site` will now lookup
   the current site based on :meth:`request.get_host()
@@ -267,20 +267,20 @@ Minor features
   using ``pk=1``).
 
 Cache
-^^^^^
+~~~~~
 
 * The ``incr()`` method of the
   ``django.core.cache.backends.locmem.LocMemCache`` backend is now thread-safe.
 
 Cryptography
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 * The ``max_age`` parameter of the
   :meth:`django.core.signing.TimestampSigner.unsign` method now also accepts a
   :py:class:`datetime.timedelta` object.
 
 Database backends
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 * The MySQL backend no longer strips microseconds from ``datetime`` values as
   MySQL 5.6.4 and up supports fractional seconds depending on the declaration
@@ -297,7 +297,7 @@ Database backends
   when getting the description of a table.
 
 Email
-^^^^^
+~~~~~
 
 * :ref:`Email backends <topic-email-backends>` now support the context manager
   protocol for opening and closing connections.
@@ -313,7 +313,7 @@ Email
   support the ``reply_to`` parameter.
 
 File Storage
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 * :meth:`Storage.get_available_name()
   <django.core.files.storage.Storage.get_available_name>` and
@@ -326,7 +326,7 @@ File Storage
   storage classes.
 
 Forms
-^^^^^
+~~~~~
 
 * Form widgets now render attributes with a value of ``True`` or ``False``
   as HTML5 boolean attributes.
@@ -364,7 +364,7 @@ Forms
   instantiating a :class:`~django.forms.ChoiceField`.
 
 Generic Views
-^^^^^^^^^^^^^
+~~~~~~~~~~~~~
 
 * Generic views that use :class:`~django.views.generic.list.MultipleObjectMixin`
   may now specify the ordering applied to the
@@ -388,7 +388,7 @@ Generic Views
   supported but will be removed in Django 1.10.
 
 Internationalization
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 * :setting:`FORMAT_MODULE_PATH` can now be a list of strings representing
   module paths. This allows importing several format modules from different
@@ -396,14 +396,14 @@ Internationalization
   Django project.
 
 Logging
-^^^^^^^
+~~~~~~~
 
 * The :class:`django.utils.log.AdminEmailHandler` class now has a
   :meth:`~django.utils.log.AdminEmailHandler.send_mail` method to make it more
   subclass friendly.
 
 Management Commands
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 * Database connections are now always closed after a management command called
   from the command line has finished doing its job.
@@ -453,7 +453,7 @@ Management Commands
   their dependencies in a project.
 
 Middleware
-^^^^^^^^^^
+~~~~~~~~~~
 
 * The :attr:`CommonMiddleware.response_redirect_class
   <django.middleware.common.CommonMiddleware.response_redirect_class>`
@@ -464,7 +464,7 @@ Middleware
   in :setting:`DEBUG` mode.
 
 Migrations
-^^^^^^^^^^
+~~~~~~~~~~
 
 * The :class:`~django.db.migrations.operations.RunSQL` operation can now handle
   parameters passed to the SQL statements.
@@ -492,7 +492,7 @@ Migrations
   <deprecated-signature-of-allow-migrate>` for more details.
 
 Models
-^^^^^^
+~~~~~~
 
 * Django now logs at most 9000 queries in ``connections.queries``, in order
   to prevent excessive memory usage in long-running processes in debug mode.
@@ -539,7 +539,7 @@ Models
   ``None``.
 
 Signals
-^^^^^^^
+~~~~~~~
 
 * Exceptions from the ``(receiver, exception)`` tuples returned by
   :meth:`Signal.send_robust() <django.dispatch.Signal.send_robust>` now have
@@ -554,12 +554,12 @@ Signals
   situations. Django no longer does so itself.
 
 System Check Framework
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 * :attr:`~django.core.checks.register` can now be used as a function.
 
 Templates
-^^^^^^^^^
+~~~~~~~~~
 
 * :tfilter:`urlize` now supports domain-only links that include characters after
   the top-level domain (e.g. ``djangoproject.com/`` and
@@ -576,7 +576,7 @@ Templates
   usual syntax: ``{% now 'j n Y' as varname %}``.
 
 Requests and Responses
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 * ``WSGIRequest`` now respects paths starting with ``//``.
 
@@ -623,7 +623,7 @@ Requests and Responses
   conditional view processing now supports the ``If-unmodified-since`` header.
 
 Tests
-^^^^^
+~~~~~
 
 * The :class:`RequestFactory.trace() <django.test.RequestFactory>`
   and :class:`Client.trace() <django.test.Client.trace>` methods were
@@ -658,7 +658,7 @@ Tests
   between threads.
 
 Validators
-^^^^^^^^^^
+~~~~~~~~~~
 
 * :class:`~django.core.validators.URLValidator` now supports IPv6 addresses,
   unicode domains, and URLs containing authentication data.
@@ -675,7 +675,7 @@ Backwards incompatible changes in 1.8
     backwards incompatible change.
 
 Related object operations are run in a transaction
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 Some operations on related objects such as
 :meth:`~django.db.models.fields.related.RelatedManager.add()` or
@@ -693,7 +693,7 @@ exception in a signal handler will prevent the whole operation.
 .. _unsaved-model-instance-check-18:
 
 Assigning unsaved objects to relations raises an error
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------
 
 .. note::
 
@@ -740,7 +740,7 @@ objects to the database), you can disable this check by using the
 removed in 1.8.4 as it's no longer relevant.)
 
 Management commands that only accept positional arguments
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 If you have written a custom management command that only accepts positional
 arguments and you didn't specify the
@@ -754,7 +754,7 @@ implement the new :meth:`~django.core.management.BaseCommand.add_arguments`
 method as described in :doc:`/howto/custom-management-commands`.
 
 Custom test management command arguments through test runner
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------
 
 The method to add custom arguments to the `test` management command through the
 test runner has changed. Previously, you could provide an `option_list` class
@@ -765,7 +765,7 @@ Now to implement the same behavior, you have to create an
 :py:class:`argparse.ArgumentParser` instance.
 
 Model check ensures auto-generated column names are within limits specified by database
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------------------
 
 A field name that's longer than the column name length supported by a database
 can create problems. For example, with MySQL you'll get an exception trying to
@@ -787,7 +787,7 @@ and then specify :attr:`~django.db.models.Field.db_column` on its column(s)
 as needed.
 
 Query relation lookups now check object types
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 Querying for model lookups now checks if the object passed is of correct type
 and raises a :exc:`ValueError` if not. Previously, Django didn't care if the
@@ -802,7 +802,7 @@ lookups::
     ValueError: Cannot query "<Book: Django>": Must be "Author" instance.
 
 ``select_related()`` now checks given fields
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 ``select_related()`` now validates that the given fields actually exist.
 Previously, nonexistent fields were silently ignored. Now, an error is raised::
@@ -820,7 +820,7 @@ The validation also makes sure that the given field is relational::
     FieldError: Non-relational field given in select_related: 'name'
 
 Default ``EmailField.max_length`` increased to 254
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 The old default 75 character ``max_length`` was not capable of storing all
 possible RFC3696/5321-compliant email addresses. In order to store all
@@ -831,7 +831,7 @@ your current fields). A migration for
 :attr:`django.contrib.auth.models.User.email` is included.
 
 Support for PostgreSQL versions older than 9.0
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 The end of upstream support periods was reached in July 2014 for PostgreSQL 8.4.
 As a consequence, Django 1.8 sets 9.0 as the minimum PostgreSQL version it
@@ -844,21 +844,21 @@ Django also now requires the use of Psycopg2 version 2.4.5 or higher (or 2.5+
 if you want to use :mod:`django.contrib.postgres`).
 
 Support for MySQL versions older than 5.5
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------
 
 The end of upstream support periods was reached in January 2012 for MySQL 5.0
 and December 2013 for MySQL 5.1. As a consequence, Django 1.8 sets 5.5 as the
 minimum MySQL version it officially supports.
 
 Support for Oracle versions older than 11.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 The end of upstream support periods was reached in July 2010 for Oracle 9.2,
 January 2012 for Oracle 10.1, and July 2013 for Oracle 10.2. As a consequence,
 Django 1.8 sets 11.1 as the minimum Oracle version it officially supports.
 
 Specific privileges used instead of roles for tests on Oracle
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------
 
 Earlier versions of Django granted the CONNECT and RESOURCE roles to the test
 user on Oracle. These roles have been deprecated, so Django 1.8 uses the
@@ -868,7 +868,7 @@ creating a test user). The exact privileges required now are detailed in
 :ref:`Oracle notes <oracle-notes>`.
 
 ``AbstractUser.last_login`` allows null values
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 The :attr:`AbstractUser.last_login <django.contrib.auth.models.User.last_login>`
 field now allows null values. Previously, it defaulted to the time when the user
@@ -892,7 +892,7 @@ for users who haven't logged in, you can run this query::
         ).update(last_login=None)
 
 :mod:`django.contrib.gis`
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 * Support for GEOS 3.1 and GDAL 1.6 has been dropped.
 
@@ -908,7 +908,7 @@ for users who haven't logged in, you can run this query::
   contain the SRID value of geometry objects.
 
 Priority of context processors for ``TemplateResponse`` brought in line with ``render``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------------------
 
 The :class:`~django.template.response.TemplateResponse` constructor is designed to be a
 drop-in replacement for the :func:`~django.shortcuts.render` function. However,
@@ -922,7 +922,7 @@ in the view. If you were relying on the fact context data in a
 need to change your code.
 
 Overriding ``setUpClass`` / ``tearDownClass`` in test cases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------
 
 The decorators :func:`~django.test.override_settings` and
 :func:`~django.test.modify_settings` now act at the class level when used as
@@ -930,7 +930,7 @@ class decorators. As a consequence, when overriding ``setUpClass()`` or
 ``tearDownClass()``, the ``super`` implementation should always be called.
 
 Removal of ``django.contrib.formtools``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 The formtools contrib app has been moved to a separate package and the
 relevant documentation pages have been updated or removed.
@@ -940,7 +940,7 @@ The new package is available `on GitHub`_ and on PyPI.
 .. _on GitHub: https://github.com/django/django-formtools/
 
 Database connection reloading between tests
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 Django previously closed database connections between each test within a
 ``TestCase``. This is no longer the case as Django now wraps the whole
@@ -948,7 +948,7 @@ Django previously closed database connections between each test within a
 behavior, you should have them inherit from ``TransactionTestCase`` instead.
 
 Cleanup of the ``django.template`` namespace
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 If you've been relying on private APIs exposed in the ``django.template``
 module, you may have to import them from ``django.template.base`` instead.
@@ -958,7 +958,7 @@ Also private APIs ``django.template.base.compile_string()``,
 ``django.template.loader.get_template_from_string()`` were removed.
 
 ``model`` attribute on private model relations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------
 
 In earlier versions of Django, on a model with a reverse foreign key
 relationship (for example), ``model._meta.get_all_related_objects()`` returned
@@ -996,7 +996,7 @@ Also note that ``get_all_related_objects()`` is deprecated in 1.8. See the
 :ref:`upgrade guide <migrating-old-meta-api>` for the new API.
 
 Database backend API
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 The following changes to the database backend API are documented to assist
 those writing third-party backends in updating their code:
@@ -1025,7 +1025,7 @@ those writing third-party backends in updating their code:
   ``timedelta`` parameter.
 
 :mod:`django.contrib.admin`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 * ``AdminSite`` no longer takes an ``app_name`` argument and its ``app_name``
   attribute has been removed. The application name is always ``admin`` (as
@@ -1042,7 +1042,7 @@ those writing third-party backends in updating their code:
   identifier used to retrieve the object before deletion.
 
 Default autoescaping of functions in ``django.template.defaultfilters``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------------
 
 In order to make built-in template filters that output HTML "safe by default"
 when calling them in Python code, the following functions in
@@ -1062,7 +1062,7 @@ are passing trusted content. This change doesn't have any effect when using
 the corresponding filters in templates.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * ``connections.queries`` is now a read-only attribute.
 
@@ -1209,7 +1209,7 @@ Features deprecated in 1.8
 ==========================
 
 Selected methods in ``django.db.models.options.Options``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------------
 
 As part of the formalization of the ``Model._meta`` API (from the
 :class:`django.db.models.options.Options` class), a number of methods have been
@@ -1229,7 +1229,7 @@ A :ref:`migration guide <migrating-old-meta-api>` has been provided to assist
 in converting your code from the old API to the new, official API.
 
 Loading ``cycle`` and ``firstof`` template tags from ``future`` library
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------------
 
 Django 1.6 introduced ``{% load cycle from future %}`` and
 ``{% load firstof from future %}`` syntax for forward compatibility of the
@@ -1238,7 +1238,7 @@ and will be removed in Django 1.10. You can simply remove the
 ``{% load ... from future %}`` tags.
 
 ``django.conf.urls.patterns()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 In the olden days of Django, it was encouraged to reference views as strings
 in ``urlpatterns``::
@@ -1290,14 +1290,14 @@ Updating your code is as simple as ensuring that ``urlpatterns`` is a list of
     ]
 
 Passing a string as ``view`` to :func:`~django.conf.urls.url`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------
 
 Related to the previous item, referencing views as strings in the ``url()``
 function is deprecated. Pass the callable view as described in the previous
 section instead.
 
 Template-related settings
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 As a consequence of the multiple template engines refactor, several settings
 are deprecated in favor of :setting:`TEMPLATES`:
@@ -1310,13 +1310,13 @@ are deprecated in favor of :setting:`TEMPLATES`:
 * ``TEMPLATE_STRING_IF_INVALID``
 
 ``django.core.context_processors``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Built-in template context processors have been moved to
 ``django.template.context_processors``.
 
 ``django.test.SimpleTestCase.urls``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 The attribute :attr:`SimpleTestCase.urls <django.test.SimpleTestCase.urls>`
 for specifying URLconf configuration in tests has been deprecated and will be
@@ -1324,20 +1324,22 @@ removed in Django 1.10. Use :func:`@override_settings(ROOT_URLCONF=...)
 <django.test.override_settings>` instead.
 
 ``prefix`` argument to :func:`~django.conf.urls.i18n.i18n_patterns`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 Related to the previous item, the ``prefix`` argument to
 :func:`django.conf.urls.i18n.i18n_patterns` has been deprecated. Simply pass a
 list of :func:`django.conf.urls.url` instances instead.
 
 Using an incorrect count of unpacked values in the :ttag:`for` template tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------
 
 Using an incorrect count of unpacked values in :ttag:`for` tag will raise an
 exception rather than fail silently in Django 1.10.
 
 Passing a dotted path to :func:`~django.core.urlresolvers.reverse()` and :ttag:`url`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Passing a dotted path to ``reverse()`` and :ttag:`url`
+------------------------------------------------------
 
 Reversing URLs by Python path is an expensive operation as it causes the
 path being reversed to be imported. This behavior has also resulted in a
@@ -1360,7 +1362,7 @@ or ``name='django.contrib.gis.sitemaps.views.kmz'``.
 .. _security issue: https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse
 
 Aggregate methods and modules
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 The ``django.db.models.sql.aggregates`` and
 ``django.contrib.gis.db.models.sql.aggregates`` modules (both private API), have
@@ -1383,7 +1385,7 @@ in Django 1.10:
 * ``Query.append_aggregate_mask()``, replaced by ``append_annotation_mask()``.
 
 Extending management command arguments through ``Command.option_list``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------
 
 Management commands now use :py:mod:`argparse` instead of :py:mod:`optparse` to
 parse command-line arguments passed to commands. This also means that the way
@@ -1394,21 +1396,21 @@ arguments through ``argparse.add_argument()``. See
 :ref:`this example <custom-commands-options>` for more details.
 
 ``django.core.management.NoArgsCommand``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 The class :class:`~django.core.management.NoArgsCommand` is now deprecated and
 will be removed in Django 1.10. Use :class:`~django.core.management.BaseCommand`
 instead, which takes no arguments by default.
 
 Listing all migrations in a project
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------
 
 The ``--list`` option of the :djadmin:`migrate` management command is
 deprecated and will be removed in Django 1.10. Use :djadmin:`showmigrations`
 instead.
 
 ``cache_choices`` option of ``ModelChoiceField`` and ``ModelMultipleChoiceField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------------
 
 :class:`~django.forms.ModelChoiceField` and
 :class:`~django.forms.ModelMultipleChoiceField` took an undocumented, untested
@@ -1417,27 +1419,27 @@ the same ``Form`` object. This option is subject to an accelerated deprecation
 and will be removed in Django 1.9.
 
 ``django.template.resolve_variable()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 The function has been informally marked as "Deprecated" for some time. Replace
 ``resolve_variable(path, context)`` with
 ``django.template.Variable(path).resolve(context)``.
 
 ``django.contrib.webdesign``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 It provided the :ttag:`lorem` template tag which is now included in the
 built-in tags. Simply remove ``'django.contrib.webdesign'`` from
 :setting:`INSTALLED_APPS` and ``{% load webdesign %}`` from your templates.
 
 ``error_message`` argument to ``django.forms.RegexField``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------
 
 It provided backwards compatibility for pre-1.0 code, but its functionality is
 redundant. Use ``Field.error_messages['invalid']`` instead.
 
 Old :tfilter:`unordered_list` syntax
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------
 
 An older (pre-1.0), more restrictive and verbose input format for the
 :tfilter:`unordered_list` template filter has been deprecated::
@@ -1449,13 +1451,13 @@ Using the new syntax, this becomes::
     ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``
 
 ``django.forms.Field._has_changed()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 Rename this method to :meth:`~django.forms.Field.has_changed` by removing the
 leading underscore. The old name will still work until Django 1.10.
 
 ``django.utils.html.remove_tags()`` and ``removetags`` template filter
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------
 
 ``django.utils.html.remove_tags()`` as well as the template filter
 ``removetags`` have been deprecated as they cannot guarantee safe output. Their
@@ -1466,12 +1468,12 @@ The unused and undocumented ``django.utils.html.strip_entities()`` function has
 also been deprecated.
 
 ``is_admin_site`` argument to ``django.contrib.auth.views.password_reset()``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------------
 
 It's a legacy option that should no longer be necessary.
 
 ``SubfieldBase``
-~~~~~~~~~~~~~~~~
+----------------
 
 ``django.db.models.fields.subclassing.SubfieldBase`` has been deprecated and
 will be removed in Django 1.10. Historically, it was used to handle fields where
@@ -1482,7 +1484,7 @@ not call the :meth:`~django.db.models.Field.to_python` method on assignment
 as was the case with ``SubfieldBase``.
 
 ``django.utils.checksums``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 The ``django.utils.checksums`` module has been deprecated and will be removed
 in Django 1.10. The functionality it provided (validating checksum using the
@@ -1492,7 +1494,7 @@ moved to the `django-localflavor`_ package (version 1.1+).
 .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor
 
 ``InlineAdminForm.original_content_type_id``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 The ``original_content_type_id`` attribute on ``InlineAdminForm`` has been
 deprecated and will be removed in Django 1.10. Historically, it was used
@@ -1500,14 +1502,14 @@ to construct the "view on site" URL. This URL is now accessible using the
 ``absolute_url`` attribute of the form.
 
 ``django.views.generic.edit.FormMixin.get_form()``’s ``form_class`` argument
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------------------
 
 ``FormMixin`` subclasses that override the ``get_form()`` method should make
 sure to provide a default value for the ``form_class`` argument since it's
 now optional.
 
 Rendering templates loaded by :func:`~django.template.loader.get_template()` with a :class:`~django.template.Context`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------------------------------------------------
 
 The return type of :func:`~django.template.loader.get_template()` has changed
 in Django 1.8: instead of a :class:`django.template.Template`, it returns a
@@ -1524,7 +1526,7 @@ Since it's easier to understand with examples, the :ref:`upgrade guide
 All this also applies to :func:`~django.template.loader.select_template()`.
 
 :class:`~django.template.Template` and :class:`~django.template.Context` classes in template responses
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------------------------------------------
 
 Some methods of :class:`~django.template.response.SimpleTemplateResponse` and
 :class:`~django.template.response.TemplateResponse` accepted
@@ -1539,7 +1541,7 @@ Check the :doc:`template response API documentation </ref/template-response>`
 for details.
 
 ``current_app`` argument of template-related APIs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 The following functions and classes will no longer accept a ``current_app``
 parameter to set an URL namespace in Django 1.10:
@@ -1554,7 +1556,7 @@ to these functions or classes. If you're using a plain ``Context``, use a
 ``RequestContext`` instead.
 
 ``dictionary`` and ``context_instance`` arguments of rendering functions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------------
 
 The following functions will no longer accept the ``dictionary`` and
 ``context_instance`` parameters in Django 1.10:
@@ -1585,7 +1587,7 @@ becomes::
     render(request, 'template.html', {...})
 
 ``dirs`` argument of template-finding functions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 The following functions will no longer accept a ``dirs`` parameter to override
 ``TEMPLATE_DIRS`` in Django 1.10:
@@ -1599,14 +1601,14 @@ The parameter didn't work consistently across different template loaders and
 didn't work for included templates.
 
 ``django.template.loader.BaseLoader``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 ``django.template.loader.BaseLoader`` was renamed to
 ``django.template.loaders.base.Loader``. If you've written a custom template
 loader that inherits ``BaseLoader``, you must inherit ``Loader`` instead.
 
 ``django.test.utils.TestTemplateLoader``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------
 
 Private API ``django.test.utils.TestTemplateLoader`` is deprecated in favor of
 ``django.template.loaders.locmem.Loader`` and will be removed in Django 1.9.
@@ -1614,7 +1616,7 @@ Private API ``django.test.utils.TestTemplateLoader`` is deprecated in favor of
 .. _storage-max-length-update:
 
 Support for the ``max_length`` argument on custom ``Storage`` classes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------
 
 ``Storage`` subclasses should add ``max_length=None`` as a parameter to
 :meth:`~django.core.files.storage.Storage.get_available_name` and/or
@@ -1623,7 +1625,7 @@ Support for storages that do not accept this argument will be removed in
 Django 1.10.
 
 ``qn`` replaced by ``compiler``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 In previous Django versions, various internal ORM methods (mostly ``as_sql``
 methods) accepted a ``qn`` (for "quote name") argument, which was a reference
@@ -1637,14 +1639,14 @@ deprecated: you should rename your ``qn`` arguments to ``compiler``, and call
 ``qn(...)``.
 
 Default value of ``RedirectView.permanent``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 The default value of the
 :attr:`RedirectView.permanent <django.views.generic.base.RedirectView.permanent>`
 attribute will change from ``True`` to ``False`` in Django 1.9.
 
 Using ``AuthenticationMiddleware`` without ``SessionAuthenticationMiddleware``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------------------------------
 
 :class:`django.contrib.auth.middleware.SessionAuthenticationMiddleware` was
 added in Django 1.7. In Django 1.7.2, its functionality was moved to
@@ -1659,14 +1661,14 @@ to your ``MIDDLEWARE_CLASSES`` sometime before then to opt-in. Please read the
 :ref:`upgrade considerations <session-invalidation-on-password-change>` first.
 
 ``django.contrib.sitemaps.FlatPageSitemap``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 ``django.contrib.sitemaps.FlatPageSitemap`` has moved to
 ``django.contrib.flatpages.sitemaps.FlatPageSitemap``. The old import location
 is deprecated and will be removed in Django 1.9.
 
 Model ``Field.related``
-~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------
 
 Private attribute ``django.db.models.Field.related`` is deprecated in favor
 of ``Field.rel``.  The latter is an instance of
@@ -1676,7 +1678,7 @@ module has been removed and the ``Field.related`` attribute will be removed in
 Django 1.10.
 
 ``ssi`` template tag
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 The :ttag:`ssi` template tag allows files to be included in a template by
 absolute path. This is of limited use in most deployment situations, and
@@ -1684,20 +1686,20 @@ the :ttag:`include` tag often makes more sense. This tag is now deprecated and
 will be removed in Django 1.10.
 
 ``=`` as comparison operator in ``if`` template tag
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 Using a single equals sign with the ``{% if %}`` template tag for equality
 testing was undocumented and untested. It's now deprecated in favor of ``==``.
 
 ``%(<foo>)s`` syntax in ``ModelFormMixin.success_url``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------
 
 The legacy ``%(<foo>)s`` syntax in :attr:`ModelFormMixin.success_url
 <django.views.generic.edit.ModelFormMixin.success_url>` is deprecated and
 will be removed in Django 1.10.
 
 ``GeoQuerySet`` aggregate methods
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The ``collect()``, ``extent()``, ``extent3d()``, ``make_line()``, and
 ``unionagg()`` aggregate methods are deprecated and should be replaced by their
@@ -1707,7 +1709,7 @@ function-based aggregate equivalents (``Collect``, ``Extent``, ``Extent3D``,
 .. _deprecated-signature-of-allow-migrate:
 
 Signature of the ``allow_migrate`` router method
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 The signature of the :meth:`allow_migrate` method of database routers has
 changed from ``allow_migrate(db, model)`` to
diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt
index 2c1a4b0d22..039171634c 100644
--- a/docs/releases/1.9.txt
+++ b/docs/releases/1.9.txt
@@ -29,7 +29,7 @@ What's new in Django 1.9
 ========================
 
 Performing actions after a transaction commit
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 The new :func:`~django.db.transaction.on_commit` hook allows performing actions
 after a database transaction is successfully committed. This is useful for
@@ -42,7 +42,7 @@ integrated into Django.
 .. _django-transaction-hooks: https://pypi.python.org/pypi/django-transaction-hooks
 
 Password validation
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 Django now offers password validation to help prevent the usage of weak
 passwords by users. The validation is integrated in the included password
@@ -82,7 +82,7 @@ the included auth forms for your project, you could set, for example::
 See :ref:`password-validation` for more details.
 
 Permission mixins for class-based views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------
 
 Django now ships with the mixins
 :class:`~django.contrib.auth.mixins.AccessMixin`,
@@ -119,7 +119,7 @@ though:
 .. _django-braces: http://django-braces.readthedocs.org/en/latest/index.html
 
 New styling for ``contrib.admin``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The admin sports a modern, flat design with new SVG icons which look perfect
 on HiDPI screens. It still provides a fully-functional experience to `YUI's
@@ -129,7 +129,7 @@ degradation.
 .. _YUI's A-grade: https://github.com/yui/yui3/wiki/Graded-Browser-Support
 
 Running tests in parallel
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 The :djadmin:`test` command now supports a :djadminopt:`--parallel` option to
 run a project's tests in multiple processes in parallel.
@@ -144,10 +144,10 @@ This option is enabled by default for Django's own test suite provided:
 - the database backend supports it (all the built-in backends but Oracle)
 
 Minor features
-~~~~~~~~~~~~~~
+--------------
 
 :mod:`django.contrib.admin`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Admin views now have ``model_admin`` or ``admin_site`` attributes.
 
@@ -185,13 +185,13 @@ Minor features
 * JavaScript slug generation now supports Romanian characters.
 
 :mod:`django.contrib.admindocs`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The model section of the ``admindocs`` now also describes methods that take
   arguments, rather than ignoring them.
 
 :mod:`django.contrib.auth`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The default iteration count for the PBKDF2 password hasher has been increased
   by 20%. This backwards compatible change will not affect users who have
@@ -219,14 +219,14 @@ Minor features
   ``extra_email_context`` parameter.
 
 :mod:`django.contrib.contenttypes`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * It's now possible to use
   :attr:`~django.db.models.Options.order_with_respect_to` with a
   ``GenericForeignKey``.
 
 :mod:`django.contrib.gis`
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * All ``GeoQuerySet`` methods have been deprecated and replaced by
   :doc:`equivalent database functions </ref/contrib/gis/functions>`. As soon
@@ -256,7 +256,7 @@ Minor features
   MaxMind's GeoLite2 databases which includes support for IPv6 addresses.
 
 :mod:`django.contrib.postgres`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Added support for the :lookup:`rangefield.contained_by` lookup for some built
   in fields which correspond to the range fields.
@@ -269,7 +269,7 @@ Minor features
   function.
 
 :mod:`django.contrib.sessions`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * The session model and ``SessionStore`` classes for the ``db`` and
   ``cached_db`` backends are refactored to allow a custom database session
@@ -277,7 +277,7 @@ Minor features
   :ref:`extending-database-backed-session-engines` for more details.
 
 :mod:`django.contrib.sites`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * :func:`~django.contrib.sites.shortcuts.get_current_site` now handles the case
   where ``request.get_host()`` returns ``domain:port``, e.g.
@@ -286,14 +286,14 @@ Minor features
   lookup is retried with the domain part only.
 
 :mod:`django.contrib.syndication`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 * Support for multiple enclosures per feed item has been added. If multiple
   enclosures are defined on a RSS feed, an exception is raised as RSS feeds,
   unlike Atom feeds, do not support multiple enclosures per feed item.
 
 Cache
-^^^^^
+~~~~~
 
 * ``django.core.cache.backends.base.BaseCache`` now has a ``get_or_set()``
   method.
@@ -303,7 +303,7 @@ Cache
   to better prevent caching. This was also added in Django 1.8.8.
 
 CSRF
-^^^^
+~~~~
 
 * The request header's name used for CSRF authentication can be customized
   with :setting:`CSRF_HEADER_NAME`.
@@ -316,14 +316,14 @@ CSRF
   cross-origin unsafe requests (e.g. ``POST``) over HTTPS.
 
 Database backends
-^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~
 
 * The PostgreSQL backend (``django.db.backends.postgresql_psycopg2``) is also
   available as ``django.db.backends.postgresql``. The old name will continue to
   be available for backwards compatibility.
 
 File Storage
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 * :meth:`Storage.get_valid_name()
   <django.core.files.storage.Storage.get_valid_name>` is now called when
@@ -333,7 +333,7 @@ File Storage
   Python 3.
 
 Forms
-^^^^^
+~~~~~
 
 * :class:`~django.forms.ModelForm` accepts the new ``Meta`` option
   ``field_classes`` to customize the type of the fields. See
@@ -365,7 +365,7 @@ Forms
   :meth:`~django.forms.Field.get_bound_field()` method.
 
 Generic Views
-^^^^^^^^^^^^^
+~~~~~~~~~~~~~
 
 * Class-based views generated using ``as_view()`` now have ``view_class``
   and ``view_initkwargs`` attributes.
@@ -375,7 +375,7 @@ Generic Views
   of methods <decorating-class-based-views>`.
 
 Internationalization
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 * The :func:`django.views.i18n.set_language` view now properly redirects to
   :ref:`translated URLs <url-internationalization>`, when available.
@@ -411,7 +411,7 @@ Internationalization
 * Two new languages are available: Colombian Spanish and Scottish Gaelic.
 
 Management Commands
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 * The new :djadmin:`sendtestemail` command lets you send a test email to
   easily confirm that email sending through Django is working.
@@ -444,7 +444,7 @@ Management Commands
   ``--no-input`` as an alias for that option.
 
 Migrations
-^^^^^^^^^^
+~~~~~~~~~~
 
 * Initial migrations are now marked with an :attr:`initial = True
   <django.db.migrations.Migration.initial>` class attribute which allows
@@ -476,7 +476,7 @@ Migrations
   migration from which migrations will be squashed.
 
 Models
-^^^^^^
+~~~~~~
 
 * :meth:`QuerySet.bulk_create() <django.db.models.query.QuerySet.bulk_create>`
   now works on proxy models.
@@ -548,7 +548,7 @@ Models
   ``bulk_create()``.
 
 Requests and Responses
-^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~
 
 * Unless :attr:`HttpResponse.reason_phrase
   <django.http.HttpResponse.reason_phrase>` is explicitly set, it now is
@@ -592,7 +592,7 @@ Requests and Responses
   the requested URL.
 
 Templates
-^^^^^^^^^
+~~~~~~~~~
 
 * Template tags created with the :meth:`~django.template.Library.simple_tag`
   helper can now store results in a template variable by using the ``as``
@@ -636,7 +636,7 @@ Templates
   rendering, speeding up reuse in places such as for loops.
 
 Tests
-^^^^^
+~~~~~
 
 * Added the :meth:`json() <django.test.Response.json>` method to test client
   responses to give access to the response body as JSON.
@@ -647,7 +647,7 @@ Tests
   :meth:`~django.test.Client.login()`.
 
 URLs
-^^^^
+~~~~
 
 * Regular expression lookaround assertions are now allowed in URL patterns.
 
@@ -659,7 +659,7 @@ URLs
 * System checks have been added for common URL pattern mistakes.
 
 Validators
-^^^^^^^^^^
+~~~~~~~~~~
 
 * Added :func:`django.core.validators.int_list_validator` to generate
   validators of strings containing integers separated with a custom character.
@@ -682,7 +682,7 @@ Backwards incompatible changes in 1.9
     may appear as a backwards incompatible change.
 
 Database backend API
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 * A couple of new tests rely on the ability of the backend to introspect column
   defaults (returning the result as ``Field.default``). You can set the
@@ -727,13 +727,13 @@ Database backend API
   ``DatabaseCreation.get_test_db_clone_settings()``.
 
 Default settings that were tuples are now lists
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 The default settings in ``django.conf.global_settings`` were a combination of
 lists and tuples. All settings that were formerly tuples are now lists.
 
 ``is_usable`` attribute on template loaders is removed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------------
 
 Django template loaders previously required an ``is_usable`` attribute to be
 defined. If a loader was configured in the template settings and this attribute
@@ -743,7 +743,7 @@ attribute is now removed and the egg loader instead fails at runtime if
 setuptools is not installed.
 
 Related set direct assignment
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 :ref:`Direct assignment <direct-assignment>` of related objects in the ORM used
 to perform a ``clear()`` followed by a call to ``add()``. This caused
@@ -763,7 +763,7 @@ assignment for many-to-many relations and as a consequence now use the new
 behavior.
 
 Filesystem-based template loaders catch more specific exceptions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------------
 
 When using the :class:`filesystem.Loader <django.template.loaders.filesystem.Loader>`
 or :class:`app_directories.Loader <django.template.loaders.app_directories.Loader>`
@@ -776,7 +776,7 @@ does not exist. All other situations result in the original ``IOError`` being
 raised.
 
 HTTP redirects no longer forced to absolute URIs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------------
 
 Relative redirects are no longer converted to absolute URIs. :rfc:`2616`
 required the ``Location`` header in redirect responses to be an absolute URI,
@@ -791,19 +791,19 @@ replaced by ``self.assertRedirects(response, '/some-url/')`` (unless the
 redirection specifically contained an absolute URL, of course).
 
 Dropped support for PostgreSQL 9.0
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 Upstream support for PostgreSQL 9.0 ended in September 2015. As a consequence,
 Django 1.9 sets 9.1 as the minimum PostgreSQL version it officially supports.
 
 Dropped support for Oracle 11.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Upstream support for Oracle 11.1 ended in August 2015. As a consequence, Django
 1.9 sets 11.2 as the minimum Oracle version it officially supports.
 
 Bulk behavior of ``add()`` method of related managers
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------
 
 To improve performance, the ``add()`` methods of the related managers created
 by ``ForeignKey`` and ``GenericForeignKey`` changed from a series of
@@ -812,7 +812,7 @@ that ``pre_save`` and ``post_save`` signals aren't sent anymore. You can use
 the ``bulk=False`` keyword argument to revert to the previous behavior.
 
 Template ``LoaderOrigin`` and ``StringOrigin`` are removed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------------------------------
 
 In previous versions of Django, when a template engine was initialized with
 debug as ``True``, an instance of ``django.template.loader.LoaderOrigin`` or
@@ -826,7 +826,7 @@ Django 2.0.
 .. _default-logging-changes-19:
 
 Changes to the default logging configuration
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------
 
 To make it easier to write custom logging configurations, Django's default
 logging configuration no longer defines 'django.request' and 'django.security'
@@ -845,7 +845,7 @@ If you are overriding Django's default logging, you should check to see how
 your configuration merges with the new defaults.
 
 ``HttpRequest`` details in error reporting
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 It was redundant to display the full details of the
 :class:`~django.http.HttpRequest` each time it appeared as a stack frame
@@ -860,7 +860,7 @@ traceback of the same structure as in the case of AJAX requests. The traceback
 details are rendered by the ``ExceptionReporter.get_traceback_text()`` method.
 
 Removal of time zone aware global adapters and converters for datetimes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------------------
 
 Django no longer registers global adapters and converters for managing time
 zone information on :class:`~datetime.datetime` values sent to the database as
@@ -895,7 +895,7 @@ even if you're using :meth:`raw() <django.db.models.query.QuerySet.raw>`
 queries. The ORM takes care of managing time zone information.
 
 Template tag modules are imported when templates are configured
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------
 
 The :class:`~django.template.backends.django.DjangoTemplates` backend now
 performs discovery on installed template tag modules when instantiated. This
@@ -907,7 +907,7 @@ rather than when a template with a :ttag:`{% load %}<load>` tag is first
 compiled.
 
 ``django.template.base.add_to_builtins()`` is removed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------
 
 Although it was a private API, projects commonly used ``add_to_builtins()`` to
 make template tags and filters available without using the
@@ -919,7 +919,7 @@ define built-in libraries via the ``'builtins'`` key of :setting:`OPTIONS
 .. _simple-tag-conditional-escape-fix:
 
 ``simple_tag`` now wraps tag output in ``conditional_escape``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------
 
 In general, template tags do not autoescape their contents, and this behavior is
 :ref:`documented <tags-auto-escaping>`. For tags like
@@ -960,7 +960,7 @@ Tags that follow these rules will be correct and safe whether they are run on
 Django 1.9+ or earlier.
 
 ``Paginator.page_range``
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 :attr:`Paginator.page_range <django.core.paginator.Paginator.page_range>` is
 now an iterator instead of a list.
@@ -973,7 +973,7 @@ Existing code that depends on ``list`` specific features, such as indexing,
 can be ported by converting the iterator into a ``list`` using ``list()``.
 
 Implicit ``QuerySet`` ``__in`` lookup removed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 In earlier versions, queries such as::
 
@@ -991,7 +991,7 @@ subquery returns multiple results, at least some databases will throw an error.
 .. _admin-browser-support-19:
 
 ``contrib.admin`` browser support
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 The admin no longer supports Internet Explorer 8 and below, as these browsers
 have reached end-of-life.
@@ -1014,7 +1014,7 @@ a Django application with this structure::
 .. _syntax-error-old-setuptools-django-19:
 
 ``SyntaxError`` when installing Django setuptools 5.5.x
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------
 
 When installing Django 1.9+ with setuptools 5.5.x, you'll see::
 
@@ -1036,7 +1036,7 @@ using pip, you can upgrade pip using ``pip install -U pip`` which will also
 upgrade setuptools.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * The jQuery static files in ``contrib.admin`` have been moved into a
   ``vendor/jquery`` subdirectory.
@@ -1159,7 +1159,7 @@ Features deprecated in 1.9
 ==========================
 
 ``assignment_tag()``
-~~~~~~~~~~~~~~~~~~~~
+--------------------
 
 Django 1.4 added the ``assignment_tag`` helper to ease the creation of
 template tags that store results in a template variable. The
@@ -1168,7 +1168,7 @@ ability, making the ``assignment_tag`` obsolete. Tags that use
 ``assignment_tag`` should be updated to use ``simple_tag``.
 
 ``{% cycle %}`` syntax with comma-separated arguments
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------
 
 The :ttag:`cycle` tag supports an inferior old syntax from previous Django
 versions:
@@ -1181,7 +1181,7 @@ Its parsing caused bugs with the current syntax, so support for the old syntax
 will be removed in Django 1.10 following an accelerated deprecation.
 
 ``ForeignKey`` and ``OneToOneField`` ``on_delete`` argument
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------------------
 
 In order to increase awareness about cascading model deletion, the
 ``on_delete`` argument of ``ForeignKey`` and ``OneToOneField`` will be required
@@ -1194,7 +1194,7 @@ can also pass it as the second positional argument if you don't care about
 compatibility with older versions of Django.
 
 ``Field.rel`` changes
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 ``Field.rel`` and its methods and attributes have changed to match the related
 fields API. The ``Field.rel`` attribute is renamed to ``remote_field`` and many
@@ -1203,7 +1203,7 @@ of its methods and attributes are either changed or renamed.
 The aim of these changes is to provide a documented API for relation fields.
 
 ``GeoManager`` and ``GeoQuerySet`` custom methods
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------
 
 All custom ``GeoQuerySet`` methods (``area()``, ``distance()``, ``gml()``, ...)
 have been replaced by equivalent geographic expressions in annotations (see in
@@ -1213,7 +1213,7 @@ methods, you can simply remove the ``objects = GeoManager()`` lines from your
 models.
 
 Template loader APIs have changed
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 Django template loaders have been updated to allow recursive template
 extending. This change necessitated a new template loader API. The old
@@ -1222,7 +1222,7 @@ Details about the new API can be found :ref:`in the template loader
 documentation <custom-template-loaders>`.
 
 Passing a 3-tuple or an ``app_name`` to :func:`~django.conf.urls.include()`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------------------------------
 
 The instance namespace part of passing a tuple as an argument to ``include()``
 has been replaced by passing the ``namespace`` argument to ``include()``. For
@@ -1291,7 +1291,7 @@ is deprecated. Instead, pass ``admin.site.urls`` directly to
     ]
 
 URL application namespace required if setting an instance namespace
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------------------------------
 
 In the past, an instance namespace without an application namespace
 would serve the same purpose as the application namespace, but it was
@@ -1300,7 +1300,7 @@ with the same name. Includes that specify an instance namespace require that
 the included URLconf sets an application namespace.
 
 ``current_app`` parameter to ``contrib.auth`` views
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------------
 
 All views in ``django.contrib.auth.views`` have the following structure::
 
@@ -1318,14 +1318,14 @@ consistency, these views will require the caller to set ``current_app`` on the
 ``request`` instead of passing it in a separate argument.
 
 ``django.contrib.gis.geoip``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 The :mod:`django.contrib.gis.geoip2` module supersedes
 ``django.contrib.gis.geoip``. The new module provides a similar API except that
 it doesn't provide the legacy GeoIP-Python API compatibility methods.
 
 Miscellaneous
-~~~~~~~~~~~~~
+-------------
 
 * The ``weak`` argument to ``django.dispatch.signals.Signal.disconnect()`` has
   been deprecated as it has no effect.
diff --git a/docs/releases/security.txt b/docs/releases/security.txt
index f6f2534baa..cbd5585244 100644
--- a/docs/releases/security.txt
+++ b/docs/releases/security.txt
@@ -1,5 +1,3 @@
-.. _security-releases:
-
 ==========================
 Archive of security issues
 ==========================
@@ -40,24 +38,24 @@ security process in use. For these, new releases may not have been
 issued at the time and CVEs may not have been assigned.
 
 August 16, 2006 - CVE-2007-0404
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2007-0404 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-0404&cid=3>`_: Filename validation issue in translation framework. `Full description <https://www.djangoproject.com/weblog/2006/aug/16/compilemessages/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.90 `(patch) <https://github.com/django/django/commit/518d406e53>`__
 * Django 0.91 `(patch) <https://github.com/django/django/commit/518d406e53>`__
 * Django 0.95 `(patch) <https://github.com/django/django/commit/a132d411c6>`__ (released January 21 2007)
 
 January 21, 2007 - CVE-2007-0405
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2007-0405 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-0405&cid=3>`_: Apparent "caching" of authenticated user. `Full description <https://www.djangoproject.com/weblog/2007/jan/21/0951/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.95 `(patch) <https://github.com/django/django/commit/e89f0a6558>`__
 
@@ -68,179 +66,179 @@ All other security issues have been handled under versions of Django's
 security process. These are listed below.
 
 October 26, 2007 - CVE-2007-5712
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2007-5712 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-5712&cid=3>`_: Denial-of-service via arbitrarily-large ``Accept-Language`` header. `Full description <https://www.djangoproject.com/weblog/2007/oct/26/security-fix/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.91 `(patch) <https://github.com/django/django/commit/8bc36e726c9e8c75c681d3ad232df8e882aaac81>`__
 * Django 0.95 `(patch) <https://github.com/django/django/commit/412ed22502e11c50dbfee854627594f0e7e2c234>`__
 * Django 0.96 `(patch) <https://github.com/django/django/commit/7dd2dd08a79e388732ce00e2b5514f15bd6d0f6f>`__
 
 May 14, 2008 - CVE-2008-2302
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2008-2302 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-2302&cid=3>`_: XSS via admin login redirect. `Full description <https://www.djangoproject.com/weblog/2008/may/14/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.91 `(patch) <https://github.com/django/django/commit/50ce7fb57d>`__
 * Django 0.95 `(patch) <https://github.com/django/django/commit/50ce7fb57d>`__
 * Django 0.96 `(patch) <https://github.com/django/django/commit/7791e5c050>`__
 
 September 2, 2008 - CVE-2008-3909
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2008-3909 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2008-3909&cid=3>`_: CSRF via preservation of POST data during admin login. `Full description <https://www.djangoproject.com/weblog/2008/sep/02/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.91 `(patch) <https://github.com/django/django/commit/44debfeaa4473bd28872c735dd3d9afde6886752>`__
 * Django 0.95 `(patch) <https://github.com/django/django/commit/aee48854a164382c655acb9f18b3c06c3d238e81>`__
 * Django 0.96 `(patch) <https://github.com/django/django/commit/7e0972bded362bc4b851c109df2c8a6548481a8e>`__
 
 July 28, 2009 - CVE-2009-2659
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 `CVE-2009-2659 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2659&cid=3>`_: Directory-traversal in development server media handler. `Full description <https://www.djangoproject.com/weblog/2009/jul/28/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 0.96 `(patch) <https://github.com/django/django/commit/da85d76fd6>`__
 * Django 1.0 `(patch) <https://github.com/django/django/commit/df7f917b7f>`__
 
 October 9, 2009 - CVE-2009-3965
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2009-3965 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3695&cid=3>`_: Denial-of-service via pathological regular expression performance. `Full description <https://www.djangoproject.com/weblog/2009/oct/09/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.0 `(patch) <https://github.com/django/django/commit/594a28a904>`__
 * Django 1.1 `(patch) <https://github.com/django/django/commit/e3e992e18b>`__
 
 September 8, 2010 - CVE-2010-3082
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2010-3082 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3082&cid=3>`_: XSS via trusting unsafe cookie value. `Full description <https://www.djangoproject.com/weblog/2010/sep/08/security-release/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.2 `(patch) <https://github.com/django/django/commit/7f84657b6b>`__
 
 December 22, 2010 - CVE-2010-4534
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2010-4534 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4534&cid=3>`_: Information leakage in administrative interface. `Full description <https://www.djangoproject.com/weblog/2010/dec/22/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.1 `(patch) <https://github.com/django/django/commit/17084839fd>`__
 * Django 1.2 `(patch) <https://github.com/django/django/commit/85207a245b>`__
 
 December 22, 2010 - CVE-2010-4535
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2010-4535 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4535&cid=2>`_: Denial-of-service in password-reset mechanism. `Full description <https://www.djangoproject.com/weblog/2010/dec/22/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.1 `(patch) <https://github.com/django/django/commit/7f8dd9cbac>`__
 * Django 1.2 `(patch) <https://github.com/django/django/commit/d5d8942a16>`__
 
 February 8, 2011 - CVE-2011-0696
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2011-0696 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0696&cid=2>`_: CSRF via forged HTTP headers. `Full description <https://www.djangoproject.com/weblog/2011/feb/08/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.1 `(patch) <https://github.com/django/django/commit/408c5c873c>`__
 * Django 1.2 `(patch) <https://github.com/django/django/commit/818e70344e>`__
 
 February 8, 2011 - CVE-2011-0697
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2011-0697 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0697&cid=2>`_: XSS via unsanitized names of uploaded files. `Full description <https://www.djangoproject.com/weblog/2011/feb/08/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.1 `(patch) <https://github.com/django/django/commit/1966786d2d>`__
 * Django 1.2 `(patch) <https://github.com/django/django/commit/1f814a9547>`__
 
 February 8, 2011 - CVE-2011-0698
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2011-0698 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0698&cid=2>`_: Directory-traversal on Windows via incorrect path-separator handling. `Full description <https://www.djangoproject.com/weblog/2011/feb/08/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.1 `(patch) <https://github.com/django/django/commit/570a32a047>`__
 * Django 1.2 `(patch) <https://github.com/django/django/commit/194566480b>`__
 
 September 9, 2011 - CVE-2011-4136
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2011-4136 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4136&cid=2>`_: Session manipulation when using memory-cache-backed session. `Full description <https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.2 `(patch) <https://github.com/django/django/commit/ac7c3a110f>`__
 * Django 1.3 `(patch) <https://github.com/django/django/commit/fbe2eead2f>`__
 
 September 9, 2011 - CVE-2011-4137
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2011-4137 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4137&cid=2>`_: Denial-of-service via via ``URLField.verify_exists``. `Full description <https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.2 `(patch) <https://github.com/django/django/commit/7268f8af86>`__
 * Django 1.3 `(patch) <https://github.com/django/django/commit/1a76dbefdf>`__
 
 September 9, 2011 - CVE-2011-4138
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2011-4138 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4138&cid=2>`_: Information leakage/arbitrary request issuance via ``URLField.verify_exists``. `Full description <https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.2: `(patch) <https://github.com/django/django/commit/7268f8af86>`__
 * Django 1.3: `(patch) <https://github.com/django/django/commit/1a76dbefdf>`__
 
 September 9, 2011 - CVE-2011-4139
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2011-4139 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4139&cid=2>`_: ``Host`` header cache poisoning. `Full description <https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.2 `(patch) <https://github.com/django/django/commit/c613af4d64>`__
 * Django 1.3 `(patch) <https://github.com/django/django/commit/2f7fadc38e>`__
 
 September 9, 2011 - CVE-2011-4140
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2011-4140 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4140&cid=2>`_: Potential CSRF via ``Host`` header.  `Full description <https://www.djangoproject.com/weblog/2011/sep/09/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 This notification was an advisory only, so no patches were issued.
 
@@ -248,165 +246,165 @@ This notification was an advisory only, so no patches were issued.
 * Django 1.3
 
 July 30, 2012 - CVE-2012-3442
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 `CVE-2012-3442 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3442&cid=2>`_: XSS via failure to validate redirect scheme. `Full description <https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3: `(patch) <https://github.com/django/django/commit/4dea4883e6c50d75f215a6b9bcbd95273f57c72d>`__
 * Django 1.4: `(patch) <https://github.com/django/django/commit/e34685034b60be1112160e76091e5aee60149fa1>`__
 
 July 30, 2012 - CVE-2012-3443
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 `CVE-2012-3443 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3443&cid=2>`_: Denial-of-service via compressed image files. `Full description <https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3: `(patch) <https://github.com/django/django/commit/b2eb4787a0fff9c9993b78be5c698e85108f3446>`__
 * Django 1.4: `(patch) <https://github.com/django/django/commit/c14f325c4eef628bc7bfd8873c3a72aeb0219141>`__
 
 July 30, 2012 - CVE-2012-3444
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 `CVE-2012-3444 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-3444&cid=2>`_: Denial-of-service via large image files. `Full description <https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/9ca0ff6268eeff92d0d0ac2c315d4b6a8e229155>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/da33d67181b53fe6cc737ac1220153814a1509f6>`__
 
 October 17, 2012 - CVE-2012-4520
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2012-4520 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4520&cid=2>`_: ``Host`` header poisoning. `Full description <https://www.djangoproject.com/weblog/2012/oct/17/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/b45c377f8f488955e0c7069cad3f3dd21910b071>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/92d3430f12171f16f566c9050c40feefb830a4a3>`__
 
 December 10, 2012 - No CVE 1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Additional hardening of ``Host`` header handling. `Full description <https://www.djangoproject.com/weblog/2012/dec/10/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/2da4ace0bc1bc1d79bf43b368cb857f6f0cd6b1b>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/319627c184e71ae267d6b7f000e293168c7b6e09>`__
 
 December 10, 2012 - No CVE 2
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 Additional hardening of redirect validation. `Full description <https://www.djangoproject.com/weblog/2012/dec/10/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3: `(patch) <https://github.com/django/django/commit/1515eb46daa0897ba5ad5f0a2db8969255f1b343>`__
 * Django 1.4: `(patch) <https://github.com/django/django/commit/b2ae0a63aeec741f1e51bac9a95a27fd635f9652>`__
 
 February 19, 2013 - No CVE
-~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------
 
 Additional hardening of ``Host`` header handling. `Full description <https://www.djangoproject.com/weblog/2013/feb/19/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/27cd872e6e36a81d0bb6f5b8765a1705fecfc253>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/9936fdb11d0bbf0bd242f259bfb97bbf849d16f8>`__
 
 February 19, 2013 - CVE-2013-1664/1665
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------
 
 `CVE-2013-1664 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1664&cid=2>`_ and `CVE-2013-1665 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1665&cid=2>`_: Entity-based attacks against Python XML libraries. `Full description <https://www.djangoproject.com/weblog/2013/feb/19/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/d19a27066b2247102e65412aa66917aff0091112>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/1c60d07ba23e0350351c278ad28d0bd5aa410b40>`__
 
 February 19, 2013 - CVE-2013-0305
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2013-0305 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0305&cid=2>`_: Information leakage via admin history log.  `Full description <https://www.djangoproject.com/weblog/2013/feb/19/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/d3a45e10c8ac8268899999129daa27652ec0da35>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/0e7861aec73702f7933ce2a93056f7983939f0d6>`__
 
 February 19, 2013 - CVE-2013-0306
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2013-0306 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0306&cid=2>`_: Denial-of-service via formset ``max_num`` bypass. `Full description <https://www.djangoproject.com/weblog/2013/feb/19/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.3 `(patch) <https://github.com/django/django/commit/d7094bbce8cb838f3b40f504f198c098ff1cf727>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/0cc350a896f70ace18280410eb616a9197d862b0>`__
 
 August 13, 2013 - CVE-2013-4249
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2013-4249 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4249&cid=2>`_: XSS via admin trusting ``URLField`` values. `Full description <https://www.djangoproject.com/weblog/2013/aug/13/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.5 `(patch) <https://github.com/django/django/commit/90363e388c61874add3f3557ee654a996ec75d78>`__
 
 August 13, 2013 - CVE-2013-6044
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2013-6044 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-6044&cid=2>`_: Possible XSS via unvalidated URL redirect schemes. `Full description <https://www.djangoproject.com/weblog/2013/aug/13/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/ec67af0bd609c412b76eaa4cc89968a2a8e5ad6a>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/1a274ccd6bc1afbdac80344c9b6e5810c1162b5f>`__
 
 September 10, 2013 - CVE-2013-4315
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 `CVE-2013-4315 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4315&cid=2>`_ Directory-traversal via ``ssi`` template tag. `Full description <https://www.djangoproject.com/weblog/2013/sep/10/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/87d2750b39f6f2d54b7047225521a44dcd37e896>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/988b61c550d798f9a66d17ee0511fb7a9a7f33ca>`__
 
 September 14, 2013 - CVE-2013-1443
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 CVE-2013-1443: Denial-of-service via large passwords. `Full description <https://www.djangoproject.com/weblog/2013/sep/15/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch <https://github.com/django/django/commit/3f3d887a6844ec2db743fee64c9e53e04d39a368>`__ and `Python compatibility fix) <https://github.com/django/django/commit/6903d1690a92aa040adfb0c8eb37cf62e4206714>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/22b74fa09d7ccbc8c52270d648a0da7f3f0fa2bc>`__
 
 April 21, 2014 - CVE-2014-0472
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 `CVE-2014-0472 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0472&cid=2>`_: Unexpected code execution using ``reverse()``. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/c1a8c420fe4b27fb2caf5e46d23b5712fc0ac535>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/2a5bcb69f42b84464b24b5c835dca6467b6aa7f1>`__
@@ -414,12 +412,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/546740544d7f69254a67b06a3fc7fa0c43512958>`__
 
 April 21, 2014 - CVE-2014-0473
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 `CVE-2014-0473 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0473&cid=2>`_: Caching of anonymous pages could reveal CSRF token. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/1170f285ddd6a94a65f911a27788ba49ca08c0b0>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/6872f42757d7ef6a97e0b6ec5db4d2615d8a2bd8>`__
@@ -427,12 +425,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/380545bf85cbf17fc698d136815b7691f8d023ca>`__
 
 April 21, 2014 - CVE-2014-0474
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 `CVE-2014-0474 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0474&cid=2>`_: MySQL typecasting causes unexpected query results. `Full description <https://www.djangoproject.com/weblog/2014/apr/21/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/aa80f498de6d687e613860933ac58433ab71ea4b>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/985434fb1d6bf2335bf96c6ebf91c3674f1f399f>`__
@@ -440,12 +438,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/34526c2f56b863c2103655a0893ac801667e86ea>`__
 
 May 18, 2014 - CVE-2014-1418
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2014-1418 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1418&cid=2>`_: Caches may be allowed to store and serve private data. `Full description <https://www.djangoproject.com/weblog/2014/may/14/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/28e23306aa53bbbb8fb87db85f99d970b051026c>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/4001ec8698f577b973c5a540801d8a0bbea1205b>`__
@@ -453,12 +451,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/7fef18ba9e5a8b47bc24b5bb259c8bf3d3879f2a>`__
 
 May 18, 2014 - CVE-2014-3730
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2014-3730 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3730&cid=2>`_: Malformed URLs from user input incorrectly validated. `Full description <https://www.djangoproject.com/weblog/2014/may/14/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/7feb54bbae3f637ab3c4dd4831d4385964f574df>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/ad32c218850ad40972dcef57beb460f8c979dd6d>`__
@@ -466,12 +464,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/e7b0cace455c2da24492660636bfd48c45a19cdf>`__
 
 August 20, 2014 - CVE-2014-0480
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2014-0480 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0480&cid=2>`_: reverse() can generate URLs pointing to other hosts. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/c2fe73133b62a1d9e8f7a6b43966570b14618d7e>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/45ac9d4fb087d21902469fc22643f5201d41a0cd>`__
@@ -479,12 +477,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/bf650a2ee78c6d1f4544a875dcc777cf27fe93e9>`__
 
 August 20, 2014 - CVE-2014-0481
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2014-0481 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0481&cid=2>`_: File upload denial of service. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/30042d475bf084c6723c6217a21598d9247a9c41>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/26cd48e166ac4d84317c8ee6d63ac52a87e8da99>`__
@@ -492,12 +490,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/3123f8452cf49071be9110e277eea60ba0032216>`__
 
 August 20, 2014 - CVE-2014-0482
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2014-0482 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0482&cid=2>`_: RemoteUserMiddleware session hijacking. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/c9e3b9949cd55f090591fbdc4a114fcb8368b6d9>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/dd68f319b365f6cb38c5a6c106faf4f6142d7d88>`__
@@ -505,12 +503,12 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/1a45d059c70385fcd6f4a3955f3b4e4cc96d0150>`__
 
 August 20, 2014 - CVE-2014-0483
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 `CVE-2014-0483 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0483&cid=2>`_: Data leakage via querystring manipulation in admin. `Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/027bd348642007617518379f8b02546abacaa6e0>`__
 * Django 1.5 `(patch) <https://github.com/django/django/commit/2a446c896e7c814661fb9c4f212b071b2a7fa446>`__
@@ -518,94 +516,94 @@ Versions affected
 * Django 1.7 `(patch) <https://github.com/django/django/commit/2b31342cdf14fc20e07c43d258f1e7334ad664a6>`__
 
 January 13, 2015 - CVE-2015-0219
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2015-0219 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0219&cid=2>`_:
 WSGI header spoofing via underscore/dash conflation.
 `Full description <https://www.djangoproject.com/weblog/2015/jan/13/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/4f6fffc1dc429f1ad428ecf8e6620739e8837450>`__
 * Django 1.6 `(patch) <https://github.com/django/django/commit/d7597b31d5c03106eeba4be14a33b32a5e25f4ee>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/41b4bc73ee0da7b2e09f4af47fc1fd21144c710f>`__
 
 January 13, 2015 - CVE-2015-0220
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2015-0220 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0220&cid=2>`_: Mitigated possible XSS attack via user-supplied redirect URLs. `Full description <https://www.djangoproject.com/weblog/2015/jan/13/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/4c241f1b710da6419d9dca160e80b23b82db7758>`__
 * Django 1.6 `(patch) <https://github.com/django/django/commit/72e0b033662faa11bb7f516f18a132728aa0ae28>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/de67dedc771ad2edec15c1d00c083a1a084e1e89>`__
 
 January 13, 2015 - CVE-2015-0221
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2015-0221 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0221&cid=2>`_:
 Denial-of-service attack against ``django.views.static.serve()``.
 `Full description <https://www.djangoproject.com/weblog/2015/jan/13/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/d020da6646c5142bc092247d218a3d1ce3e993f7>`__
 * Django 1.6 `(patch) <https://github.com/django/django/commit/553779c4055e8742cc832ed525b9ee34b174934f>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/818e59a3f0fbadf6c447754d202d88df025f8f2a>`__
 
 January 13, 2015 - CVE-2015-0222
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 `CVE-2015-0222 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0222&cid=2>`_:
 Database denial-of-service with ``ModelMultipleChoiceField``.
 `Full description <https://www.djangoproject.com/weblog/2015/jan/13/security/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.6 `(patch) <https://github.com/django/django/commit/d7a06ee7e571b6dad07c0f5b519b1db02e2a476c>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/bcfb47780ce7caecb409a9e9c1c314266e41d392>`__
 
 March 9, 2015 - CVE-2015-2241
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 `CVE-2015-2241 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2241&cid=2>`_:
 XSS attack via properties in ``ModelAdmin.readonly_fields``.
 `Full description <https://www.djangoproject.com/weblog/2015/mar/09/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.7 `(patch) <https://github.com/django/django/commit/d16e4e1d6f95e6f46bff53cc4fd0ab398b8e5059>`__
 * Django 1.8 `(patch) <https://github.com/django/django/commit/2654e1b93923bac55f12b4e66c5e39b16695ace5>`_
 
 March 18, 2015 - CVE-2015-2316
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 `CVE-2015-2316 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2316&cid=2>`_:
 Denial-of-service possibility with ``strip_tags()``.
 `Full description <https://www.djangoproject.com/weblog/2015/mar/18/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.6 `(patch) <https://github.com/django/django/commit/b6b3cb9899214a23ebb0f4ebf0e0b300b0ee524f>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/e63363f8e075fa8d66326ad6a1cc3391cc95cd97>`__
 * Django 1.8 `(patch) <https://github.com/django/django/commit/5447709a571cd5d95971f1d5d21d4a7edcf85bbd>`__
 
 March 18, 2015 - CVE-2015-2317
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------
 
 `CVE-2015-2317 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-2317&cid=2>`_:
 Mitigated possible XSS attack via user-supplied redirect URLs.
 `Full description <https://www.djangoproject.com/weblog/2015/mar/18/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.4 `(patch) <https://github.com/django/django/commit/2342693b31f740a422abf7267c53b4e7bc487c1b>`__
 * Django 1.6 `(patch) <https://github.com/django/django/commit/5510f070711540aaa8d3707776cd77494e688ef9>`__
@@ -613,59 +611,59 @@ Versions affected
 * Django 1.8 `(patch) <https://github.com/django/django/commit/770427c2896a078925abfca2317486b284d22f04>`__
 
 May 20, 2015 - CVE-2015-3982
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2015-3982 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3982&cid=2>`_:
 Fixed session flushing in the cached_db backend.
 `Full description <https://www.djangoproject.com/weblog/2015/may/20/security-release/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/31cb25adecba930bdeee4556709f5a1c42d88fd6>`__
 
 July 8, 2015 - CVE-2015-5143
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2015-5143 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5143&cid=2>`_:
 Denial-of-service possibility by filling session store.
 `Full description <https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/66d12d1ababa8f062857ee5eb43276493720bf16>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/1828f4341ec53a8684112d24031b767eba557663>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/2e47f3e401c29bc2ba5ab794d483cb0820855fb9>`__
 
 July 8, 2015 - CVE-2015-5144
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2015-5144 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5144&cid=2>`_:
 Header injection possibility since validators accept newlines in input.
 `Full description <https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/574dd5e0b0fbb877ae5827b1603d298edc9bb2a0>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/ae49b4d994656bc037513dcd064cb9ce5bb85649>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/1ba1cdce7d58e6740fe51955d945b56ae51d072a>`__
 
 July 8, 2015 - CVE-2015-5145
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 `CVE-2015-5145 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5145&cid=2>`_:
 Denial-of-service possibility in URL validation.
 `Full description <https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/8f9a4d3a2bc42f14bb437defd30c7315adbff22c>`__
 
 August 18, 2015 - CVE-2015-5963/CVE-2015-5964
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------------------
 
 `CVE-2015-5963 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5963&cid=2>`_
 and
@@ -674,21 +672,21 @@ Denial-of-service possibility in ``logout()`` view by filling session store.
 `Full description <https://www.djangoproject.com/weblog/2015/aug/18/security-releases/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/2eb86b01d7b59be06076f6179a454d0fd0afaff6>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/2f5485346ee6f84b4e52068c04e043092daf55f7>`__
 * Django 1.4 `(patch) <https://github.com/django/django/commit/575f59f9bc7c59a5e41a081d1f5f55fc859c5012>`__
 
 November 24, 2015 - CVE-2015-8213
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 `CVE-2015-8213 <https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8213&cid=2>`_:
 Settings leak possibility in ``date`` template filter.
 `Full description <https://www.djangoproject.com/weblog/2015/nov/24/security-releases-issued/>`__
 
 Versions affected
------------------
+~~~~~~~~~~~~~~~~~
 
 * Django 1.8 `(patch) <https://github.com/django/django/commit/9f83fc2f66f5a0bac7c291aec55df66050bb6991>`__
 * Django 1.7 `(patch) <https://github.com/django/django/commit/8a01c6b53169ee079cb21ac5919fdafcc8c5e172>`__
diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt
index a4bb3a190a..0c3ac0b742 100644
--- a/docs/topics/class-based-views/generic-display.txt
+++ b/docs/topics/class-based-views/generic-display.txt
@@ -1,5 +1,3 @@
-.. _Generic views:
-
 ==================================
 Built-in class-based generic views
 ==================================
diff --git a/docs/topics/class-based-views/generic-editing.txt b/docs/topics/class-based-views/generic-editing.txt
index 4908d6a99e..a41895268e 100644
--- a/docs/topics/class-based-views/generic-editing.txt
+++ b/docs/topics/class-based-views/generic-editing.txt
@@ -1,3 +1,4 @@
+====================================
 Form handling with class-based views
 ====================================
 
@@ -13,7 +14,7 @@ this, Django provides a collection of generic class-based views for form
 processing.
 
 Basic Forms
------------
+===========
 
 Given a simple contact form:
 
@@ -60,7 +61,7 @@ Notes:
   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:`~django.forms.ModelForm`, so long as
@@ -190,7 +191,7 @@ Finally, we hook these new views into the URLconf:
     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:`~django.forms.ModelForm` to do this. First, add
@@ -233,7 +234,7 @@ alternatively handle unauthorized users in the
 :meth:`~django.views.generic.edit.ModelFormMixin.form_valid()`.
 
 AJAX example
-------------
+============
 
 Here is a simple example showing how you might go about implementing a form that
 works for AJAX requests as well as 'normal' form POSTs::
diff --git a/docs/topics/db/examples/many_to_many.txt b/docs/topics/db/examples/many_to_many.txt
index 79605ac158..4fcd36cbd6 100644
--- a/docs/topics/db/examples/many_to_many.txt
+++ b/docs/topics/db/examples/many_to_many.txt
@@ -1,6 +1,6 @@
-##########################
+==========================
 Many-to-many relationships
-##########################
+==========================
 
 .. highlight:: pycon
 
diff --git a/docs/topics/db/examples/many_to_one.txt b/docs/topics/db/examples/many_to_one.txt
index efa5c37f3b..dacc762702 100644
--- a/docs/topics/db/examples/many_to_one.txt
+++ b/docs/topics/db/examples/many_to_one.txt
@@ -1,6 +1,6 @@
-#########################
+=========================
 Many-to-one relationships
-#########################
+=========================
 
 To define a many-to-one relationship, use :class:`~django.db.models.ForeignKey`::
 
diff --git a/docs/topics/db/examples/one_to_one.txt b/docs/topics/db/examples/one_to_one.txt
index 8eb003b167..8d7fb7de26 100644
--- a/docs/topics/db/examples/one_to_one.txt
+++ b/docs/topics/db/examples/one_to_one.txt
@@ -1,6 +1,6 @@
-########################
+========================
 One-to-one relationships
-########################
+========================
 
 To define a one-to-one relationship, use :ref:`ref-onetoone`.
 
diff --git a/docs/topics/db/index.txt b/docs/topics/db/index.txt
index 5b45e36e7c..79624d7fdf 100644
--- a/docs/topics/db/index.txt
+++ b/docs/topics/db/index.txt
@@ -1,3 +1,4 @@
+====================
 Models and databases
 ====================
 
diff --git a/docs/topics/db/tablespaces.txt b/docs/topics/db/tablespaces.txt
index 8c60fd568e..6cda629254 100644
--- a/docs/topics/db/tablespaces.txt
+++ b/docs/topics/db/tablespaces.txt
@@ -14,7 +14,7 @@ A common paradigm for optimizing performance in database systems is the use of
 
 
 Declaring tablespaces for tables
---------------------------------
+================================
 
 A tablespace can be specified for the table generated by a model by supplying
 the :attr:`~django.db.models.Options.db_tablespace` option inside the model's
@@ -27,7 +27,7 @@ a tablespace for the built-in Django apps and other applications whose code you
 cannot control.
 
 Declaring tablespaces for indexes
----------------------------------
+=================================
 
 You can pass the :attr:`~django.db.models.Field.db_tablespace` option to a
 ``Field`` constructor to specify an alternate tablespace for the ``Field``’s
@@ -42,7 +42,7 @@ set :setting:`DEFAULT_INDEX_TABLESPACE`, the index is created in the same
 tablespace as the tables.
 
 An example
-----------
+==========
 
 .. code-block:: python
 
@@ -62,7 +62,7 @@ also generate an index, but no tablespace for it is specified, so it would be
 stored in the model tablespace ``tables`` by default.
 
 Database support
-----------------
+================
 
 PostgreSQL and Oracle support tablespaces. SQLite and MySQL don't.
 
diff --git a/docs/topics/external-packages.txt b/docs/topics/external-packages.txt
index 29a6c3dc41..e74274c0fd 100644
--- a/docs/topics/external-packages.txt
+++ b/docs/topics/external-packages.txt
@@ -7,7 +7,7 @@ problems (``contrib.*``). For easier maintenance and to trim the size of the
 codebase, a few of those applications have been moved out to separate projects.
 
 Localflavor
-~~~~~~~~~~~
+===========
 
 ``django-localflavor`` is a collection of utilities for particular countries
 and cultures.
@@ -17,7 +17,7 @@ and cultures.
 * `PyPI <https://pypi.python.org/pypi/django-localflavor>`__
 
 Comments
-~~~~~~~~
+========
 
 ``django-contrib-comments`` can be used to attach comments to any model, so you
 can use it for comments on blog entries, photos, book chapters, or anything
@@ -29,7 +29,7 @@ product like Disqus.
 * `PyPI <https://pypi.python.org/pypi/django-contrib-comments>`__
 
 Formtools
-~~~~~~~~~
+=========
 
 ``django-formtools`` is a collection of assorted utilities to work with forms.
 
diff --git a/docs/topics/forms/formsets.txt b/docs/topics/forms/formsets.txt
index 5620693582..1871c223ac 100644
--- a/docs/topics/forms/formsets.txt
+++ b/docs/topics/forms/formsets.txt
@@ -1,5 +1,4 @@
-.. _formsets:
-
+========
 Formsets
 ========
 
@@ -51,7 +50,7 @@ matching behavior.
 .. _formsets-initial-data:
 
 Using initial data with a formset
----------------------------------
+=================================
 
 Initial data is what drives the main usability of a formset. As shown above
 you can define the number of extra forms. What this means is that you are
@@ -88,7 +87,7 @@ list of dictionaries as the initial data.
 .. _formsets-max-num:
 
 Limiting the maximum number of forms
-------------------------------------
+====================================
 
 The ``max_num`` parameter to :func:`~django.forms.formsets.formset_factory`
 gives you the ability to limit the number of forms the formset will display::
@@ -124,7 +123,7 @@ affect validation.  If ``validate_max=True`` is passed to the
 validation.  See :ref:`validate_max`.
 
 Formset validation
-------------------
+==================
 
 Validation with a formset is almost identical to a regular ``Form``. There is
 an ``is_valid`` method on the formset to provide a convenient way to validate
@@ -195,7 +194,7 @@ sent without any data)::
 .. _understanding-the-managementform:
 
 Understanding the ManagementForm
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 You may have noticed the additional data (``form-TOTAL_FORMS``,
 ``form-INITIAL_FORMS`` and ``form-MAX_NUM_FORMS``) that was required
@@ -227,7 +226,7 @@ the management data by rendering ``{{ my_formset.management_form }}``
 (substituting the name of your formset as appropriate).
 
 ``total_form_count`` and ``initial_form_count``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------------------------
 
 ``BaseFormSet`` has a couple of methods that are closely related to the
 ``ManagementForm``, ``total_form_count`` and ``initial_form_count``.
@@ -241,14 +240,14 @@ sure you understand what they do before doing so.
 .. _empty_form:
 
 ``empty_form``
-~~~~~~~~~~~~~~
+--------------
 
 ``BaseFormSet`` provides an additional attribute ``empty_form`` which returns
 a form instance with a prefix of ``__prefix__`` for easier use in dynamic
 forms with JavaScript.
 
 Custom formset validation
-~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------
 
 A formset has a ``clean`` method similar to the one on a ``Form`` class. This
 is where you define your own validation that works at the formset level::
@@ -295,14 +294,14 @@ method on the formset.
 .. _validate_max:
 
 Validating the number of forms in a formset
--------------------------------------------
+===========================================
 
 Django provides a couple ways to validate the minimum or maximum number of
 submitted forms. Applications which need more customizable validation of the
 number of forms should use custom formset validation.
 
 ``validate_max``
-~~~~~~~~~~~~~~~~
+----------------
 
 If ``validate_max=True`` is passed to
 :func:`~django.forms.formsets.formset_factory`, validation will also check
@@ -344,7 +343,7 @@ excessive.
     using forged POST requests.
 
 ``validate_min``
-~~~~~~~~~~~~~~~~
+----------------
 
 If ``validate_min=True`` is passed to
 :func:`~django.forms.formsets.formset_factory`, validation will also check
@@ -373,14 +372,14 @@ deletion, is greater than or equal to ``min_num``.
     ['Please submit 3 or more forms.']
 
 Dealing with ordering and deletion of forms
--------------------------------------------
+===========================================
 
 The :func:`~django.forms.formsets.formset_factory` provides two optional
 parameters ``can_order`` and ``can_delete`` to help with ordering of forms in
 formsets and deletion of forms from a formset.
 
 ``can_order``
-~~~~~~~~~~~~~
+-------------
 
 .. attribute:: BaseFormSet.can_order
 
@@ -440,7 +439,7 @@ happen when the user changes these values::
     {'pub_date': datetime.date(2008, 5, 10), 'ORDER': 2, 'title': 'Article #1'}
 
 ``can_delete``
-~~~~~~~~~~~~~~
+--------------
 
 .. attribute:: BaseFormSet.can_delete
 
@@ -512,7 +511,7 @@ handle ``formset.deleted_forms``, perhaps in your formset's ``save()`` method,
 as there's no general notion of what it means to delete a form.
 
 Adding additional fields to a formset
--------------------------------------
+=====================================
 
 If you need to add additional fields to the formset this can be easily
 accomplished. The formset base class provides an ``add_fields`` method. You
@@ -538,7 +537,7 @@ default fields/attributes of the order and deletion fields::
 .. _custom-formset-form-kwargs:
 
 Passing custom parameters to formset forms
-------------------------------------------
+==========================================
 
 Sometimes your form class takes custom parameters, like ``MyArticleForm``.
 You can pass this parameter when instantiating the formset::
@@ -575,7 +574,7 @@ argument - the index of the form in the formset. The index is ``None`` for the
     The ``form_kwargs`` argument was added.
 
 Using a formset in views and templates
---------------------------------------
+======================================
 
 Using a formset inside a view is as easy as using a regular ``Form`` class.
 The only thing you will want to be aware of is making sure to use the
@@ -625,7 +624,7 @@ The above ends up calling the ``as_table`` method on the formset class.
 .. _manually-rendered-can-delete-and-can-order:
 
 Manually rendered ``can_delete`` and ``can_order``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------------------------
 
 If you manually render fields in the template, you can render
 ``can_delete`` parameter with ``{{ form.DELETE }}``:
@@ -650,7 +649,7 @@ Similarly, if the formset has the ability to order (``can_order=True``), it is
 possible to render it with ``{{ form.ORDER }}``.
 
 Using more than one formset in a view
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------
 
 You are able to use more than one formset in a view if you like. Formsets
 borrow much of its behavior from forms. With that said you are able to use
diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt
index abdcade6ff..41127f03ba 100644
--- a/docs/topics/forms/index.txt
+++ b/docs/topics/forms/index.txt
@@ -221,7 +221,7 @@ Building a form in Django
 -------------------------
 
 The :class:`Form` class
-^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~
 
 We already know what we want our HTML form to look like. Our starting point for
 it in Django is this:
@@ -267,7 +267,7 @@ We'll have to provide those ourselves in the template.
 .. _using-a-form-in-a-view:
 
 The view
-^^^^^^^^
+~~~~~~~~
 
 Form data sent back to a Django website is processed by a view, generally the
 same view which published the form. This allows us to reuse some of the same
@@ -324,7 +324,7 @@ telling it where to go next.
 .. _topics-forms-index-basic-form-template:
 
 The template
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 We don't need to do much in our ``name.html`` template. The simplest example
 is:
@@ -420,7 +420,7 @@ this case, our form has four fields: ``subject``, ``message``, ``sender`` and
 can be found in :doc:`/ref/forms/fields`.
 
 Widgets
-^^^^^^^
+~~~~~~~
 
 Each form field has a corresponding :doc:`Widget class </ref/forms/widgets/>`,
 which in turn corresponds to an HTML form widget such as ``<input
@@ -433,7 +433,7 @@ instead, you'd specify the appropriate widget when defining your form field,
 as we have done for the ``message`` field.
 
 Field data
-^^^^^^^^^^
+~~~~~~~~~~
 
 Whatever the data submitted with a form, once it has been successfully
 validated by calling ``is_valid()`` (and ``is_valid()`` has returned ``True``),
@@ -573,7 +573,7 @@ Complete ``<label>`` elements can also be generated using the
 
 
 Rendering form error messages
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Of course, the price of this flexibility is more work. Until now we haven't had
 to worry about how to display form errors, because that's taken care of for us.
@@ -699,7 +699,7 @@ Useful attributes on ``{{ field }}`` include:
     :class:`~django.forms.BoundField`.
 
 Looping over hidden and visible fields
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you're manually laying out a form in a template, as opposed to relying on
 Django's default form layout, you might want to treat ``<input type="hidden">``
diff --git a/docs/topics/forms/media.txt b/docs/topics/forms/media.txt
index a7975b4bce..2a478f37ca 100644
--- a/docs/topics/forms/media.txt
+++ b/docs/topics/forms/media.txt
@@ -1,3 +1,4 @@
+=================================
 Form Assets (the ``Media`` class)
 =================================
 
@@ -42,7 +43,7 @@ in a form suitable for easy inclusion on your Web page.
 .. _assets-as-a-static-definition:
 
 Assets as a static definition
------------------------------
+=============================
 
 The easiest way to define assets is as a static definition. Using this
 method, the declaration is an inner ``Media`` class. The properties of the
@@ -77,7 +78,7 @@ can be retrieved through this property::
 Here's a list of all possible ``Media`` options. There are no required options.
 
 ``css``
-~~~~~~~
+-------
 
 A dictionary describing the CSS files required for various forms of output
 media.
@@ -118,14 +119,14 @@ If this last CSS definition were to be rendered, it would become the following H
     <link href="http://static.example.com/newspaper.css" type="text/css" media="print" rel="stylesheet" />
 
 ``js``
-~~~~~~
+------
 
 A tuple describing the required JavaScript files. See :ref:`the
 section on paths <form-asset-paths>` for details of how to specify
 paths to these files.
 
 ``extend``
-~~~~~~~~~~
+----------
 
 A boolean defining inheritance behavior for ``Media`` declarations.
 
@@ -174,7 +175,7 @@ complete control over which files are inherited, and which are not.
 .. _dynamic-property:
 
 ``Media`` as a dynamic property
--------------------------------
+===============================
 
 If you need to perform some more sophisticated manipulation of asset
 requirements, you can define the ``media`` property directly. This is
@@ -198,7 +199,7 @@ return values for dynamic ``media`` properties.
 .. _form-asset-paths:
 
 Paths in asset definitions
---------------------------
+==========================
 
 Paths used to specify assets can be either relative or absolute. If a
 path starts with ``/``, ``http://`` or ``https://``, it will be
@@ -240,7 +241,7 @@ But if :setting:`STATIC_URL` is ``'http://static.example.com/'``::
 
 
 ``Media`` objects
------------------
+=================
 
 When you interrogate the ``media`` attribute of a widget or form, the
 value that is returned is a ``forms.Media`` object. As we have already
@@ -251,7 +252,7 @@ HTML page.
 However, ``Media`` objects have some other interesting properties.
 
 Subsets of assets
-~~~~~~~~~~~~~~~~~
+-----------------
 
 If you only want files of a particular type, you can use the subscript
 operator to filter out a medium of interest. For example::
@@ -269,7 +270,7 @@ When you use the subscript operator, the value that is returned is a
 new ``Media`` object -- but one that only contains the media of interest.
 
 Combining ``Media`` objects
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 ``Media`` objects can also be added together. When two ``Media`` objects are
 added, the resulting ``Media`` object contains the union of the assets
@@ -296,7 +297,7 @@ specified by both::
     <script type="text/javascript" src="http://static.example.com/whizbang.js"></script>
 
 ``Media`` on Forms
-------------------
+==================
 
 Widgets aren't the only objects that can have ``media`` definitions --
 forms can also define ``media``. The rules for ``media`` definitions
diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt
index 0f690aae46..1106980bac 100644
--- a/docs/topics/forms/modelforms.txt
+++ b/docs/topics/forms/modelforms.txt
@@ -208,7 +208,7 @@ Validation on a ``ModelForm``
 
 There are two main steps involved in validating a ``ModelForm``:
 
-1. :ref:`Validating the form <form-and-field-validation>`
+1. :doc:`Validating the form </ref/forms/validation>`
 2. :ref:`Validating the model instance <validating-objects>`
 
 Just like normal form validation, model form validation is triggered implicitly
@@ -232,7 +232,7 @@ validation step, right after the form's ``clean()`` method is called.
 .. _overriding-modelform-clean-method:
 
 Overriding the clean() method
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You can override the ``clean()`` method on a model form to provide additional
 validation in the same way you can on a normal form.
@@ -251,7 +251,7 @@ attribute that gives its methods access to that specific model instance.
     validation, you must call the parent class's ``clean()`` method.
 
 Interaction with model validation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 As part of the validation process, ``ModelForm`` will call the ``clean()``
 method of each field on your model that has a corresponding field on your form.
@@ -266,7 +266,7 @@ on the model's ``clean()`` hook.
 .. _considerations-regarding-model-errormessages:
 
 Considerations regarding model's ``error_messages``
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Error messages defined at the
 :attr:`form field <django.forms.Field.error_messages>` level or at the
diff --git a/docs/topics/http/index.txt b/docs/topics/http/index.txt
index 3c53b2ea4d..a606f01b73 100644
--- a/docs/topics/http/index.txt
+++ b/docs/topics/http/index.txt
@@ -1,3 +1,4 @@
+======================
 Handling HTTP requests
 ======================
 
diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt
index e149805a11..8b4aec5300 100644
--- a/docs/topics/http/sessions.txt
+++ b/docs/topics/http/sessions.txt
@@ -336,7 +336,7 @@ cookie-stored data to prevent tampering, a :setting:`SECRET_KEY` leak
 immediately escalates to a remote code execution vulnerability.
 
 Bundled Serializers
-^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~
 
 .. class:: serializers.JSONSerializer
 
@@ -366,7 +366,7 @@ Bundled Serializers
 .. _custom-serializers:
 
 Write Your Own Serializer
-^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Note that unlike :class:`~django.contrib.sessions.serializers.PickleSerializer`,
 the :class:`~django.contrib.sessions.serializers.JSONSerializer` cannot handle
diff --git a/docs/topics/i18n/formatting.txt b/docs/topics/i18n/formatting.txt
index 8a96bd74a9..c2efc2516a 100644
--- a/docs/topics/i18n/formatting.txt
+++ b/docs/topics/i18n/formatting.txt
@@ -1,5 +1,3 @@
-.. _format-localization:
-
 ===================
 Format localization
 ===================
diff --git a/docs/topics/i18n/timezones.txt b/docs/topics/i18n/timezones.txt
index b964ccadbf..2adfd48267 100644
--- a/docs/topics/i18n/timezones.txt
+++ b/docs/topics/i18n/timezones.txt
@@ -1,5 +1,3 @@
-.. _time-zones:
-
 ==========
 Time zones
 ==========
diff --git a/docs/topics/index.txt b/docs/topics/index.txt
index 5521cd1c0e..6f85baddb6 100644
--- a/docs/topics/index.txt
+++ b/docs/topics/index.txt
@@ -1,3 +1,4 @@
+============
 Using Django
 ============
 
diff --git a/docs/topics/install.txt b/docs/topics/install.txt
index e911494ceb..f0fbc47881 100644
--- a/docs/topics/install.txt
+++ b/docs/topics/install.txt
@@ -158,7 +158,7 @@ It's easy, no matter which way you choose.
 .. _installing-official-release:
 
 Installing an official release with ``pip``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------------------
 
 This is the recommended way to install Django.
 
@@ -183,7 +183,7 @@ This is the recommended way to install Django.
 .. _standalone pip installer: https://pip.pypa.io/en/latest/installing.html#install-pip
 
 Installing a distribution-specific package
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------------------------
 
 Check the :doc:`distribution specific notes </misc/distributions>` to see if
 your platform/distribution provides official Django packages/installers.
@@ -194,7 +194,7 @@ contain the latest release of Django.
 .. _installing-development-version:
 
 Installing the development version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------------
 
 .. admonition:: Tracking Django development
 
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index c197c5556f..01a76f63bc 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -11,7 +11,7 @@ designed to be mostly automatic, but you'll need to know when to make
 migrations, when to run them, and the common problems you might run into.
 
 The Commands
-------------
+============
 
 There are several commands which you will use to interact with migrations
 and Django's handling of database schema:
@@ -53,7 +53,7 @@ need those options in some data migrations later on (for example, if you've
 set custom validators).
 
 Backend Support
----------------
+===============
 
 Migrations are supported on all backends that Django ships with, as well
 as any third-party backends if they have programmed in support for schema
@@ -63,7 +63,7 @@ However, some databases are more capable than others when it comes to
 schema migrations; some of the caveats are covered below.
 
 PostgreSQL
-~~~~~~~~~~
+----------
 
 PostgreSQL is the most capable of all the databases here in terms of schema
 support; the only caveat is that adding columns with default values will
@@ -73,7 +73,7 @@ For this reason, it's recommended you always create new columns with
 ``null=True``, as this way they will be added immediately.
 
 MySQL
-~~~~~
+-----
 
 MySQL lacks support for transactions around schema alteration operations,
 meaning that if a migration fails to apply you will have to manually unpick
@@ -92,7 +92,7 @@ covers. This means that indexes that are possible on other backends will
 fail to be created under MySQL.
 
 SQLite
-~~~~~~
+------
 
 SQLite has very little built-in schema alteration support, and so Django
 attempts to emulate it by:
@@ -110,7 +110,7 @@ developers to use SQLite on their local machines to develop less complex
 Django projects without the need for a full database.
 
 Workflow
---------
+========
 
 Working with migrations is simple. Make changes to your models - say, add
 a field and remove a model - and then run :djadmin:`makemigrations`::
@@ -150,7 +150,7 @@ one, you can use the :djadminopt:`--name` option::
     $ python manage.py makemigrations --name changed_my_model your_app_label
 
 Version control
-~~~~~~~~~~~~~~~
+---------------
 
 Because migrations are stored in version control, you'll occasionally
 come across situations where you and another developer have both committed
@@ -170,7 +170,7 @@ yourself - don't worry, this isn't difficult, and is explained more in
 :ref:`migration-files` below.
 
 Dependencies
-------------
+============
 
 While migrations are per-app, the tables and relationships implied by
 your models are too complex to be created for just one app at a time. When
@@ -194,7 +194,7 @@ will be.
 .. _migration-files:
 
 Migration files
----------------
+===============
 
 Migrations are stored as an on-disk format, referred to here as
 "migration files". These files are actually just normal Python files with
@@ -240,7 +240,7 @@ more complex operations are not autodetectable and are only available via
 a hand-written migration, so don't be scared about editing them if you have to.
 
 Custom fields
-~~~~~~~~~~~~~
+-------------
 
 You can't modify the number of positional arguments in an already migrated
 custom field without raising a ``TypeError``. The old migration will call the
@@ -251,7 +251,7 @@ argument, please create a keyword argument and add something like
 .. _using-managers-in-migrations:
 
 Model managers
-~~~~~~~~~~~~~~
+--------------
 
 .. versionadded:: 1.8
 
@@ -279,7 +279,7 @@ Please refer to the notes about :ref:`historical-models` in migrations to see
 the implications that come along.
 
 Initial migrations
-~~~~~~~~~~~~~~~~~~
+------------------
 
 .. attribute:: Migration.initial
 
@@ -306,7 +306,7 @@ already exist in the database and fake-applies the migration if so. Without
 from any other migration.
 
 Adding migrations to apps
--------------------------
+=========================
 
 Adding migrations to new apps is straightforward - they come preconfigured to
 accept migrations, and so just run :djadmin:`makemigrations` once you've made
@@ -344,7 +344,7 @@ Note that this only works given two things:
 .. _historical-models:
 
 Historical models
------------------
+=================
 
 When you run migrations, Django is working from historical versions of your
 models stored in the migration files. If you write Python code using the
@@ -380,7 +380,7 @@ can opt to move them into a superclass.
 .. _migrations-removing-model-fields:
 
 Considerations when removing model fields
------------------------------------------
+=========================================
 
 .. versionadded:: 1.8
 
@@ -429,7 +429,7 @@ removing the old ones, you should be able to remove the field completely.
 .. _data-migrations:
 
 Data Migrations
----------------
+===============
 
 As well as changing the database schema, you can also use migrations to change
 the data in the database itself, in conjunction with the schema if you want.
@@ -514,7 +514,7 @@ want executed when migrating backwards. If this callable is omitted, migrating
 backwards will raise an exception.
 
 Accessing models from other apps
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+--------------------------------
 
 When writing a ``RunPython`` function that uses models from apps other than the
 one in which the migration is located, the migration's ``dependencies``
@@ -541,7 +541,7 @@ added a dependency that specifies the last migration of ``app2``::
         ]
 
 More advanced migrations
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 If you're interested in the more advanced migration operations, or want
 to be able to write your own, see the :doc:`migration operations reference
@@ -551,7 +551,7 @@ to be able to write your own, see the :doc:`migration operations reference
 .. _migration-squashing:
 
 Squashing migrations
---------------------
+====================
 
 You are encouraged to make migrations freely and not worry about how many you
 have; the migration code is optimized to deal with hundreds at a time without
@@ -642,7 +642,7 @@ You must then transition the squashed migration to a normal migration by:
 .. _migration-serializing:
 
 Serializing values
-------------------
+==================
 
 Migrations are just Python files containing the old definitions of your models
 - thus, to write them, Django must take the current state of your models and
@@ -701,7 +701,7 @@ the main module body, rather than the class body.
 .. _custom-deconstruct-method:
 
 Adding a deconstruct() method
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 You can let Django serialize your own custom class instances by giving the class
 a ``deconstruct()`` method. It takes no arguments, and should return a tuple
@@ -753,7 +753,7 @@ way into your constructor, and then returns those arguments exactly when
 deconstruct() is called.
 
 Supporting Python 2 and 3
--------------------------
+=========================
 
 In order to generate migrations that support both Python 2 and 3, all string
 literals used in your models and fields (e.g. ``verbose_name``,
@@ -773,7 +773,7 @@ changes as it converts all the bytestring attributes to text strings; this is
 normal and should only happen once.
 
 Supporting multiple Django versions
------------------------------------
+===================================
 
 If you are the maintainer of a third-party app with models, you may need to
 ship migrations that support multiple Django versions. In this case, you should
diff --git a/docs/topics/performance.txt b/docs/topics/performance.txt
index 718fa4762e..e50c63288f 100644
--- a/docs/topics/performance.txt
+++ b/docs/topics/performance.txt
@@ -53,7 +53,7 @@ It's no good just guessing or assuming where the inefficiencies lie in your
 code.
 
 Django tools
-^^^^^^^^^^^^
+~~~~~~~~~~~~
 
 `django-debug-toolbar
 <https://github.com/django-debug-toolbar/django-debug-toolbar/>`_ is a very
@@ -65,7 +65,7 @@ Third-party panels are also available for the toolbar, that can (for example)
 report on cache performance and template rendering times.
 
 Third-party services
-^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~
 
 There are a number of free services that will analyze and report on the
 performance of your site's pages from the perspective of a remote HTTP client,
@@ -96,7 +96,7 @@ most skills, learning what "looks right" takes practice, but one of the most
 useful guidelines is:
 
 Work at the appropriate level
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Django offers many different ways of approaching things, but just because it's
 possible to do something in a certain way doesn't mean that it's the most
@@ -259,13 +259,13 @@ Django comes with a few helpful pieces of :doc:`middleware </ref/middleware>`
 that can help optimize your site's performance. They include:
 
 :class:`~django.middleware.http.ConditionalGetMiddleware`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Adds support for modern browsers to conditionally GET responses based on the
 ``ETag`` and ``Last-Modified`` headers.
 
 :class:`~django.middleware.gzip.GZipMiddleware`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Compresses responses for all modern browsers, saving bandwidth and transfer
 time. Note that GZipMiddleware is currently considered a security risk, and is
@@ -276,7 +276,7 @@ Sessions
 --------
 
 Using cached sessions
-^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~
 
 :ref:`Using cached sessions <cached-sessions-backend>` may be a way to increase
 performance by eliminating the need to load session data from a slower storage
@@ -290,7 +290,7 @@ Static files, which by definition are not dynamic, make an excellent target for
 optimization gains.
 
 :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By taking advantage of web browsers' caching abilities, you can
 eliminate network hits entirely for a given file after the initial download.
@@ -302,7 +302,7 @@ long-term without missing future changes - when a file changes, so will the
 tag, so browsers will reload the asset automatically.
 
 "Minification"
-^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~
 
 Several third-party Django tools and packages provide the ability to "minify"
 HTML, CSS, and JavaScript. They remove unnecessary whitespace, newlines, and
@@ -410,7 +410,7 @@ performance gains for your application to outweigh the potential risks.
 With these caveats in mind, you should be aware of:
 
 `PyPy <http://pypy.org/>`_
-^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 `PyPy <http://pypy.org/>`_ is an implementation of Python in Python itself (the
 'standard' Python implementation is in C). PyPy can offer substantial
@@ -422,7 +422,7 @@ Django is compatible, but you will need to check the compatibility of other
 libraries you rely on.
 
 C implementations of Python libraries
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Some Python libraries are also implemented in C, and can be much faster. They
 aim to offer the same APIs. Note that compatibility issues and behavior
diff --git a/docs/topics/serialization.txt b/docs/topics/serialization.txt
index e34553699d..87f98a4825 100644
--- a/docs/topics/serialization.txt
+++ b/docs/topics/serialization.txt
@@ -13,7 +13,7 @@ serializer to handle any format (text-based or not).
     form, you could use the :djadmin:`dumpdata` management command.
 
 Serializing data
-----------------
+================
 
 At the highest level, serializing data is a very simple operation::
 
@@ -50,7 +50,7 @@ This is useful if you want to serialize data directly to a file-like object
 .. _subset-of-fields:
 
 Subset of fields
-~~~~~~~~~~~~~~~~
+----------------
 
 If you only want a subset of fields to be serialized, you can
 specify a ``fields`` argument to the serializer::
@@ -69,7 +69,7 @@ be serialized.
     model, the deserializer will not be able to save deserialized instances.
 
 Inherited Models
-~~~~~~~~~~~~~~~~
+----------------
 
 If you have a model that is defined using an :ref:`abstract base class
 <abstract-base-classes>`, you don't have to do anything special to serialize
@@ -102,7 +102,7 @@ serialize the ``Place`` models as well::
     data = serializers.serialize('xml', all_objects)
 
 Deserializing data
-------------------
+==================
 
 Deserializing data is also a fairly simple operation::
 
@@ -147,7 +147,7 @@ argument is passed in as ``True``::
 .. _serialization-formats:
 
 Serialization formats
----------------------
+=====================
 
 Django supports a number of serialization formats, some of which require you
 to install third-party Python modules:
@@ -167,7 +167,7 @@ Identifier  Information
 .. _PyYAML: http://www.pyyaml.org/
 
 XML
-~~~
+---
 
 The basic XML serialization format is quite simple::
 
@@ -226,7 +226,7 @@ This example links the given user with the permission models with PKs 46 and 47.
 .. _serialization-formats-json:
 
 JSON
-~~~~
+----
 
 When staying with the same example data as before it would be serialized as
 JSON in the following way::
@@ -276,7 +276,7 @@ Also note that GeoDjango provides a :doc:`customized GeoJSON serializer
 .. _ecma-262: http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
 
 YAML
-~~~~
+----
 
 YAML serialization looks quite similar to JSON. The object list is serialized
 as a sequence mappings with the keys "pk", "model" and "fields". Each field is
@@ -291,7 +291,7 @@ Referential fields are again just represented by the PK or sequence of PKs.
 .. _topics-serialization-natural-keys:
 
 Natural keys
-------------
+============
 
 The default serialization strategy for foreign keys and many-to-many relations
 is to serialize the value of the primary key(s) of the objects in the relation.
@@ -327,7 +327,7 @@ key is a tuple of values that can be used to uniquely identify an
 object instance without using the primary key value.
 
 Deserialization of natural keys
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-------------------------------
 
 Consider the following two models::
 
@@ -420,7 +420,7 @@ model's manager has a ``get_by_natural_key()`` method and if so, use it to
 populate the deserialized object's primary key.
 
 Serialization of natural keys
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+-----------------------------
 
 So how do you get Django to emit a natural key when serializing an object?
 Firstly, you need to add another method -- this time to the model itself::
@@ -488,7 +488,7 @@ line flags to generate natural keys.
     key values, just don't define the ``get_by_natural_key()`` method.
 
 Dependencies during serialization
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------------
 
 Since natural keys rely on database lookups to resolve references, it
 is important that the data exists before it is referenced. You can't make
diff --git a/docs/topics/testing/tools.txt b/docs/topics/testing/tools.txt
index 3572b31b95..2b432211ef 100644
--- a/docs/topics/testing/tools.txt
+++ b/docs/topics/testing/tools.txt
@@ -9,7 +9,7 @@ Django provides a small set of tools that come in handy when writing tests.
 .. _test-client:
 
 The test client
----------------
+===============
 
 The test client is a Python class that acts as a dummy Web browser, allowing
 you to test your views and interact with your Django-powered application
@@ -42,7 +42,7 @@ short:
 A comprehensive test suite should use a combination of both test types.
 
 Overview and a quick example
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+----------------------------
 
 To use the test client, instantiate ``django.test.Client`` and retrieve
 Web pages::
@@ -105,7 +105,7 @@ Note a few important things about how the test client works:
       >>> csrf_client = Client(enforce_csrf_checks=True)
 
 Making requests
-~~~~~~~~~~~~~~~
+---------------
 
 Use the ``django.test.Client`` class to make requests.
 
@@ -421,7 +421,7 @@ Use the ``django.test.Client`` class to make requests.
         to come from an :class:`~django.contrib.auth.models.AnonymousUser`.
 
 Testing responses
-~~~~~~~~~~~~~~~~~
+-----------------
 
 The ``get()`` and ``post()`` methods both return a ``Response`` object. This
 ``Response`` object is *not* the same as the ``HttpResponse`` object returned
@@ -535,7 +535,7 @@ of any settings in the HTTP headers. For example, you could determine the
 content type of a response using ``response['Content-Type']``.
 
 Exceptions
-~~~~~~~~~~
+----------
 
 If you point the test client at a view that raises an exception, that exception
 will be visible in the test case. You can then use a standard ``try ... except``
@@ -549,7 +549,7 @@ exceptions internally and converts them into the appropriate HTTP response
 codes. In these cases, you can check ``response.status_code`` in your test.
 
 Persistent state
-~~~~~~~~~~~~~~~~
+----------------
 
 The test client is stateful. If a response returns a cookie, then that cookie
 will be stored in the test client and sent with all subsequent ``get()`` and
@@ -583,7 +583,7 @@ can access these properties as part of a test condition.
             session.save()
 
 Example
-~~~~~~~
+-------
 
 The following is a simple unit test using the test client::
 
@@ -612,7 +612,7 @@ The following is a simple unit test using the test client::
 .. _django-testcase-subclasses:
 
 Provided test case classes
---------------------------
+==========================
 
 Normal Python unit test classes extend a base class of
 :class:`unittest.TestCase`. Django provides a few extensions of this base class:
@@ -627,7 +627,7 @@ Normal Python unit test classes extend a base class of
    Hierarchy of Django unit testing classes
 
 SimpleTestCase
-~~~~~~~~~~~~~~
+--------------
 
 .. class:: SimpleTestCase()
 
@@ -712,7 +712,7 @@ then you should use :class:`~django.test.TransactionTestCase` or
     calling ``super()`` to avoid this.
 
 TransactionTestCase
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. class:: TransactionTestCase()
 
@@ -761,7 +761,7 @@ to test the effects of commit and rollback:
 ``TransactionTestCase`` inherits from :class:`~django.test.SimpleTestCase`.
 
 TestCase
-~~~~~~~~
+--------
 
 .. class:: TestCase()
 
@@ -832,7 +832,7 @@ additions, including:
 .. _live-test-server:
 
 LiveServerTestCase
-~~~~~~~~~~~~~~~~~~
+------------------
 
 .. class:: LiveServerTestCase()
 
@@ -986,10 +986,10 @@ out the `full reference`_ for more details.
     .. _Selenium documentation: http://seleniumhq.org/docs/04_webdriver_advanced.html#explicit-waits
 
 Test cases features
--------------------
+===================
 
 Default test client
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. attribute:: SimpleTestCase.client
 
@@ -1028,7 +1028,7 @@ This means, instead of instantiating a ``Client`` in each test::
             self.assertEqual(response.status_code, 200)
 
 Customizing the test client
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+---------------------------
 
 .. attribute:: SimpleTestCase.client_class
 
@@ -1052,7 +1052,7 @@ attribute::
 .. _topics-testing-fixtures:
 
 Fixture loading
-~~~~~~~~~~~~~~~
+---------------
 
 .. attribute:: TransactionTestCase.fixtures
 
@@ -1109,7 +1109,7 @@ using multiple databases and set :attr:`multi_db=True
 <TransactionTestCase.multi_db>`, fixtures will be loaded into all databases.
 
 URLconf configuration
-~~~~~~~~~~~~~~~~~~~~~
+---------------------
 
 .. attribute:: SimpleTestCase.urls
 
@@ -1148,7 +1148,7 @@ URLconf for the duration of the test case.
 .. _emptying-test-outbox:
 
 Multi-database support
-~~~~~~~~~~~~~~~~~~~~~~
+----------------------
 
 .. attribute:: TransactionTestCase.multi_db
 
@@ -1186,7 +1186,7 @@ If ``multi_db=True``, fixtures are loaded into all databases.
 .. _overriding-settings:
 
 Overriding settings
-~~~~~~~~~~~~~~~~~~~
+-------------------
 
 .. warning::
 
@@ -1362,7 +1362,7 @@ MEDIA_ROOT, DEFAULT_FILE_STORAGE Default file storage
 ================================ ========================
 
 Emptying the test outbox
-~~~~~~~~~~~~~~~~~~~~~~~~
+------------------------
 
 If you use any of Django's custom ``TestCase`` classes, the test runner will
 clear the contents of the test email outbox at the start of each test case.
@@ -1372,7 +1372,7 @@ For more detail on email services during tests, see `Email services`_ below.
 .. _assertions:
 
 Assertions
-~~~~~~~~~~
+----------
 
 As Python's normal :class:`unittest.TestCase` class implements assertion methods
 such as :meth:`~unittest.TestCase.assertTrue` and
@@ -1667,7 +1667,7 @@ your test suite.
 .. _topics-testing-email:
 
 Email services
---------------
+==============
 
 If any of your Django views send email using :doc:`Django's email
 functionality </topics/email>`, you probably don't want to send email each time
@@ -1724,7 +1724,7 @@ manually, assign the empty list to ``mail.outbox``::
 .. _topics-testing-management-commands:
 
 Management Commands
--------------------
+===================
 
 Management commands can be tested with the
 :func:`~django.core.management.call_command` function. The output can be
@@ -1743,7 +1743,7 @@ redirected into a ``StringIO`` instance::
 .. _skipping-tests:
 
 Skipping tests
---------------
+==============
 
 .. currentmodule:: django.test
author	Elif T. Kus <elifkus@gmail.com>	2016-01-03 12:56:22 +0200
committer	Tim Graham <timograham@gmail.com>	2016-01-22 12:18:24 -0500
commit	5dceb1f07807d76f163ce1929e9f1dc1b2da6289 (patch)
tree	21057f127c428fd95dc35badefd67560a3d2c100 /docs
parent	647ce33e86807bcc75977a34871e1ee08230d9a5 (diff)