Refs #26601 -- Removed support for old-style middleware using settings.MIDDLEWARE_CLASSES.

docs/internals/deprecation.txt

@@ -571,7 +571,7 @@ details on these changes.
 
 * The ``SEND_BROKEN_LINK_EMAILS`` setting will be removed. Add the
   :class:`django.middleware.common.BrokenLinkEmailsMiddleware` middleware to
-  your :setting:`MIDDLEWARE_CLASSES` setting instead.
+  your ``MIDDLEWARE_CLASSES`` setting instead.
 
 * ``django.middleware.doc.XViewMiddleware`` will be removed. Use
   ``django.contrib.admindocs.middleware.XViewMiddleware`` instead.

docs/ref/checks.txt

@@ -323,19 +323,19 @@ The following checks are run if you use the :option:`check --deploy` option:
 
 * **security.W001**: You do not have
   :class:`django.middleware.security.SecurityMiddleware` in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES` so the :setting:`SECURE_HSTS_SECONDS`,
+  :setting:`MIDDLEWARE` so the :setting:`SECURE_HSTS_SECONDS`,
   :setting:`SECURE_CONTENT_TYPE_NOSNIFF`, :setting:`SECURE_BROWSER_XSS_FILTER`,
   and :setting:`SECURE_SSL_REDIRECT` settings will have no effect.
 * **security.W002**: You do not have
   :class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, so your pages will not be served with an
+  :setting:`MIDDLEWARE`, so your pages will not be served with an
   ``'x-frame-options'`` header. Unless there is a good reason for your
   site to be served in a frame, you should consider enabling this
   header to help prevent clickjacking attacks.
 * **security.W003**: You don't appear to be using Django's built-in cross-site
   request forgery protection via the middleware
   (:class:`django.middleware.csrf.CsrfViewMiddleware` is not in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`). Enabling the middleware is the safest
+  :setting:`MIDDLEWARE`). Enabling the middleware is the safest
   approach to ensure you don't leave any holes.
 * **security.W004**: You have not set a value for the
   :setting:`SECURE_HSTS_SECONDS` setting. If your entire site is served only
@@ -372,10 +372,9 @@ The following checks are run if you use the :option:`check --deploy` option:
   sessions.
 * **security.W011**: You have
   :class:`django.contrib.sessions.middleware.SessionMiddleware` in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
-  :setting:`SESSION_COOKIE_SECURE` to ``True``. Using a secure-only session
-  cookie makes it more difficult for network traffic sniffers to hijack user
-  sessions.
+  :setting:`MIDDLEWARE`, but you have not set :setting:`SESSION_COOKIE_SECURE`
+  to ``True``. Using a secure-only session cookie makes it more difficult for
+  network traffic sniffers to hijack user sessions.
 * **security.W012**: :setting:`SESSION_COOKIE_SECURE` is not set to ``True``.
   Using a secure-only session cookie makes it more difficult for network traffic
   sniffers to hijack user sessions.
@@ -386,10 +385,9 @@ The following checks are run if you use the :option:`check --deploy` option:
   sessions.
 * **security.W014**: You have
   :class:`django.contrib.sessions.middleware.SessionMiddleware` in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but you have not set
-  :setting:`SESSION_COOKIE_HTTPONLY` to ``True``. Using an ``HttpOnly`` session
-  cookie makes it more difficult for cross-site scripting attacks to hijack user
-  sessions.
+  :setting:`MIDDLEWARE`, but you have not set :setting:`SESSION_COOKIE_HTTPONLY`
+  to ``True``. Using an ``HttpOnly`` session cookie makes it more difficult for
+  cross-site scripting attacks to hijack user sessions.
 * **security.W015**: :setting:`SESSION_COOKIE_HTTPONLY` is not set to ``True``.
   Using an ``HttpOnly`` session cookie makes it more difficult for cross-site
   scripting attacks to hijack user sessions.
@@ -405,7 +403,7 @@ The following checks are run if you use the :option:`check --deploy` option:
   deployment.
 * **security.W019**: You have
   :class:`django.middleware.clickjacking.XFrameOptionsMiddleware` in your
-  :setting:`MIDDLEWARE`/:setting:`MIDDLEWARE_CLASSES`, but :setting:`X_FRAME_OPTIONS` is not set to
+  :setting:`MIDDLEWARE`, but :setting:`X_FRAME_OPTIONS` is not set to
   ``'DENY'``. The default is ``'SAMEORIGIN'``, but unless there is a good reason
   for your site to serve other parts of itself in a frame, you should change
   it to ``'DENY'``.

docs/ref/settings.txt

@@ -9,9 +9,9 @@ Settings
 .. warning::
 
     Be careful when you override settings, especially when the default value
-    is a non-empty list or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
-    and :setting:`STATICFILES_FINDERS`. Make sure you keep the components
-    required by the features of Django you wish to use.
+    is a non-empty list or dictionary, such as :setting:`STATICFILES_FINDERS`.
+    Make sure you keep the components required by the features of Django you
+    wish to use.
 
 Core Settings
 =============
@@ -1900,30 +1900,6 @@ Default:: ``None``
 
 A list of middleware to use. See :doc:`/topics/http/middleware`.
 
-.. setting:: MIDDLEWARE_CLASSES
-
-``MIDDLEWARE_CLASSES``
-----------------------
-
-.. deprecated:: 1.10
-
-    Old-style middleware that uses  ``settings.MIDDLEWARE_CLASSES`` are
-    deprecated. :ref:`Adapt old, custom middleware <upgrading-middleware>` and
-    use the :setting:`MIDDLEWARE` setting.
-
-Default::
-
-    [
-        'django.middleware.common.CommonMiddleware',
-        'django.middleware.csrf.CsrfViewMiddleware',
-    ]
-
-A list of middleware classes to use. This was the default setting used in
-Django 1.9 and earlier. Django 1.10 introduced a new style of middleware. If
-you have an older project using this setting you should :ref:`update any
-middleware you've written yourself <upgrading-middleware>` to the new style
-and then use the :setting:`MIDDLEWARE` setting.
-
 .. setting:: MIGRATION_MODULES
 
 ``MIGRATION_MODULES``
@@ -3411,7 +3387,6 @@ HTTP
 * :setting:`FORCE_SCRIPT_NAME`
 * :setting:`INTERNAL_IPS`
 * :setting:`MIDDLEWARE`
-* :setting:`MIDDLEWARE_CLASSES`
 * Security
 
   * :setting:`SECURE_BROWSER_XSS_FILTER`

docs/releases/1.2.txt

@@ -434,7 +434,7 @@ should be aware of:
      The upgrade notes have been removed in current Django docs. Please refer
      to the docs for Django 1.3 or older to find these instructions.
 
-* ``CsrfViewMiddleware`` is included in :setting:`MIDDLEWARE_CLASSES` by
+* ``CsrfViewMiddleware`` is included in ``MIDDLEWARE_CLASSES`` by
   default. This turns on CSRF protection by default, so views that accept
   POST requests need to be written to work with the middleware. Instructions
   on how to do this are found in the CSRF docs.

docs/releases/1.6.txt

@@ -1060,7 +1060,7 @@ out into a new middleware:
 
 If you're relying on this feature, you should add
 ``'django.middleware.common.BrokenLinkEmailsMiddleware'`` to your
-:setting:`MIDDLEWARE_CLASSES` setting and remove ``SEND_BROKEN_LINK_EMAILS``
+``MIDDLEWARE_CLASSES`` setting and remove ``SEND_BROKEN_LINK_EMAILS``
 from your settings.
 
 ``_has_changed`` method on widgets

docs/releases/1.7.txt

@@ -1271,13 +1271,13 @@ in a test class which is a subclass of
 :class:`~django.test.TransactionTestCase` rather than
 :class:`~django.test.TestCase`.
 
-Contrib middleware removed from default :setting:`MIDDLEWARE_CLASSES`
----------------------------------------------------------------------
+Contrib middleware removed from default ``MIDDLEWARE_CLASSES``
+--------------------------------------------------------------
 
 The :ref:`app-loading refactor <app-loading-refactor-17-release-note>`
 deprecated using models from apps which are not part of the
 :setting:`INSTALLED_APPS` setting. This exposed an incompatibility between
-the default :setting:`INSTALLED_APPS` and :setting:`MIDDLEWARE_CLASSES` in the
+the default :setting:`INSTALLED_APPS` and ``MIDDLEWARE_CLASSES`` in the
 global defaults (``django.conf.global_settings``). To bring these settings in
 sync and prevent deprecation warnings when doing things like testing reusable
 apps with minimal settings,
@@ -1287,7 +1287,7 @@ apps with minimal settings,
 from the defaults. These classes will still be included in the default settings
 generated by :djadmin:`startproject`. Most projects will not be affected by
 this change but if you were not previously declaring the
-:setting:`MIDDLEWARE_CLASSES` in your project settings and relying on the
+``MIDDLEWARE_CLASSES`` in your project settings and relying on the
 global default you should ensure that the new defaults are in line with your
 project's needs. You should also check for any code that accesses
 ``django.conf.global_settings.MIDDLEWARE_CLASSES`` directly.

docs/releases/1.8.txt

@@ -1641,7 +1641,7 @@ Using ``AuthenticationMiddleware`` without ``SessionAuthenticationMiddleware``
 added in Django 1.7. In Django 1.7.2, its functionality was moved to
 ``auth.get_user()`` and, for backwards compatibility, enabled only if
 ``'django.contrib.auth.middleware.SessionAuthenticationMiddleware'`` appears in
-:setting:`MIDDLEWARE_CLASSES`.
+``MIDDLEWARE_CLASSES``.
 
 In Django 1.10, session verification will be enabled regardless of whether or not
 ``SessionAuthenticationMiddleware`` is enabled (at which point

docs/releases/2.0.txt

@@ -390,3 +390,6 @@ these features.
 * Model ``Manager`` inheritance follows MRO inheritance rules. The requirement
   to use ``Meta.manager_inheritance_from_future`` to opt-in to the behavior is
   removed.
+
+* Support for old-style middleware using ``settings.MIDDLEWARE_CLASSES`` is
+  removed.

docs/topics/http/middleware.txt

@@ -16,16 +16,6 @@ how to write your own middleware. Django ships with some built-in middleware
 you can use right out of the box. They're documented in the :doc:`built-in
 middleware reference </ref/middleware>`.
 
-.. versionchanged:: 1.10
-
-    A new style of middleware was introduced for use with the new
-    :setting:`MIDDLEWARE` setting. If you're using the old
-    :setting:`MIDDLEWARE_CLASSES` setting, you'll need to :ref:`adapt old,
-    custom middleware <upgrading-middleware>` before using the new setting.
-    This document describes new-style middleware. Refer to this page in older
-    versions of the documentation for a description of how old-style middleware
-    works.
-
 Writing your own middleware
 ===========================
 
@@ -311,7 +301,7 @@ Upgrading pre-Django 1.10-style middleware
 
 Django provides ``django.utils.deprecation.MiddlewareMixin`` to ease creating
 middleware classes that are compatible with both :setting:`MIDDLEWARE` and the
-old :setting:`MIDDLEWARE_CLASSES`. All middleware classes included with Django
+old ``MIDDLEWARE_CLASSES``. All middleware classes included with Django
 are compatible with both settings.
 
 The mixin provides an ``__init__()`` method that accepts an optional
@@ -325,7 +315,7 @@ The ``__call__()`` method:
 #. Calls ``self.process_response(request, response)`` (if defined).
 #. Returns the response.
 
-If used with :setting:`MIDDLEWARE_CLASSES`, the ``__call__()`` method will
+If used with ``MIDDLEWARE_CLASSES``, the ``__call__()`` method will
 never be used; Django calls ``process_request()`` and ``process_response()``
 directly.
 
@@ -336,9 +326,9 @@ even beneficial to the existing middleware. In a few cases, a middleware class
 may need some changes to adjust to the new semantics.
 
 These are the behavioral differences between using :setting:`MIDDLEWARE` and
-:setting:`MIDDLEWARE_CLASSES`:
+``MIDDLEWARE_CLASSES``:
 
-1. Under :setting:`MIDDLEWARE_CLASSES`, every middleware will always have its
+1. Under ``MIDDLEWARE_CLASSES``, every middleware will always have its
    ``process_response`` method called, even if an earlier middleware
    short-circuited by returning a response from its ``process_request``
    method. Under :setting:`MIDDLEWARE`, middleware behaves more like an onion:
@@ -347,7 +337,7 @@ These are the behavioral differences between using :setting:`MIDDLEWARE` and
    that middleware and the ones before it in :setting:`MIDDLEWARE` will see the
    response.
 
-2. Under :setting:`MIDDLEWARE_CLASSES`, ``process_exception`` is applied to
+2. Under ``MIDDLEWARE_CLASSES``, ``process_exception`` is applied to
    exceptions raised from a middleware ``process_request`` method. Under
    :setting:`MIDDLEWARE`, ``process_exception`` applies only to exceptions
    raised from the view (or from the ``render`` method of a
@@ -355,7 +345,7 @@ These are the behavioral differences between using :setting:`MIDDLEWARE` and
    a middleware are converted to the appropriate HTTP response and then passed
    to the next middleware.
 
-3. Under :setting:`MIDDLEWARE_CLASSES`, if a ``process_response`` method raises
+3. Under ``MIDDLEWARE_CLASSES``, if a ``process_response`` method raises
    an exception, the ``process_response`` methods of all earlier middleware are
    skipped and a ``500 Internal Server Error`` HTTP response is always
    returned (even if the exception raised was e.g. an