Cleaned up the release notes index page, and added some stub 1.1.2 and 1.2 release notes.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@11760 bcc190cf-cafb-0310-a4f2-bffc1f526a37

2 files changed, 8 insertions, 6 deletions

diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index c1bdb59cd1..b76ec2f4f0 100644
--- a/docs/ref/contrib/csrf.txt
+++ b/docs/ref/contrib/csrf.txt
@@ -46,7 +46,7 @@ To enable CSRF protection for your views, follow these steps:
        ``django.views.decorators.csrf.csrf_protect`` on particular views you
        want to protect (see below).
 
-    2. In any template that uses a POST form, use the ``csrf_token`` tag inside
+    2. In any template that uses a POST form, use the :ttag:`csrf_token` tag inside
        the ``<form>`` element if the form is for an internal URL, e.g.::
 
            <form action="" method="POST">{% csrf_token %}
@@ -123,14 +123,14 @@ as ``CsrfResponseMiddleware``, and it can be used by following these steps:
 
        ``CsrfResponseMiddleware`` needs to process the response before things
        like compression or setting ofETags happen to the response, so it must
-       come after ``GZipMiddleware``, ``CommonMiddleware`` and 
+       come after ``GZipMiddleware``, ``CommonMiddleware`` and
        ``ConditionalGetMiddleware`` in the list. It also must come after
        ``CsrfViewMiddleware``.
 
 Use of the ``CsrfResponseMiddleware`` is not recommended because of the
 performance hit it imposes, and because of a potential security problem (see
 below).  It can be used as an interim measure until applications have been
-updated to use the ``{% csrf_token %}`` tag.  It is deprecated and will be
+updated to use the :ttag:`csrf_token` tag.  It is deprecated and will be
 removed in Django 1.4.
 
 Django 1.1 and earlier provided a single ``CsrfMiddleware`` class.  This is also
@@ -199,7 +199,7 @@ Note that contrib apps, such as the admin, have been updated to use the
 ``CsrfViewMiddleware`` to your settings.  However, if you have supplied
 customised templates to any of the view functions of contrib apps (whether
 explicitly via a keyword argument, or by overriding built-in templates), **you
-MUST update them** to include the ``csrf_token`` template tag as described
+MUST update them** to include the :ttag:`csrf_token` template tag as described
 above, or they will stop working.  (If you cannot update these templates for
 some reason, you will be forced to use ``CsrfResponseMiddleware`` for these
 views to continue working).
@@ -364,7 +364,7 @@ exactly that.
 Caching
 =======
 
-If the ``csrf_token`` template tag is used by a template (or the ``get_token``
+If the :ttag:`csrf_token` template tag is used by a template (or the ``get_token``
 function is called some other way), ``CsrfViewMiddleware`` will add a cookie and
 a ``Vary: Cookie`` header to the response.  Similarly,
 ``CsrfResponseMiddleware`` will send the ``Vary: Cookie`` header if it inserted
diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt
index 8266224c39..6d6abd1098 100644
--- a/docs/ref/templates/builtins.txt
+++ b/docs/ref/templates/builtins.txt
@@ -51,7 +51,7 @@ comment
 
 Ignore everything between ``{% comment %}`` and ``{% endcomment %}``
 
-.. templatetag:: cycle
+.. templatetag:: csrf_token
 
 csrf_token
 ~~~~~~~~~~
@@ -63,6 +63,8 @@ future compatibility purposes.  In Django 1.2 and later, it is used for CSRF
 protection, as described in the documentation for :ref:`Cross Site Request
 Forgeries <ref-contrib-csrf>`.
 
+.. templatetag:: cycle
+
 cycle
 ~~~~~