fixes some of errors by removing directives

docs/advanced_topics/api/v2/configuration.md

@@ -42,10 +42,10 @@ can hook into the rest of your project.
 
 Wagtail provides multiple endpoint classes you can use:
 
--   Pages {class}`wagtail.api.v2.views.PagesAPIViewSet`
--   Images {class}`wagtail.images.api.v2.views.ImagesAPIViewSet`
--   Documents {class}`wagtail.documents.api.v2.views.DocumentsAPIViewSet`
--   Redirects {class}`wagtail.contrib.redirects.api.RedirectsAPIViewSet` see [](redirects_api_endpoint)
+-   Pages `wagtail.api.v2.views.PagesAPIViewSet`
+-   Images `wagtail.images.api.v2.views.ImagesAPIViewSet`
+-   Documents `wagtail.documents.api.v2.views.DocumentsAPIViewSet`
+-   Redirects `wagtail.contrib.redirects.api.RedirectsAPIViewSet` see [](redirects_api_endpoint)
 
 You can subclass any of these endpoint classes to customize their functionality.
 For example, in this case, if you need to change the `APIViewSet` by setting a desired renderer class:

docs/conf.py

@@ -35,6 +35,7 @@ html_theme_options = {
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 sys.path.insert(0, os.path.abspath(".."))
+sys.path.insert(0, os.path.abspath("../i18n.py"))
 
 # Autodoc may need to import some models modules which require django settings
 # be configured

docs/extending/custom_account_settings.md

@@ -7,7 +7,7 @@ at the bottom of the main menu.
 
 ## Adding new panels
 
-Each panel on this form is a separate model form that can operate on an instance of either the user model, or the {class}`wagtail.users.models.UserProfile`.
+Each panel on this form is a separate model form that can operate on an instance of either the user model, or the `wagtail.users.models.UserProfile`.
 
 ### Basic example
 
@@ -54,7 +54,7 @@ The attributes are as follows:
 
 ## Operating on the `UserProfile` model
 
-To add a panel that alters data on the user's {class}`wagtail.users.models.UserProfile` instance, set `form_object` to `'profile'`:
+To add a panel that alters data on the user's `wagtail.users.models.UserProfile` instance, set `form_object` to `'profile'`:
 
 ```python
 # forms.py

docs/reference/pages/model_reference.md

@@ -521,7 +521,7 @@ Pages already include this mixin, so there is no need to add it.
 
     .. attribute:: locale
 
-        (Foreign Key to :class:`~wagtail.models.Locale`)
+        (Foreign Key to `~wagtail.models.Locale`)
 
         For pages, this defaults to the locale of the parent page.
 
@@ -808,7 +808,7 @@ You can use the [`purge_revisions`](purge_revisions) command to delete old revis
 
     .. attribute:: objects
 
-        This default manager is used to retrieve all of the ``Revision`` objects in the database. It also provides a :meth:`~wagtail.models.RevisionsManager.for_instance` method that lets you query for revisions of a specific object.
+        This default manager is used to retrieve all of the ``Revision`` objects in the database. It also provides a `~wagtail.models.RevisionsManager.for_instance` method that lets you query for revisions of a specific object.
 
         Example:
 
@@ -1280,7 +1280,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 :meth:`~LogEntryManger.log_action`
+        Note: Wagtail will attempt to use ``get_admin_display_title`` or the string representation of the object passed to `~LogEntryManger.log_action`
 
     .. attribute:: user
 

docs/reference/pages/panels.md

@@ -280,7 +280,7 @@ The `MultipleChooserPanel` definition on `BlogPage` would be:
 
 .. class:: FormSubmissionsPanel(**kwargs)
 
-    This panel adds a single, read-only section in the edit interface for pages implementing the :class:`~wagtail.contrib.forms.models.AbstractForm` model.
+    This panel adds a single, read-only section in the edit interface for pages implementing the `~wagtail.contrib.forms.models.AbstractForm` model.
     It includes the number of total submissions for the given form and also a link to the listing of submissions.
 
     .. code-block:: python

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 :attr:`~django.db.models.Options.model_name` will be used
+   Required; the model class that this viewset will work with. The `~django.db.models.Options.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 :class:`wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin`.
+* RoutablePage can now be used as a mixin. See `wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin`.
 * 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 :class:`~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin` had endpoints configured by setting their :attr:`~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 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).
 
 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

@@ -20,15 +20,15 @@ Usually, an operation that retrieves a QuerySet of pages (such as ``homepage.get
 "Promoted search results" has moved into its own module
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Previously, this was implemented in :mod:`~wagtail.wagtailsearch` but now has
-been moved into a separate module: :mod:`wagtail.contrib.wagtailsearchpromotions`
+Previously, this was implemented in `~wagtail.wagtailsearch` but now has
+been moved into a separate module: `wagtail.contrib.wagtailsearchpromotions`
 
 Atomic rebuilding of Elasticsearch indexes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The Elasticsearch search backend now accepts an experimental ``ATOMIC_REBUILD`` flag which ensures that the existing search index continues to be available while the ``update_index`` task is running. See :ref:`wagtailsearch_backends_atomic_rebuild`.
 
-The :mod:`~wagtail.contrib.wagtailapi` module now uses Django REST Framework
+The `~wagtail.contrib.wagtailapi` module now uses Django REST Framework
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The ``wagtailapi`` module is now built on Django REST Framework and it now also has a `library of serialisers <https://github.com/wagtail/wagtail/blob/stable/1.1.x/wagtail/contrib/wagtailapi/serializers.py>`_ that you can use in your own REST Framework based APIs. No user-facing changes have been made.
@@ -100,12 +100,12 @@ Bug fixes
 Upgrade considerations
 ======================
 
-"Promoted search results" no longer in :mod:`~wagtail.wagtailsearch`
+"Promoted search results" no longer in `~wagtail.wagtailsearch`
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This feature has moved into a contrib module so is no longer enabled by default.
 
-To re-enable it, add :mod:`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 :mod:`wagtail.contrib.wagtailsearchpromotions` to your ``IN
         ...
 
 If you have references to the ``wagtail.wagtailsearch.models.EditorsPick`` model in your
-project, you will need to update these to point to the :mod:`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.11.rst

@@ -121,8 +121,8 @@ to:
 
 and passing those through at the point where you are calling ``get_url_parts`` on ``super`` (if applicable).
 
-See also: :meth:`wagtail.core.models.Page.get_url_parts`, :meth:`wagtail.core.models.Page.get_url`,
-:meth:`wagtail.core.models.Page.get_full_url`, and :meth:`wagtail.core.models.Page.relative_url`
+See also: `wagtail.core.models.Page.get_url_parts`, `wagtail.core.models.Page.get_url`,
+`wagtail.core.models.Page.get_full_url`, and `wagtail.core.models.Page.relative_url`
 
 
 "Password required" template for documents

docs/releases/1.2.rst

@@ -115,7 +115,7 @@ Bug fixes
 * Dropdown for ``ForeignKey`` s are now styled consistently (Ashia Zawaduk)
 * Date choosers now appear on top of StreamField menus (Sergey Nikitin)
 * Fixed a migration error that was raised when block-updating from 0.8 to 1.1+
-* :meth:`Page.copy() <wagtail.core.models.Page.copy>` no longer breaks on models with a ``ClusterTaggableManager`` or ``ManyToManyField``
+* `Page.copy() <wagtail.core.models.Page.copy>` no longer breaks on models with a ``ClusterTaggableManager`` or ``ManyToManyField``
 * Validation errors when inserting an embed into a rich text area are now reported back to the editor
 
 Upgrade considerations
@@ -184,7 +184,7 @@ 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.
 
 
-:meth:`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() <wagtail.core.models.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,7 @@ 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.core.models.Page.can_create_at` method is now checked in the create page view (Mikalai Radchuk)
+* The `~wagtail.core.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)

docs/releases/1.8.rst

@@ -70,7 +70,7 @@ 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.core.query.PageQuerySet.in_site` method for filtering page QuerySets to pages within the specified site (Chris Rogers)
+* Added `wagtail.core.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 :class:`~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/releases/5.2.md

@@ -63,7 +63,7 @@ Thank you to core contributor LB (Ben) Johnston for writing this documentation.
 
 ### `ModelViewSet` improvements
 
-Several features from {class}`~wagtail.snippets.views.snippets.SnippetViewSet` have been implemented in {class}`~wagtail.admin.viewsets.model.ModelViewSet`, allowing you to use them without registering your models as snippets. For more details on using `ModelViewSet`, refer to [](generic_views).
+Several features from `~wagtail.snippets.views.snippets.SnippetViewSet` have been implemented in `~wagtail.admin.viewsets.model.ModelViewSet`, allowing you to use them without registering your models as snippets. For more details on using `ModelViewSet`, refer to [](generic_views).
 
  * Move `SnippetViewSet` menu registration mechanism to base `ViewSet` class (Sage Abdullah)
  * Move `SnippetViewSet` template override mechanism to `ModelViewSet` (Sage Abdullah)
@@ -243,10 +243,10 @@ The legacy moderation system will be removed in a future release. If you still h
 
 As a result, the following features are now deprecated:
 
-- {attr}`wagtail.models.Revision.submitted_for_moderation`
-- {attr}`wagtail.models.Revision.submitted_revisions`
-- {meth}`wagtail.models.Revision.approve_moderation`
-- {meth}`wagtail.models.Revision.reject_moderation`
+- `wagtail.models.Revision.submitted_for_moderation`
+- `wagtail.models.Revision.submitted_revisions`
+- `wagtail.models.Revision.approve_moderation`
+- `wagtail.models.Revision.reject_moderation`
 - The `submitted_for_moderation` argument in {meth}`wagtail.models.RevisionMixin.save_revision`
 - `WAGTAIL_MODERATION_ENABLED`
 - `wagtail.admin.userbar.ModeratePageItem`
@@ -300,7 +300,7 @@ def register_frank_menu_item():
 
 ### Edit and delete URLs in `ModelViewSet` changed to allow non-integer primary keys
 
-To accommodate models with non-integer primary keys, the URL patterns for the edit and delete views in {class}`~wagtail.admin.viewsets.model.ModelViewSet` have been changed.
+To accommodate models with non-integer primary keys, the URL patterns for the edit and delete views in `~wagtail.admin.viewsets.model.ModelViewSet` have been changed.
 
 Relative to the viewset's {attr}`~wagtail.admin.viewsets.base.ViewSet.url_prefix`, the following changes have been made:
 - The edit URL pattern has been changed from `<int:pk>/` to `edit/<str:pk>/`
@@ -310,7 +310,7 @@ If you use {func}`~django.urls.reverse` with {meth}`~wagtail.admin.viewsets.base
 
 Redirects for the legacy URLs are in place for backwards compatibility, but will be removed in a future release.
 
-The URLs for snippets underwent similar changes in Wagtail 2.14. The redirects for the legacy URLs in {class}`~wagtail.snippets.views.snippets.SnippetViewSet` have now been marked for removal in a future release.
+The URLs for snippets underwent similar changes in Wagtail 2.14. The redirects for the legacy URLs in `~wagtail.snippets.views.snippets.SnippetViewSet` have now been marked for removal in a future release.
 
 ### `ModelViewSet` automatically registers the model to the reference index
 

docs/topics/snippets/features.md

@@ -86,7 +86,7 @@ class Advert(PreviewableMixin, models.Model):
 
 ## Making snippets searchable
 
-If a snippet model inherits from {class}`wagtail.search.index.Indexed`, as described in [](wagtailsearch_indexing_models), Wagtail will automatically add a search box to the chooser interface for that snippet type. For example, the `Advert` snippet could be made searchable as follows:
+If a snippet model inherits from `wagtail.search.index.Indexed`, as described in [](wagtailsearch_indexing_models), Wagtail will automatically add a search box to the chooser interface for that snippet type. For example, the `Advert` snippet could be made searchable as follows:
 
 ```python
 # ...
@@ -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 {class}`taggit.manager.TaggableManager` should be used in the place of {class}`~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
 # ...

wagtail/documents/__init__.py

@@ -14,7 +14,7 @@ def get_document_model_string():
 def get_document_model():
     """
     Get the document model from the ``WAGTAILDOCS_DOCUMENT_MODEL`` setting.
-    Defaults to the standard :class:`~wagtail.documents.models.Document` model
+    Defaults to the standard `~wagtail.documents.models.Document` model
     if no custom model is defined.
     """
     from django.apps import apps

wagtail/images/__init__.py

@@ -15,7 +15,7 @@ def get_image_model():
     """
     Get the image model from the ``WAGTAILIMAGES_IMAGE_MODEL`` setting.
     Useful for developers making Wagtail plugins that need the image model.
-    Defaults to the standard :class:`~wagtail.images.models.Image` model
+    Defaults to the standard `~wagtail.images.models.Image` model
     if no custom model is defined.
     """
     from django.apps import apps