======== 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. 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:: 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 webserver 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`). 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:: 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 ` 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:: 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 ` 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 ` 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 ` 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 ` 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 ` 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 ------------------ 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 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 ` section. .. 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 ---------------- .. 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 ----------------- 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-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:: 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 ` 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 ~~~~~~~~~~~~~~~~~ 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 ` 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 ` 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 `. .. 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 `. 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 `. 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'`` .. versionchanged:: 1.4 We changed ``'PASSWORD'`` ``'PASS'``. ``'API'``, ``'TOKEN'`` and ``'KEY'`` were added. 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 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`. .. 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 ------------------ .. 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`). Regular expressions are matched against :meth:`request's full paths ` (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 :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 `. .. 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`. 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: 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 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 ``/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`. 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 -------------- 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. .. versionchanged:: 1.5 This setting now also accepts view function names and :ref:`named 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 ` 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:: MANAGERS MANAGERS -------- Default: ``()`` (Empty tuple) A tuple in the same format as :setting:`ADMINS` that specifies who should get broken-link notifications when :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``. .. setting:: MEDIA_ROOT MEDIA_ROOT ---------- Default: ``''`` (Empty string) Absolute filesystem path to the directory that will hold :doc:`user-uploaded 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 `. It must end in a slash if set to a non-empty value. Example: ``"http://media.example.com/"`` MESSAGE_LEVEL ------------- Default: ``messages.INFO`` Sets the minimum message level that will be recorded by the messages framework. See the :doc:`messages documentation ` for more details. MESSAGE_STORAGE --------------- Default: ``'django.contrib.messages.storage.fallback.FallbackStorage'`` Controls where Django stores message data. See the :doc:`messages documentation ` for more details. MESSAGE_TAGS ------------ 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 ` 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`. .. 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 `. 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:: PASSWORD_HASHERS PASSWORD_HASHERS ---------------- .. versionadded:: 1.4 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',) .. 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 be forbidden in comments when ``COMMENTS_ALLOW_PROFANITIES`` is ``False``. .. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS RESTRUCTUREDTEXT_FILTER_SETTINGS -------------------------------- Default: ``{}`` A dictionary containing settings for the ``restructuredtext`` markup filter from the :doc:`django.contrib.markup application `. 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 a particular Django installation. This is used to provide :doc:`cryptographic signing `, and should be set to a unique, unpredictable value. :djadmin:`django-admin.py 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 ----------------------- .. versionadded:: 1.4 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 ----------------------- 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 ``".example.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: ``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 .. versionchanged:: 1.4 The default value of the setting was changed from ``False`` to ``True``. .. 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_CACHE_ALIAS SESSION_CACHE_ALIAS ------------------- Default: ``default`` If you're using :ref:`cache-based session storage `, this selects the cache to use. .. 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'`` * ``'django.contrib.sessions.backends.signed_cookies'`` 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 ----------------- 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 `. 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 `. See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_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: ``"/var/www/example.com/static/"`` If the :doc:`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` 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`'s :setting:`finders`, which by default, are ``'static/'`` app sub-directories and any directories you include in :setting:`STATICFILES_DIRS`). See :doc:`staticfiles reference` 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: ``"/static/"`` or ``"http://static.example.com/"`` If not ``None``, this will be used as the base path for :ref:`media definitions` and the :doc:`staticfiles app`. 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.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. .. versionadded:: 1.4 The ``django.core.context_processors.tz`` 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 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.simple.DjangoTestSuiteRunner'`` The name of the class to use for starting the test suite. See :ref:`other-testing-frameworks`. .. 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 `. 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', # '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`. .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior .. setting:: TIME_ZONE TIME_ZONE --------- Default: ``'America/Chicago'`` .. versionchanged:: 1.4 The meaning of this setting now depends on the value of :setting:`USE_TZ`. 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 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 `, 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 `, 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. .. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE .. _pytz: http://pytz.sourceforge.net/ .. setting:: TRANSACTIONS_MANAGED TRANSACTIONS_MANAGED -------------------- Default: ``False`` Set this to ``True`` if you want to :ref:`disable Django's 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 ` 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 ------ .. versionadded:: 1.4 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 ` 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 ---------------- .. versionadded:: 1.4 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 ` 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 `. 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 ` documentation. Deprecated settings =================== .. setting:: AUTH_PROFILE_MODULE AUTH_PROFILE_MODULE ------------------- .. deprecated:: 1.5 With the introduction of :ref:`custom User models `, the use of :setting:`AUTH_PROFILE_MODULE` to define a single profile model is no longer supported. See the :doc:`Django 1.5 release notes` for more information. Default: Not defined The site-specific user profile model used by this site. See :ref:`User profiles `. .. 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`.