django/docs/ref/settings.txt

========
Settings
========

.. contents::
    :local:
    :depth: 1

Available settings
==================

Here's a full list of all available settings, in alphabetical order, and their
default values.

.. 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:: 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.

.. setting:: ADMIN_MEDIA_PREFIX

ADMIN_MEDIA_PREFIX
------------------

Default: ``'/static/admin/'``

The URL prefix for admin media -- CSS, JavaScript and images used by the Django
administrative interface. Make sure to use a trailing slash, and to have this be
different from the :setting:`MEDIA_URL` setting (since the same URL cannot be
mapped onto two different sets of files). For integration with :doc:`staticfiles
</ref/contrib/staticfiles>`, this should be the same as
:setting:`STATIC_URL` followed by ``'admin/'``.

.. 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_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:: 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 :doc:`authentication backends documentation
</ref/authbackends>` for details.

.. setting:: AUTH_PROFILE_MODULE

AUTH_PROFILE_MODULE
-------------------

Default: Not defined

The site-specific user profile model used by this site. See
:ref:`auth-profiles`.

.. setting:: CACHES

CACHES
------

.. versionadded:: 1.3

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 <CACHE-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.

.. note::
    Prior to Django 1.3, you could use a URI based version of the backend
    name to reference the built-in cache backends (e.g., you could use
    ``'db://tablename'`` to refer to the database backend). This format has
    been deprecated, and will be removed in Django 1.5.

.. 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), smart_str(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``

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``.

See :doc:`/topics/cache`.

.. 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`.

.. setting:: CSRF_COOKIE_DOMAIN

CSRF_COOKIE_DOMAIN
------------------

.. versionadded:: 1.2

Default: ``None``

The domain to be used when setting the CSRF cookie.  This can be useful for
easily allowing cross-subdomain requests to be exluded from the normal cross
site request forgery protection.  It should be set to a string such as
``".lawrence.com"`` to allow a POST request from a form on one subdomain to be
accepted by 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_NAME

CSRF_COOKIE_NAME
----------------

.. versionadded:: 1.2

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
----------------

.. versionadded:: 1.4

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
------------------

.. versionadded:: 1.4

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
-----------------

.. versionadded:: 1.2

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
---------

.. versionadded:: 1.2

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-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.

.. note::
    Prior to Django 1.2, you could use a short version of the backend name
    to reference the built-in database backends (e.g., you could use
    ``'sqlite3'`` to refer to the SQLite backend). This format has been
    deprecated, and will be removed in Django 1.4.

.. 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, an empty string means to use a Unix domain socket
for the connection, rather than a network connection to localhost. If you
explicitly need to use a TCP/IP connection on the local machine with
PostgreSQL, specify ``localhost`` here.

.. 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:: 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/8.2/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
~~~~~~~~~~~~~~~~~

.. versionadded:: 1.3

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 :doc:`/topics/testing`.

.. 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.

.. setting:: DATABASE_ROUTERS

DATABASE_ROUTERS
----------------

.. versionadded:: 1.2

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>`.

.. versionchanged:: 1.2
    This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.

See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`.

.. setting:: DATE_INPUT_FORMATS

DATE_INPUT_FORMATS
------------------

.. versionadded:: 1.2

Default::

    ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y',
    '%b %d, %Y', '%d %b %Y', '%d %b, %Y', '%B %d %Y',
    '%B %d, %Y', '%d %B %Y', '%d %B, %Y')

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.
Note that these format strings are specified in Python's datetime_ module
syntax, that is different from the one used by Django for formatting dates
to be displayed.

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>`.

.. versionchanged:: 1.2
    This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.

See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`.

.. setting:: DATETIME_INPUT_FORMATS

DATETIME_INPUT_FORMATS
----------------------

.. versionadded:: 1.2

Default::

    ('%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M', '%Y-%m-%d',
    '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M', '%m/%d/%Y',
    '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y')

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.
Note that these format strings are specified in Python's datetime_ module
syntax, that is different from the one used by Django for formatting dates
to be displayed.

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.

If you define custom settings, `django/views/debug.py`_ has a ``HIDDEN_SETTINGS``
regular expression which will hide from the DEBUG view anything that contains
``'SECRET'``, ``'PASSWORD'``, ``'PROFANITIES'``, or ``'SIGNATURE'``. This allows
untrusted users to be able to give backtraces without seeing sensitive (or
offensive) settings.

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 are debugging, but on a production server, it will rapidly consume
memory.

Never deploy a site into production with :setting:`DEBUG` turned on.

.. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py

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
-----------------

.. versionadded:: 1.2

Default: ``'.'`` (Dot)

Default decimal separator used when formatting decimal numbers.

.. 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:`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.

.. setting:: DEFAULT_TABLESPACE

DEFAULT_TABLESPACE
------------------

Default: ``''`` (Empty string)

Default tablespace to use for models that don't specify one, if the
backend supports it.

.. 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
-------------

.. versionadded:: 1.2

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
---------------

.. versionadded:: 1.2

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
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.


.. _documentation for os.chmod: http://docs.python.org/library/os.html#os.chmod

.. 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
-----------------

.. versionadded:: 1.2

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 locations of the fixture data files, in search order. Note that
these paths should use Unix-style forward slashes, even on Windows. See
:doc:`/topics/testing`.

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
------------------

.. versionadded:: 1.2

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
------------------

.. versionadded:: 1.4

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`). 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 :setting:`SEND_BROKEN_LINK_EMAILS` is set to ``True`` and
``CommonMiddleware`` is installed (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 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 :doc:`/topics/i18n/index`.

.. 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: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py

The list is a tuple of two-tuples in the format ``(language code, language
name)``, the ``language code`` part should be a
:term:`language name<language code>` -- 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:`using-translations-in-your-own-projects`.

Example::

    LOCALE_PATHS = (
        '/home/www/project/common_files/locale',
        '/var/local/translations/locale'
    )

Note that in the paths you add to the value of this setting, if you have the
typical ``/path/to/locale/xx/LC_MESSAGES`` hierarchy, you should use the path to
the ``locale`` directory (i.e. ``'/path/to/locale'``).

.. setting:: LOGGING

LOGGING
-------

.. versionadded:: 1.3

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`.

The default logging configuration passes HTTP 500 server errors to an
email log handler; all other log messages are given to a NullHandler.

.. setting:: LOGGING_CONFIG

LOGGING_CONFIG
--------------

.. versionadded:: 1.3

Default: ``'django.utils.log.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.

.. _dictConfig: http://docs.python.org/library/logging.config.html#configuration-dictionary-schema

.. 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.

.. 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.

.. setting:: LOGOUT_URL

LOGOUT_URL
----------

Default: ``'/accounts/logout/'``

LOGIN_URL counterpart.

.. setting:: MANAGERS

MANAGERS
--------

Default: ``()`` (Empty tuple)

A tuple in the same format as :setting:`ADMINS` that specifies who should get
broken-link notifications when ``SEND_BROKEN_LINK_EMAILS=True``.

.. setting:: MEDIA_ROOT

MEDIA_ROOT
----------

Default: ``''`` (Empty string)

Absolute path to the directory that holds media for this installation, used
for :doc:`managing stored files </topics/files>`.

Example: ``"/home/media/media.lawrence.com/"``

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>`.

Example: ``"http://media.lawrence.com/"``

.. versionchanged:: 1.3
   It must end in a slash if set to a non-empty value.

MESSAGE_LEVEL
-------------

.. versionadded:: 1.2

Default: `messages.INFO`

Sets the minimum message level that will be recorded by the messages
framework. See the :doc:`messages documentation </ref/contrib/messages>` for
more details.

MESSAGE_STORAGE
---------------

.. versionadded:: 1.2

Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'``

Controls where Django stores message data.  See the
:doc:`messages documentation </ref/contrib/messages>` for more details.

MESSAGE_TAGS
------------

.. versionadded:: 1.2

Default::

        {messages.DEBUG: 'debug',
        messages.INFO: 'info',
        messages.SUCCESS: 'success',
        messages.WARNING: 'warning',
        messages.ERROR: 'error',}

Sets the mapping of message levels to message tags. See the
:doc:`messages documentation </ref/contrib/messages>` for more details.

.. 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`.

.. versionchanged:: 1.2
   ``'django.contrib.messages.middleware.MessageMiddleware'`` was added to the
   default.  For more information, see the :doc:`messages documentation
   </ref/contrib/messages>`.

.. 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
----------------

.. versionadded:: 1.2

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 the
setting :setting:`THOUSAND_SEPARATOR` will be used as the separator between those
groups.

See also :setting:`THOUSAND_SEPARATOR` and :setting:`USE_THOUSAND_SEPARATOR`.

.. 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:: 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:: PROFANITIES_LIST

PROFANITIES_LIST
----------------

Default: ``()`` (Empty tuple)

A tuple of profanities, as strings, that will trigger a validation error when
the ``hasNoProfanities`` validator is called.

.. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS

RESTRUCTUREDTEXT_FILTER_SETTINGS
--------------------------------

Default: ``{}``

A dictionary containing settings for the ``restructuredtext`` markup filter from
the :doc:`django.contrib.markup application </ref/contrib/markup>`. They override
the default writer settings. See the Docutils restructuredtext `writer settings
docs`_ for details.

.. _writer settings docs: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer

.. 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 this particular Django installation. Used to provide a seed in
secret-key hashing algorithms. Set this to a random string -- the longer, the
better. ``django-admin.py startproject`` creates one automatically.

.. setting:: SEND_BROKEN_LINK_EMAILS

SEND_BROKEN_LINK_EMAILS
-----------------------

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:: SESSION_COOKIE_AGE

SESSION_COOKIE_AGE
------------------

Default: ``1209600`` (2 weeks, in seconds)

The age of session cookies, in seconds. See :doc:`/topics/http/sessions`.

.. setting:: SESSION_COOKIE_DOMAIN

SESSION_COOKIE_DOMAIN
---------------------

Default: ``None``

The domain to use for session cookies. Set this to a string such as
``".lawrence.com"`` for cross-domain cookies, or use ``None`` for a standard
domain cookie. See the :doc:`/topics/http/sessions`.

.. setting:: SESSION_COOKIE_HTTPONLY

SESSION_COOKIE_HTTPONLY
-----------------------

Default: ``False``

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 RFC2109 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: http://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`).
See the :doc:`/topics/http/sessions`.

.. 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.
See the :doc:`/topics/http/sessions`.

.. 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'``

See :doc:`/topics/http/sessions`.

.. 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 the :doc:`/topics/http/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. See :doc:`/topics/http/sessions`. 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. See
:doc:`/topics/http/sessions`.

.. setting:: SHORT_DATE_FORMAT

SHORT_DATE_FORMAT
-----------------

.. versionadded:: 1.2

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
---------------------

.. versionadded:: 1.2

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_DATETIME_FORMAT`.

.. setting:: SIGNING_BACKEND

SIGNING_BACKEND
---------------

.. versionadded:: 1.4

Default: 'django.core.signing.TimestampSigner'

The backend used for signing cookies and other data.

See also the :doc:`/topics/signing` documentation.

.. 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 site(s)
and a single database can manage content for multiple sites.

See :doc:`/ref/contrib/sites`.

.. _site framework docs: ../sites/

.. setting:: STATIC_ROOT

STATIC_ROOT
-----------

Default: ``''`` (Empty string)

The absolute path to the directory where :djadmin:`collectstatic` will collect
static files for deployment.

Example: ``"/home/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>` 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`).

See :doc:`staticfiles reference</ref/contrib/staticfiles>` and
:setting:`STATIC_URL`.

.. setting:: STATIC_URL

STATIC_URL
----------

Default: ``None``

URL to use when referring to static files located in :setting:`STATIC_ROOT`.

Example: ``"/site_media/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.

See :setting:`STATIC_ROOT`.

.. 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.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.

.. versionchanged:: 1.2
   ``django.contrib.messages.context_processors.messages`` was added to the
   default.  For more information, see the :doc:`messages documentation
   </ref/contrib/messages>`.

.. versionchanged:: 1.2
    The auth context processor was moved in this release from its old location
    ``django.core.context_processors.auth`` to
    ``django.contrib.auth.context_processors.auth``.

.. versionadded:: 1.3
    The ``django.core.context_processors.static`` context processor
    was added in this release.

.. 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 ``TemplateSyntaxError``. 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, 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`.

.. versionchanged:: 1.2
    The class-based API for template loaders was introduced in Django 1.2
    although  the :setting:`TEMPLATE_LOADERS` setting will accept strings
    that specify function-based loaders until compatibility with them is
    completely removed in Django 1.4.

.. 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.simple.DjangoTestSuiteRunner'``

.. versionchanged:: 1.2
   Prior to 1.2, test runners were a function, not a class.

The name of the class to use for starting the test suite. See
:doc:`/topics/testing`.

.. _Testing Django Applications: ../testing/

.. setting:: THOUSAND_SEPARATOR

THOUSAND_SEPARATOR
------------------

.. versionadded:: 1.2

Default: ``,`` (Comma)

Default thousand separator used when formatting numbers. This setting is
used only when :setting:`NUMBER_GROUPING` and :setting:`USE_THOUSAND_SEPARATOR`
are set.

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>`.

.. versionchanged:: 1.2
    This setting can now be overriden by setting :setting:`USE_L10N` to ``True``.

See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`.

.. setting:: TIME_INPUT_FORMATS

TIME_INPUT_FORMATS
------------------

.. versionadded:: 1.2

Default: ``('%H:%M:%S', '%H:%M')``

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.
Note that these format strings are specified in Python's datetime_ module
syntax, that is different from the one used by Django for formatting dates
to be displayed.

See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`.

.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior

.. setting:: TIME_ZONE

TIME_ZONE
---------

Default: ``'America/Chicago'``

.. versionchanged:: 1.2
   ``None`` was added as an allowed value.

A string representing the time zone for this installation, or
``None``. `See available choices`_. (Note that list of available
choices lists more than one on the same line; you'll want to use just
one of the choices for a given time zone. For instance, one line says
``'Europe/London GB GB-Eire'``, but you should use the first bit of
that -- ``'Europe/London'`` -- as your :setting:`TIME_ZONE` setting.)

Note that this is the time zone to which Django will convert all
dates/times -- not necessarily the timezone of the server. For
example, one server may serve multiple Django-powered sites, each with
a separate time-zone setting.

Normally, 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 the correct 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.

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, this variable
    must be set to match the system timezone.


.. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE

.. setting:: URL_VALIDATOR_USER_AGENT

URL_VALIDATOR_USER_AGENT
------------------------

Default: ``Django/<version> (http://www.djangoproject.com/)``

The string to use as the ``User-Agent`` header when checking to see if URLs
exist (see the ``verify_exists`` option on :class:`~django.db.models.URLField`).

.. 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 internationalization 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
internationalization machinery.

See also :setting:`USE_L10N`

.. setting:: USE_L10N

USE_L10N
--------

.. versionadded:: 1.2

Default: ``False``

A boolean that specifies if data will be localized 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:`USE_I18N` and :setting:`LANGUAGE_CODE`

.. setting:: USE_THOUSAND_SEPARATOR

USE_THOUSAND_SEPARATOR
----------------------

.. versionadded:: 1.2

Default: ``False``

A boolean that specifies wheter to display numbers using a thousand separator.
If this is set to ``True``, Django will use values from
:setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING` from current
locale, to format the number. :setting:`USE_L10N` must be set to ``True``,
in order to format numbers.

See also :setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING`.

.. 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.

Deprecated settings
===================

.. setting:: CACHE_BACKEND

CACHE_BACKEND
-------------

.. deprecated:: 1.3
   This setting has been replaced by :setting:`BACKEND <CACHES-BACKEND>` in
   :setting:`CACHES`.

.. setting:: DATABASE_ENGINE

DATABASE_ENGINE
---------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`ENGINE` in
   :setting:`DATABASES`.

.. setting:: DATABASE_HOST

DATABASE_HOST
-------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`HOST` in
   :setting:`DATABASES`.

.. setting:: DATABASE_NAME

DATABASE_NAME
-------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`NAME` in
   :setting:`DATABASES`.

.. setting:: DATABASE_OPTIONS

DATABASE_OPTIONS
----------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`OPTIONS` in
   :setting:`DATABASES`.

.. setting:: DATABASE_PASSWORD

DATABASE_PASSWORD
-----------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`PASSWORD` in
   :setting:`DATABASES`.

.. setting:: DATABASE_PORT

DATABASE_PORT
-------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`PORT` in
   :setting:`DATABASES`.

.. setting:: DATABASE_USER

DATABASE_USER
-------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`USER` in
   :setting:`DATABASES`.

.. setting:: IGNORABLE_404_ENDS

IGNORABLE_404_ENDS
------------------

.. deprecated:: 1.4
   This setting has been superseded by :setting:`IGNORABLE_404_URLS`.

.. setting:: IGNORABLE_404_STARTS

IGNORABLE_404_STARTS
--------------------

.. deprecated:: 1.4
   This setting has been superseded by :setting:`IGNORABLE_404_URLS`.

.. setting:: TEST_DATABASE_CHARSET

TEST_DATABASE_CHARSET
---------------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`TEST_CHARSET` in
   :setting:`DATABASES`.

.. setting:: TEST_DATABASE_COLLATION

TEST_DATABASE_COLLATION
-----------------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`TEST_COLLATION` in
   :setting:`DATABASES`.

.. setting:: TEST_DATABASE_NAME

TEST_DATABASE_NAME
------------------

.. deprecated:: 1.2
   This setting has been replaced by :setting:`TEST_NAME` in
   :setting:`DATABASES`.