Alphabetized system check reference.

1 files changed, 261 insertions, 266 deletions

diff --git a/docs/ref/checks.txt b/docs/ref/checks.txt
index f8e5522a2b..d5d0bd4e0f 100644
--- a/docs/ref/checks.txt
+++ b/docs/ref/checks.txt
@@ -11,7 +11,7 @@ The framework is extensible so you can easily add your own checks.
 For details on how to add your own checks and integrate them with Django's
 system checks, see the :doc:`System check topic guide </topics/checks>`.
 
-API Reference
+API reference
 =============
 
 ``CheckMessage``
@@ -66,88 +66,81 @@ class name.
 .. class:: Error(msg, hint=None, obj=None, id=None)
 .. class:: Critical(msg, hint=None, obj=None, id=None)
 
-Builtin checks
-==============
-
 .. _system-check-builtin-tags:
 
 Builtin tags
-------------
+============
 
 Django's system checks are organized using the following tags:
 
-* ``models``: Checks governing model, field and manager definitions.
-* ``signals``: Checks on signal declarations and handler registrations.
 * ``admin``: Checks of any admin site declarations.
-* ``compatibility``: Flagging potential problems with version upgrades.
-* ``security``: Checks security related configuration.
-* ``templates``: Checks template related configuration.
 * ``caches``: Checks cache related configuration.
-* ``urls``: Checks URL configuration.
+* ``compatibility``: Flags potential problems with version upgrades.
 * ``database``: Checks database-related configuration issues. Database checks
   are not run by default because they do more than static code analysis as
   regular checks do. They are only run by the :djadmin:`migrate` command or if
   you specify the ``database`` tag when calling the :djadmin:`check` command.
-
-.. versionadded:: 1.10
-
-    The ``database`` tag was added.
+* ``models``: Checks of model, field, and manager definitions.
+* ``security``: Checks security related configuration.
+* ``signals``: Checks on signal declarations and handler registrations.
+* ``templates``: Checks template related configuration.
+* ``urls``: Checks URL configuration.
 
 Some checks may be registered with multiple tags.
 
 Core system checks
-------------------
+==================
 
-Models
-~~~~~~
+Backwards compatibility
+-----------------------
 
-* **models.E001**: ``<swappable>`` is not of the form ``app_label.app_name``.
-* **models.E002**: ``<SETTING>`` references ``<model>``, which has not been
-  installed, or is abstract.
-* **models.E003**: The model has two many-to-many relations through the
-  intermediate model ``<app_label>.<model>``.
-* **models.E004**: ``id`` can only be used as a field name if the field also
-  sets ``primary_key=True``.
-* **models.E005**: The field ``<field name>`` from parent model ``<model>``
-  clashes with the field ``<field name>`` from parent model ``<model>``.
-* **models.E006**: The field clashes with the field ``<field name>`` from model
-  ``<model>``.
-* **models.E007**: Field ``<field name>`` has column name ``<column name>``
-  that is used by another field.
-* **models.E008**: ``index_together`` must be a list or tuple.
-* **models.E009**: All ``index_together`` elements must be lists or tuples.
-* **models.E010**: ``unique_together`` must be a list or tuple.
-* **models.E011**: All ``unique_together`` elements must be lists or tuples.
-* **models.E012**: ``index_together/unique_together`` refers to the
-  non-existent field ``<field name>``.
-* **models.E013**: ``index_together/unique_together`` refers to a
-  ``ManyToManyField`` ``<field name>``, but ``ManyToManyField``\s are not
-  supported for that option.
-* **models.E014**: ``ordering`` must be a tuple or list (even if you want to
-  order by only one field).
-* **models.E015**: ``ordering`` refers to the non-existent field
-  ``<field name>``.
-* **models.E016**: ``index_together/unique_together`` refers to field
-  ``<field_name>`` which is not local to model ``<model>``.
-* **models.E017**: Proxy model ``<model>`` contains model fields.
-* **models.E018**: Autogenerated column name too long for field ``<field>``.
-  Maximum length is ``<maximum length>`` for database ``<alias>``.
-* **models.E019**: Autogenerated column name too long for M2M field
-  ``<M2M field>``. Maximum length is ``<maximum length>`` for database
-  ``<alias>``.
-* **models.E020**: The ``<model>.check()`` class method is currently overridden.
-* **models.E021**: ``ordering`` and ``order_with_respect_to`` cannot be used
-  together.
-* **models.E022**: ``<function>`` contains a lazy reference to
-  ``<app label>.<model>``, but app ``<app label>`` isn't installed or
-  doesn't provide model ``<model>``.
-* **models.E023**: The model name ``<model>`` cannot start or end with an
-  underscore as it collides with the query lookup syntax.
-* **models.E024**: The model name ``<model>`` cannot contain double underscores
-  as it collides with the query lookup syntax.
+The following checks are performed to warn the user of any potential problems
+that might occur as a result of a version upgrade.
+
+* **1_6.W001**: Some project unit tests may not execute as expected. *This
+  check was removed in Django 1.8 due to false positives*.
+* **1_6.W002**: ``BooleanField`` does not have a default value. *This
+  check was removed in Django 1.8 due to false positives*.
+* **1_7.W001**:  Django 1.7 changed the global defaults for the
+  ``MIDDLEWARE_CLASSES.``
+  ``django.contrib.sessions.middleware.SessionMiddleware``,
+  ``django.contrib.auth.middleware.AuthenticationMiddleware``, and
+  ``django.contrib.messages.middleware.MessageMiddleware`` were removed from
+  the defaults. If your project needs these middleware then you should
+  configure this setting. *This check was removed in Django 1.9*.
+* **1_8.W001**: The standalone ``TEMPLATE_*`` settings were deprecated in
+  Django 1.8 and the :setting:`TEMPLATES` dictionary takes precedence. You must
+  put the values of the following settings into your defaults ``TEMPLATES``
+  dict: ``TEMPLATE_DIRS``, ``TEMPLATE_CONTEXT_PROCESSORS``, ``TEMPLATE_DEBUG``,
+  ``TEMPLATE_LOADERS``, ``TEMPLATE_STRING_IF_INVALID``.
+* **1_10.W001**: The ``MIDDLEWARE_CLASSES`` setting is deprecated in Django
+  1.10  and the :setting:`MIDDLEWARE` setting takes precedence. Since you've
+  set ``MIDDLEWARE``, the value of ``MIDDLEWARE_CLASSES`` is ignored.
+
+Caches
+------
 
-Fields
-~~~~~~
+The following checks verify that your :setting:`CACHES` setting is correctly
+configured:
+
+* **caches.E001**: You must define a ``'default'`` cache in your
+  :setting:`CACHES` setting.
+
+Database
+--------
+
+MySQL
+~~~~~
+
+If you're using MySQL, the following checks will be performed:
+
+* **mysql.E001**: MySQL does not allow unique ``CharField``\s to have a
+  ``max_length`` > 255.
+* **mysql.W002**: MySQL Strict Mode is not set for database connection
+  '<alias>'. See also :ref:`mysql-sql-mode`.
+
+Model fields
+------------
 
 * **fields.E001**: Field names must not end with an underscore.
 * **fields.E002**: Field names must not contain ``"__"``.
@@ -183,7 +176,7 @@ Fields
 * **fields.W901**: ``CommaSeparatedIntegerField`` has been deprecated. Support
   for it (except in historical migrations) will be removed in Django 2.0.
 
-File Fields
+File fields
 ~~~~~~~~~~~
 
 * **fields.E200**: ``unique`` is not a valid argument for a ``FileField``.
@@ -193,7 +186,7 @@ File Fields
   path, not an absolute path.
 * **fields.E210**: Cannot use ``ImageField`` because Pillow is not installed.
 
-Related Fields
+Related fields
 ~~~~~~~~~~~~~~
 
 * **fields.E300**: Field defines a relation with model ``<model>``, which is
@@ -261,41 +254,211 @@ Related Fields
 * **fields.W343**: ``limit_choices_to`` has no effect on ``ManyToManyField``
   with a ``through`` model.
 
+Models
+------
+
+* **models.E001**: ``<swappable>`` is not of the form ``app_label.app_name``.
+* **models.E002**: ``<SETTING>`` references ``<model>``, which has not been
+  installed, or is abstract.
+* **models.E003**: The model has two many-to-many relations through the
+  intermediate model ``<app_label>.<model>``.
+* **models.E004**: ``id`` can only be used as a field name if the field also
+  sets ``primary_key=True``.
+* **models.E005**: The field ``<field name>`` from parent model ``<model>``
+  clashes with the field ``<field name>`` from parent model ``<model>``.
+* **models.E006**: The field clashes with the field ``<field name>`` from model
+  ``<model>``.
+* **models.E007**: Field ``<field name>`` has column name ``<column name>``
+  that is used by another field.
+* **models.E008**: ``index_together`` must be a list or tuple.
+* **models.E009**: All ``index_together`` elements must be lists or tuples.
+* **models.E010**: ``unique_together`` must be a list or tuple.
+* **models.E011**: All ``unique_together`` elements must be lists or tuples.
+* **models.E012**: ``index_together/unique_together`` refers to the
+  non-existent field ``<field name>``.
+* **models.E013**: ``index_together/unique_together`` refers to a
+  ``ManyToManyField`` ``<field name>``, but ``ManyToManyField``\s are not
+  supported for that option.
+* **models.E014**: ``ordering`` must be a tuple or list (even if you want to
+  order by only one field).
+* **models.E015**: ``ordering`` refers to the non-existent field
+  ``<field name>``.
+* **models.E016**: ``index_together/unique_together`` refers to field
+  ``<field_name>`` which is not local to model ``<model>``.
+* **models.E017**: Proxy model ``<model>`` contains model fields.
+* **models.E018**: Autogenerated column name too long for field ``<field>``.
+  Maximum length is ``<maximum length>`` for database ``<alias>``.
+* **models.E019**: Autogenerated column name too long for M2M field
+  ``<M2M field>``. Maximum length is ``<maximum length>`` for database
+  ``<alias>``.
+* **models.E020**: The ``<model>.check()`` class method is currently overridden.
+* **models.E021**: ``ordering`` and ``order_with_respect_to`` cannot be used
+  together.
+* **models.E022**: ``<function>`` contains a lazy reference to
+  ``<app label>.<model>``, but app ``<app label>`` isn't installed or
+  doesn't provide model ``<model>``.
+* **models.E023**: The model name ``<model>`` cannot start or end with an
+  underscore as it collides with the query lookup syntax.
+* **models.E024**: The model name ``<model>`` cannot contain double underscores
+  as it collides with the query lookup syntax.
+
+Security
+--------
+
+The security checks do not make your site secure. They do not audit code, do
+intrusion detection, or do anything particularly complex. Rather, they help
+perform an automated, low-hanging-fruit checklist. They help you remember the
+simple things that improve your site's security.
+
+Some of these checks may not be appropriate for your particular deployment
+configuration. For instance, if you do your HTTP to HTTPS redirection in a load
+balancer, it'd be irritating to be constantly warned about not having enabled
+:setting:`SECURE_SSL_REDIRECT`. Use :setting:`SILENCED_SYSTEM_CHECKS` to
+silence unneeded checks.
+
+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:`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
+  ``'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
+  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
+  over SSL, you may want to consider setting a value and enabling :ref:`HTTP
+  Strict Transport Security <http-strict-transport-security>`. Be sure to read
+  the documentation first; enabling HSTS carelessly can cause serious,
+  irreversible problems.
+* **security.W005**: You have not set the
+  :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS` setting to ``True``. Without this,
+  your site is potentially vulnerable to attack via an insecure connection to a
+  subdomain. Only set this to ``True`` if you are certain that all subdomains of
+  your domain should be served exclusively via SSL.
+* **security.W006**: Your :setting:`SECURE_CONTENT_TYPE_NOSNIFF` setting is not
+  set to ``True``, so your pages will not be served with an
+  ``'x-content-type-options: nosniff'`` header. You should consider enabling
+  this header to prevent the browser from identifying content types incorrectly.
+* **security.W007**: Your :setting:`SECURE_BROWSER_XSS_FILTER` setting is not
+  set to ``True``, so your pages will not be served with an
+  ``'x-xss-protection: 1; mode=block'`` header. You should consider enabling
+  this header to activate the browser's XSS filtering and help prevent XSS
+  attacks.
+* **security.W008**: Your :setting:`SECURE_SSL_REDIRECT` setting is not set to
+  ``True``. Unless your site should be available over both SSL and non-SSL
+  connections, you may want to either set this setting to ``True`` or configure
+  a load balancer or reverse-proxy server  to redirect all connections to HTTPS.
+* **security.W009**: Your :setting:`SECRET_KEY` has less than 50 characters or
+  less than 5 unique characters. Please generate a long and random
+  ``SECRET_KEY``, otherwise many of Django's security-critical features will be
+  vulnerable to attack.
+* **security.W010**: You have :mod:`django.contrib.sessions` in your
+  :setting:`INSTALLED_APPS` 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.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.
+* **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.
+* **security.W013**: You have :mod:`django.contrib.sessions` in your
+  :setting:`INSTALLED_APPS`, 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.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.
+* **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.
+* **security.W016**: :setting:`CSRF_COOKIE_SECURE` is not set to ``True``.
+  Using a secure-only CSRF cookie makes it more difficult for network traffic
+  sniffers to steal the CSRF token.
+* **security.W017**: :setting:`CSRF_COOKIE_HTTPONLY` is not set to ``True``.
+  Using an ``HttpOnly`` CSRF cookie makes it more difficult for cross-site
+  scripting attacks to steal the CSRF token. *This check is removed in Django
+  1.11 as the* :setting:`CSRF_COOKIE_HTTPONLY` *setting offers no pratical
+  benefit.*
+* **security.W018**: You should not have :setting:`DEBUG` set to ``True`` in
+  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
+  ``'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'``.
+* **security.W020**: :setting:`ALLOWED_HOSTS` must not be empty in deployment.
+* **security.W021**: You have not set the
+  :setting:`SECURE_HSTS_PRELOAD` setting to ``True``. Without this, your site
+  cannot be submitted to the browser preload list.
+
 Signals
-~~~~~~~
+-------
 
 * **signals.E001**: ``<handler>`` was connected to the ``<signal>`` signal with
   a lazy reference to the sender ``<app label>.<model>``, but app ``<app label>``
   isn't installed or doesn't provide model ``<model>``.
 
-Backwards Compatibility
-~~~~~~~~~~~~~~~~~~~~~~~
+Templates
+---------
 
-The following checks are performed to warn the user of any potential problems
-that might occur as a result of a version upgrade.
+The following checks verify that your :setting:`TEMPLATES` setting is correctly
+configured:
 
-* **1_6.W001**: Some project unit tests may not execute as expected. *This
-  check was removed in Django 1.8 due to false positives*.
-* **1_6.W002**: ``BooleanField`` does not have a default value. *This
-  check was removed in Django 1.8 due to false positives*.
-* **1_7.W001**:  Django 1.7 changed the global defaults for the
-  ``MIDDLEWARE_CLASSES.``
-  ``django.contrib.sessions.middleware.SessionMiddleware``,
-  ``django.contrib.auth.middleware.AuthenticationMiddleware``, and
-  ``django.contrib.messages.middleware.MessageMiddleware`` were removed from
-  the defaults. If your project needs these middleware then you should
-  configure this setting. *This check was removed in Django 1.9*.
-* **1_8.W001**: The standalone ``TEMPLATE_*`` settings were deprecated in
-  Django 1.8 and the :setting:`TEMPLATES` dictionary takes precedence. You must
-  put the values of the following settings into your defaults ``TEMPLATES``
-  dict: ``TEMPLATE_DIRS``, ``TEMPLATE_CONTEXT_PROCESSORS``, ``TEMPLATE_DEBUG``,
-  ``TEMPLATE_LOADERS``, ``TEMPLATE_STRING_IF_INVALID``.
-* **1_10.W001**: The ``MIDDLEWARE_CLASSES`` setting is deprecated in Django
-  1.10  and the :setting:`MIDDLEWARE` setting takes precedence. Since you've
-  set ``MIDDLEWARE``, the value of ``MIDDLEWARE_CLASSES`` is ignored.
+* **templates.E001**: You have ``'APP_DIRS': True`` in your
+  :setting:`TEMPLATES` but also specify ``'loaders'`` in ``OPTIONS``. Either
+  remove ``APP_DIRS`` or remove the ``'loaders'`` option.
+* **templates.E002**: ``string_if_invalid`` in :setting:`TEMPLATES`
+  :setting:`OPTIONS <TEMPLATES-OPTIONS>` must be a string but got: ``{value}``
+  (``{type}``).
+
+URLs
+----
+
+The following checks are performed on your URL configuration:
+
+* **urls.W001**: Your URL pattern ``<pattern>`` uses
+  :func:`~django.conf.urls.include` with a ``regex`` ending with a
+  ``$``. Remove the dollar from the ``regex`` to avoid problems
+  including URLs.
+* **urls.W002**: Your URL pattern ``<pattern>`` has a ``regex``
+  beginning with a ``/``. Remove this slash as it is unnecessary.
+  If this pattern is targeted in an :func:`~django.conf.urls.include`, ensure
+  the :func:`~django.conf.urls.include` pattern has a trailing ``/``.
+* **urls.W003**: Your URL pattern ``<pattern>`` has a ``name``
+  including a ``:``. Remove the colon, to avoid ambiguous namespace
+  references.
+* **urls.E004**: Your URL pattern ``<pattern>`` is invalid. Ensure that
+  ``urlpatterns`` is a list of :func:`~django.conf.urls.url()` instances.
+* **urls.W005**: URL namespace ``<namespace>`` isn't unique. You may not be
+  able to reverse all URLs in this namespace.
+* **urls.E006**: The :setting:`MEDIA_URL`/ :setting:`STATIC_URL` setting must
+  end with a slash.
 
-Admin
------
+``contrib`` app checks
+======================
+
+``admin``
+---------
 
 Admin checks are all performed as part of the ``admin`` tag.
 
@@ -457,8 +620,8 @@ The following checks are performed on the default
 * **admin.E402**: :mod:`django.contrib.auth.context_processors.auth`
   must be in :setting:`TEMPLATES` in order to use the admin application.
 
-Auth
-----
+``auth``
+--------
 
 * **auth.E001**: ``REQUIRED_FIELDS`` must be a list or tuple.
 * **auth.E002**: The field named as the ``USERNAME_FIELD`` for a custom user
@@ -484,9 +647,8 @@ Auth
   property rather than a method. Ignoring this is a security issue as anonymous
   users will be treated as authenticated!
 
-
-Content Types
--------------
+``contenttypes``
+----------------
 
 The following checks are performed when a model contains a
 :class:`~django.contrib.contenttypes.fields.GenericForeignKey` or
@@ -500,117 +662,8 @@ The following checks are performed when a model contains a
 * **contenttypes.E004**: ``<field>`` is not a ``ForeignKey`` to
   ``contenttypes.ContentType``.
 
-Security
---------
-
-The security checks do not make your site secure. They do not audit code, do
-intrusion detection, or do anything particularly complex. Rather, they help
-perform an automated, low-hanging-fruit checklist. They help you remember the
-simple things that improve your site's security.
-
-Some of these checks may not be appropriate for your particular deployment
-configuration. For instance, if you do your HTTP to HTTPS redirection in a load
-balancer, it'd be irritating to be constantly warned about not having enabled
-:setting:`SECURE_SSL_REDIRECT`. Use :setting:`SILENCED_SYSTEM_CHECKS` to
-silence unneeded checks.
-
-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:`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
-  ``'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
-  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
-  over SSL, you may want to consider setting a value and enabling :ref:`HTTP
-  Strict Transport Security <http-strict-transport-security>`. Be sure to read
-  the documentation first; enabling HSTS carelessly can cause serious,
-  irreversible problems.
-* **security.W005**: You have not set the
-  :setting:`SECURE_HSTS_INCLUDE_SUBDOMAINS` setting to ``True``. Without this,
-  your site is potentially vulnerable to attack via an insecure connection to a
-  subdomain. Only set this to ``True`` if you are certain that all subdomains of
-  your domain should be served exclusively via SSL.
-* **security.W006**: Your :setting:`SECURE_CONTENT_TYPE_NOSNIFF` setting is not
-  set to ``True``, so your pages will not be served with an
-  ``'x-content-type-options: nosniff'`` header. You should consider enabling
-  this header to prevent the browser from identifying content types incorrectly.
-* **security.W007**: Your :setting:`SECURE_BROWSER_XSS_FILTER` setting is not
-  set to ``True``, so your pages will not be served with an
-  ``'x-xss-protection: 1; mode=block'`` header. You should consider enabling
-  this header to activate the browser's XSS filtering and help prevent XSS
-  attacks.
-* **security.W008**: Your :setting:`SECURE_SSL_REDIRECT` setting is not set to
-  ``True``. Unless your site should be available over both SSL and non-SSL
-  connections, you may want to either set this setting to ``True`` or configure
-  a load balancer or reverse-proxy server  to redirect all connections to HTTPS.
-* **security.W009**: Your :setting:`SECRET_KEY` has less than 50 characters or
-  less than 5 unique characters. Please generate a long and random
-  ``SECRET_KEY``, otherwise many of Django's security-critical features will be
-  vulnerable to attack.
-* **security.W010**: You have :mod:`django.contrib.sessions` in your
-  :setting:`INSTALLED_APPS` 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.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.
-* **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.
-* **security.W013**: You have :mod:`django.contrib.sessions` in your
-  :setting:`INSTALLED_APPS`, 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.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.
-* **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.
-* **security.W016**: :setting:`CSRF_COOKIE_SECURE` is not set to ``True``.
-  Using a secure-only CSRF cookie makes it more difficult for network traffic
-  sniffers to steal the CSRF token.
-* **security.W017**: :setting:`CSRF_COOKIE_HTTPONLY` is not set to ``True``.
-  Using an ``HttpOnly`` CSRF cookie makes it more difficult for cross-site
-  scripting attacks to steal the CSRF token. *This check is removed in Django
-  1.11 as the* :setting:`CSRF_COOKIE_HTTPONLY` *setting offers no pratical
-  benefit.*
-* **security.W018**: You should not have :setting:`DEBUG` set to ``True`` in
-  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
-  ``'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'``.
-* **security.W020**: :setting:`ALLOWED_HOSTS` must not be empty in deployment.
-* **security.W021**: You have not set the
-  :setting:`SECURE_HSTS_PRELOAD` setting to ``True``. Without this, your site
-  cannot be submitted to the browser preload list.
-
-Sites
------
+``sites``
+---------
 
 The following checks are performed on any model using a
 :class:`~django.contrib.sites.managers.CurrentSiteManager`:
@@ -619,61 +672,3 @@ The following checks are performed on any model using a
   ``<field name>``.
 * **sites.E002**: ``CurrentSiteManager`` cannot use ``<field>`` as it is not a
   foreign key or a many-to-many field.
-
-Database
---------
-
-MySQL
-~~~~~
-
-If you're using MySQL, the following checks will be performed:
-
-* **mysql.E001**: MySQL does not allow unique ``CharField``\s to have a
-  ``max_length`` > 255.
-* **mysql.W002**: MySQL Strict Mode is not set for database connection
-  '<alias>'. See also :ref:`mysql-sql-mode`.
-
-Templates
----------
-
-The following checks verify that your :setting:`TEMPLATES` setting is correctly
-configured:
-
-* **templates.E001**: You have ``'APP_DIRS': True`` in your
-  :setting:`TEMPLATES` but also specify ``'loaders'`` in ``OPTIONS``. Either
-  remove ``APP_DIRS`` or remove the ``'loaders'`` option.
-* **templates.E002**: ``string_if_invalid`` in :setting:`TEMPLATES`
-  :setting:`OPTIONS <TEMPLATES-OPTIONS>` must be a string but got: ``{value}``
-  (``{type}``).
-
-Caches
-------
-
-The following checks verify that your :setting:`CACHES` setting is correctly
-configured:
-
-* **caches.E001**: You must define a ``'default'`` cache in your
-  :setting:`CACHES` setting.
-
-URLs
-----
-
-The following checks are performed on your URL configuration:
-
-* **urls.W001**: Your URL pattern ``<pattern>`` uses
-  :func:`~django.conf.urls.include` with a ``regex`` ending with a
-  ``$``. Remove the dollar from the ``regex`` to avoid problems
-  including URLs.
-* **urls.W002**: Your URL pattern ``<pattern>`` has a ``regex``
-  beginning with a ``/``. Remove this slash as it is unnecessary.
-  If this pattern is targeted in an :func:`~django.conf.urls.include`, ensure
-  the :func:`~django.conf.urls.include` pattern has a trailing ``/``.
-* **urls.W003**: Your URL pattern ``<pattern>`` has a ``name``
-  including a ``:``. Remove the colon, to avoid ambiguous namespace
-  references.
-* **urls.E004**: Your URL pattern ``<pattern>`` is invalid. Ensure that
-  ``urlpatterns`` is a list of :func:`~django.conf.urls.url()` instances.
-* **urls.W005**: URL namespace ``<namespace>`` isn't unique. You may not be
-  able to reverse all URLs in this namespace.
-* **urls.E006**: The :setting:`MEDIA_URL`/ :setting:`STATIC_URL` setting must
-  end with a slash.