Update Django intersphinx references to new format

docs/advanced_topics/add_to_django_project.md

@@ -1,6 +1,6 @@
 # How to add Wagtail into an existing Django project
 
-To install Wagtail completely from scratch, create a new Django project and an app within that project. For instructions on these tasks, see [Writing your first Django app](django:intro/tutorial01). Your project directory will look like the following:
+To install Wagtail completely from scratch, create a new Django project and an app within that project. For instructions on these tasks, see [Writing your first Django app](inv:django#intro/tutorial01). Your project directory will look like the following:
 
 ```
 myproject/
@@ -18,7 +18,7 @@ myproject/
     manage.py
 ```
 
-From your app directory, you can safely remove `admin.py` and `views.py`, since Wagtail will provide this functionality for your models. Configuring Django to load Wagtail involves adding modules and variables to `settings.py` and URL configuration to `urls.py`. For a more complete view of what's defined in these files, see [Django Settings](django:topics/settings) and [Django URL Dispatcher](django:topics/http/urls).
+From your app directory, you can safely remove `admin.py` and `views.py`, since Wagtail will provide this functionality for your models. Configuring Django to load Wagtail involves adding modules and variables to `settings.py` and URL configuration to `urls.py`. For a more complete view of what's defined in these files, see [Django Settings](inv:django#topics/settings) and [Django URL Dispatcher](inv:django#topics/http/urls).
 
 What follows is a settings reference which skips many boilerplate Django settings. If you just want to get your Wagtail install up quickly without fussing with settings at the moment, see [](complete_example_config).
 

docs/advanced_topics/customisation/streamfield_blocks.md

@@ -255,4 +255,4 @@ As with any model field in Django, any changes to a model definition that affect
 
 To mitigate this, StructBlock, StreamBlock and ChoiceBlock implement additional logic to ensure that any subclasses of these blocks are deconstructed to plain instances of StructBlock, StreamBlock and ChoiceBlock -- in this way, the migrations avoid having any references to your custom class definitions. This is possible because these block types provide a standard pattern for inheritance, and know how to reconstruct the block definition for any subclass that follows that pattern.
 
-If you subclass any other block class, such as `FieldBlock`, you will need to either keep that class definition in place for the lifetime of your project, or implement a [custom deconstruct method](django:custom-deconstruct-method) that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customise a StructBlock, StreamBlock or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own `deconstruct` method.
+If you subclass any other block class, such as `FieldBlock`, you will need to either keep that class definition in place for the lifetime of your project, or implement a [custom deconstruct method](inv:django#custom-deconstruct-method) that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customise a StructBlock, StreamBlock or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own `deconstruct` method.

docs/advanced_topics/deploying.md

@@ -4,7 +4,7 @@
 
 Once you've built your Wagtail site, it's time to release it upon the rest of the internet.
 
-Wagtail is built on Django, and so the vast majority of the deployment steps and considerations for deploying Django are also true for Wagtail. We recommend reading Django's ["How to deploy Django"](django:howto/deployment/index) documentation.
+Wagtail is built on Django, and so the vast majority of the deployment steps and considerations for deploying Django are also true for Wagtail. We recommend reading Django's ["How to deploy Django"](inv:django#howto/deployment/index) documentation.
 
 ## Infrastructure Requirements
 
@@ -14,12 +14,12 @@ When designing infrastructure for hosting a Wagtail site, there are a few basic
 
 > Django, being a web framework, needs a web server in order to operate. Since most web servers don’t natively speak Python, we need an interface to make that communication happen.
 
-Wagtail can be deployed using either [WSGI](django:howto/deployment/wsgi/index) or [ASGI](django:howto/deployment/asgi/index), however Wagtail doesn't natively implement any async views or middleware, so we recommend WSGI.
+Wagtail can be deployed using either [WSGI](inv:django#howto/deployment/wsgi/index) or [ASGI](inv:django#howto/deployment/asgi/index), however Wagtail doesn't natively implement any async views or middleware, so we recommend WSGI.
 
 ### Static files
 
 As with all Django projects, static files are only served by the Django application server during development, when running through the `manage.py runserver` command. In production, these need to be handled separately at the web server level.
-See [Django's documentation on deploying static files](django:howto/static-files/deployment).
+See [Django's documentation on deploying static files](inv:django#howto/static-files/deployment).
 
 The JavaScript and CSS files used by the Wagtail admin frequently change between releases of Wagtail - it's important to avoid serving outdated versions of these files due to browser or server-side caching, as this can cause hard-to-diagnose issues.
 We recommend enabling [ManifestStaticFilesStorage](django.contrib.staticfiles.storage.ManifestStaticFilesStorage) in the `STATICFILES_STORAGE` setting - this ensures that different versions of files are assigned distinct URLs.
@@ -28,7 +28,7 @@ We recommend enabling [ManifestStaticFilesStorage](django.contrib.staticfiles.st
 
 ### User Uploaded Files
 
-Wagtail follows [Django's conventions for managing uploaded files](django:topics/files).
+Wagtail follows [Django's conventions for managing uploaded files](inv:django#topics/files).
 So by default, Wagtail uses Django's built-in `FileSystemStorage` class which stores files on your site's server, in the directory specified by the `MEDIA_ROOT` setting.
 Alternatively, Wagtail can be configured to store uploaded images and documents on a cloud storage service such as Amazon S3;
 this is done through the [DEFAULT_FILE_STORAGE](https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-DEFAULT_FILE_STORAGE)
@@ -60,7 +60,7 @@ The django-storages Amazon S3 backends (`storages.backends.s3boto.S3BotoStorage`
 
 ### Cache
 
-Wagtail is designed to make huge advantage of Django's [cache framework](django:topics/cache) when available to accelerate page loads. The cache is especially useful for the Wagtail admin, which can't take advantage of conventional CDN caching.
+Wagtail is designed to make huge advantage of Django's [cache framework](inv:django#topics/cache) when available to accelerate page loads. The cache is especially useful for the Wagtail admin, which can't take advantage of conventional CDN caching.
 
 Wagtail supports any of Django's cache backend, however we recommend against using one tied to the specific process or environment Django is running (eg `FileBasedCache` or `LocMemCache`).
 
@@ -70,7 +70,7 @@ Wagtail, and by extension Django, can be deployed in many different ways on many
 
 ### Use Django's deployment checklist
 
-Django has a [deployment checklist](django:howto/deployment/checklist) which runs through everything you should have done or should be aware of before deploying a Django application.
+Django has a [deployment checklist](inv:django#howto/deployment/checklist) which runs through everything you should have done or should be aware of before deploying a Django application.
 
 ### Performance optimisation
 

docs/advanced_topics/documents/storing_and_serving.md

@@ -2,7 +2,7 @@
 
 # Storing and serving
 
-Wagtail follows [Django’s conventions for managing uploaded files](django:topics/files). For configuration of `FileSystemStorage` and more information on handling user uploaded files, see [](user_uploaded_files).
+Wagtail follows [Django’s conventions for managing uploaded files](inv:django#topics/files). For configuration of `FileSystemStorage` and more information on handling user uploaded files, see [](user_uploaded_files).
 
 ## File storage location
 

docs/advanced_topics/i18n.md

@@ -27,7 +27,7 @@ There are two options for managing translations across different languages in th
 
 This document only covers the internationalisation of content managed by Wagtail.
 For information on how to translate static content in template files, JavaScript
-code, etc, refer to the [Django internationalisation docs](django:topics/i18n/translation).
+code, etc, refer to the [Django internationalisation docs](inv:django#topics/i18n/translation).
 Or, if you are building a headless site, refer to the docs of the frontend framework you are using.
 
 ### Wagtail's approach to multi-lingual content

docs/advanced_topics/performance.md

@@ -135,4 +135,4 @@ Manually updating a page might not result in a change to its cache key, unless t
 
 ## Django
 
-Wagtail is built on Django. Many of the [performance tips](django:topics/performance) set out by Django are also applicable to Wagtail.
+Wagtail is built on Django. Many of the [performance tips](inv:django#topics/performance) set out by Django are also applicable to Wagtail.

docs/advanced_topics/testing.md

@@ -287,7 +287,7 @@ class MyPageTest(WagtailPageTestCase):
 
 ### Using `dumpdata`
 
-Creating [fixtures](django:howto/initial-data) for tests is best done by creating content in a development
+Creating [fixtures](inv:django#howto/initial-data) for tests is best done by creating content in a development
 environment, and using Django's [dumpdata](https://docs.djangoproject.com/en/stable/ref/django-admin/#django-admin-dumpdata) command.
 
 Note that by default `dumpdata` will represent `content_type` by the primary key; this may cause consistency issues when adding / removing models, as content types are populated separately from fixtures. To prevent this, use the `--natural-foreign` switch, which represents content types by `["app", "model"]` instead.

docs/advanced_topics/third_party_tutorials.md

@@ -102,7 +102,7 @@ the latest Wagtail versions.
 -   [How To Alternate Blocks in Your Django & Wagtail Templates](https://www.coderedcorp.com/blog/how-to-alternate-blocks-in-your-templates/) (19 February 2021)
 -   [Build a Blog With Wagtail CMS (second version)](https://www.accordbox.com/blog/build-blog-wagtail-cms-second-version-available/) (13 January 2021)
 -   [Migrate your Wagtail Website from wagtailtrans to the new wagtail-localize](https://www.cnc.io/en/blog/wagtailtrans-to-wagtail-localize-migration) (10 January 2021)
--   [How to Use the Wagtail CMS for Django: An Overview](https://steelkiwi.com/blog/how-to-use-the-wagtail-cms-for-django-an-overview/) (21 December 2020)
+-   [How to Use the Wagtail CMS for inv:django# An Overview](https://steelkiwi.com/blog/how-to-use-the-wagtail-cms-for-django-an-overview/) (21 December 2020)
 -   [Wagtail `modeladmin` and a dynamic panels list](https://kuttler.eu/code/wagtail-modeladmin-and-dynamic-panels-list/) (14 December 2020)
 -   [Install and Deploy Wagtail CMS on pythonanywhere.com](https://www.theinsidetrade.com/blog/install-and-deploy-wagtail-cms-pythonanywherecom/) (14 December 2020)
 -   [Overriding the admin CSS in Wagtail](https://www.yellowduck.be/posts/overriding-the-admin-css-in-wagtail/) (4 December 2020)

docs/contributing/developing.md

@@ -118,7 +118,7 @@ django-admin makemigrations --settings=wagtail.test.settings
 ### Testing against PostgreSQL
 
 ```{note}
-In order to run these tests, you must install the required modules for PostgreSQL as described in Django's [Databases documentation](django:ref/databases).
+In order to run these tests, you must install the required modules for PostgreSQL as described in Django's [Databases documentation](inv:django#ref/databases).
 ```
 
 By default, Wagtail tests against SQLite. You can switch to using PostgreSQL by
@@ -133,7 +133,7 @@ If you need to use a different user, password, host, or port, use the `PGUSER`,
 ### Testing against a different database
 
 ```{note}
-In order to run these tests, you must install the required client libraries and modules for the given database as described in Django's [Databases documentation](django:ref/databases) or the 3rd-party database backend's documentation.
+In order to run these tests, you must install the required client libraries and modules for the given database as described in Django's [Databases documentation](inv:django#ref/databases) or the 3rd-party database backend's documentation.
 ```
 
 If you need to test against a different database, set the `DATABASE_ENGINE`
@@ -282,7 +282,7 @@ export DJANGO_SETTINGS_MODULE=wagtail.test.settings_ui
 npm run storybook
 ```
 
-The last command will start Storybook at `http://localhost:6006/`. It will proxy specific requests to Django at `http://localhost:8000` by default. Use the `TEST_ORIGIN` environment variable to use a different port for Django: `TEST_ORIGIN=http://localhost:9000 npm run storybook`.
+The last command will start Storybook at `http://localhost:6006/`. It will proxy specific requests to Django at `http://localhost:8000` by default. Use the `TEST_ORIGIN` environment variable to use a different port for inv:django# `TEST_ORIGIN=http://localhost:9000 npm run storybook`.
 
 ## Compiling the documentation
 

docs/contributing/first_contribution_guide.md

@@ -32,7 +32,7 @@ One thing to keep in mind is that "scratching your own itch" can be a great moti
 
 Before you start contributing to Wagtail, it's important to understand what it is and how it works. Wagtail is a content management system (CMS) used for building websites. Unlike other CMSs, it requires some development time to build up the models and supporting code to use as a CMS. Additionally, Wagtail is built on top of another framework called Django, which is a Python web framework. This might be confusing at first, but it provides a powerful way to create custom systems for developers to build with.
 
-To get started, we recommend reading the [the Zen of Wagtail](../getting_started/the_zen_of_wagtail), which provides a good introduction to the project. You might also want to read the [Django overview](django:intro/overview) to understand what Django provides. To get a sense of how Wagtail fits into the CMS landscape, you can search online for articles that compare WordPress to Wagtail or list the top open source CMSs. Finally, reading some of the [Wagtail Guide](https://guide.wagtail.org/) will give you a better understanding of how the CMS works for everyday users.
+To get started, we recommend reading the [the Zen of Wagtail](../getting_started/the_zen_of_wagtail), which provides a good introduction to the project. You might also want to read the [Django overview](inv:django#intro/overview) to understand what Django provides. To get a sense of how Wagtail fits into the CMS landscape, you can search online for articles that compare WordPress to Wagtail or list the top open source CMSs. Finally, reading some of the [Wagtail Guide](https://guide.wagtail.org/) will give you a better understanding of how the CMS works for everyday users.
 
 ```{note}
 Below is a checklist. There are many like these you can copy for yourself as you progress through this guide.
@@ -319,7 +319,7 @@ It is best to avoid fixing more than one issue in a single pull request, unless
 
 Unless you are updating the documentation or only making visual style changes, your Pull Request should contain tests.
 
-If you are new to writing tests in Django, start by reading the [Django documentation on testing](django:topics/testing/overview). Re-read the [Wagtail documentation notes on testing](testing) and have a look at [existing tests](https://cs.github.com/?scopeName=All+repos&scope=&q=repo%3Awagtail%2Fwagtail+path%3A**%2Ftests%2F**).
+If you are new to writing tests in Django, start by reading the [Django documentation on testing](inv:django#topics/testing/overview). Re-read the [Wagtail documentation notes on testing](testing) and have a look at [existing tests](https://cs.github.com/?scopeName=All+repos&scope=&q=repo%3Awagtail%2Fwagtail+path%3A**%2Ftests%2F**).
 
 Note that the JavaScript testing is not as robust as the Python testing, if possible at least attempt to add some basic JS tests to new behaviour.
 

docs/contributing/translations.md

@@ -10,7 +10,7 @@ For translations and internationalisation of content made with Wagtail see [](in
 
 ## Translation workflow
 
-Wagtail is localised (translated) using Django's [translation system](django:topics/i18n/translation) and the translations are provided to and managed by [Transifex](https://www.transifex.com/), a web platform that helps organisations coordinate translation projects.
+Wagtail is localised (translated) using Django's [translation system](inv:django#topics/i18n/translation) and the translations are provided to and managed by [Transifex](https://www.transifex.com/), a web platform that helps organisations coordinate translation projects.
 
 Translations from Transifex are only integrated into the repository at the time of a new release. When a release is close to being ready there will be a RC (Release Candidate) for the upcoming version and the translations will be exported to Transifex.
 
@@ -38,7 +38,7 @@ These new translations are imported into Wagtail for any subsequent RC and the f
 
 ## Marking strings for translation
 
-In code, strings can be marked for translation with using Django's [translation system](django:topics/i18n/translation), using `gettext` or `gettext_lazy` in Python and `blocktranslate`, `translate`, and `_(" ")` in templates.
+In code, strings can be marked for translation with using Django's [translation system](inv:django#topics/i18n/translation), using `gettext` or `gettext_lazy` in Python and `blocktranslate`, `translate`, and `_(" ")` in templates.
 
 In both Python and templates, make sure to always use named placeholder. In addition, in Python, only use the printf style formatting. This is to ensure compatibility with Transifex and help translators in their work.
 
@@ -104,7 +104,7 @@ This still works fine. `trans` and `blocktrans` were the tags earlier on in Djan
 
 ## Additional resources
 
--   [](django:topics/i18n/translation)
+-   [](inv:django#topics/i18n/translation)
 -   A screen-share [Wagtail Space US 2020 Lightning Talk](https://www.youtube.com/watch?v=sLI_AuOMUQw&t=17s) that walks through using Transifex step-by-step
 -   [Core development instructions for syncing Wagtail translations with Transifex](https://github.com/wagtail/wagtail/wiki/Managing-Wagtail-translations)
--   [Django docs](django:topics/i18n/translation)
+-   [Django docs](inv:django#topics/i18n/translation)

docs/contributing/ui_guidelines.md

@@ -2,7 +2,7 @@
 
 Wagtail’s user interface is built with:
 
--   **HTML** using [Django templates](django:ref/templates/language)
+-   **HTML** using [Django templates](inv:django#ref/templates/language)
 -   **CSS** using [Sass](https://sass-lang.com/) and [Tailwind](https://tailwindcss.com/)
 -   **JavaScript** with [TypeScript](https://www.typescriptlang.org/)
 -   **SVG** for our icons, minified with [SVGO](https://jakearchibald.github.io/svgomg/)

docs/extending/extending_draftail.md

@@ -135,7 +135,7 @@ Entities aren’t simply formatting buttons in the toolbar. They usually need to
 -   Custom UIs in rich text can be brittle. Be ready to spend time **testing in multiple browsers**.
 
 The good news is that having such a low-level API will enable third-party Wagtail plugins to innovate on rich text features, proposing new kinds of experiences.
-But in the meantime, consider implementing your UI through [StreamField](../topics/streamfield.rst) instead, which has a battle-tested API meant for Django developers.
+But in the meantime, consider implementing your UI through [StreamField](../topics/streamfield) instead, which has a battle-tested API meant for Django developers.
 
 Here are the main requirements to create a new entity feature:
 
@@ -194,7 +194,7 @@ def register_stock_feature(features):
     })
 ```
 
-The `js` and `css` keyword arguments on `EntityFeature` can be used to specify additional JS and CSS files to load when this feature is active. Both are optional. Their values are added to a `Media` object, more documentation on these objects is available in the [Django Form Assets documentation](django:topics/forms/media).
+The `js` and `css` keyword arguments on `EntityFeature` can be used to specify additional JS and CSS files to load when this feature is active. Both are optional. Their values are added to a `Media` object, more documentation on these objects is available in the [Django Form Assets documentation](inv:django#topics/forms/media).
 
 Since entities hold data, the conversion to/from database format is more complicated. We have to create two handlers:
 

docs/extending/forms.md

@@ -1,6 +1,6 @@
 # Using forms in admin views
 
-[Django's forms framework](django:topics/forms/index) can be used within Wagtail admin views just like in any other Django app. However, Wagtail also provides various admin-specific form widgets, such as date/time pickers and choosers for pages, documents, images, and snippets. By constructing forms using `wagtail.admin.forms.models.WagtailAdminModelForm` as the base class instead of `django.forms.models.ModelForm`, the most appropriate widget will be selected for each model field. For example, given the model and form definition:
+[Django's forms framework](inv:django#topics/forms/index) can be used within Wagtail admin views just like in any other Django app. However, Wagtail also provides various admin-specific form widgets, such as date/time pickers and choosers for pages, documents, images, and snippets. By constructing forms using `wagtail.admin.forms.models.WagtailAdminModelForm` as the base class instead of `django.forms.models.ModelForm`, the most appropriate widget will be selected for each model field. For example, given the model and form definition:
 
 ```python
 from django.db import models

docs/extending/rich_text_internals.md

@@ -15,7 +15,7 @@ The components involved in Wagtail's rich text handling are described below.
 
 ## Data format
 
-Rich text data (as handled by [RichTextField](rich_text_field), and `RichTextBlock` within [StreamField](../topics/streamfield.rst)) is stored in the database in a format that is similar, but not identical, to HTML. For example, a link to a page might be stored as:
+Rich text data (as handled by [RichTextField](rich_text_field), and `RichTextBlock` within [StreamField](../topics/streamfield)) is stored in the database in a format that is similar, but not identical, to HTML. For example, a link to a page might be stored as:
 
 ```html
 <p><a linktype="page" id="3">Contact us</a> for more information.</p>

docs/getting_started/integrating_into_django.md

@@ -105,7 +105,7 @@ urlpatterns = [
 ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
 ```
 
-Note that this only works in development mode (`DEBUG = True`); in production, you have to configure your web server to serve files from `MEDIA_ROOT`. For further details, see the Django documentation: [Serving files uploaded by a user during development](https://docs.djangoproject.com/en/stable/howto/static-files/#serving-files-uploaded-by-a-user-during-development) and [Deploying static files](django:howto/static-files/deployment).
+Note that this only works in development mode (`DEBUG = True`); in production, you have to configure your web server to serve files from `MEDIA_ROOT`. For further details, see the Django documentation: [Serving files uploaded by a user during development](https://docs.djangoproject.com/en/stable/howto/static-files/#serving-files-uploaded-by-a-user-during-development) and [Deploying static files](inv:django#howto/static-files/deployment).
 
 With this configuration in place, you are ready to run `python manage.py migrate` to create the database tables used by Wagtail.
 

docs/getting_started/tutorial.md

@@ -225,7 +225,7 @@ Also, you must load `wagtailcore_tags` at the top of the template and provide ad
 
 ### Wagtail template tags
 
-In addition to Django's [template tags and filters](django:ref/templates/builtins),
+In addition to Django's [template tags and filters](inv:django#ref/templates/builtins),
 Wagtail provides a number of its own [template tags & filters](template_tags_and_filters),
 which you can load by including `{% load wagtailcore_tags %}` at the top of
 your template file.

docs/reference/contrib/forms/index.md

@@ -5,7 +5,7 @@
 The `wagtailforms` module allows you to set up single-page forms, such as a 'Contact us' form, as pages of a Wagtail site. It provides a set of base models that site implementers can extend to create their own `FormPage` type with their own site-specific templates. Once a page type has been set up in this way, editors can build forms within the usual page editor, consisting of any number of fields. Form submissions are stored for later retrieval through a new 'Forms' section within the Wagtail admin interface; in addition, they can be optionally e-mailed to an address specified by the editor.
 
 ```{note}
-**wagtailforms is not a replacement for** [Django's form support](django:topics/forms/index). It is designed as a way for page authors to build general-purpose data collection forms without having to write code. If you intend to build a form that assigns specific behaviour to individual fields (such as creating user accounts), or needs a custom HTML layout, you will almost certainly be better served by a standard Django form, where the fields are fixed in code rather than defined on-the-fly by a page author. See the [wagtail-form-example project](https://github.com/gasman/wagtail-form-example/commits/master) for an example of integrating a Django form into a Wagtail page.
+**wagtailforms is not a replacement for** [Django's form support](inv:django#topics/forms/index). It is designed as a way for page authors to build general-purpose data collection forms without having to write code. If you intend to build a form that assigns specific behaviour to individual fields (such as creating user accounts), or needs a custom HTML layout, you will almost certainly be better served by a standard Django form, where the fields are fixed in code rather than defined on-the-fly by a page author. See the [wagtail-form-example project](https://github.com/gasman/wagtail-form-example/commits/master) for an example of integrating a Django form into a Wagtail page.
 ```
 
 (form_builder_usage)=

docs/reference/contrib/routablepage.md

@@ -30,7 +30,7 @@ To use `RoutablePageMixin`, you need to make your class inherit from both :class
 
 These view methods behave like ordinary Django view functions, and must return an `HttpResponse` object; typically this is done through a call to `django.shortcuts.render`.
 
-The `path` and `re_path` decorators from `wagtail.contrib.routable_page.models.path` are similar to [the Django `django.urls` `path` and `re_path` functions](django:topics/http/urls). The former allows the use of plain paths and converters while the latter lets you specify your URL patterns as regular expressions.
+The `path` and `re_path` decorators from `wagtail.contrib.routable_page.models.path` are similar to [the Django `django.urls` `path` and `re_path` functions](inv:django#topics/http/urls). The former allows the use of plain paths and converters while the latter lets you specify your URL patterns as regular expressions.
 
 Here's an example of an `EventIndexPage` with three views, assuming that an `EventPage` model with an `event_date` field has been defined elsewhere:
 

docs/reference/hooks.md

@@ -6,7 +6,7 @@ On loading, Wagtail will search for any app with the file `wagtail_hooks.py` and
 
 ```{note}
 Hooks are typically used to customise the view-level behaviour of the Wagtail admin and front-end.
-For customisations that only deal with model-level behaviour - such as calling an external service when a page or document is added - it is often better to use [Django's signal mechanism](django:topics/signals) (see also: [Wagtail signals](signals)), as these are not dependent on a user taking a particular path through the admin interface.
+For customisations that only deal with model-level behaviour - such as calling an external service when a page or document is added - it is often better to use [Django's signal mechanism](inv:django#topics/signals) (see also: [Wagtail signals](signals)), as these are not dependent on a user taking a particular path through the admin interface.
 ```
 
 Registering functions with a Wagtail hook is done through the `@hooks.register` decorator:
@@ -270,7 +270,7 @@ def register_frank_menu_item():
 
 ### `register_admin_urls`
 
-Register additional admin page URLs. The callable fed into this hook should return a list of Django URL patterns which define the structure of the pages and endpoints of your extension to the Wagtail admin. For more about vanilla Django URLconfs and views, see [url dispatcher](django:topics/http/urls).
+Register additional admin page URLs. The callable fed into this hook should return a list of Django URL patterns which define the structure of the pages and endpoints of your extension to the Wagtail admin. For more about vanilla Django URLconfs and views, see [url dispatcher](inv:django#topics/http/urls).
 
 ```python
 from django.http import HttpResponse

docs/reference/pages/model_reference.md

@@ -505,7 +505,7 @@ The `translation_key` and `locale` fields have a unique key constraint to preven
 ```{note}
 This is currently enforced via {attr}`~django.db.models.Options.unique_together` in `TranslatableMixin.Meta`, but may be replaced with a {class}`~django.db.models.UniqueConstraint` in `TranslatableMixin.Meta.constraints` in the future.
 
-If your model defines a [`Meta` class](django:ref/models/options) (either with a new definition or inheriting `TranslatableMixin.Meta` explicitly), be mindful when setting `unique_together` or {attr}`~django.db.models.Options.constraints`. Ensure that there is either a `unique_together` or a `UniqueConstraint` (not both) on `translation_key` and `locale`. There is a system check for this.
+If your model defines a [`Meta` class](inv:django#ref/models/options) (either with a new definition or inheriting `TranslatableMixin.Meta` explicitly), be mindful when setting `unique_together` or {attr}`~django.db.models.Options.constraints`. Ensure that there is either a `unique_together` or a `UniqueConstraint` (not both) on `translation_key` and `locale`. There is a system check for this.
 ```
 
 ```{versionchanged} 6.0

docs/reference/pages/panels.md

@@ -317,7 +317,7 @@ The `MultipleChooserPanel` definition on `BlogPage` would be:
 ## Panel customisation
 
 By adding extra parameters to your panel/field definitions, you can control much of how your fields will display in the Wagtail page editing interface. Wagtail's page editing interface takes much of its behaviour from Django's admin, so you may find many options for customisation covered there.
-(See [Django model field reference](django:ref/models/fields)).
+(See [Django model field reference](inv:django#ref/models/fields)).
 
 (customising_panel_icons)=
 
@@ -358,7 +358,7 @@ Use the `help_text` argument to the panel constructor to customise the help text
 
 ### Placeholder text
 
-By default, Wagtail uses the field's label as placeholder text. To change it, pass to the `FieldPanel` a widget with a placeholder attribute set to your desired text. You can select widgets from [Django's form widgets](django:ref/forms/widgets), or any of the Wagtail's widgets found in `wagtail.admin.widgets`.
+By default, Wagtail uses the field's label as placeholder text. To change it, pass to the `FieldPanel` a widget with a placeholder attribute set to your desired text. You can select widgets from [Django's form widgets](inv:django#ref/forms/widgets), or any of the Wagtail's widgets found in `wagtail.admin.widgets`.
 
 For example, to customise placeholders for a `Book` snippet model:
 

docs/reference/settings.md

@@ -1,6 +1,6 @@
 # Settings
 
-Wagtail makes use of the following settings, in addition to [Django's core settings](django:ref/settings)`:
+Wagtail makes use of the following settings, in addition to [Django's core settings](inv:django#ref/settings)`:
 
 ## Sites
 

docs/reference/signals.md

@@ -1,6 +1,6 @@
 # Signals
 
-Wagtail's [](revision_model_ref) and [](page_model_ref) implement [Signals](django:topics/signals) from `django.dispatch`.
+Wagtail's [](revision_model_ref) and [](page_model_ref) implement [Signals](inv:django#topics/signals) from `django.dispatch`.
 Signals are useful for creating side-effects from page publish/unpublish events.
 
 For example, you could use signals to send publish notifications to a messaging service, or `POST` messages to another app that's consuming the API, such as a static site generator.
@@ -60,7 +60,7 @@ page_published.connect(receiver, sender=BlogPostPage)
 
 Wagtail provides access to a list of registered page types through the `get_page_models()` function in `wagtail.models`.
 
-Read the [Django documentation](django:topics/signals) for more information about specifying senders.
+Read the [Django documentation](inv:django#topics/signals) for more information about specifying senders.
 
 ## `page_unpublished`
 

docs/releases/3.0.md

@@ -197,7 +197,7 @@ Template paths have also been renamed accordingly - templates previously within
 
 Where possible, third-party packages that implement their own field panel types should be updated to allow using a plain `FieldPanel` instead, in line with Wagtail dropping its own special-purpose field panel types such as `StreamFieldPanel` and `ImageChooserPanel`. The steps for doing this will depend on the package's functionality, but in general:
 
- * If the panel sets a custom template, your code should instead define [a `Widget` class](django:ref/forms/widgets) that produces your desired HTML rendering.
+ * If the panel sets a custom template, your code should instead define [a `Widget` class](inv:django#ref/forms/widgets) that produces your desired HTML rendering.
  * If the panel provides a `widget_overrides` method, your code should instead call [`register_form_field_override`](/extending/forms) so that the desired widget is always selected for the relevant model field type.
  * If the panel provides a `get_comparison_class` method, your code should instead call `wagtail.admin.compare.register_comparison_class` to register the comparison class against the relevant model field type.
 

docs/releases/5.2.md

@@ -354,7 +354,7 @@ In most cases, the usage of those templates can be replaced with the `wagtailadm
 
 ### `BaseSidePanels`, `PageSidePanels` and `SnippetSidePanels` classes are removed
 
-The `BaseSidePanels`, `PageSidePanels` and `SnippetSidePanels` classes that were used to combine the side panels (i.e. status, preview and comments side panels) have been removed. Each side panel is now instantiated directly in the view. The `wagtail.admin.ui.components.MediaContainer` class can be used to combine the [`Media`](django:topics/forms/media) objects for the side panels.
+The `BaseSidePanels`, `PageSidePanels` and `SnippetSidePanels` classes that were used to combine the side panels (i.e. status, preview and comments side panels) have been removed. Each side panel is now instantiated directly in the view. The `wagtail.admin.ui.components.MediaContainer` class can be used to combine the [`Media`](inv:django#topics/forms/media) objects for the side panels.
 
 The `BasePreviewSidePanel`, `PagePreviewSidePanel` and `SnippetPreviewSidePanel` classes have been replaced with the consolidated `PreviewSidePanel` class.
 

docs/topics/pages.md

@@ -2,7 +2,7 @@
 
 Each page type (a.k.a. content type) in Wagtail is represented by a Django model. All page models must inherit from the {class}`wagtail.models.Page` class.
 
-As all page types are Django models, you can use any field type that Django provides. See [Model field reference](django:ref/models/fields) for a complete list of field types you can use. Wagtail also provides `wagtail.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content.
+As all page types are Django models, you can use any field type that Django provides. See [Model field reference](inv:django#ref/models/fields) for a complete list of field types you can use. Wagtail also provides `wagtail.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content.
 
 ```{note}
 If you're not yet familiar with Django models, have a quick look at the following links to get you started:
@@ -229,7 +229,7 @@ You just need to create a template in a location where it can be accessed with t
 
 ### Template context
 
-Wagtail renders templates with the `page` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, use `{{ page.title }}`. All variables provided by [context processors](https://docs.djangoproject.com/en/stable/ref/templates/api/#subclassing-context-requestcontext) are also available.
+Wagtail renders templates with the `page` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, use `{{ page.title }}`. All variables provided by [context processors](inv:django#subclassing-context-requestcontext) are also available.
 
 #### Customising template context
 
@@ -427,7 +427,7 @@ This will then make `related_links` available as a relation across all page type
 
 ## Working with pages
 
-Wagtail uses Django's [multi-table inheritance](https://docs.djangoproject.com/en/stable/topics/db/models/#multi-table-inheritance) feature to allow multiple page models to be used in the same tree.
+Wagtail uses Django's [multi-table inheritance](inv:django#meta-and-multi-table-inheritance) feature to allow multiple page models to be used in the same tree.
 
 Each page is added to both Wagtail's built-in {class}`~wagtail.models.Page` model as well as its user-defined model (such as the `BlogPage` model created earlier).
 

docs/topics/search/searching.md

@@ -6,7 +6,7 @@
 
 ## Searching QuerySets
 
-Wagtail search is built on Django's [QuerySet API](django:ref/models/querysets). You should be able to search any Django QuerySet provided the model and the fields being filtered on have been added to the search index.
+Wagtail search is built on Django's [QuerySet API](inv:django#ref/models/querysets). You should be able to search any Django QuerySet provided the model and the fields being filtered on have been added to the search index.
 
 ### Searching Pages
 
@@ -261,7 +261,7 @@ support writing phrase queries by wrapping the phrase with double-quotes. In add
 add filters into the query using the colon syntax (`hello world published:yes`).
 
 These two features can be implemented using the `parse_query_string` utility function. This function takes a query string that a user
-typed and returns a query object and a [QueryDict](django:django.http.QueryDict) of filters:
+typed and returns a query object and a [QueryDict](inv:django#django.http.QueryDict) of filters:
 
 For example:
 

docs/topics/snippets/rendering.md

@@ -6,7 +6,7 @@ As Django models, snippets can be rendered in Django templates using a custom te
 
 ## Including snippets in template tags
 
-The simplest way to make your snippets available to templates is with a template tag. This is mostly done with vanilla Django, so perhaps reviewing Django's documentation for [custom template tags](django:howto/custom-template-tags) will be more helpful. We'll go over the basics, though, and point out any considerations to make for Wagtail.
+The simplest way to make your snippets available to templates is with a template tag. This is mostly done with vanilla Django, so perhaps reviewing Django's documentation for [custom template tags](inv:django#howto/custom-template-tags) will be more helpful. We'll go over the basics, though, and point out any considerations to make for Wagtail.
 
 First, add a new Python file to a `templatetags` folder within your app - for example, `myproject/demo/templatetags/demo_tags.py`. We'll need to load some Django modules and our app's models, and ready the `register` decorator:
 

docs/topics/writing_templates.md

@@ -3,10 +3,10 @@
 # Writing templates
 
 Wagtail uses Django's templating language. For developers new to Django, start with Django's own template documentation:
-[](django:topics/templates)
+[](inv:django#topics/templates)
 
 Python programmers new to Django/Wagtail may prefer more technical documentation:
-[](django:ref/templates/api)
+[](inv:django#ref/templates/api)
 
 You should be familiar with Django templating basics before continuing with this documentation.
 
@@ -29,7 +29,7 @@ name_of_project/
         models.py
 ```
 
-For more information, see the Django documentation for the [application directories template loader](django:ref/templates/api).
+For more information, see the Django documentation for the [application directories template loader](inv:django#ref/templates/api).
 
 ### Page content
 
@@ -72,7 +72,7 @@ Read more about the image manipulation syntax here: [](image_tag).
 
 ## Template tags & filters
 
-In addition to Django's standard tags and filters, Wagtail provides some of its own, which can be `load`-ed [just like any other](django:howto/custom-template-tags).
+In addition to Django's standard tags and filters, Wagtail provides some of its own, which can be `load`-ed [just like any other](inv:django#howto/custom-template-tags).
 
 ## Images (tag)