From 5bd47f46d41b96183e4b2fb981f549c0bd4acacc Mon Sep 17 00:00:00 2001 From: Matt Westcott Date: Tue, 15 May 2018 14:54:41 +0100 Subject: [PATCH] Remove ancient versionchanged notes --- docs/advanced_topics/jinja2.rst | 4 ---- docs/reference/contrib/frontendcache.rst | 13 ------------- docs/reference/contrib/searchpromotions.rst | 4 ---- docs/reference/hooks.rst | 4 ---- docs/reference/pages/panels.rst | 8 -------- docs/topics/search/backends.rst | 8 -------- docs/topics/search/indexing.rst | 4 ---- 7 files changed, 45 deletions(-) diff --git a/docs/advanced_topics/jinja2.rst b/docs/advanced_topics/jinja2.rst index 671cb63b4..fc77011dd 100644 --- a/docs/advanced_topics/jinja2.rst +++ b/docs/advanced_topics/jinja2.rst @@ -9,10 +9,6 @@ Wagtail supports Jinja2 templating for all front end features. More information Configuring Django ================== -.. versionchanged:: 1.3 - - Jinja2 tags were moved from "templatetags" into "jinja2tags" to separate them from Django template tags. - Django needs to be configured to support Jinja2 templates. As the Wagtail admin is written using regular Django templates, Django has to be configured to use both templating engines. Add the following configuration to the ``TEMPLATES`` setting for your app: .. code-block:: python diff --git a/docs/reference/contrib/frontendcache.rst b/docs/reference/contrib/frontendcache.rst index 419fa7afe..b1ba18eed 100644 --- a/docs/reference/contrib/frontendcache.rst +++ b/docs/reference/contrib/frontendcache.rst @@ -3,15 +3,6 @@ Frontend cache invalidator ========================== -.. versionchanged:: 0.7 - - * Multiple backend support added - * Cloudflare support added - -.. versionchanged:: 1.7 - - * Amazon CloudFront support added - Many websites use a frontend cache such as Varnish, Squid, Cloudflare or CloudFront to gain extra performance. The downside of using a frontend cache though is that they don't respond well to updating content and will often keep an old version of a page cached after it has been updated. This document describes how to configure Wagtail to purge old versions of pages from a frontend cache whenever a page gets updated. @@ -30,10 +21,6 @@ Firstly, add ``"wagtail.contrib.frontend_cache"`` to your INSTALLED_APPS: "wagtail.contrib.frontend_cache" ] -.. versionchanged:: 0.8 - - Signal handlers are now automatically registered - The ``wagtailfrontendcache`` module provides a set of signal handlers which will automatically purge the cache whenever a page is published or deleted. These signal handlers are automatically registered when the ``wagtail.contrib.frontend_cache`` app is loaded. diff --git a/docs/reference/contrib/searchpromotions.rst b/docs/reference/contrib/searchpromotions.rst index f71bfd789..69397fe60 100644 --- a/docs/reference/contrib/searchpromotions.rst +++ b/docs/reference/contrib/searchpromotions.rst @@ -6,10 +6,6 @@ Promoted search results .. module:: wagtail.contrib.search_promotions -.. versionchanged:: 1.1 - - Before Wagtail 1.1, promoted search results were implemented in the :mod:`wagtail.search` core module and called "editors picks". - The ``searchpromotions`` module provides the models and user interface for managing "Promoted search results" and displaying them in a search results page. "Promoted search results" allow editors to explicitly link relevant content to search terms, so results pages can contain curated content in addition to results from the search engine. diff --git a/docs/reference/hooks.rst b/docs/reference/hooks.rst index 46fa91c0f..082c34526 100644 --- a/docs/reference/hooks.rst +++ b/docs/reference/hooks.rst @@ -526,10 +526,6 @@ Hooks for customising the way users are directed through the process of creating ``construct_wagtail_userbar`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - .. versionchanged:: 1.0 - - The hook was renamed from ``construct_wagtail_edit_bird`` - Add or remove items from the wagtail userbar. Add, edit, and moderation tools are provided by default. The callable passed into the hook must take the ``request`` object and a list of menu objects, ``items``. The menu item objects must have a ``render`` method which can take a ``request`` object and return the HTML string representing the menu item. See the userbar templates and menu item classes for more information. .. code-block:: python diff --git a/docs/reference/pages/panels.rst b/docs/reference/pages/panels.rst index 0bd23b0a5..a9891b86a 100644 --- a/docs/reference/pages/panels.rst +++ b/docs/reference/pages/panels.rst @@ -213,10 +213,6 @@ DocumentChooserPanel SnippetChooserPanel ------------------- -.. versionchanged:: 1.1 - - Before Wagtail 1.1, it was necessary to pass the snippet model class as a second parameter to ``SnippetChooserPanel``. This is now automatically picked up from the field. - .. module:: wagtail.snippets.edit_handlers .. class:: SnippetChooserPanel(field_name, snippet_type=None) @@ -359,10 +355,6 @@ The ``RelatedLink`` class is a vanilla Django abstract model. The ``BookPageRela The ``relation_name`` is the ``related_name`` label given to the cluster's ``ParentalKey`` relation. You can add the ``panels`` manually or make them part of the cluster model. ``heading`` and ``help_text`` provide a heading and caption, respectively, for the Wagtail editor. ``label`` sets the text on the add button, and is used as the heading when ``heading`` is not present. Finally, ``min_num`` and ``max_num`` allow you to set the minimum/maximum number of forms that the user must submit. -.. versionchanged:: 1.0 - - In previous versions, it was necessary to pass the base model as the first parameter to :class:`~wagtail.admin.edit_handlers.InlinePanel`; this is no longer required. - For another example of using model clusters, see :ref:`tagging` For more on ``django-modelcluster``, visit `the django-modelcluster github project page`_. diff --git a/docs/topics/search/backends.rst b/docs/topics/search/backends.rst index ac4bdd96f..92134482f 100644 --- a/docs/topics/search/backends.rst +++ b/docs/topics/search/backends.rst @@ -89,14 +89,6 @@ See :ref:`postgres_search` for more detail. Elasticsearch Backend --------------------- -.. versionchanged:: 1.7 - - Support for Elasticsearch 2.x was added - -.. versionchanged:: 1.8 - - Support for Elasticsearch 5.x was added - .. versionchanged:: 2.1 Support for Elasticsearch 6.x was added diff --git a/docs/topics/search/indexing.rst b/docs/topics/search/indexing.rst index 3d8ff6c9f..8041df627 100644 --- a/docs/topics/search/indexing.rst +++ b/docs/topics/search/indexing.rst @@ -24,10 +24,6 @@ If the search index is kept separate from the database (when using Elasticsearch Signal handlers --------------- -.. versionchanged:: 0.8 - - Signal handlers are now automatically registered - ``wagtailsearch`` provides some signal handlers which bind to the save/delete signals of all indexed models. This would automatically add and delete them from all backends you have registered in ``WAGTAILSEARCH_BACKENDS``. These signal handlers are automatically registered when the ``wagtail.search`` app is loaded.