Remove Django 1.7 support from documentation, requirements and CI definitions

.travis.yml

@@ -6,17 +6,10 @@ sudo: false
 
 matrix:
   include:
-   - env: TOXENV=py27-dj17-postgres
-   - env: TOXENV=py27-dj17-sqlite
-   - env: TOXENV=py27-dj17-mysql
-   - env: TOXENV=py33-dj17-postgres
-   - env: TOXENV=py34-dj17-postgres
-   - env: TOXENV=py34-dj17-sqlite
-   - env: TOXENV=py34-dj17-mysql
    - env: TOXENV=py27-dj18-postgres
-#   - env: TOXENV=py27-dj18-mysql
-#   - env: TOXENV=py27-dj18-sqlite
-#  - env: TOXENV=py33-dj18-postgres
+   - env: TOXENV=py27-dj18-mysql
+   - env: TOXENV=py27-dj18-sqlite
+   - env: TOXENV=py33-dj18-postgres
    - env: TOXENV=py34-dj18-postgres
    - env: TOXENV=py34-dj18-sqlite
    - env: TOXENV=py34-dj18-mysql

README.rst

@@ -69,7 +69,7 @@ Wagtail is sponsored by `Torchbox <https://torchbox.com/>`_. If you need help im
 
 Compatibility
 ~~~~~~~~~~~~~
-Wagtail supports Django 1.7.1+ on Python 2.7, 3.3, 3.4 and 3.5. Supported database backends are PostgreSQL, MySQL and SQLite.
+Wagtail supports Django 1.8.1+ on Python 2.7, 3.3, 3.4 and 3.5. Supported database backends are PostgreSQL, MySQL and SQLite.
 
 Contributing
 ~~~~~~~~~~~~

docs/getting_started/integrating_into_django.rst

@@ -5,7 +5,7 @@ Integrating Wagtail into a Django project
 
 Wagtail provides the ``wagtail start`` command and project template to get you started with a new Wagtail project as quickly as possible, but it's easy to integrate Wagtail into an existing Django project too.
 
-Wagtail is currently compatible with Django 1.7 and 1.8. First, install the ``wagtail`` package from PyPI::
+Wagtail is currently compatible with Django 1.8 and 1.9. First, install the ``wagtail`` package from PyPI::
 
     pip install wagtail
 

docs/reference/contrib/frontendcache.rst

@@ -28,17 +28,9 @@ Firstly, add ``"wagtail.contrib.wagtailfrontendcache"`` to your INSTALLED_APPS:
 
 .. versionchanged:: 0.8
 
-    Signal handlers are now automatically registered in Django 1.7 and upwards
+    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.
-
-If you are using Django version 1.7 or newer, these signal handlers are automatically registered when the ``wagtail.contrib.wagtailfrontendcache`` app is loaded. Otherwise, they must be registered as your application starts up. This can be done by placing the following code in your ``urls.py``:
-
-.. code-block:: python
-
-    # urls.py
-    from wagtail.contrib.wagtailfrontendcache.signal_handlers import register_signal_handlers
-    register_signal_handlers()
+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.wagtailfrontendcache`` app is loaded.
 
 
 Varnish/Squid

docs/topics/pages.rst

@@ -4,15 +4,15 @@ Page models
 
 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.wagtailcore.models.Page` class.
 
-As all page types are Django models, you can use any field type that Django provides. See `Model field reference <https://docs.djangoproject.com/en/1.7/ref/models/fields/>`_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.wagtailcore.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 <https://docs.djangoproject.com/en/1.9/ref/models/fields/>`_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.wagtailcore.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content.
 
 
 .. topic:: Django models
 
     If you're not yet familiar with Django models, have a quick look at the following links to get you started:
 
-    * `Creating models <https://docs.djangoproject.com/en/1.7/intro/tutorial01/#creating-models>`_
-    * `Model syntax <https://docs.djangoproject.com/en/1.7/topics/db/models/>`_
+    * `Creating models <https://docs.djangoproject.com/en/1.9/intro/tutorial02/#creating-models>`_
+    * `Model syntax <https://docs.djangoproject.com/en/1.9/topics/db/models/>`_
 
 
 An example Wagtail page model

docs/topics/search/indexing.rst

@@ -26,17 +26,9 @@ Signal handlers
 
 .. versionchanged:: 0.8
 
-    Signal handlers are now automatically registered in Django 1.7 and upwards
+    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``.
-
-If you are using Django version 1.7 or newer, these signal handlers are automatically registered when the ``wagtail.wagtailsearch`` app is loaded. Otherwise, they must be registered as your application starts up. This can be done by placing the following code in your ``urls.py``:
-
-.. code-block:: python
-
-    # urls.py
-    from wagtail.wagtailsearch.signal_handlers import register_signal_handlers
-    register_signal_handlers()
+``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.wagtailsearch`` app is loaded.
 
 
 The ``update_index`` command

docs/topics/streamfield.rst

@@ -618,7 +618,7 @@ 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 <https://docs.djangoproject.com/en/1.7/topics/migrations/#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 <https://docs.djangoproject.com/en/1.9/topics/migrations/#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.
 
 Migrating RichTextFields to StreamField
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

setup.py

@@ -21,7 +21,7 @@ except ImportError:
 
 
 install_requires = [
-    "Django>=1.7.1,<1.10",
+    "Django>=1.8.1,<1.10",
     "django-compressor>=1.4",
     "django-modelcluster>=1.1",
     "django-taggit>=0.17.5",
@@ -60,7 +60,6 @@ setup(
         'Programming Language :: Python :: 3.4',
         'Programming Language :: Python :: 3.5',
         'Framework :: Django',
-        'Framework :: Django :: 1.7',
         'Framework :: Django :: 1.8',
         'Framework :: Django :: 1.9',
         'Topic :: Internet :: WWW/HTTP :: Site Management',

tox.ini

@@ -2,7 +2,7 @@
 skipsdist = True
 usedevelop = True
 
-envlist = py{27,33,34,35}-dj{17,18,19}-{sqlite,postgres,mysql}, flake8
+envlist = py{27,33,34,35}-dj{18,19}-{sqlite,postgres,mysql}, flake8
 
 [flake8]
 ignore = E501,E303
@@ -38,9 +38,8 @@ deps =
     jinja2==2.8
     coverage
 
-    dj17: Django>=1.7.1,<1.8
-    dj18: Django==1.8.7 # Temporily pinned to work around bug in Django 1.8.8
-    dj19: Django==1.9.0 # Temporily pinned to work around bug in Django 1.9.1
+    dj18: Django>=1.8.1,<1.9
+    dj19: Django>=1.9,<1.10
     postgres: psycopg2>=2.6
     mysql: mysqlclient==1.3.6