mirror of
https://github.com/django/django.git
synced 2024-12-25 02:26:12 +00:00
2741 lines
77 KiB
Plaintext
2741 lines
77 KiB
Plaintext
========
|
|
Settings
|
|
========
|
|
|
|
.. contents::
|
|
:local:
|
|
:depth: 1
|
|
|
|
.. warning::
|
|
|
|
Be careful when you override settings, especially when the default value
|
|
is a non-empty tuple or dictionary, such as :setting:`MIDDLEWARE_CLASSES`
|
|
and :setting:`TEMPLATE_CONTEXT_PROCESSORS`. Make sure you keep the
|
|
components required by the features of Django you wish to use.
|
|
|
|
Core settings
|
|
=============
|
|
|
|
Here's a list of settings available in Django core and their default values.
|
|
Settings provided by contrib apps are listed below, followed by a topical index
|
|
of the core settings.
|
|
|
|
.. setting:: ABSOLUTE_URL_OVERRIDES
|
|
|
|
ABSOLUTE_URL_OVERRIDES
|
|
----------------------
|
|
|
|
Default: ``{}`` (Empty dictionary)
|
|
|
|
A dictionary mapping ``"app_label.model_name"`` strings to functions that take
|
|
a model object and return its URL. This is a way of overriding
|
|
``get_absolute_url()`` methods on a per-installation basis. Example::
|
|
|
|
ABSOLUTE_URL_OVERRIDES = {
|
|
'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
|
|
'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
|
|
}
|
|
|
|
Note that the model name used in this setting should be all lower-case, regardless
|
|
of the case of the actual model class name.
|
|
|
|
.. setting:: ADMINS
|
|
|
|
ADMINS
|
|
------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple that lists people who get code error notifications. When
|
|
``DEBUG=False`` and a view raises an exception, Django will email these people
|
|
with the full exception information. Each member of the tuple should be a tuple
|
|
of (Full name, email address). Example::
|
|
|
|
(('John', 'john@example.com'), ('Mary', 'mary@example.com'))
|
|
|
|
Note that Django will email *all* of these people whenever an error happens.
|
|
See :doc:`/howto/error-reporting` for more information.
|
|
|
|
.. setting:: ALLOWED_HOSTS
|
|
|
|
ALLOWED_HOSTS
|
|
-------------
|
|
|
|
Default: ``[]`` (Empty list)
|
|
|
|
A list of strings representing the host/domain names that this Django site can
|
|
serve. This is a security measure to prevent an attacker from poisoning caches
|
|
and password reset emails with links to malicious hosts by submitting requests
|
|
with a fake HTTP ``Host`` header, which is possible even under many
|
|
seemingly-safe web server configurations.
|
|
|
|
Values in this list can be fully qualified names (e.g. ``'www.example.com'``),
|
|
in which case they will be matched against the request's ``Host`` header
|
|
exactly (case-insensitive, not including port). A value beginning with a period
|
|
can be used as a subdomain wildcard: ``'.example.com'`` will match
|
|
``example.com``, ``www.example.com``, and any other subdomain of
|
|
``example.com``. A value of ``'*'`` will match anything; in this case you are
|
|
responsible to provide your own validation of the ``Host`` header (perhaps in a
|
|
middleware; if so this middleware must be listed first in
|
|
:setting:`MIDDLEWARE_CLASSES`).
|
|
|
|
.. note::
|
|
|
|
If you want to also allow the `fully qualified domain name (FQDN)`_, which
|
|
some browsers can send in the Host header, you must explicitly add another
|
|
ALLOWED_HOSTS entry that includes a trailing period. This entry can also be
|
|
a subdomain wildcard::
|
|
|
|
ALLOWED_HOSTS = [
|
|
'.example.com', # Allow domain and subdomains
|
|
'.example.com.', # Also allow FQDN and subdomains
|
|
]
|
|
|
|
.. _`fully qualified domain name (FQDN)`: http://en.wikipedia.org/wiki/Fully_qualified_domain_name
|
|
|
|
If the ``Host`` header (or ``X-Forwarded-Host`` if
|
|
:setting:`USE_X_FORWARDED_HOST` is enabled) does not match any value in this
|
|
list, the :meth:`django.http.HttpRequest.get_host()` method will raise
|
|
:exc:`~django.core.exceptions.SuspiciousOperation`.
|
|
|
|
When :setting:`DEBUG` is ``True`` or when running tests, host validation is
|
|
disabled; any host will be accepted. Thus it's usually only necessary to set it
|
|
in production.
|
|
|
|
This validation only applies via :meth:`~django.http.HttpRequest.get_host()`;
|
|
if your code accesses the ``Host`` header directly from ``request.META`` you
|
|
are bypassing this security protection.
|
|
|
|
.. setting:: ALLOWED_INCLUDE_ROOTS
|
|
|
|
ALLOWED_INCLUDE_ROOTS
|
|
---------------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple of strings representing allowed prefixes for the ``{% ssi %}`` template
|
|
tag. This is a security measure, so that template authors can't access files
|
|
that they shouldn't be accessing.
|
|
|
|
For example, if :setting:`ALLOWED_INCLUDE_ROOTS` is ``('/home/html', '/var/www')``,
|
|
then ``{% ssi /home/html/foo.txt %}`` would work, but ``{% ssi /etc/passwd %}``
|
|
wouldn't.
|
|
|
|
.. setting:: APPEND_SLASH
|
|
|
|
APPEND_SLASH
|
|
------------
|
|
|
|
Default: ``True``
|
|
|
|
When set to ``True``, if the request URL does not match any of the patterns
|
|
in the URLconf and it doesn't end in a slash, an HTTP redirect is issued to the
|
|
same URL with a slash appended. Note that the redirect may cause any data
|
|
submitted in a POST request to be lost.
|
|
|
|
The :setting:`APPEND_SLASH` setting is only used if
|
|
:class:`~django.middleware.common.CommonMiddleware` is installed
|
|
(see :doc:`/topics/http/middleware`). See also :setting:`PREPEND_WWW`.
|
|
|
|
.. setting:: CACHES
|
|
|
|
CACHES
|
|
------
|
|
|
|
Default::
|
|
|
|
{
|
|
'default': {
|
|
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
|
|
}
|
|
}
|
|
|
|
A dictionary containing the settings for all caches to be used with
|
|
Django. It is a nested dictionary whose contents maps cache aliases
|
|
to a dictionary containing the options for an individual cache.
|
|
|
|
The :setting:`CACHES` setting must configure a ``default`` cache;
|
|
any number of additional caches may also be specified. If you
|
|
are using a cache backend other than the local memory cache, or
|
|
you need to define multiple caches, other options will be required.
|
|
The following cache options are available.
|
|
|
|
.. setting:: CACHES-BACKEND
|
|
|
|
BACKEND
|
|
~~~~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The cache backend to use. The built-in cache backends are:
|
|
|
|
* ``'django.core.cache.backends.db.DatabaseCache'``
|
|
* ``'django.core.cache.backends.dummy.DummyCache'``
|
|
* ``'django.core.cache.backends.filebased.FileBasedCache'``
|
|
* ``'django.core.cache.backends.locmem.LocMemCache'``
|
|
* ``'django.core.cache.backends.memcached.MemcachedCache'``
|
|
* ``'django.core.cache.backends.memcached.PyLibMCCache'``
|
|
|
|
You can use a cache backend that doesn't ship with Django by setting
|
|
:setting:`BACKEND <CACHES-BACKEND>` to a fully-qualified path of a cache
|
|
backend class (i.e. ``mypackage.backends.whatever.WhateverCache``).
|
|
Writing a whole new cache backend from scratch is left as an exercise
|
|
to the reader; see the other backends for examples.
|
|
|
|
.. setting:: CACHES-KEY_FUNCTION
|
|
|
|
KEY_FUNCTION
|
|
~~~~~~~~~~~~
|
|
|
|
A string containing a dotted path to a function that defines how to
|
|
compose a prefix, version and key into a final cache key. The default
|
|
implementation is equivalent to the function::
|
|
|
|
def make_key(key, key_prefix, version):
|
|
return ':'.join([key_prefix, str(version), key])
|
|
|
|
You may use any key function you want, as long as it has the same
|
|
argument signature.
|
|
|
|
See the :ref:`cache documentation <cache_key_transformation>` for more
|
|
information.
|
|
|
|
.. setting:: CACHES-KEY_PREFIX
|
|
|
|
KEY_PREFIX
|
|
~~~~~~~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
A string that will be automatically included (prepended by default) to
|
|
all cache keys used by the Django server.
|
|
|
|
See the :ref:`cache documentation <cache_key_prefixing>` for more information.
|
|
|
|
.. setting:: CACHES-LOCATION
|
|
|
|
LOCATION
|
|
~~~~~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The location of the cache to use. This might be the directory for a
|
|
file system cache, a host and port for a memcache server, or simply an
|
|
identifying name for a local memory cache. e.g.::
|
|
|
|
CACHES = {
|
|
'default': {
|
|
'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
|
|
'LOCATION': '/var/tmp/django_cache',
|
|
}
|
|
}
|
|
|
|
.. setting:: CACHES-OPTIONS
|
|
|
|
OPTIONS
|
|
~~~~~~~
|
|
|
|
Default: None
|
|
|
|
Extra parameters to pass to the cache backend. Available parameters
|
|
vary depending on your cache backend.
|
|
|
|
Some information on available parameters can be found in the
|
|
:doc:`Cache Backends </topics/cache>` documentation. For more information,
|
|
consult your backend module's own documentation.
|
|
|
|
.. setting:: CACHES-TIMEOUT
|
|
|
|
TIMEOUT
|
|
~~~~~~~
|
|
|
|
Default: 300
|
|
|
|
The number of seconds before a cache entry is considered stale.
|
|
|
|
.. setting:: CACHES-VERSION
|
|
|
|
VERSION
|
|
~~~~~~~
|
|
|
|
Default: ``1``
|
|
|
|
The default version number for cache keys generated by the Django server.
|
|
|
|
See the :ref:`cache documentation <cache_versioning>` for more information.
|
|
|
|
.. setting:: CACHE_MIDDLEWARE_ALIAS
|
|
|
|
CACHE_MIDDLEWARE_ALIAS
|
|
----------------------
|
|
|
|
Default: ``default``
|
|
|
|
The cache connection to use for the cache middleware.
|
|
|
|
.. setting:: CACHE_MIDDLEWARE_ANONYMOUS_ONLY
|
|
|
|
CACHE_MIDDLEWARE_ANONYMOUS_ONLY
|
|
-------------------------------
|
|
|
|
Default: ``False``
|
|
|
|
.. deprecated:: 1.6
|
|
|
|
This setting was largely ineffective because of using cookies for sessions
|
|
and CSRF. See the :doc:`Django 1.6 release notes</releases/1.6>` for more
|
|
information.
|
|
|
|
If the value of this setting is ``True``, only anonymous requests (i.e., not
|
|
those made by a logged-in user) will be cached. Otherwise, the middleware
|
|
caches every page that doesn't have GET or POST parameters.
|
|
|
|
If you set the value of this setting to ``True``, you should make sure you've
|
|
activated ``AuthenticationMiddleware``.
|
|
|
|
.. setting:: CACHE_MIDDLEWARE_KEY_PREFIX
|
|
|
|
CACHE_MIDDLEWARE_KEY_PREFIX
|
|
---------------------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The cache key prefix that the cache middleware should use.
|
|
|
|
See :doc:`/topics/cache`.
|
|
|
|
.. setting:: CACHE_MIDDLEWARE_SECONDS
|
|
|
|
CACHE_MIDDLEWARE_SECONDS
|
|
------------------------
|
|
|
|
Default: ``600``
|
|
|
|
The default number of seconds to cache a page when the caching middleware or
|
|
``cache_page()`` decorator is used.
|
|
|
|
See :doc:`/topics/cache`.
|
|
|
|
.. _settings-csrf:
|
|
|
|
.. setting:: CSRF_COOKIE_DOMAIN
|
|
|
|
CSRF_COOKIE_DOMAIN
|
|
------------------
|
|
|
|
Default: ``None``
|
|
|
|
The domain to be used when setting the CSRF cookie. This can be useful for
|
|
easily allowing cross-subdomain requests to be excluded from the normal cross
|
|
site request forgery protection. It should be set to a string such as
|
|
``".example.com"`` to allow a POST request from a form on one subdomain to be
|
|
accepted by a view served from another subdomain.
|
|
|
|
Please note that the presence of this setting does not imply that Django's CSRF
|
|
protection is safe from cross-subdomain attacks by default - please see the
|
|
:ref:`CSRF limitations <csrf-limitations>` section.
|
|
|
|
.. setting:: CSRF_COOKIE_HTTPONLY
|
|
|
|
CSRF_COOKIE_HTTPONLY
|
|
--------------------
|
|
|
|
.. versionadded:: 1.6
|
|
|
|
Default: ``False``
|
|
|
|
Whether to use ``HttpOnly`` flag on the CSRF cookie. If this is set to
|
|
``True``, client-side JavaScript will not to be able to access the CSRF cookie.
|
|
See :setting:`SESSION_COOKIE_HTTPONLY` for details on ``HttpOnly``.
|
|
|
|
.. setting:: CSRF_COOKIE_NAME
|
|
|
|
CSRF_COOKIE_NAME
|
|
----------------
|
|
|
|
Default: ``'csrftoken'``
|
|
|
|
The name of the cookie to use for the CSRF authentication token. This can be whatever you
|
|
want. See :doc:`/ref/contrib/csrf`.
|
|
|
|
.. setting:: CSRF_COOKIE_PATH
|
|
|
|
CSRF_COOKIE_PATH
|
|
----------------
|
|
|
|
Default: ``'/'``
|
|
|
|
The path set on the CSRF cookie. This should either match the URL path of your
|
|
Django installation or be a parent of that path.
|
|
|
|
This is useful if you have multiple Django instances running under the same
|
|
hostname. They can use different cookie paths, and each instance will only see
|
|
its own CSRF cookie.
|
|
|
|
.. setting:: CSRF_COOKIE_SECURE
|
|
|
|
CSRF_COOKIE_SECURE
|
|
------------------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to use a secure cookie for the CSRF cookie. If this is set to ``True``,
|
|
the cookie will be marked as "secure," which means browsers may ensure that the
|
|
cookie is only sent under an HTTPS connection.
|
|
|
|
.. setting:: CSRF_FAILURE_VIEW
|
|
|
|
CSRF_FAILURE_VIEW
|
|
-----------------
|
|
|
|
Default: ``'django.views.csrf.csrf_failure'``
|
|
|
|
A dotted path to the view function to be used when an incoming request
|
|
is rejected by the CSRF protection. The function should have this signature::
|
|
|
|
def csrf_failure(request, reason="")
|
|
|
|
where ``reason`` is a short message (intended for developers or logging, not for
|
|
end users) indicating the reason the request was rejected. See
|
|
:doc:`/ref/contrib/csrf`.
|
|
|
|
.. setting:: DATABASES
|
|
|
|
DATABASES
|
|
---------
|
|
|
|
Default: ``{}`` (Empty dictionary)
|
|
|
|
A dictionary containing the settings for all databases to be used with
|
|
Django. It is a nested dictionary whose contents maps database aliases
|
|
to a dictionary containing the options for an individual database.
|
|
|
|
The :setting:`DATABASES` setting must configure a ``default`` database;
|
|
any number of additional databases may also be specified.
|
|
|
|
The simplest possible settings file is for a single-database setup using
|
|
SQLite. This can be configured using the following::
|
|
|
|
DATABASES = {
|
|
'default': {
|
|
'ENGINE': 'django.db.backends.sqlite3',
|
|
'NAME': 'mydatabase'
|
|
}
|
|
}
|
|
|
|
For other database backends, or more complex SQLite configurations, other options
|
|
will be required. The following inner options are available.
|
|
|
|
.. setting:: DATABASE-ATOMIC_REQUESTS
|
|
|
|
ATOMIC_REQUESTS
|
|
~~~~~~~~~~~~~~~
|
|
|
|
.. versionadded:: 1.6
|
|
|
|
Default: ``False``
|
|
|
|
Set this to ``True`` to wrap each HTTP request in a transaction on this
|
|
database. See :ref:`tying-transactions-to-http-requests`.
|
|
|
|
.. setting:: DATABASE-AUTOCOMMIT
|
|
|
|
AUTOCOMMIT
|
|
~~~~~~~~~~
|
|
|
|
.. versionadded:: 1.6
|
|
|
|
Default: ``True``
|
|
|
|
Set this to ``False`` if you want to :ref:`disable Django's transaction
|
|
management <deactivate-transaction-management>` and implement your own.
|
|
|
|
.. setting:: DATABASE-ENGINE
|
|
|
|
ENGINE
|
|
~~~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The database backend to use. The built-in database backends are:
|
|
|
|
* ``'django.db.backends.postgresql_psycopg2'``
|
|
* ``'django.db.backends.mysql'``
|
|
* ``'django.db.backends.sqlite3'``
|
|
* ``'django.db.backends.oracle'``
|
|
|
|
You can use a database backend that doesn't ship with Django by setting
|
|
``ENGINE`` to a fully-qualified path (i.e.
|
|
``mypackage.backends.whatever``). Writing a whole new database backend from
|
|
scratch is left as an exercise to the reader; see the other backends for
|
|
examples.
|
|
|
|
.. setting:: HOST
|
|
|
|
HOST
|
|
~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Which host to use when connecting to the database. An empty string means
|
|
localhost. Not used with SQLite.
|
|
|
|
If this value starts with a forward slash (``'/'``) and you're using MySQL,
|
|
MySQL will connect via a Unix socket to the specified socket. For example::
|
|
|
|
"HOST": '/var/run/mysql'
|
|
|
|
If you're using MySQL and this value *doesn't* start with a forward slash, then
|
|
this value is assumed to be the host.
|
|
|
|
If you're using PostgreSQL, by default (empty :setting:`HOST`), the connection
|
|
to the database is done through UNIX domain sockets ('local' lines in
|
|
``pg_hba.conf``). If you want to connect through TCP sockets, set
|
|
:setting:`HOST` to 'localhost' or '127.0.0.1' ('host' lines in ``pg_hba.conf``).
|
|
On Windows, you should always define :setting:`HOST`, as UNIX domain sockets
|
|
are not available.
|
|
|
|
.. setting:: NAME
|
|
|
|
NAME
|
|
~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The name of the database to use. For SQLite, it's the full path to the database
|
|
file. When specifying the path, always use forward slashes, even on Windows
|
|
(e.g. ``C:/homes/user/mysite/sqlite3.db``).
|
|
|
|
.. setting:: CONN_MAX_AGE
|
|
|
|
CONN_MAX_AGE
|
|
~~~~~~~~~~~~
|
|
|
|
.. versionadded:: 1.6
|
|
|
|
Default: ``0``
|
|
|
|
The lifetime of a database connection, in seconds. Use ``0`` to close database
|
|
connections at the end of each request — Django's historical behavior — and
|
|
``None`` for unlimited persistent connections.
|
|
|
|
.. setting:: OPTIONS
|
|
|
|
OPTIONS
|
|
~~~~~~~
|
|
|
|
Default: ``{}`` (Empty dictionary)
|
|
|
|
Extra parameters to use when connecting to the database. Available parameters
|
|
vary depending on your database backend.
|
|
|
|
Some information on available parameters can be found in the
|
|
:doc:`Database Backends </ref/databases>` documentation. For more information,
|
|
consult your backend module's own documentation.
|
|
|
|
.. setting:: PASSWORD
|
|
|
|
PASSWORD
|
|
~~~~~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The password to use when connecting to the database. Not used with SQLite.
|
|
|
|
.. setting:: PORT
|
|
|
|
PORT
|
|
~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The port to use when connecting to the database. An empty string means the
|
|
default port. Not used with SQLite.
|
|
|
|
.. setting:: USER
|
|
|
|
USER
|
|
~~~~
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The username to use when connecting to the database. Not used with SQLite.
|
|
|
|
.. setting:: TEST_CHARSET
|
|
|
|
TEST_CHARSET
|
|
~~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
The character set encoding used to create the test database. The value of this
|
|
string is passed directly through to the database, so its format is
|
|
backend-specific.
|
|
|
|
Supported for the PostgreSQL_ (``postgresql_psycopg2``) and MySQL_ (``mysql``)
|
|
backends.
|
|
|
|
.. _PostgreSQL: http://www.postgresql.org/docs/current/static/multibyte.html
|
|
.. _MySQL: http://dev.mysql.com/doc/refman/5.0/en/charset-database.html
|
|
|
|
.. setting:: TEST_COLLATION
|
|
|
|
TEST_COLLATION
|
|
~~~~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
The collation order to use when creating the test database. This value is
|
|
passed directly to the backend, so its format is backend-specific.
|
|
|
|
Only supported for the ``mysql`` backend (see the `MySQL manual`_ for details).
|
|
|
|
.. _MySQL manual: MySQL_
|
|
|
|
.. setting:: TEST_DEPENDENCIES
|
|
|
|
TEST_DEPENDENCIES
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
Default: ``['default']``, for all databases other than ``default``,
|
|
which has no dependencies.
|
|
|
|
The creation-order dependencies of the database. See the documentation
|
|
on :ref:`controlling the creation order of test databases
|
|
<topics-testing-creation-dependencies>` for details.
|
|
|
|
.. setting:: TEST_MIRROR
|
|
|
|
TEST_MIRROR
|
|
~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
The alias of the database that this database should mirror during
|
|
testing.
|
|
|
|
This setting exists to allow for testing of master/slave
|
|
configurations of multiple databases. See the documentation on
|
|
:ref:`testing master/slave configurations
|
|
<topics-testing-masterslave>` for details.
|
|
|
|
.. setting:: TEST_NAME
|
|
|
|
TEST_NAME
|
|
~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
The name of database to use when running the test suite.
|
|
|
|
If the default value (``None``) is used with the SQLite database engine, the
|
|
tests will use a memory resident database. For all other database engines the
|
|
test database will use the name ``'test_' + DATABASE_NAME``.
|
|
|
|
See :ref:`the-test-database`.
|
|
|
|
.. setting:: TEST_CREATE
|
|
|
|
TEST_CREATE
|
|
~~~~~~~~~~~
|
|
|
|
Default: ``True``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
If it is set to ``False``, the test tablespaces won't be automatically created
|
|
at the beginning of the tests and dropped at the end.
|
|
|
|
.. setting:: TEST_USER
|
|
|
|
TEST_USER
|
|
~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
The username to use when connecting to the Oracle database that will be used
|
|
when running tests. If not provided, Django will use ``'test_' + USER``.
|
|
|
|
.. setting:: TEST_USER_CREATE
|
|
|
|
TEST_USER_CREATE
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
Default: ``True``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
If it is set to ``False``, the test user won't be automatically created at the
|
|
beginning of the tests and dropped at the end.
|
|
|
|
.. setting:: TEST_PASSWD
|
|
|
|
TEST_PASSWD
|
|
~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
The password to use when connecting to the Oracle database that will be used
|
|
when running tests. If not provided, Django will use a hardcoded default value.
|
|
|
|
.. setting:: TEST_TBLSPACE
|
|
|
|
TEST_TBLSPACE
|
|
~~~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
The name of the tablespace that will be used when running tests. If not
|
|
provided, Django will use ``'test_' + NAME``.
|
|
|
|
.. setting:: TEST_TBLSPACE_TMP
|
|
|
|
TEST_TBLSPACE_TMP
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
Default: ``None``
|
|
|
|
This is an Oracle-specific setting.
|
|
|
|
The name of the temporary tablespace that will be used when running tests. If
|
|
not provided, Django will use ``'test_' + NAME + '_temp'``.
|
|
|
|
.. setting:: DATABASE_ROUTERS
|
|
|
|
DATABASE_ROUTERS
|
|
----------------
|
|
|
|
Default: ``[]`` (Empty list)
|
|
|
|
The list of routers that will be used to determine which database
|
|
to use when performing a database queries.
|
|
|
|
See the documentation on :ref:`automatic database routing in multi
|
|
database configurations <topics-db-multi-db-routing>`.
|
|
|
|
.. setting:: DATE_FORMAT
|
|
|
|
DATE_FORMAT
|
|
-----------
|
|
|
|
Default: ``'N j, Y'`` (e.g. ``Feb. 4, 2003``)
|
|
|
|
The default formatting to use for displaying date fields in any part of the
|
|
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|
locale-dictated format has higher precedence and will be applied instead. See
|
|
:tfilter:`allowed date format strings <date>`.
|
|
|
|
See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
|
|
|
.. setting:: DATE_INPUT_FORMATS
|
|
|
|
DATE_INPUT_FORMATS
|
|
------------------
|
|
|
|
Default::
|
|
|
|
(
|
|
'%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06'
|
|
'%b %d %Y', '%b %d, %Y', # 'Oct 25 2006', 'Oct 25, 2006'
|
|
'%d %b %Y', '%d %b, %Y', # '25 Oct 2006', '25 Oct, 2006'
|
|
'%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006'
|
|
'%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006'
|
|
)
|
|
|
|
A tuple of formats that will be accepted when inputting data on a date field.
|
|
Formats will be tried in order, using the first valid one. Note that these
|
|
format strings use Python's datetime_ module syntax, not the format strings
|
|
from the ``date`` Django template tag.
|
|
|
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
|
precedence and will be applied instead.
|
|
|
|
See also :setting:`DATETIME_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.
|
|
|
|
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
|
|
|
.. setting:: DATETIME_FORMAT
|
|
|
|
DATETIME_FORMAT
|
|
---------------
|
|
|
|
Default: ``'N j, Y, P'`` (e.g. ``Feb. 4, 2003, 4 p.m.``)
|
|
|
|
The default formatting to use for displaying datetime fields in any part of the
|
|
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|
locale-dictated format has higher precedence and will be applied instead. See
|
|
:tfilter:`allowed date format strings <date>`.
|
|
|
|
See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
|
|
|
.. setting:: DATETIME_INPUT_FORMATS
|
|
|
|
DATETIME_INPUT_FORMATS
|
|
----------------------
|
|
|
|
Default::
|
|
|
|
(
|
|
'%Y-%m-%d %H:%M:%S', # '2006-10-25 14:30:59'
|
|
'%Y-%m-%d %H:%M:%S.%f', # '2006-10-25 14:30:59.000200'
|
|
'%Y-%m-%d %H:%M', # '2006-10-25 14:30'
|
|
'%Y-%m-%d', # '2006-10-25'
|
|
'%m/%d/%Y %H:%M:%S', # '10/25/2006 14:30:59'
|
|
'%m/%d/%Y %H:%M:%S.%f', # '10/25/2006 14:30:59.000200'
|
|
'%m/%d/%Y %H:%M', # '10/25/2006 14:30'
|
|
'%m/%d/%Y', # '10/25/2006'
|
|
'%m/%d/%y %H:%M:%S', # '10/25/06 14:30:59'
|
|
'%m/%d/%y %H:%M:%S.%f', # '10/25/06 14:30:59.000200'
|
|
'%m/%d/%y %H:%M', # '10/25/06 14:30'
|
|
'%m/%d/%y', # '10/25/06'
|
|
)
|
|
|
|
A tuple of formats that will be accepted when inputting data on a datetime
|
|
field. Formats will be tried in order, using the first valid one. Note that
|
|
these format strings use Python's datetime_ module syntax, not the format
|
|
strings from the ``date`` Django template tag.
|
|
|
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
|
precedence and will be applied instead.
|
|
|
|
See also :setting:`DATE_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`.
|
|
|
|
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
|
|
|
.. setting:: DEBUG
|
|
|
|
DEBUG
|
|
-----
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that turns on/off debug mode.
|
|
|
|
Never deploy a site into production with :setting:`DEBUG` turned on.
|
|
|
|
Did you catch that? NEVER deploy a site into production with :setting:`DEBUG`
|
|
turned on.
|
|
|
|
One of the main features of debug mode is the display of detailed error pages.
|
|
If your app raises an exception when :setting:`DEBUG` is ``True``, Django will
|
|
display a detailed traceback, including a lot of metadata about your
|
|
environment, such as all the currently defined Django settings (from
|
|
``settings.py``).
|
|
|
|
As a security measure, Django will *not* include settings that might be
|
|
sensitive (or offensive), such as :setting:`SECRET_KEY` or
|
|
:setting:`PROFANITIES_LIST`. Specifically, it will exclude any setting whose
|
|
name includes any of the following:
|
|
|
|
* ``'API'``
|
|
* ``'KEY'``
|
|
* ``'PASS'``
|
|
* ``'PROFANITIES_LIST'``
|
|
* ``'SECRET'``
|
|
* ``'SIGNATURE'``
|
|
* ``'TOKEN'``
|
|
|
|
Note that these are *partial* matches. ``'PASS'`` will also match PASSWORD,
|
|
just as ``'TOKEN'`` will also match TOKENIZED and so on.
|
|
|
|
Still, note that there are always going to be sections of your debug output
|
|
that are inappropriate for public consumption. File paths, configuration
|
|
options and the like all give attackers extra information about your server.
|
|
|
|
It is also important to remember that when running with :setting:`DEBUG`
|
|
turned on, Django will remember every SQL query it executes. This is useful
|
|
when you're debugging, but it'll rapidly consume memory on a production server.
|
|
|
|
Finally, if :setting:`DEBUG` is ``False``, you also need to properly set
|
|
the :setting:`ALLOWED_HOSTS` setting. Failing to do so will result in all
|
|
requests being returned as "Bad Request (400)".
|
|
|
|
.. _django/views/debug.py: https://github.com/django/django/blob/master/django/views/debug.py
|
|
|
|
.. setting:: DEBUG_PROPAGATE_EXCEPTIONS
|
|
|
|
DEBUG_PROPAGATE_EXCEPTIONS
|
|
--------------------------
|
|
|
|
Default: ``False``
|
|
|
|
If set to True, Django's normal exception handling of view functions
|
|
will be suppressed, and exceptions will propagate upwards. This can
|
|
be useful for some test setups, and should never be used on a live
|
|
site.
|
|
|
|
.. setting:: DECIMAL_SEPARATOR
|
|
|
|
DECIMAL_SEPARATOR
|
|
-----------------
|
|
|
|
Default: ``'.'`` (Dot)
|
|
|
|
Default decimal separator used when formatting decimal numbers.
|
|
|
|
Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated
|
|
format has higher precedence and will be applied instead.
|
|
|
|
See also :setting:`NUMBER_GROUPING`, :setting:`THOUSAND_SEPARATOR` and
|
|
:setting:`USE_THOUSAND_SEPARATOR`.
|
|
|
|
|
|
.. setting:: DEFAULT_CHARSET
|
|
|
|
DEFAULT_CHARSET
|
|
---------------
|
|
|
|
Default: ``'utf-8'``
|
|
|
|
Default charset to use for all ``HttpResponse`` objects, if a MIME type isn't
|
|
manually specified. Used with :setting:`DEFAULT_CONTENT_TYPE` to construct the
|
|
``Content-Type`` header.
|
|
|
|
.. setting:: DEFAULT_CONTENT_TYPE
|
|
|
|
DEFAULT_CONTENT_TYPE
|
|
--------------------
|
|
|
|
Default: ``'text/html'``
|
|
|
|
Default content type to use for all ``HttpResponse`` objects, if a MIME type
|
|
isn't manually specified. Used with :setting:`DEFAULT_CHARSET` to construct
|
|
the ``Content-Type`` header.
|
|
|
|
.. setting:: DEFAULT_EXCEPTION_REPORTER_FILTER
|
|
|
|
DEFAULT_EXCEPTION_REPORTER_FILTER
|
|
---------------------------------
|
|
|
|
Default: :class:`django.views.debug.SafeExceptionReporterFilter`
|
|
|
|
Default exception reporter filter class to be used if none has been assigned to
|
|
the :class:`~django.http.HttpRequest` instance yet.
|
|
See :ref:`Filtering error reports<filtering-error-reports>`.
|
|
|
|
.. setting:: DEFAULT_FILE_STORAGE
|
|
|
|
DEFAULT_FILE_STORAGE
|
|
--------------------
|
|
|
|
Default: :class:`django.core.files.storage.FileSystemStorage`
|
|
|
|
Default file storage class to be used for any file-related operations that don't
|
|
specify a particular storage system. See :doc:`/topics/files`.
|
|
|
|
.. setting:: DEFAULT_FROM_EMAIL
|
|
|
|
DEFAULT_FROM_EMAIL
|
|
------------------
|
|
|
|
Default: ``'webmaster@localhost'``
|
|
|
|
Default email address to use for various automated correspondence from the
|
|
site manager(s).
|
|
|
|
.. setting:: DEFAULT_INDEX_TABLESPACE
|
|
|
|
DEFAULT_INDEX_TABLESPACE
|
|
------------------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Default tablespace to use for indexes on fields that don't specify
|
|
one, if the backend supports it (see :doc:`/topics/db/tablespaces`).
|
|
|
|
.. setting:: DEFAULT_TABLESPACE
|
|
|
|
DEFAULT_TABLESPACE
|
|
------------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Default tablespace to use for models that don't specify one, if the
|
|
backend supports it (see :doc:`/topics/db/tablespaces`).
|
|
|
|
.. setting:: DISALLOWED_USER_AGENTS
|
|
|
|
DISALLOWED_USER_AGENTS
|
|
----------------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
List of compiled regular expression objects representing User-Agent strings that
|
|
are not allowed to visit any page, systemwide. Use this for bad robots/crawlers.
|
|
This is only used if ``CommonMiddleware`` is installed (see
|
|
:doc:`/topics/http/middleware`).
|
|
|
|
.. setting:: EMAIL_BACKEND
|
|
|
|
EMAIL_BACKEND
|
|
-------------
|
|
|
|
Default: ``'django.core.mail.backends.smtp.EmailBackend'``
|
|
|
|
The backend to use for sending emails. For the list of available backends see
|
|
:doc:`/topics/email`.
|
|
|
|
.. setting:: EMAIL_FILE_PATH
|
|
|
|
EMAIL_FILE_PATH
|
|
---------------
|
|
|
|
Default: Not defined
|
|
|
|
The directory used by the ``file`` email backend to store output files.
|
|
|
|
.. setting:: EMAIL_HOST
|
|
|
|
EMAIL_HOST
|
|
----------
|
|
|
|
Default: ``'localhost'``
|
|
|
|
The host to use for sending email.
|
|
|
|
See also :setting:`EMAIL_PORT`.
|
|
|
|
.. setting:: EMAIL_HOST_PASSWORD
|
|
|
|
EMAIL_HOST_PASSWORD
|
|
-------------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Password to use for the SMTP server defined in :setting:`EMAIL_HOST`. This
|
|
setting is used in conjunction with :setting:`EMAIL_HOST_USER` when
|
|
authenticating to the SMTP server. If either of these settings is empty,
|
|
Django won't attempt authentication.
|
|
|
|
See also :setting:`EMAIL_HOST_USER`.
|
|
|
|
.. setting:: EMAIL_HOST_USER
|
|
|
|
EMAIL_HOST_USER
|
|
---------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Username to use for the SMTP server defined in :setting:`EMAIL_HOST`.
|
|
If empty, Django won't attempt authentication.
|
|
|
|
See also :setting:`EMAIL_HOST_PASSWORD`.
|
|
|
|
.. setting:: EMAIL_PORT
|
|
|
|
EMAIL_PORT
|
|
----------
|
|
|
|
Default: ``25``
|
|
|
|
Port to use for the SMTP server defined in :setting:`EMAIL_HOST`.
|
|
|
|
.. setting:: EMAIL_SUBJECT_PREFIX
|
|
|
|
EMAIL_SUBJECT_PREFIX
|
|
--------------------
|
|
|
|
Default: ``'[Django] '``
|
|
|
|
Subject-line prefix for email messages sent with ``django.core.mail.mail_admins``
|
|
or ``django.core.mail.mail_managers``. You'll probably want to include the
|
|
trailing space.
|
|
|
|
.. setting:: EMAIL_USE_TLS
|
|
|
|
EMAIL_USE_TLS
|
|
-------------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to use a TLS (secure) connection when talking to the SMTP server.
|
|
|
|
.. setting:: FILE_CHARSET
|
|
|
|
FILE_CHARSET
|
|
------------
|
|
|
|
Default: ``'utf-8'``
|
|
|
|
The character encoding used to decode any files read from disk. This includes
|
|
template files and initial SQL data files.
|
|
|
|
.. setting:: FILE_UPLOAD_HANDLERS
|
|
|
|
FILE_UPLOAD_HANDLERS
|
|
--------------------
|
|
|
|
Default::
|
|
|
|
("django.core.files.uploadhandler.MemoryFileUploadHandler",
|
|
"django.core.files.uploadhandler.TemporaryFileUploadHandler",)
|
|
|
|
A tuple of handlers to use for uploading. See :doc:`/topics/files` for details.
|
|
|
|
.. setting:: FILE_UPLOAD_MAX_MEMORY_SIZE
|
|
|
|
FILE_UPLOAD_MAX_MEMORY_SIZE
|
|
---------------------------
|
|
|
|
Default: ``2621440`` (i.e. 2.5 MB).
|
|
|
|
The maximum size (in bytes) that an upload will be before it gets streamed to
|
|
the file system. See :doc:`/topics/files` for details.
|
|
|
|
.. setting:: FILE_UPLOAD_PERMISSIONS
|
|
|
|
FILE_UPLOAD_PERMISSIONS
|
|
-----------------------
|
|
|
|
Default: ``None``
|
|
|
|
The numeric mode (i.e. ``0644``) to set newly uploaded files to. For
|
|
more information about what these modes mean, see the documentation for
|
|
:func:`os.chmod`.
|
|
|
|
If this isn't given or is ``None``, you'll get operating-system
|
|
dependent behavior. On most platforms, temporary files will have a mode
|
|
of ``0600``, and files saved from memory will be saved using the
|
|
system's standard umask.
|
|
|
|
.. warning::
|
|
|
|
**Always prefix the mode with a 0.**
|
|
|
|
If you're not familiar with file modes, please note that the leading
|
|
``0`` is very important: it indicates an octal number, which is the
|
|
way that modes must be specified. If you try to use ``644``, you'll
|
|
get totally incorrect behavior.
|
|
|
|
|
|
.. setting:: FILE_UPLOAD_TEMP_DIR
|
|
|
|
FILE_UPLOAD_TEMP_DIR
|
|
--------------------
|
|
|
|
Default: ``None``
|
|
|
|
The directory to store data temporarily while uploading files. If ``None``,
|
|
Django will use the standard temporary directory for the operating system. For
|
|
example, this will default to '/tmp' on \*nix-style operating systems.
|
|
|
|
See :doc:`/topics/files` for details.
|
|
|
|
.. setting:: FIRST_DAY_OF_WEEK
|
|
|
|
FIRST_DAY_OF_WEEK
|
|
-----------------
|
|
|
|
Default: ``0`` (Sunday)
|
|
|
|
Number representing the first day of the week. This is especially useful
|
|
when displaying a calendar. This value is only used when not using
|
|
format internationalization, or when a format cannot be found for the
|
|
current locale.
|
|
|
|
The value must be an integer from 0 to 6, where 0 means Sunday, 1 means
|
|
Monday and so on.
|
|
|
|
.. setting:: FIXTURE_DIRS
|
|
|
|
FIXTURE_DIRS
|
|
-------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
List of directories searched for fixture files, in addition to the
|
|
``fixtures`` directory of each application, in search order.
|
|
|
|
Note that these paths should use Unix-style forward slashes, even on Windows.
|
|
|
|
See :ref:`initial-data-via-fixtures` and :ref:`topics-testing-fixtures`.
|
|
|
|
.. setting:: FORCE_SCRIPT_NAME
|
|
|
|
FORCE_SCRIPT_NAME
|
|
------------------
|
|
|
|
Default: ``None``
|
|
|
|
If not ``None``, this will be used as the value of the ``SCRIPT_NAME``
|
|
environment variable in any HTTP request. This setting can be used to override
|
|
the server-provided value of ``SCRIPT_NAME``, which may be a rewritten version
|
|
of the preferred value or not supplied at all.
|
|
|
|
.. setting:: FORMAT_MODULE_PATH
|
|
|
|
FORMAT_MODULE_PATH
|
|
------------------
|
|
|
|
Default: ``None``
|
|
|
|
A full Python path to a Python package that contains format definitions for
|
|
project locales. If not ``None``, Django will check for a ``formats.py``
|
|
file, under the directory named as the current locale, and will use the
|
|
formats defined on this file.
|
|
|
|
For example, if :setting:`FORMAT_MODULE_PATH` is set to ``mysite.formats``,
|
|
and current language is ``en`` (English), Django will expect a directory tree
|
|
like::
|
|
|
|
mysite/
|
|
formats/
|
|
__init__.py
|
|
en/
|
|
__init__.py
|
|
formats.py
|
|
|
|
Available formats are :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`,
|
|
:setting:`DATETIME_FORMAT`, :setting:`YEAR_MONTH_FORMAT`,
|
|
:setting:`MONTH_DAY_FORMAT`, :setting:`SHORT_DATE_FORMAT`,
|
|
:setting:`SHORT_DATETIME_FORMAT`, :setting:`FIRST_DAY_OF_WEEK`,
|
|
:setting:`DECIMAL_SEPARATOR`, :setting:`THOUSAND_SEPARATOR` and
|
|
:setting:`NUMBER_GROUPING`.
|
|
|
|
.. setting:: IGNORABLE_404_URLS
|
|
|
|
IGNORABLE_404_URLS
|
|
------------------
|
|
|
|
Default: ``()``
|
|
|
|
List of compiled regular expression objects describing URLs that should be
|
|
ignored when reporting HTTP 404 errors via email (see
|
|
:doc:`/howto/error-reporting`). Regular expressions are matched against
|
|
:meth:`request's full paths <django.http.HttpRequest.get_full_path>` (including
|
|
query string, if any). Use this if your site does not provide a commonly
|
|
requested file such as ``favicon.ico`` or ``robots.txt``, or if it gets
|
|
hammered by script kiddies.
|
|
|
|
This is only used if
|
|
:class:`~django.middleware.common.BrokenLinkEmailsMiddleware` is enabled (see
|
|
:doc:`/topics/http/middleware`).
|
|
|
|
.. setting:: INSTALLED_APPS
|
|
|
|
INSTALLED_APPS
|
|
--------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple of strings designating all applications that are enabled in this Django
|
|
installation. Each string should be a full Python path to a Python package that
|
|
contains a Django application, as created by :djadmin:`django-admin.py startapp
|
|
<startapp>`.
|
|
|
|
.. admonition:: App names must be unique
|
|
|
|
The application names (that is, the final dotted part of the
|
|
path to the module containing ``models.py``) defined in
|
|
:setting:`INSTALLED_APPS` *must* be unique. For example, you can't
|
|
include both ``django.contrib.auth`` and ``myproject.auth`` in
|
|
INSTALLED_APPS.
|
|
|
|
.. setting:: INTERNAL_IPS
|
|
|
|
INTERNAL_IPS
|
|
------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple of IP addresses, as strings, that:
|
|
|
|
* See debug comments, when :setting:`DEBUG` is ``True``
|
|
* Receive X headers in admindocs if the ``XViewMiddleware`` is installed (see
|
|
:doc:`/topics/http/middleware`)
|
|
|
|
.. setting:: LANGUAGE_CODE
|
|
|
|
LANGUAGE_CODE
|
|
-------------
|
|
|
|
Default: ``'en-us'``
|
|
|
|
A string representing the language code for this installation. This should be
|
|
in standard :term:`language format<language code>`. For example, U.S. English
|
|
is ``"en-us"``. See also the `list of language identifiers`_ and
|
|
:doc:`/topics/i18n/index`.
|
|
|
|
.. _list of language identifiers: http://www.i18nguy.com/unicode/language-identifiers.html
|
|
|
|
.. setting:: LANGUAGE_COOKIE_NAME
|
|
|
|
LANGUAGE_COOKIE_NAME
|
|
--------------------
|
|
|
|
Default: ``'django_language'``
|
|
|
|
The name of the cookie to use for the language cookie. This can be whatever
|
|
you want (but should be different from :setting:`SESSION_COOKIE_NAME`). See
|
|
:doc:`/topics/i18n/index`.
|
|
|
|
.. setting:: LANGUAGES
|
|
|
|
LANGUAGES
|
|
---------
|
|
|
|
Default: A tuple of all available languages. This list is continually growing
|
|
and including a copy here would inevitably become rapidly out of date. You can
|
|
see the current list of translated languages by looking in
|
|
``django/conf/global_settings.py`` (or view the `online source`_).
|
|
|
|
.. _online source: https://github.com/django/django/blob/master/django/conf/global_settings.py
|
|
|
|
The list is a tuple of two-tuples in the format
|
|
(:term:`language code<language code>`, ``language name``) -- for example,
|
|
``('ja', 'Japanese')``.
|
|
This specifies which languages are available for language selection. See
|
|
:doc:`/topics/i18n/index`.
|
|
|
|
Generally, the default value should suffice. Only set this setting if you want
|
|
to restrict language selection to a subset of the Django-provided languages.
|
|
|
|
If you define a custom :setting:`LANGUAGES` setting, it's OK to mark the
|
|
languages as translation strings (as in the default value referred to above)
|
|
-- but use a "dummy" ``gettext()`` function, not the one in
|
|
``django.utils.translation``. You should *never* import
|
|
``django.utils.translation`` from within your settings file, because that
|
|
module in itself depends on the settings, and that would cause a circular
|
|
import.
|
|
|
|
The solution is to use a "dummy" ``gettext()`` function. Here's a sample
|
|
settings file::
|
|
|
|
gettext = lambda s: s
|
|
|
|
LANGUAGES = (
|
|
('de', gettext('German')),
|
|
('en', gettext('English')),
|
|
)
|
|
|
|
With this arrangement, ``django-admin.py makemessages`` will still find and
|
|
mark these strings for translation, but the translation won't happen at
|
|
runtime -- so you'll have to remember to wrap the languages in the *real*
|
|
``gettext()`` in any code that uses :setting:`LANGUAGES` at runtime.
|
|
|
|
.. setting:: LOCALE_PATHS
|
|
|
|
LOCALE_PATHS
|
|
------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple of directories where Django looks for translation files.
|
|
See :ref:`how-django-discovers-translations`.
|
|
|
|
Example::
|
|
|
|
LOCALE_PATHS = (
|
|
'/home/www/project/common_files/locale',
|
|
'/var/local/translations/locale'
|
|
)
|
|
|
|
Django will look within each of these paths for the ``<locale_code>/LC_MESSAGES``
|
|
directories containing the actual translation files.
|
|
|
|
.. setting:: LOGGING
|
|
|
|
LOGGING
|
|
-------
|
|
|
|
Default: A logging configuration dictionary.
|
|
|
|
A data structure containing configuration information. The contents of
|
|
this data structure will be passed as the argument to the
|
|
configuration method described in :setting:`LOGGING_CONFIG`.
|
|
|
|
Among other things, the default logging configuration passes HTTP 500 server
|
|
errors to an email log handler when :setting:`DEBUG` is ``False``. See also
|
|
:ref:`configuring-logging`.
|
|
|
|
You can see the default logging configuration by looking in
|
|
``django/utils/log.py`` (or view the `online source`__).
|
|
|
|
__ https://github.com/django/django/blob/master/django/utils/log.py
|
|
|
|
.. setting:: LOGGING_CONFIG
|
|
|
|
LOGGING_CONFIG
|
|
--------------
|
|
|
|
Default: ``'logging.config.dictConfig'``
|
|
|
|
A path to a callable that will be used to configure logging in the
|
|
Django project. Points at a instance of Python's `dictConfig`_
|
|
configuration method by default.
|
|
|
|
If you set :setting:`LOGGING_CONFIG` to ``None``, the logging
|
|
configuration process will be skipped.
|
|
|
|
.. versionchanged:: 1.7
|
|
|
|
Previously, the default value was ``'django.utils.log.dictConfig'``.
|
|
|
|
.. _dictConfig: http://docs.python.org/library/logging.config.html#configuration-dictionary-schema
|
|
|
|
.. setting:: MANAGERS
|
|
|
|
MANAGERS
|
|
--------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple in the same format as :setting:`ADMINS` that specifies who should get
|
|
broken link notifications when
|
|
:class:`~django.middleware.common.BrokenLinkEmailsMiddleware` is enabled.
|
|
|
|
.. setting:: MEDIA_ROOT
|
|
|
|
MEDIA_ROOT
|
|
----------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Absolute filesystem path to the directory that will hold :doc:`user-uploaded
|
|
files </topics/files>`.
|
|
|
|
Example: ``"/var/www/example.com/media/"``
|
|
|
|
See also :setting:`MEDIA_URL`.
|
|
|
|
.. setting:: MEDIA_URL
|
|
|
|
MEDIA_URL
|
|
---------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
URL that handles the media served from :setting:`MEDIA_ROOT`, used
|
|
for :doc:`managing stored files </topics/files>`. It must end in a slash if set
|
|
to a non-empty value.
|
|
|
|
Example: ``"http://media.example.com/"``
|
|
|
|
.. setting:: MIDDLEWARE_CLASSES
|
|
|
|
MIDDLEWARE_CLASSES
|
|
------------------
|
|
|
|
Default::
|
|
|
|
('django.middleware.common.CommonMiddleware',
|
|
'django.contrib.sessions.middleware.SessionMiddleware',
|
|
'django.middleware.csrf.CsrfViewMiddleware',
|
|
'django.contrib.auth.middleware.AuthenticationMiddleware',
|
|
'django.contrib.messages.middleware.MessageMiddleware',)
|
|
|
|
A tuple of middleware classes to use. See :doc:`/topics/http/middleware`.
|
|
|
|
.. setting:: MONTH_DAY_FORMAT
|
|
|
|
MONTH_DAY_FORMAT
|
|
----------------
|
|
|
|
Default: ``'F j'``
|
|
|
|
The default formatting to use for date fields on Django admin change-list
|
|
pages -- and, possibly, by other parts of the system -- in cases when only the
|
|
month and day are displayed.
|
|
|
|
For example, when a Django admin change-list page is being filtered by a date
|
|
drilldown, the header for a given day displays the day and month. Different
|
|
locales have different formats. For example, U.S. English would say
|
|
"January 1," whereas Spanish might say "1 Enero."
|
|
|
|
See :tfilter:`allowed date format strings <date>`. See also
|
|
:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`,
|
|
:setting:`TIME_FORMAT` and :setting:`YEAR_MONTH_FORMAT`.
|
|
|
|
.. setting:: NUMBER_GROUPING
|
|
|
|
NUMBER_GROUPING
|
|
----------------
|
|
|
|
Default: ``0``
|
|
|
|
Number of digits grouped together on the integer part of a number.
|
|
|
|
Common use is to display a thousand separator. If this setting is ``0``, then
|
|
no grouping will be applied to the number. If this setting is greater than
|
|
``0``, then :setting:`THOUSAND_SEPARATOR` will be used as the separator between
|
|
those groups.
|
|
|
|
Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated
|
|
format has higher precedence and will be applied instead.
|
|
|
|
See also :setting:`DECIMAL_SEPARATOR`, :setting:`THOUSAND_SEPARATOR` and
|
|
:setting:`USE_THOUSAND_SEPARATOR`.
|
|
|
|
.. setting:: PREPEND_WWW
|
|
|
|
PREPEND_WWW
|
|
-----------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to prepend the "www." subdomain to URLs that don't have it. This is only
|
|
used if :class:`~django.middleware.common.CommonMiddleware` is installed
|
|
(see :doc:`/topics/http/middleware`). See also :setting:`APPEND_SLASH`.
|
|
|
|
.. setting:: ROOT_URLCONF
|
|
|
|
ROOT_URLCONF
|
|
------------
|
|
|
|
Default: Not defined
|
|
|
|
A string representing the full Python import path to your root URLconf. For example:
|
|
``"mydjangoapps.urls"``. Can be overridden on a per-request basis by
|
|
setting the attribute ``urlconf`` on the incoming ``HttpRequest``
|
|
object. See :ref:`how-django-processes-a-request` for details.
|
|
|
|
.. setting:: SECRET_KEY
|
|
|
|
SECRET_KEY
|
|
----------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
A secret key for a particular Django installation. This is used to provide
|
|
:doc:`cryptographic signing </topics/signing>`, and should be set to a unique,
|
|
unpredictable value.
|
|
|
|
:djadmin:`django-admin.py startproject <startproject>` automatically adds a
|
|
randomly-generated ``SECRET_KEY`` to each new project.
|
|
|
|
.. warning::
|
|
|
|
**Keep this value secret.**
|
|
|
|
Running Django with a known :setting:`SECRET_KEY` defeats many of Django's
|
|
security protections, and can lead to privilege escalation and remote code
|
|
execution vulnerabilities.
|
|
|
|
.. versionchanged:: 1.5
|
|
|
|
Django will now refuse to start if :setting:`SECRET_KEY` is not set.
|
|
|
|
.. setting:: SECURE_PROXY_SSL_HEADER
|
|
|
|
SECURE_PROXY_SSL_HEADER
|
|
-----------------------
|
|
|
|
Default: ``None``
|
|
|
|
A tuple representing a HTTP header/value combination that signifies a request
|
|
is secure. This controls the behavior of the request object's ``is_secure()``
|
|
method.
|
|
|
|
This takes some explanation. By default, ``is_secure()`` is able to determine
|
|
whether a request is secure by looking at whether the requested URL uses
|
|
"https://". This is important for Django's CSRF protection, and may be used
|
|
by your own code or third-party apps.
|
|
|
|
If your Django app is behind a proxy, though, the proxy may be "swallowing" the
|
|
fact that a request is HTTPS, using a non-HTTPS connection between the proxy
|
|
and Django. In this case, ``is_secure()`` would always return ``False`` -- even
|
|
for requests that were made via HTTPS by the end user.
|
|
|
|
In this situation, you'll want to configure your proxy to set a custom HTTP
|
|
header that tells Django whether the request came in via HTTPS, and you'll want
|
|
to set ``SECURE_PROXY_SSL_HEADER`` so that Django knows what header to look
|
|
for.
|
|
|
|
You'll need to set a tuple with two elements -- the name of the header to look
|
|
for and the required value. For example::
|
|
|
|
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
|
|
|
|
Here, we're telling Django that we trust the ``X-Forwarded-Proto`` header
|
|
that comes from our proxy, and any time its value is ``'https'``, then the
|
|
request is guaranteed to be secure (i.e., it originally came in via HTTPS).
|
|
Obviously, you should *only* set this setting if you control your proxy or
|
|
have some other guarantee that it sets/strips this header appropriately.
|
|
|
|
Note that the header needs to be in the format as used by ``request.META`` --
|
|
all caps and likely starting with ``HTTP_``. (Remember, Django automatically
|
|
adds ``'HTTP_'`` to the start of x-header names before making the header
|
|
available in ``request.META``.)
|
|
|
|
.. warning::
|
|
|
|
**You will probably open security holes in your site if you set this
|
|
without knowing what you're doing. And if you fail to set it when you
|
|
should. Seriously.**
|
|
|
|
Make sure ALL of the following are true before setting this (assuming the
|
|
values from the example above):
|
|
|
|
* Your Django app is behind a proxy.
|
|
* Your proxy strips the ``X-Forwarded-Proto`` header from all incoming
|
|
requests. In other words, if end users include that header in their
|
|
requests, the proxy will discard it.
|
|
* Your proxy sets the ``X-Forwarded-Proto`` header and sends it to Django,
|
|
but only for requests that originally come in via HTTPS.
|
|
|
|
If any of those are not true, you should keep this setting set to ``None``
|
|
and find another way of determining HTTPS, perhaps via custom middleware.
|
|
|
|
.. setting:: SEND_BROKEN_LINK_EMAILS
|
|
|
|
SEND_BROKEN_LINK_EMAILS
|
|
-----------------------
|
|
|
|
.. deprecated:: 1.6
|
|
Since :class:`~django.middleware.common.BrokenLinkEmailsMiddleware`
|
|
was split from :class:`~django.middleware.common.CommonMiddleware`,
|
|
this setting no longer serves a purpose.
|
|
|
|
Default: ``False``
|
|
|
|
Whether to send an email to the :setting:`MANAGERS` each time somebody visits
|
|
a Django-powered page that is 404ed with a non-empty referer (i.e., a broken
|
|
link). This is only used if ``CommonMiddleware`` is installed (see
|
|
:doc:`/topics/http/middleware`). See also :setting:`IGNORABLE_404_URLS` and
|
|
:doc:`/howto/error-reporting`.
|
|
|
|
.. setting:: SERIALIZATION_MODULES
|
|
|
|
SERIALIZATION_MODULES
|
|
---------------------
|
|
|
|
Default: Not defined.
|
|
|
|
A dictionary of modules containing serializer definitions (provided as
|
|
strings), keyed by a string identifier for that serialization type. For
|
|
example, to define a YAML serializer, use::
|
|
|
|
SERIALIZATION_MODULES = { 'yaml' : 'path.to.yaml_serializer' }
|
|
|
|
.. setting:: SERVER_EMAIL
|
|
|
|
SERVER_EMAIL
|
|
------------
|
|
|
|
Default: ``'root@localhost'``
|
|
|
|
The email address that error messages come from, such as those sent to
|
|
:setting:`ADMINS` and :setting:`MANAGERS`.
|
|
|
|
.. setting:: SHORT_DATE_FORMAT
|
|
|
|
SHORT_DATE_FORMAT
|
|
-----------------
|
|
|
|
Default: ``m/d/Y`` (e.g. ``12/31/2003``)
|
|
|
|
An available formatting that can be used for displaying date fields on
|
|
templates. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|
corresponding locale-dictated format has higher precedence and will be applied.
|
|
See :tfilter:`allowed date format strings <date>`.
|
|
|
|
See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.
|
|
|
|
.. setting:: SHORT_DATETIME_FORMAT
|
|
|
|
SHORT_DATETIME_FORMAT
|
|
---------------------
|
|
|
|
Default: ``m/d/Y P`` (e.g. ``12/31/2003 4 p.m.``)
|
|
|
|
An available formatting that can be used for displaying datetime fields on
|
|
templates. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|
corresponding locale-dictated format has higher precedence and will be applied.
|
|
See :tfilter:`allowed date format strings <date>`.
|
|
|
|
See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`.
|
|
|
|
.. setting:: SIGNING_BACKEND
|
|
|
|
SIGNING_BACKEND
|
|
---------------
|
|
|
|
Default: 'django.core.signing.TimestampSigner'
|
|
|
|
The backend used for signing cookies and other data.
|
|
|
|
See also the :doc:`/topics/signing` documentation.
|
|
|
|
.. setting:: TEMPLATE_CONTEXT_PROCESSORS
|
|
|
|
TEMPLATE_CONTEXT_PROCESSORS
|
|
---------------------------
|
|
|
|
Default::
|
|
|
|
("django.contrib.auth.context_processors.auth",
|
|
"django.core.context_processors.debug",
|
|
"django.core.context_processors.i18n",
|
|
"django.core.context_processors.media",
|
|
"django.core.context_processors.static",
|
|
"django.core.context_processors.tz",
|
|
"django.contrib.messages.context_processors.messages")
|
|
|
|
A tuple of callables that are used to populate the context in ``RequestContext``.
|
|
These callables take a request object as their argument and return a dictionary
|
|
of items to be merged into the context.
|
|
|
|
.. setting:: TEMPLATE_DEBUG
|
|
|
|
TEMPLATE_DEBUG
|
|
--------------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that turns on/off template debug mode. If this is ``True``, the fancy
|
|
error page will display a detailed report for any exception raised during
|
|
template rendering. This report contains the relevant snippet of the template,
|
|
with the appropriate line highlighted.
|
|
|
|
Note that Django only displays fancy error pages if :setting:`DEBUG` is ``True``, so
|
|
you'll want to set that to take advantage of this setting.
|
|
|
|
See also :setting:`DEBUG`.
|
|
|
|
.. setting:: TEMPLATE_DIRS
|
|
|
|
TEMPLATE_DIRS
|
|
-------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
List of locations of the template source files searched by
|
|
:class:`django.template.loaders.filesystem.Loader`, in search order.
|
|
|
|
Note that these paths should use Unix-style forward slashes, even on Windows.
|
|
|
|
See :doc:`/topics/templates`.
|
|
|
|
.. setting:: TEMPLATE_LOADERS
|
|
|
|
TEMPLATE_LOADERS
|
|
----------------
|
|
|
|
Default::
|
|
|
|
('django.template.loaders.filesystem.Loader',
|
|
'django.template.loaders.app_directories.Loader')
|
|
|
|
A tuple of template loader classes, specified as strings. Each ``Loader`` class
|
|
knows how to import templates from a particular source. Optionally, a tuple can be
|
|
used instead of a string. The first item in the tuple should be the ``Loader``'s
|
|
module, subsequent items are passed to the ``Loader`` during initialization. See
|
|
:doc:`/ref/templates/api`.
|
|
|
|
.. setting:: TEMPLATE_STRING_IF_INVALID
|
|
|
|
TEMPLATE_STRING_IF_INVALID
|
|
--------------------------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
Output, as a string, that the template system should use for invalid (e.g.
|
|
misspelled) variables. See :ref:`invalid-template-variables`..
|
|
|
|
.. setting:: TEST_RUNNER
|
|
|
|
TEST_RUNNER
|
|
-----------
|
|
|
|
Default: ``'django.test.runner.DiscoverRunner'``
|
|
|
|
The name of the class to use for starting the test suite. See
|
|
:ref:`other-testing-frameworks`.
|
|
|
|
.. versionchanged:: 1.6
|
|
|
|
Previously the default ``TEST_RUNNER`` was
|
|
``django.test.simple.DjangoTestSuiteRunner``.
|
|
|
|
.. setting:: THOUSAND_SEPARATOR
|
|
|
|
THOUSAND_SEPARATOR
|
|
------------------
|
|
|
|
Default: ``,`` (Comma)
|
|
|
|
Default thousand separator used when formatting numbers. This setting is
|
|
used only when :setting:`USE_THOUSAND_SEPARATOR` is ``True`` and
|
|
:setting:`NUMBER_GROUPING` is greater than ``0``.
|
|
|
|
Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated
|
|
format has higher precedence and will be applied instead.
|
|
|
|
See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and
|
|
:setting:`USE_THOUSAND_SEPARATOR`.
|
|
|
|
.. setting:: TIME_FORMAT
|
|
|
|
TIME_FORMAT
|
|
-----------
|
|
|
|
Default: ``'P'`` (e.g. ``4 p.m.``)
|
|
|
|
The default formatting to use for displaying time fields in any part of the
|
|
system. Note that if :setting:`USE_L10N` is set to ``True``, then the
|
|
locale-dictated format has higher precedence and will be applied instead. See
|
|
:tfilter:`allowed date format strings <date>`.
|
|
|
|
See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.
|
|
|
|
.. setting:: TIME_INPUT_FORMATS
|
|
|
|
TIME_INPUT_FORMATS
|
|
------------------
|
|
|
|
Default::
|
|
|
|
(
|
|
'%H:%M:%S', # '14:30:59'
|
|
'%H:%M:%S.%f', # '14:30:59.000200'
|
|
'%H:%M', # '14:30'
|
|
)
|
|
|
|
A tuple of formats that will be accepted when inputting data on a time field.
|
|
Formats will be tried in order, using the first valid one. Note that these
|
|
format strings use Python's datetime_ module syntax, not the format strings
|
|
from the ``date`` Django template tag.
|
|
|
|
When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher
|
|
precedence and will be applied instead.
|
|
|
|
See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.
|
|
|
|
.. versionchanged:: 1.6
|
|
|
|
Input format with microseconds has been added.
|
|
|
|
.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior
|
|
|
|
.. setting:: TIME_ZONE
|
|
|
|
TIME_ZONE
|
|
---------
|
|
|
|
Default: ``'America/Chicago'``
|
|
|
|
A string representing the time zone for this installation, or ``None``. See
|
|
the `list of time zones`_.
|
|
|
|
.. note::
|
|
Since Django was first released with the :setting:`TIME_ZONE` set to
|
|
``'America/Chicago'``, the global setting (used if nothing is defined in
|
|
your project's ``settings.py``) remains ``'America/Chicago'`` for backwards
|
|
compatibility. New project templates default to ``'UTC'``.
|
|
|
|
Note that this isn't necessarily the time zone of the server. For example, one
|
|
server may serve multiple Django-powered sites, each with a separate time zone
|
|
setting.
|
|
|
|
When :setting:`USE_TZ` is ``False``, this is the time zone in which Django
|
|
will store all datetimes. When :setting:`USE_TZ` is ``True``, this is the
|
|
default time zone that Django will use to display datetimes in templates and
|
|
to interpret datetimes entered in forms.
|
|
|
|
Django sets the ``os.environ['TZ']`` variable to the time zone you specify in
|
|
the :setting:`TIME_ZONE` setting. Thus, all your views and models will
|
|
automatically operate in this time zone. However, Django won't set the ``TZ``
|
|
environment variable under the following conditions:
|
|
|
|
* If you're using the manual configuration option as described in
|
|
:ref:`manually configuring settings
|
|
<settings-without-django-settings-module>`, or
|
|
|
|
* If you specify ``TIME_ZONE = None``. This will cause Django to fall back to
|
|
using the system timezone. However, this is discouraged when :setting:`USE_TZ
|
|
= True <USE_TZ>`, because it makes conversions between local time and UTC
|
|
less reliable.
|
|
|
|
If Django doesn't set the ``TZ`` environment variable, it's up to you
|
|
to ensure your processes are running in the correct environment.
|
|
|
|
.. note::
|
|
Django cannot reliably use alternate time zones in a Windows environment.
|
|
If you're running Django on Windows, :setting:`TIME_ZONE` must be set to
|
|
match the system time zone.
|
|
|
|
.. _list of time zones: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
|
|
|
|
.. _pytz: http://pytz.sourceforge.net/
|
|
|
|
.. setting:: TRANSACTIONS_MANAGED
|
|
|
|
TRANSACTIONS_MANAGED
|
|
--------------------
|
|
|
|
.. deprecated:: 1.6
|
|
|
|
This setting was deprecated because its name is very misleading. Use the
|
|
:setting:`AUTOCOMMIT <DATABASE-AUTOCOMMIT>` key in :setting:`DATABASES`
|
|
entries instead.
|
|
|
|
Default: ``False``
|
|
|
|
Set this to ``True`` if you want to :ref:`disable Django's transaction
|
|
management <deactivate-transaction-management>` and implement your own.
|
|
|
|
.. setting:: USE_ETAGS
|
|
|
|
USE_ETAGS
|
|
---------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that specifies whether to output the "Etag" header. This saves
|
|
bandwidth but slows down performance. This is used by the ``CommonMiddleware``
|
|
(see :doc:`/topics/http/middleware`) and in the``Cache Framework``
|
|
(see :doc:`/topics/cache`).
|
|
|
|
.. setting:: USE_I18N
|
|
|
|
USE_I18N
|
|
--------
|
|
|
|
Default: ``True``
|
|
|
|
A boolean that specifies whether Django's translation system should be enabled.
|
|
This provides an easy way to turn it off, for performance. If this is set to
|
|
``False``, Django will make some optimizations so as not to load the
|
|
translation machinery.
|
|
|
|
See also :setting:`LANGUAGE_CODE`, :setting:`USE_L10N` and :setting:`USE_TZ`.
|
|
|
|
.. setting:: USE_L10N
|
|
|
|
USE_L10N
|
|
--------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that specifies if localized formatting of data will be enabled by
|
|
default or not. If this is set to ``True``, e.g. Django will display numbers and
|
|
dates using the format of the current locale.
|
|
|
|
See also :setting:`LANGUAGE_CODE`, :setting:`USE_I18N` and :setting:`USE_TZ`.
|
|
|
|
.. note::
|
|
|
|
The default :file:`settings.py` file created by :djadmin:`django-admin.py
|
|
startproject <startproject>` includes ``USE_L10N = True`` for convenience.
|
|
|
|
.. setting:: USE_THOUSAND_SEPARATOR
|
|
|
|
USE_THOUSAND_SEPARATOR
|
|
----------------------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that specifies whether to display numbers using a thousand separator.
|
|
When :setting:`USE_L10N` is set to ``True`` and if this is also set to
|
|
``True``, Django will use the values of :setting:`THOUSAND_SEPARATOR` and
|
|
:setting:`NUMBER_GROUPING` to format numbers.
|
|
|
|
See also :setting:`DECIMAL_SEPARATOR`, :setting:`NUMBER_GROUPING` and
|
|
:setting:`THOUSAND_SEPARATOR`.
|
|
|
|
.. setting:: USE_TZ
|
|
|
|
USE_TZ
|
|
------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that specifies if datetimes will be timezone-aware by default or not.
|
|
If this is set to ``True``, Django will use timezone-aware datetimes internally.
|
|
Otherwise, Django will use naive datetimes in local time.
|
|
|
|
See also :setting:`TIME_ZONE`, :setting:`USE_I18N` and :setting:`USE_L10N`.
|
|
|
|
.. note::
|
|
|
|
The default :file:`settings.py` file created by
|
|
:djadmin:`django-admin.py startproject <startproject>` includes
|
|
``USE_TZ = True`` for convenience.
|
|
|
|
.. setting:: USE_X_FORWARDED_HOST
|
|
|
|
USE_X_FORWARDED_HOST
|
|
--------------------
|
|
|
|
Default: ``False``
|
|
|
|
A boolean that specifies whether to use the X-Forwarded-Host header in
|
|
preference to the Host header. This should only be enabled if a proxy
|
|
which sets this header is in use.
|
|
|
|
.. setting:: WSGI_APPLICATION
|
|
|
|
WSGI_APPLICATION
|
|
----------------
|
|
|
|
Default: ``None``
|
|
|
|
The full Python path of the WSGI application object that Django's built-in
|
|
servers (e.g. :djadmin:`runserver`) will use. The :djadmin:`django-admin.py
|
|
startproject <startproject>` management command will create a simple
|
|
``wsgi.py`` file with an ``application`` callable in it, and point this setting
|
|
to that ``application``.
|
|
|
|
If not set, the return value of ``django.core.wsgi.get_wsgi_application()``
|
|
will be used. In this case, the behavior of :djadmin:`runserver` will be
|
|
identical to previous Django versions.
|
|
|
|
.. setting:: YEAR_MONTH_FORMAT
|
|
|
|
YEAR_MONTH_FORMAT
|
|
-----------------
|
|
|
|
Default: ``'F Y'``
|
|
|
|
The default formatting to use for date fields on Django admin change-list
|
|
pages -- and, possibly, by other parts of the system -- in cases when only the
|
|
year and month are displayed.
|
|
|
|
For example, when a Django admin change-list page is being filtered by a date
|
|
drilldown, the header for a given month displays the month and the year.
|
|
Different locales have different formats. For example, U.S. English would say
|
|
"January 2006," whereas another locale might say "2006/January."
|
|
|
|
See :tfilter:`allowed date format strings <date>`. See also
|
|
:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT`
|
|
and :setting:`MONTH_DAY_FORMAT`.
|
|
|
|
.. setting:: X_FRAME_OPTIONS
|
|
|
|
X_FRAME_OPTIONS
|
|
---------------
|
|
|
|
Default: ``'SAMEORIGIN'``
|
|
|
|
The default value for the X-Frame-Options header used by
|
|
:class:`~django.middleware.clickjacking.XFrameOptionsMiddleware`. See the
|
|
:doc:`clickjacking protection </ref/clickjacking/>` documentation.
|
|
|
|
|
|
Admindocs
|
|
=========
|
|
|
|
Settings for :mod:`django.contrib.admindocs`.
|
|
|
|
.. setting:: ADMIN_FOR
|
|
|
|
ADMIN_FOR
|
|
---------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
Used for admin-site settings modules, this should be a tuple of settings
|
|
modules (in the format ``'foo.bar.baz'``) for which this site is an admin.
|
|
|
|
The admin site uses this in its automatically-introspected documentation of
|
|
models, views and template tags.
|
|
|
|
|
|
Auth
|
|
====
|
|
|
|
Settings for :mod:`django.contrib.auth`.
|
|
|
|
.. setting:: AUTHENTICATION_BACKENDS
|
|
|
|
AUTHENTICATION_BACKENDS
|
|
-----------------------
|
|
|
|
Default: ``('django.contrib.auth.backends.ModelBackend',)``
|
|
|
|
A tuple of authentication backend classes (as strings) to use when attempting to
|
|
authenticate a user. See the :ref:`authentication backends documentation
|
|
<authentication-backends>` for details.
|
|
|
|
.. setting:: AUTH_USER_MODEL
|
|
|
|
AUTH_USER_MODEL
|
|
---------------
|
|
|
|
Default: 'auth.User'
|
|
|
|
The model to use to represent a User. See :ref:`auth-custom-user`.
|
|
|
|
.. setting:: LOGIN_REDIRECT_URL
|
|
|
|
LOGIN_REDIRECT_URL
|
|
------------------
|
|
|
|
Default: ``'/accounts/profile/'``
|
|
|
|
The URL where requests are redirected after login when the
|
|
``contrib.auth.login`` view gets no ``next`` parameter.
|
|
|
|
This is used by the :func:`~django.contrib.auth.decorators.login_required`
|
|
decorator, for example.
|
|
|
|
.. versionchanged:: 1.5
|
|
|
|
This setting now also accepts view function names and
|
|
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
|
configuration duplication since you no longer have to define the URL in two
|
|
places (``settings`` and URLconf).
|
|
For backward compatibility reasons the default remains unchanged.
|
|
|
|
.. setting:: LOGIN_URL
|
|
|
|
LOGIN_URL
|
|
---------
|
|
|
|
Default: ``'/accounts/login/'``
|
|
|
|
The URL where requests are redirected for login, especially when using the
|
|
:func:`~django.contrib.auth.decorators.login_required` decorator.
|
|
|
|
.. versionchanged:: 1.5
|
|
|
|
This setting now also accepts view function names and
|
|
:ref:`named URL patterns <naming-url-patterns>` which can be used to reduce
|
|
configuration duplication since you no longer have to define the URL in two
|
|
places (``settings`` and URLconf).
|
|
For backward compatibility reasons the default remains unchanged.
|
|
|
|
.. setting:: LOGOUT_URL
|
|
|
|
LOGOUT_URL
|
|
----------
|
|
|
|
Default: ``'/accounts/logout/'``
|
|
|
|
LOGIN_URL counterpart.
|
|
|
|
.. setting:: PASSWORD_RESET_TIMEOUT_DAYS
|
|
|
|
PASSWORD_RESET_TIMEOUT_DAYS
|
|
---------------------------
|
|
|
|
Default: ``3``
|
|
|
|
The number of days a password reset link is valid for. Used by the
|
|
:mod:`django.contrib.auth` password reset mechanism.
|
|
|
|
.. setting:: PASSWORD_HASHERS
|
|
|
|
PASSWORD_HASHERS
|
|
----------------
|
|
|
|
See :ref:`auth_password_storage`.
|
|
|
|
Default::
|
|
|
|
('django.contrib.auth.hashers.PBKDF2PasswordHasher',
|
|
'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher',
|
|
'django.contrib.auth.hashers.BCryptPasswordHasher',
|
|
'django.contrib.auth.hashers.SHA1PasswordHasher',
|
|
'django.contrib.auth.hashers.MD5PasswordHasher',
|
|
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
|
|
'django.contrib.auth.hashers.CryptPasswordHasher',)
|
|
|
|
|
|
.. _settings-comments:
|
|
|
|
Comments
|
|
========
|
|
|
|
Settings for :mod:`django.contrib.comments`.
|
|
|
|
.. setting:: COMMENTS_HIDE_REMOVED
|
|
|
|
COMMENTS_HIDE_REMOVED
|
|
---------------------
|
|
|
|
If ``True`` (default), removed comments will be excluded from comment
|
|
lists/counts (as taken from template tags). Otherwise, the template author is
|
|
responsible for some sort of a "this comment has been removed by the site staff"
|
|
message.
|
|
|
|
.. setting:: COMMENT_MAX_LENGTH
|
|
|
|
COMMENT_MAX_LENGTH
|
|
------------------
|
|
|
|
The maximum length of the comment field, in characters. Comments longer than
|
|
this will be rejected. Defaults to 3000.
|
|
|
|
.. setting:: COMMENTS_APP
|
|
|
|
COMMENTS_APP
|
|
------------
|
|
|
|
An app which provides :doc:`customization of the comments framework
|
|
</ref/contrib/comments/custom>`. Use the same dotted-string notation
|
|
as in :setting:`INSTALLED_APPS`. Your custom :setting:`COMMENTS_APP`
|
|
must also be listed in :setting:`INSTALLED_APPS`.
|
|
|
|
.. setting:: PROFANITIES_LIST
|
|
|
|
PROFANITIES_LIST
|
|
----------------
|
|
|
|
Default: ``()`` (Empty tuple)
|
|
|
|
A tuple of profanities, as strings, that will be forbidden in comments when
|
|
``COMMENTS_ALLOW_PROFANITIES`` is ``False``.
|
|
|
|
|
|
.. _settings-messages:
|
|
|
|
Messages
|
|
========
|
|
|
|
Settings for :mod:`django.contrib.messages`.
|
|
|
|
.. setting:: MESSAGE_LEVEL
|
|
|
|
MESSAGE_LEVEL
|
|
-------------
|
|
|
|
Default: ``messages.INFO``
|
|
|
|
Sets the minimum message level that will be recorded by the messages
|
|
framework. See :ref:`message levels <message-level>` for more details.
|
|
|
|
.. admonition:: Important
|
|
|
|
If you override ``MESSAGE_LEVEL`` in your settings file and rely on any of
|
|
the built-in constants, you must import the constants module directly to
|
|
avoid the potential for circular imports, e.g.::
|
|
|
|
from django.contrib.messages import constants as message_constants
|
|
MESSAGE_LEVEL = message_constants.DEBUG
|
|
|
|
If desired, you may specify the numeric values for the constants directly
|
|
according to the values in the above :ref:`constants table
|
|
<message-level-constants>`.
|
|
|
|
.. setting:: MESSAGE_STORAGE
|
|
|
|
MESSAGE_STORAGE
|
|
---------------
|
|
|
|
Default: ``'django.contrib.messages.storage.fallback.FallbackStorage'``
|
|
|
|
Controls where Django stores message data. Valid values are:
|
|
|
|
* ``'django.contrib.messages.storage.fallback.FallbackStorage'``
|
|
* ``'django.contrib.messages.storage.session.SessionStorage'``
|
|
* ``'django.contrib.messages.storage.cookie.CookieStorage'``
|
|
|
|
See :ref:`message storage backends <message-storage-backends>` for more details.
|
|
|
|
The backends that use cookies -- ``CookieStorage`` and ``FallbackStorage`` --
|
|
use the value of :setting:`SESSION_COOKIE_DOMAIN` when setting their cookies.
|
|
|
|
.. setting:: MESSAGE_TAGS
|
|
|
|
MESSAGE_TAGS
|
|
------------
|
|
|
|
Default::
|
|
|
|
{messages.DEBUG: 'debug',
|
|
messages.INFO: 'info',
|
|
messages.SUCCESS: 'success',
|
|
messages.WARNING: 'warning',
|
|
messages.ERROR: 'error',}
|
|
|
|
This sets the mapping of message level to message tag, which is typically
|
|
rendered as a CSS class in HTML. If you specify a value, it will extend
|
|
the default. This means you only have to specify those values which you need
|
|
to override. See :ref:`message-displaying` above for more details.
|
|
|
|
.. admonition:: Important
|
|
|
|
If you override ``MESSAGE_TAGS`` in your settings file and rely on any of
|
|
the built-in constants, you must import the ``constants`` module directly to
|
|
avoid the potential for circular imports, e.g.::
|
|
|
|
from django.contrib.messages import constants as message_constants
|
|
MESSAGE_TAGS = {message_constants.INFO: ''}
|
|
|
|
If desired, you may specify the numeric values for the constants directly
|
|
according to the values in the above :ref:`constants table
|
|
<message-level-constants>`.
|
|
|
|
.. _settings-sessions:
|
|
|
|
Sessions
|
|
========
|
|
|
|
Settings for :mod:`django.contrib.sessions`.
|
|
|
|
.. setting:: SESSION_CACHE_ALIAS
|
|
|
|
SESSION_CACHE_ALIAS
|
|
-------------------
|
|
|
|
Default: ``default``
|
|
|
|
If you're using :ref:`cache-based session storage <cached-sessions-backend>`,
|
|
this selects the cache to use.
|
|
|
|
.. setting:: SESSION_COOKIE_AGE
|
|
|
|
SESSION_COOKIE_AGE
|
|
------------------
|
|
|
|
Default: ``1209600`` (2 weeks, in seconds)
|
|
|
|
The age of session cookies, in seconds.
|
|
|
|
.. setting:: SESSION_COOKIE_DOMAIN
|
|
|
|
SESSION_COOKIE_DOMAIN
|
|
---------------------
|
|
|
|
Default: ``None``
|
|
|
|
The domain to use for session cookies. Set this to a string such as
|
|
``".example.com"`` (note the leading dot!) for cross-domain cookies, or use
|
|
``None`` for a standard domain cookie.
|
|
|
|
Be cautious when updating this setting on a production site. If you update
|
|
this setting to enable cross-domain cookies on a site that previously used
|
|
standard domain cookies, existing user cookies will be set to the old
|
|
domain. This may result in them being unable to log in as long as these cookies
|
|
persist.
|
|
|
|
.. setting:: SESSION_COOKIE_HTTPONLY
|
|
|
|
SESSION_COOKIE_HTTPONLY
|
|
-----------------------
|
|
|
|
Default: ``True``
|
|
|
|
Whether to use ``HTTPOnly`` flag on the session cookie. If this is set to
|
|
``True``, client-side JavaScript will not to be able to access the
|
|
session cookie.
|
|
|
|
HTTPOnly_ is a flag included in a Set-Cookie HTTP response header. It
|
|
is not part of the :rfc:`2109` standard for cookies, and it isn't honored
|
|
consistently by all browsers. However, when it is honored, it can be a
|
|
useful way to mitigate the risk of client side script accessing the
|
|
protected cookie data.
|
|
|
|
.. _HTTPOnly: https://www.owasp.org/index.php/HTTPOnly
|
|
|
|
.. setting:: SESSION_COOKIE_NAME
|
|
|
|
SESSION_COOKIE_NAME
|
|
-------------------
|
|
|
|
Default: ``'sessionid'``
|
|
|
|
The name of the cookie to use for sessions. This can be whatever you want (but
|
|
should be different from :setting:`LANGUAGE_COOKIE_NAME`).
|
|
|
|
.. setting:: SESSION_COOKIE_PATH
|
|
|
|
SESSION_COOKIE_PATH
|
|
-------------------
|
|
|
|
Default: ``'/'``
|
|
|
|
The path set on the session cookie. This should either match the URL path of your
|
|
Django installation or be parent of that path.
|
|
|
|
This is useful if you have multiple Django instances running under the same
|
|
hostname. They can use different cookie paths, and each instance will only see
|
|
its own session cookie.
|
|
|
|
.. setting:: SESSION_COOKIE_SECURE
|
|
|
|
SESSION_COOKIE_SECURE
|
|
---------------------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to use a secure cookie for the session cookie. If this is set to
|
|
``True``, the cookie will be marked as "secure," which means browsers may
|
|
ensure that the cookie is only sent under an HTTPS connection.
|
|
|
|
.. setting:: SESSION_ENGINE
|
|
|
|
SESSION_ENGINE
|
|
--------------
|
|
|
|
Default: ``django.contrib.sessions.backends.db``
|
|
|
|
Controls where Django stores session data. Valid values are:
|
|
|
|
* ``'django.contrib.sessions.backends.db'``
|
|
* ``'django.contrib.sessions.backends.file'``
|
|
* ``'django.contrib.sessions.backends.cache'``
|
|
* ``'django.contrib.sessions.backends.cached_db'``
|
|
* ``'django.contrib.sessions.backends.signed_cookies'``
|
|
|
|
See :ref:`configuring-sessions` for more details.
|
|
|
|
.. setting:: SESSION_EXPIRE_AT_BROWSER_CLOSE
|
|
|
|
SESSION_EXPIRE_AT_BROWSER_CLOSE
|
|
-------------------------------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to expire the session when the user closes his or her browser. See
|
|
:ref:`browser-length-vs-persistent-sessions`.
|
|
|
|
.. setting:: SESSION_FILE_PATH
|
|
|
|
SESSION_FILE_PATH
|
|
-----------------
|
|
|
|
Default: ``None``
|
|
|
|
If you're using file-based session storage, this sets the directory in
|
|
which Django will store session data. When the default value (``None``) is
|
|
used, Django will use the standard temporary directory for the system.
|
|
|
|
|
|
.. setting:: SESSION_SAVE_EVERY_REQUEST
|
|
|
|
SESSION_SAVE_EVERY_REQUEST
|
|
--------------------------
|
|
|
|
Default: ``False``
|
|
|
|
Whether to save the session data on every request. If this is ``False``
|
|
(default), then the session data will only be saved if it has been modified --
|
|
that is, if any of its dictionary values have been assigned or deleted.
|
|
|
|
|
|
Sites
|
|
=====
|
|
|
|
Settings for :mod:`django.contrib.sites`.
|
|
|
|
.. setting:: SITE_ID
|
|
|
|
SITE_ID
|
|
-------
|
|
|
|
Default: Not defined
|
|
|
|
The ID, as an integer, of the current site in the ``django_site`` database
|
|
table. This is used so that application data can hook into specific sites
|
|
and a single database can manage content for multiple sites.
|
|
|
|
|
|
.. _settings-staticfiles:
|
|
|
|
Static files
|
|
============
|
|
|
|
Settings for :mod:`django.contrib.staticfiles`.
|
|
|
|
.. setting:: STATIC_ROOT
|
|
|
|
STATIC_ROOT
|
|
-----------
|
|
|
|
Default: ``''`` (Empty string)
|
|
|
|
The absolute path to the directory where :djadmin:`collectstatic` will collect
|
|
static files for deployment.
|
|
|
|
Example: ``"/var/www/example.com/static/"``
|
|
|
|
If the :doc:`staticfiles</ref/contrib/staticfiles>` contrib app is enabled
|
|
(default) the :djadmin:`collectstatic` management command will collect static
|
|
files into this directory. See the howto on :doc:`managing static
|
|
files</howto/static-files/index>` for more details about usage.
|
|
|
|
.. warning::
|
|
|
|
This should be an (initially empty) destination directory for collecting
|
|
your static files from their permanent locations into one directory for
|
|
ease of deployment; it is **not** a place to store your static files
|
|
permanently. You should do that in directories that will be found by
|
|
:doc:`staticfiles</ref/contrib/staticfiles>`'s
|
|
:setting:`finders<STATICFILES_FINDERS>`, which by default, are
|
|
``'static/'`` app sub-directories and any directories you include in
|
|
:setting:`STATICFILES_DIRS`).
|
|
|
|
.. setting:: STATIC_URL
|
|
|
|
STATIC_URL
|
|
----------
|
|
|
|
Default: ``None``
|
|
|
|
URL to use when referring to static files located in :setting:`STATIC_ROOT`.
|
|
|
|
Example: ``"/static/"`` or ``"http://static.example.com/"``
|
|
|
|
If not ``None``, this will be used as the base path for
|
|
:ref:`media definitions<form-media-paths>` and the
|
|
:doc:`staticfiles app</ref/contrib/staticfiles>`.
|
|
|
|
It must end in a slash if set to a non-empty value.
|
|
|
|
.. setting:: STATICFILES_DIRS
|
|
|
|
STATICFILES_DIRS
|
|
----------------
|
|
|
|
Default: ``[]``
|
|
|
|
This setting defines the additional locations the staticfiles app will traverse
|
|
if the ``FileSystemFinder`` finder is enabled, e.g. if you use the
|
|
:djadmin:`collectstatic` or :djadmin:`findstatic` management command or use the
|
|
static file serving view.
|
|
|
|
This should be set to a list or tuple of strings that contain full paths to
|
|
your additional files directory(ies) e.g.::
|
|
|
|
STATICFILES_DIRS = (
|
|
"/home/special.polls.com/polls/static",
|
|
"/home/polls.com/polls/static",
|
|
"/opt/webfiles/common",
|
|
)
|
|
|
|
Prefixes (optional)
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
In case you want to refer to files in one of the locations with an additional
|
|
namespace, you can **optionally** provide a prefix as ``(prefix, path)``
|
|
tuples, e.g.::
|
|
|
|
STATICFILES_DIRS = (
|
|
# ...
|
|
("downloads", "/opt/webfiles/stats"),
|
|
)
|
|
|
|
Example:
|
|
|
|
Assuming you have :setting:`STATIC_URL` set ``'/static/'``, the
|
|
:djadmin:`collectstatic` management command would collect the "stats" files
|
|
in a ``'downloads'`` subdirectory of :setting:`STATIC_ROOT`.
|
|
|
|
This would allow you to refer to the local file
|
|
``'/opt/webfiles/stats/polls_20101022.tar.gz'`` with
|
|
``'/static/downloads/polls_20101022.tar.gz'`` in your templates, e.g.:
|
|
|
|
.. code-block:: html+django
|
|
|
|
<a href="{{ STATIC_URL }}downloads/polls_20101022.tar.gz">
|
|
|
|
.. setting:: STATICFILES_STORAGE
|
|
|
|
STATICFILES_STORAGE
|
|
-------------------
|
|
|
|
Default: ``'django.contrib.staticfiles.storage.StaticFilesStorage'``
|
|
|
|
The file storage engine to use when collecting static files with the
|
|
:djadmin:`collectstatic` management command.
|
|
|
|
A ready-to-use instance of the storage backend defined in this setting
|
|
can be found at ``django.contrib.staticfiles.storage.staticfiles_storage``.
|
|
|
|
For an example, see :ref:`staticfiles-from-cdn`.
|
|
|
|
.. setting:: STATICFILES_FINDERS
|
|
|
|
STATICFILES_FINDERS
|
|
-------------------
|
|
|
|
Default::
|
|
|
|
("django.contrib.staticfiles.finders.FileSystemFinder",
|
|
"django.contrib.staticfiles.finders.AppDirectoriesFinder")
|
|
|
|
The list of finder backends that know how to find static files in
|
|
various locations.
|
|
|
|
The default will find files stored in the :setting:`STATICFILES_DIRS` setting
|
|
(using ``django.contrib.staticfiles.finders.FileSystemFinder``) and in a
|
|
``static`` subdirectory of each app (using
|
|
``django.contrib.staticfiles.finders.AppDirectoriesFinder``). If multiple
|
|
files with the same name are present, the first file that is found will be
|
|
used.
|
|
|
|
One finder is disabled by default:
|
|
``django.contrib.staticfiles.finders.DefaultStorageFinder``. If added to
|
|
your :setting:`STATICFILES_FINDERS` setting, it will look for static files in
|
|
the default file storage as defined by the :setting:`DEFAULT_FILE_STORAGE`
|
|
setting.
|
|
|
|
.. note::
|
|
|
|
When using the ``AppDirectoriesFinder`` finder, make sure your apps
|
|
can be found by staticfiles. Simply add the app to the
|
|
:setting:`INSTALLED_APPS` setting of your site.
|
|
|
|
Static file finders are currently considered a private interface, and this
|
|
interface is thus undocumented.
|
|
|
|
Core Settings Topical Index
|
|
===========================
|
|
|
|
Cache
|
|
-----
|
|
* :setting:`CACHES`
|
|
* :setting:`CACHE_MIDDLEWARE_ALIAS`
|
|
* :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY`
|
|
* :setting:`CACHE_MIDDLEWARE_KEY_PREFIX`
|
|
* :setting:`CACHE_MIDDLEWARE_SECONDS`
|
|
|
|
Database
|
|
--------
|
|
* :setting:`DATABASES`
|
|
* :setting:`DATABASE_ROUTERS`
|
|
* :setting:`DEFAULT_INDEX_TABLESPACE`
|
|
* :setting:`DEFAULT_TABLESPACE`
|
|
* :setting:`TRANSACTIONS_MANAGED`
|
|
|
|
Debugging
|
|
---------
|
|
* :setting:`DEBUG`
|
|
* :setting:`DEBUG_PROPAGATE_EXCEPTIONS`
|
|
|
|
Email
|
|
-----
|
|
* :setting:`ADMINS`
|
|
* :setting:`DEFAULT_CHARSET`
|
|
* :setting:`DEFAULT_FROM_EMAIL`
|
|
* :setting:`EMAIL_BACKEND`
|
|
* :setting:`EMAIL_FILE_PATH`
|
|
* :setting:`EMAIL_HOST`
|
|
* :setting:`EMAIL_HOST_PASSWORD`
|
|
* :setting:`EMAIL_HOST_USER`
|
|
* :setting:`EMAIL_PORT`
|
|
* :setting:`EMAIL_SUBJECT_PREFIX`
|
|
* :setting:`EMAIL_USE_TLS`
|
|
* :setting:`MANAGERS`
|
|
* :setting:`SEND_BROKEN_LINK_EMAILS`
|
|
* :setting:`SERVER_EMAIL`
|
|
|
|
Error reporting
|
|
---------------
|
|
* :setting:`DEFAULT_EXCEPTION_REPORTER_FILTER`
|
|
* :setting:`IGNORABLE_404_URLS`
|
|
* :setting:`MANAGERS`
|
|
* :setting:`SEND_BROKEN_LINK_EMAILS`
|
|
|
|
File uploads
|
|
------------
|
|
* :setting:`DEFAULT_FILE_STORAGE`
|
|
* :setting:`FILE_CHARSET`
|
|
* :setting:`FILE_UPLOAD_HANDLERS`
|
|
* :setting:`FILE_UPLOAD_MAX_MEMORY_SIZE`
|
|
* :setting:`FILE_UPLOAD_PERMISSIONS`
|
|
* :setting:`FILE_UPLOAD_TEMP_DIR`
|
|
* :setting:`MEDIA_ROOT`
|
|
* :setting:`MEDIA_URL`
|
|
|
|
Globalization (i18n/l10n)
|
|
-------------------------
|
|
* :setting:`DATE_FORMAT`
|
|
* :setting:`DATE_INPUT_FORMATS`
|
|
* :setting:`DATETIME_FORMAT`
|
|
* :setting:`DATETIME_INPUT_FORMATS`
|
|
* :setting:`DECIMAL_SEPARATOR`
|
|
* :setting:`FIRST_DAY_OF_WEEK`
|
|
* :setting:`FORMAT_MODULE_PATH`
|
|
* :setting:`LANGUAGE_CODE`
|
|
* :setting:`LANGUAGE_COOKIE_NAME`
|
|
* :setting:`LANGUAGES`
|
|
* :setting:`LOCALE_PATHS`
|
|
* :setting:`MONTH_DAY_FORMAT`
|
|
* :setting:`NUMBER_GROUPING`
|
|
* :setting:`SHORT_DATE_FORMAT`
|
|
* :setting:`SHORT_DATETIME_FORMAT`
|
|
* :setting:`THOUSAND_SEPARATOR`
|
|
* :setting:`TIME_FORMAT`
|
|
* :setting:`TIME_INPUT_FORMATS`
|
|
* :setting:`TIME_ZONE`
|
|
* :setting:`USE_I18N`
|
|
* :setting:`USE_L10N`
|
|
* :setting:`USE_THOUSAND_SEPARATOR`
|
|
* :setting:`USE_TZ`
|
|
* :setting:`YEAR_MONTH_FORMAT`
|
|
|
|
HTTP
|
|
----
|
|
* :setting:`DEFAULT_CHARSET`
|
|
* :setting:`DEFAULT_CONTENT_TYPE`
|
|
* :setting:`DISALLOWED_USER_AGENTS`
|
|
* :setting:`FORCE_SCRIPT_NAME`
|
|
* :setting:`INTERNAL_IPS`
|
|
* :setting:`MIDDLEWARE_CLASSES`
|
|
* :setting:`SECURE_PROXY_SSL_HEADER`
|
|
* :setting:`SIGNING_BACKEND`
|
|
* :setting:`USE_ETAGS`
|
|
* :setting:`USE_X_FORWARDED_HOST`
|
|
* :setting:`WSGI_APPLICATION`
|
|
|
|
Logging
|
|
-------
|
|
* :setting:`LOGGING`
|
|
* :setting:`LOGGING_CONFIG`
|
|
|
|
Models
|
|
------
|
|
* :setting:`ABSOLUTE_URL_OVERRIDES`
|
|
* :setting:`FIXTURE_DIRS`
|
|
* :setting:`INSTALLED_APPS`
|
|
|
|
Security
|
|
--------
|
|
* Cross Site Request Forgery protection
|
|
|
|
* :setting:`CSRF_COOKIE_DOMAIN`
|
|
* :setting:`CSRF_COOKIE_NAME`
|
|
* :setting:`CSRF_COOKIE_PATH`
|
|
* :setting:`CSRF_COOKIE_SECURE`
|
|
* :setting:`CSRF_FAILURE_VIEW`
|
|
|
|
* :setting:`SECRET_KEY`
|
|
* :setting:`X_FRAME_OPTIONS`
|
|
|
|
Serialization
|
|
-------------
|
|
* :setting:`DEFAULT_CHARSET`
|
|
* :setting:`SERIALIZATION_MODULES`
|
|
|
|
Templates
|
|
---------
|
|
* :setting:`ALLOWED_INCLUDE_ROOTS`
|
|
* :setting:`TEMPLATE_CONTEXT_PROCESSORS`
|
|
* :setting:`TEMPLATE_DEBUG`
|
|
* :setting:`TEMPLATE_DIRS`
|
|
* :setting:`TEMPLATE_LOADERS`
|
|
* :setting:`TEMPLATE_STRING_IF_INVALID`
|
|
|
|
Testing
|
|
-------
|
|
* Database
|
|
|
|
* :setting:`TEST_CHARSET`
|
|
* :setting:`TEST_COLLATION`
|
|
* :setting:`TEST_DEPENDENCIES`
|
|
* :setting:`TEST_MIRROR`
|
|
* :setting:`TEST_NAME`
|
|
* :setting:`TEST_CREATE`
|
|
* :setting:`TEST_USER`
|
|
* :setting:`TEST_USER_CREATE`
|
|
* :setting:`TEST_PASSWD`
|
|
* :setting:`TEST_TBLSPACE`
|
|
* :setting:`TEST_TBLSPACE_TMP`
|
|
|
|
* :setting:`TEST_RUNNER`
|
|
|
|
URLs
|
|
----
|
|
* :setting:`APPEND_SLASH`
|
|
* :setting:`PREPEND_WWW`
|
|
* :setting:`ROOT_URLCONF`
|