Fix formatting errors

docs/reference/pages/model_reference.md

@@ -1281,7 +1281,7 @@ An abstract base class that represents a record of an action performed on an obj
 
         The object title at the time of the entry creation
 
-        Note: Wagtail will attempt to use ``get_admin_display_title`` or the string representation of the object passed to ``LogEntryManger.log_action``
+        Note: Wagtail will attempt to use ``get_admin_display_title`` or the string representation of the object passed to ``LogEntryManager.log_action``
 
     .. attribute:: user
 

docs/reference/viewsets.md

@@ -64,7 +64,7 @@ Viewsets are Wagtail's mechanism for defining a group of related admin views wit
 
    .. attribute:: model
 
-   Required; the model class that this viewset will work with. The `~django.db.models.Options.model_name` will be used
+   Required; the model class that this viewset will work with. The ``model_name`` will be used
    as the URL prefix and namespace, unless these are specified explicitly via the :attr:`~.ViewSet.name`, :attr:`~.ViewSet.url_prefix` or
    :attr:`~.ViewSet.url_namespace` attributes.
 

docs/releases/0.6.rst

@@ -28,7 +28,7 @@ Wagtail can now be used with Django 1.7.
 Minor features
 ~~~~~~~~~~~~~~
 * A new template tag has been added for reversing URLs inside routable pages. See :ref:`routablepageurl_template_tag`.
-* RoutablePage can now be used as a mixin. See `wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin`.
+* RoutablePage can now be used as a mixin. See :ref:`routable_page_mixin`.
 * MenuItems can now have bundled JavaScript
 * Added the ``register_admin_menu_item`` hook for registering menu items at startup. See :ref:`admin_hooks`
 * Added a version indicator into the admin interface (hover over the wagtail to see it)

docs/releases/1.0.rst

@@ -200,7 +200,7 @@ should work fine without them.
 ``RoutablePage`` now uses decorator syntax for defining views
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-In previous versions of Wagtail, page types that used the `~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin` had endpoints configured by setting their `~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin.subpage_urls` attribute to a list of urls with view names. This will not work on Django 1.8 as view names can no longer be passed into a url (see: https://docs.djangoproject.com/en/stable/releases/1.8/#django-conf-urls-patterns).
+In previous versions of Wagtail, page types that used :ref:`routable_page_mixin` had endpoints configured by setting their ``subpage_urls`` attribute to a list of urls with view names. This will not work on Django 1.8 as view names can no longer be passed into a url (see: https://docs.djangoproject.com/en/stable/releases/1.8/#django-conf-urls-patterns).
 
 Wagtail 1.0 introduces a new syntax where each view function is annotated with a ``@route`` decorator - see :ref:`routable_page_mixin`.
 

docs/releases/1.1.rst

@@ -21,7 +21,7 @@ Usually, an operation that retrieves a QuerySet of pages (such as ``homepage.get
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Previously, this was implemented in ``wagtail.wagtailsearch`` but now has
-been moved into a separate module: `wagtail.contrib.wagtailsearchpromotions`
+been moved into a separate module: ``wagtail.contrib.wagtailsearchpromotions``
 
 Atomic rebuilding of Elasticsearch indexes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -105,7 +105,7 @@ Upgrade considerations
 
 This feature has moved into a contrib module so is no longer enabled by default.
 
-To re-enable it, add `wagtail.contrib.wagtailsearchpromotions` to your ``INSTALLED_APPS``:
+To re-enable it, add ``wagtail.contrib.wagtailsearchpromotions`` to your ``INSTALLED_APPS``:
 
 .. code-block:: python
 
@@ -117,7 +117,7 @@ To re-enable it, add `wagtail.contrib.wagtailsearchpromotions` to your ``INSTALL
         ...
 
 If you have references to the ``wagtail.wagtailsearch.models.EditorsPick`` model in your
-project, you will need to update these to point to the `wagtail.contrib.wagtailsearchpromotions.models.SearchPromotion` model instead.
+project, you will need to update these to point to the ``wagtail.contrib.wagtailsearchpromotions.models.SearchPromotion`` model instead.
 
 If you created your project using the ``wagtail start`` command with Wagtail 1.0,
 you will probably have references to this model in the ``search/views.py`` file.

docs/releases/1.2.rst

@@ -184,8 +184,8 @@ Wagtail API requires adding ``rest_framework`` to INSTALLED_APPS
 If you have the Wagtail API (``wagtail.contrib.wagtailapi``) enabled, you must now add ``'rest_framework'`` to your project's ``INSTALLED_APPS`` setting. In the current version the API will continue to function without this app, but the browsable front-end will not be available; this ability will be dropped in a future release.
 
 
-`Page.get_latest_revision_as_page() <wagtail.core.models.Page.get_latest_revision_as_page>` now returns live page object when there are no draft changes
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+``Page.get_latest_revision_as_page()`` now returns live page object when there are no draft changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you have any application code that makes direct updates to page data, at the model or database level, be aware that the way these edits are reflected in the page editor has changed.
 

docs/releases/1.6.1.rst

@@ -22,7 +22,8 @@ Bug fixes
 ~~~~~~~~~
 
 * Wagtail's middleware classes are now compatible with Django 1.10's `new-style middleware <https://docs.djangoproject.com/en/stable/releases/1.10/#new-style-middleware>`_ (Karl Hobley)
-* The :meth:`~wagtail.models.Page.can_create_at` method is now checked in the create page view (Mikalai Radchuk)* Fixed regression on Django 1.10.1 causing Page subclasses to fail to use PageManager (Matt Westcott)
+* The :meth:`~wagtail.models.Page.can_create_at` method is now checked in the create page view (Mikalai Radchuk)
+* Fixed regression on Django 1.10.1 causing Page subclasses to fail to use PageManager (Matt Westcott)
 * ChoiceBlocks with lazy translations as option labels no longer break Elasticsearch indexing (Matt Westcott)
 * The page editor no longer fails to load JavaScript files with ``ManifestStaticFilesStorage`` (Matt Westcott)
 * Django 1.10 enables client-side validation for all forms by default, but it fails to handle all the nuances of how forms are used in Wagtail. The client-side validation has been disabled for the Wagtail UI (Matt Westcott)

docs/releases/1.8.rst

@@ -70,7 +70,8 @@ Other features
 * ``ChoiceBlock`` now accepts a callable as the choices list (Mikalai Radchuk)
 * Redundant action buttons are now omitted from the root page in the explorer (Nick Smith)
 * Locked pages are now disabled from editing at the browser level (Edd Baldry)
-* Added :meth:`wagtail.query.PageQuerySet.in_site` method for filtering page QuerySets to pages within the specified site (Chris Rogers)* Added the ability to override the default index settings for Elasticsearch. See :ref:`wagtailsearch_backends_elasticsearch` (PyMan Claudio Marinozzi)
+* Added :meth:`wagtail.query.PageQuerySet.in_site` method for filtering page QuerySets to pages within the specified site (Chris Rogers)
+* Added the ability to override the default index settings for Elasticsearch. See :ref:`wagtailsearch_backends_elasticsearch` (PyMan Claudio Marinozzi)
 * Extra options for the Elasticsearch constructor should be now defined with the new key ``OPTIONS`` of the ``WAGTAILSEARCH_BACKENDS`` setting (PyMan Claudio Marinozzi)
 
 

docs/releases/2.9.rst

@@ -94,7 +94,7 @@ Django 2.1 is no longer supported as of this release; please upgrade to Django 2
 ``SiteMiddleware`` and ``request.site`` deprecated
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Wagtail's `~wagtail.core.middleware.SiteMiddleware`, which makes the current site object available as the property ``request.site``, is now deprecated as it clashes with Django's sites framework and makes unnecessary database queries on non-Wagtail views. References to ``request.site`` in your code should be removed; the recommended way of retrieving the current site is ``Site.find_for_request(request)`` in Python code, and the ``{% wagtail_site %}`` tag within Django templates.
+Wagtail's ``wagtail.core.middleware.SiteMiddleware``, which makes the current site object available as the property ``request.site``, is now deprecated as it clashes with Django's sites framework and makes unnecessary database queries on non-Wagtail views. References to ``request.site`` in your code should be removed; the recommended way of retrieving the current site is ``Site.find_for_request(request)`` in Python code, and the ``{% wagtail_site %}`` tag within Django templates.
 
 For example:
 

docs/topics/snippets/features.md

@@ -326,7 +326,7 @@ The admin dashboard and workflow reports will also show you snippets (alongside
 
 ## Tagging snippets
 
-Adding tags to snippets is very similar to adding tags to pages. The only difference is that if `RevisionMixin` is not applied, then `taggit.manager.TaggableManager` should be used in the place of `~modelcluster.contrib.taggit.ClusterTaggableManager`.
+Adding tags to snippets is very similar to adding tags to pages. The only difference is that if `RevisionMixin` is not applied, then `taggit.manager.TaggableManager` should be used in the place of `modelcluster.contrib.taggit.ClusterTaggableManager`.
 
 ```python
 # ...