| ======== |
| 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 |
| <authentication-backends>` for details. |
| |
| .. setting:: AUTH_USER_MODEL |
| |
| AUTH_USER_MODEL |
| --------------- |
| |
| Default: 'auth.User' |
| |
| The model to use to represent a User. See :ref:`auth-custom-user`. |
| |
| .. setting:: CACHES |
| |
| CACHES |
| ------ |
| |
| Default:: |
| |
| { |
| 'default': { |
| 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache', |
| } |
| } |
| |
| A dictionary containing the settings for all caches to be used with |
| Django. It is a nested dictionary whose contents maps cache aliases |
| to a dictionary containing the options for an individual cache. |
| |
| The :setting:`CACHES` setting must configure a ``default`` cache; |
| any number of additional caches may also be specified. If you |
| are using a cache backend other than the local memory cache, or |
| you need to define multiple caches, other options will be required. |
| The following cache options are available. |
| |
| .. setting:: CACHES-BACKEND |
| |
| BACKEND |
| ~~~~~~~ |
| |
| Default: ``''`` (Empty string) |
| |
| The cache backend to use. The built-in cache backends are: |
| |
| * ``'django.core.cache.backends.db.DatabaseCache'`` |
| * ``'django.core.cache.backends.dummy.DummyCache'`` |
| * ``'django.core.cache.backends.filebased.FileBasedCache'`` |
| * ``'django.core.cache.backends.locmem.LocMemCache'`` |
| * ``'django.core.cache.backends.memcached.MemcachedCache'`` |
| * ``'django.core.cache.backends.memcached.PyLibMCCache'`` |
| |
| You can use a cache backend that doesn't ship with Django by setting |
| :setting:`BACKEND <CACHES-BACKEND>` to a fully-qualified path of a cache |
| backend class (i.e. ``mypackage.backends.whatever.WhateverCache``). |
| Writing a whole new cache backend from scratch is left as an exercise |
| to the reader; see the other backends for examples. |
| |
| .. setting:: CACHES-KEY_FUNCTION |
| |
| KEY_FUNCTION |
| ~~~~~~~~~~~~ |
| |
| A string containing a dotted path to a function that defines how to |
| compose a prefix, version and key into a final cache key. The default |
| implementation is equivalent to the function:: |
| |
| def make_key(key, key_prefix, version): |
| return ':'.join([key_prefix, str(version), key]) |
| |
| You may use any key function you want, as long as it has the same |
| argument signature. |
| |
| See the :ref:`cache documentation <cache_key_transformation>` for more information. |
| |
| .. setting:: CACHES-KEY_PREFIX |
| |
| KEY_PREFIX |
| ~~~~~~~~~~ |
| |
| Default: ``''`` (Empty string) |
| |
| A string that will be automatically included (prepended by default) to |
| all cache keys used by the Django server. |
| |
| See the :ref:`cache documentation <cache_key_prefixing>` for more information. |
| |
| .. setting:: CACHES-LOCATION |
| |
| LOCATION |
| ~~~~~~~~ |
| |
| Default: ``''`` (Empty string) |
| |
| The location of the cache to use. This might be the directory for a |
| file system cache, a host and port for a memcache server, or simply an |
| identifying name for a local memory cache. e.g.:: |
| |
| CACHES = { |
| 'default': { |
| 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache', |
| 'LOCATION': '/var/tmp/django_cache', |
| } |
| } |
| |
| .. setting:: CACHES-OPTIONS |
| |
| OPTIONS |
| ~~~~~~~ |
| |
| Default: None |
| |
| Extra parameters to pass to the cache backend. Available parameters |
| vary depending on your cache backend. |
| |
| Some information on available parameters can be found in the |
| :doc:`Cache Backends </topics/cache>` documentation. For more information, |
| consult your backend module's own documentation. |
| |
| .. setting:: CACHES-TIMEOUT |
| |
| TIMEOUT |
| ~~~~~~~ |
| |
| Default: 300 |
| |
| The number of seconds before a cache entry is considered stale. |
| |
| .. setting:: CACHES-VERSION |
| |
| VERSION |
| ~~~~~~~ |
| |
| Default: ``1`` |
| |
| The default version number for cache keys generated by the Django server. |
| |
| See the :ref:`cache documentation <cache_versioning>` for more information. |
| |
| .. setting:: CACHE_MIDDLEWARE_ALIAS |
| |
| CACHE_MIDDLEWARE_ALIAS |
| ---------------------- |
| |
| Default: ``default`` |
| |
| The cache connection to use for the cache middleware. |
| |
| .. setting:: CACHE_MIDDLEWARE_ANONYMOUS_ONLY |
| |
| CACHE_MIDDLEWARE_ANONYMOUS_ONLY |
| ------------------------------- |
| |
| Default: ``False`` |
| |
| 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 <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 </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 |
| ~~~~~~~~~~~~~~~~~ |
| |
| Default: ``['default']``, for all databases other than ``default``, |
| which has no dependencies. |
| |
| The creation-order dependencies of the database. See the documentation |
| on :ref:`controlling the creation order of test databases |
| <topics-testing-creation-dependencies>` for details. |
| |
| .. setting:: TEST_MIRROR |
| |
| TEST_MIRROR |
| ~~~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| The alias of the database that this database should mirror during |
| testing. |
| |
| This setting exists to allow for testing of master/slave |
| configurations of multiple databases. See the documentation on |
| :ref:`testing master/slave configurations |
| <topics-testing-masterslave>` for details. |
| |
| .. setting:: TEST_NAME |
| |
| TEST_NAME |
| ~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| The name of database to use when running the test suite. |
| |
| If the default value (``None``) is used with the SQLite database engine, the |
| tests will use a memory resident database. For all other database engines the |
| test database will use the name ``'test_' + DATABASE_NAME``. |
| |
| See :ref:`the-test-database`. |
| |
| .. setting:: TEST_CREATE |
| |
| TEST_CREATE |
| ~~~~~~~~~~~ |
| |
| Default: ``True`` |
| |
| This is an Oracle-specific setting. |
| |
| If it is set to ``False``, the test tablespaces won't be automatically created |
| at the beginning of the tests and dropped at the end. |
| |
| .. setting:: TEST_USER |
| |
| TEST_USER |
| ~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| This is an Oracle-specific setting. |
| |
| The username to use when connecting to the Oracle database that will be used |
| when running tests. If not provided, Django will use ``'test_' + USER``. |
| |
| .. setting:: TEST_USER_CREATE |
| |
| TEST_USER_CREATE |
| ~~~~~~~~~~~~~~~~ |
| |
| Default: ``True`` |
| |
| This is an Oracle-specific setting. |
| |
| If it is set to ``False``, the test user won't be automatically created at the |
| beginning of the tests and dropped at the end. |
| |
| .. setting:: TEST_PASSWD |
| |
| TEST_PASSWD |
| ~~~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| This is an Oracle-specific setting. |
| |
| The password to use when connecting to the Oracle database that will be used |
| when running tests. If not provided, Django will use a hardcoded default value. |
| |
| .. setting:: TEST_TBLSPACE |
| |
| TEST_TBLSPACE |
| ~~~~~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| This is an Oracle-specific setting. |
| |
| The name of the tablespace that will be used when running tests. If not |
| provided, Django will use ``'test_' + NAME``. |
| |
| .. setting:: TEST_TBLSPACE_TMP |
| |
| TEST_TBLSPACE_TMP |
| ~~~~~~~~~~~~~~~~~ |
| |
| Default: ``None`` |
| |
| This is an Oracle-specific setting. |
| |
| The name of the temporary tablespace that will be used when running tests. If |
| not provided, Django will use ``'test_' + NAME + '_temp'``. |
| |
| .. setting:: DATABASE_ROUTERS |
| |
| DATABASE_ROUTERS |
| ---------------- |
| |
| Default: ``[]`` (Empty list) |
| |
| The list of routers that will be used to determine which database |
| to use when performing a database queries. |
| |
| See the documentation on :ref:`automatic database routing in multi |
| database configurations <topics-db-multi-db-routing>`. |
| |
| .. setting:: DATE_FORMAT |
| |
| DATE_FORMAT |
| ----------- |
| |
| Default: ``'N j, Y'`` (e.g. ``Feb. 4, 2003``) |
| |
| The default formatting to use for displaying date fields in any part of the |
| system. Note that if :setting:`USE_L10N` is set to ``True``, then the |
| locale-dictated format has higher precedence and will be applied instead. See |
| :tfilter:`allowed date format strings <date>`. |
| |
| See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`. |
| |
| .. setting:: DATE_INPUT_FORMATS |
| |
| DATE_INPUT_FORMATS |
| ------------------ |
| |
| Default:: |
| |
| ( |
| '%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', # '2006-10-25', '10/25/2006', '10/25/06' |
| '%b %d %Y', '%b %d, %Y', # 'Oct 25 2006', 'Oct 25, 2006' |
| '%d %b %Y', '%d %b, %Y', # '25 Oct 2006', '25 Oct, 2006' |
| '%B %d %Y', '%B %d, %Y', # 'October 25 2006', 'October 25, 2006' |
| '%d %B %Y', '%d %B, %Y', # '25 October 2006', '25 October, 2006' |
| ) |
| |
| A tuple of formats that will be accepted when inputting data on a date field. |
| Formats will be tried in order, using the first valid one. Note that these |
| format strings use Python's datetime_ module syntax, not the format strings |
| from the ``date`` Django template tag. |
| |
| When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher |
| precedence and will be applied instead. |
| |
| See also :setting:`DATETIME_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`. |
| |
| .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior |
| |
| .. setting:: DATETIME_FORMAT |
| |
| DATETIME_FORMAT |
| --------------- |
| |
| Default: ``'N j, Y, P'`` (e.g. ``Feb. 4, 2003, 4 p.m.``) |
| |
| The default formatting to use for displaying datetime fields in any part of the |
| system. Note that if :setting:`USE_L10N` is set to ``True``, then the |
| locale-dictated format has higher precedence and will be applied instead. See |
| :tfilter:`allowed date format strings <date>`. |
| |
| See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. |
| |
| .. setting:: DATETIME_INPUT_FORMATS |
| |
| DATETIME_INPUT_FORMATS |
| ---------------------- |
| |
| Default:: |
| |
| ( |
| '%Y-%m-%d %H:%M:%S', # '2006-10-25 14:30:59' |
| '%Y-%m-%d %H:%M:%S.%f', # '2006-10-25 14:30:59.000200' |
| '%Y-%m-%d %H:%M', # '2006-10-25 14:30' |
| '%Y-%m-%d', # '2006-10-25' |
| '%m/%d/%Y %H:%M:%S', # '10/25/2006 14:30:59' |
| '%m/%d/%Y %H:%M:%S.%f', # '10/25/2006 14:30:59.000200' |
| '%m/%d/%Y %H:%M', # '10/25/2006 14:30' |
| '%m/%d/%Y', # '10/25/2006' |
| '%m/%d/%y %H:%M:%S', # '10/25/06 14:30:59' |
| '%m/%d/%y %H:%M:%S.%f', # '10/25/06 14:30:59.000200' |
| '%m/%d/%y %H:%M', # '10/25/06 14:30' |
| '%m/%d/%y', # '10/25/06' |
| ) |
| |
| A tuple of formats that will be accepted when inputting data on a datetime |
| field. Formats will be tried in order, using the first valid one. Note that |
| these format strings use Python's datetime_ module syntax, not the format |
| strings from the ``date`` Django template tag. |
| |
| When :setting:`USE_L10N` is ``True``, the locale-dictated format has higher |
| precedence and will be applied instead. |
| |
| See also :setting:`DATE_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`. |
| |
| .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior |
| |
| .. setting:: DEBUG |
| |
| DEBUG |
| ----- |
| |
| Default: ``False`` |
| |
| A boolean that turns on/off debug mode. |
| |
| Never deploy a site into production with :setting:`DEBUG` turned on. |
| |
| Did you catch that? NEVER deploy a site into production with :setting:`DEBUG` |
| turned on. |
| |
| One of the main features of debug mode is the display of detailed error pages. |
| If your app raises an exception when :setting:`DEBUG` is ``True``, Django will |
| display a detailed traceback, including a lot of metadata about your |
| environment, such as all the currently defined Django settings (from |
| ``settings.py``). |
| |
| As a security measure, Django will *not* include settings that might be |
| sensitive (or offensive), such as :setting:`SECRET_KEY` or |
| :setting:`PROFANITIES_LIST`. Specifically, it will exclude any setting whose |
| name includes any of the following: |
| |
| * ``'API'`` |
| * ``'KEY'`` |
| * ``'PASS'`` |
| * ``'PROFANITIES_LIST'`` |
| * ``'SECRET'`` |
| * ``'SIGNATURE'`` |
| * ``'TOKEN'`` |
| |
| .. 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<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 <django.http.HttpRequest.get_full_path>` (including |
| query string, if any). Use this if your site does not provide a commonly |
| requested file such as ``favicon.ico`` or ``robots.txt``, or if it gets |
| hammered by script kiddies. |
| |
| This is only used if :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 ID format <language code>`. For example, U.S. English |
| is ``"en-us"``. See also the `list of language identifiers`_ and |
| :doc:`/topics/i18n/index`. |
| |
| :setting:`USE_I18N` must be active for this setting to have any effect. |
| |
| It serves two purposes: |
| |
| * If the locale middleware isn't in use, it decides which translation is served |
| to all users. |
| * If the locale middleware is active, it provides the fallback translation when |
| no translation exist for a given literal to the user's preferred language. |
| |
| See :ref:`how-django-discovers-language-preference` for more details. |
| |
| .. _list of language identifiers: http://www.i18nguy.com/unicode/language-identifiers.html |
| |
| .. setting:: LANGUAGE_COOKIE_NAME |
| |
| LANGUAGE_COOKIE_NAME |
| -------------------- |
| |
| Default: ``'django_language'`` |
| |
| The name of the cookie to use for the language cookie. This can be whatever |
| you want (but should be different from :setting:`SESSION_COOKIE_NAME`). See |
| :doc:`/topics/i18n/index`. |
| |
| .. setting:: LANGUAGES |
| |
| LANGUAGES |
| --------- |
| |
| Default: A tuple of all available languages. This list is continually growing |
| and including a copy here would inevitably become rapidly out of date. You can |
| see the current list of translated languages by looking in |
| ``django/conf/global_settings.py`` (or view the `online source`_). |
| |
| .. _online source: https://github.com/django/django/blob/master/django/conf/global_settings.py |
| |
| The list is a tuple of two-tuples in the format |
| (:term:`language code<language code>`, ``language name``) -- for example, |
| ``('ja', 'Japanese')``. |
| This specifies which languages are available for language selection. See |
| :doc:`/topics/i18n/index`. |
| |
| Generally, the default value should suffice. Only set this setting if you want |
| to restrict language selection to a subset of the Django-provided languages. |
| |
| If you define a custom :setting:`LANGUAGES` setting, it's OK to mark the |
| languages as translation strings (as in the default value referred to above) |
| -- but use a "dummy" ``gettext()`` function, not the one in |
| ``django.utils.translation``. You should *never* import |
| ``django.utils.translation`` from within your settings file, because that |
| module in itself depends on the settings, and that would cause a circular |
| import. |
| |
| The solution is to use a "dummy" ``gettext()`` function. Here's a sample |
| settings file:: |
| |
| gettext = lambda s: s |
| |
| LANGUAGES = ( |
| ('de', gettext('German')), |
| ('en', gettext('English')), |
| ) |
| |
| With this arrangement, ``django-admin.py makemessages`` will still find and |
| mark these strings for translation, but the translation won't happen at |
| runtime -- so you'll have to remember to wrap the languages in the *real* |
| ``gettext()`` in any code that uses :setting:`LANGUAGES` at runtime. |
| |
| .. setting:: LOCALE_PATHS |
| |
| LOCALE_PATHS |
| ------------ |
| |
| Default: ``()`` (Empty tuple) |
| |
| A tuple of directories where Django looks for translation files. |
| See :ref:`how-django-discovers-translations`. |
| |
| Example:: |
| |
| LOCALE_PATHS = ( |
| '/home/www/project/common_files/locale', |
| '/var/local/translations/locale' |
| ) |
| |
| Django will look within each of these paths for the ``<locale_code>/LC_MESSAGES`` |
| directories containing the actual translation files. |
| |
| .. setting:: LOGGING |
| |
| LOGGING |
| ------- |
| |
| Default: A logging configuration dictionary. |
| |
| A data structure containing configuration information. The contents of |
| this data structure will be passed as the argument to the |
| configuration method described in :setting:`LOGGING_CONFIG`. |
| |
| 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 <naming-url-patterns>` which can be used to reduce |
| configuration duplication since you no longer have to define the URL in two |
| places (``settings`` and URLconf). |
| For backward compatibility reasons the default remains unchanged. |
| |
| .. setting:: LOGIN_URL |
| |
| LOGIN_URL |
| --------- |
| |
| Default: ``'/accounts/login/'`` |
| |
| The URL where requests are redirected for login, especially when using the |
| :func:`~django.contrib.auth.decorators.login_required` decorator. |
| |
| .. versionchanged:: 1.5 |
| |
| This setting now also accepts view function names and |
| :ref:`named URL patterns <naming-url-patterns>` which can be used to reduce |
| configuration duplication since you no longer have to define the URL in two |
| places (``settings`` and URLconf). |
| For backward compatibility reasons the default remains unchanged. |
| |
| .. setting:: LOGOUT_URL |
| |
| LOGOUT_URL |
| ---------- |
| |
| Default: ``'/accounts/logout/'`` |
| |
| LOGIN_URL counterpart. |
| |
| .. setting:: 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 </topics/files>`. |
| |
| Example: ``"/var/www/example.com/media/"`` |
| |
| See also :setting:`MEDIA_URL`. |
| |
| .. setting:: MEDIA_URL |
| |
| MEDIA_URL |
| --------- |
| |
| Default: ``''`` (Empty string) |
| |
| URL that handles the media served from :setting:`MEDIA_ROOT`, used |
| for :doc:`managing stored files </topics/files>`. It must end in a slash if set |
| to a non-empty value. |
| |
| Example: ``"http://media.example.com/"`` |
| |
| MESSAGE_LEVEL |
| ------------- |
| |
| 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. |
| |
| .. setting:: MESSAGE_STORAGE |
| |
| MESSAGE_STORAGE |
| --------------- |
| |
| Default: ``'django.contrib.messages.storage.fallback.FallbackStorage'`` |
| |
| Controls where Django stores message data. See the |
| :doc:`messages documentation </ref/contrib/messages>` 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 </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`. |
| |
| .. setting:: MONTH_DAY_FORMAT |
| |
| MONTH_DAY_FORMAT |
| ---------------- |
| |
| Default: ``'F j'`` |
| |
| The default formatting to use for date fields on Django admin change-list |
| pages -- and, possibly, by other parts of the system -- in cases when only the |
| month and day are displayed. |
| |
| For example, when a Django admin change-list page is being filtered by a date |
| drilldown, the header for a given day displays the day and month. Different |
| locales have different formats. For example, U.S. English would say |
| "January 1," whereas Spanish might say "1 Enero." |
| |
| See :tfilter:`allowed date format strings <date>`. See also |
| :setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, |
| :setting:`TIME_FORMAT` and :setting:`YEAR_MONTH_FORMAT`. |
| |
| .. setting:: NUMBER_GROUPING |
| |
| NUMBER_GROUPING |
| ---------------- |
| |
| Default: ``0`` |
| |
| Number of digits grouped together on the integer part of a number. |
| |
| Common use is to display a thousand separator. If this setting is ``0``, then |
| no grouping will be applied to the number. If this setting is greater than |
| ``0``, then :setting:`THOUSAND_SEPARATOR` will be used as the separator between |
| those groups. |
| |
| Note that if :setting:`USE_L10N` is set to ``True``, then the locale-dictated |
| format has higher precedence and will be applied instead. |
| |
| See also :setting:`DECIMAL_SEPARATOR`, :setting:`THOUSAND_SEPARATOR` and |
| :setting:`USE_THOUSAND_SEPARATOR`. |
| |
| .. setting:: 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 </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 a particular Django installation. This is used to provide |
| :doc:`cryptographic signing </topics/signing>`, and should be set to a unique, |
| unpredictable value. |
| |
| :djadmin:`django-admin.py startproject <startproject>` automatically adds a |
| randomly-generated ``SECRET_KEY`` to each new project. |
| |
| .. warning:: |
| |
| **Keep this value secret.** |
| |
| Running Django with a known :setting:`SECRET_KEY` defeats many of Django's |
| security protections, and can lead to privilege escalation and remote code |
| execution vulnerabilities. |
| |
| .. versionchanged:: 1.5 |
| Django will now refuse to start if :setting:`SECRET_KEY` is not set. |
| |
| .. setting:: SECURE_PROXY_SSL_HEADER |
| |
| SECURE_PROXY_SSL_HEADER |
| ----------------------- |
| |
| .. 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 <cached-sessions-backend>`, |
| 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. Included engines 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:: SESSION_SERIALIZER |
| |
| SESSION_SERIALIZER |
| ------------------ |
| |
| .. versionadded:: 1.5.3 |
| |
| Default: ``'django.contrib.sessions.serializers.PickleSerializer'`` |
| |
| Full import path of a serializer class to use for serializing session data. |
| Included serializers are: |
| |
| * ``'django.contrib.sessions.serializers.PickleSerializer'`` |
| * ``'django.contrib.sessions.serializers.JSONSerializer'`` |
| |
| See :ref:`session_serialization` for details, including a warning regarding |
| possible remote code execution when using |
| :class:`~django.contrib.sessions.serializers.PickleSerializer`. |
| |
| In Django 1.5.3, the default in newly created projects using |
| :djadmin:`django-admin.py startproject <startproject>` is |
| :class:`django.contrib.sessions.serializers.JSONSerializer`, and the global |
| default will switch to this class in Django 1.6. |
| |
| .. setting:: SHORT_DATE_FORMAT |
| |
| SHORT_DATE_FORMAT |
| ----------------- |
| |
| Default: ``m/d/Y`` (e.g. ``12/31/2003``) |
| |
| An available formatting that can be used for displaying date fields on |
| templates. Note that if :setting:`USE_L10N` is set to ``True``, then the |
| corresponding locale-dictated format has higher precedence and will be applied. |
| See :tfilter:`allowed date format strings <date>`. |
| |
| See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. |
| |
| .. setting:: SHORT_DATETIME_FORMAT |
| |
| SHORT_DATETIME_FORMAT |
| --------------------- |
| |
| Default: ``m/d/Y P`` (e.g. ``12/31/2003 4 p.m.``) |
| |
| An available formatting that can be used for displaying datetime fields on |
| templates. Note that if :setting:`USE_L10N` is set to ``True``, then the |
| corresponding locale-dictated format has higher precedence and will be applied. |
| See :tfilter:`allowed date format strings <date>`. |
| |
| See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATE_FORMAT`. |
| |
| .. setting:: SIGNING_BACKEND |
| |
| SIGNING_BACKEND |
| --------------- |
| |
| .. 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</ref/contrib/staticfiles>` contrib app is enabled |
| (default) the :djadmin:`collectstatic` management command will collect static |
| files into this directory. See the howto on :doc:`managing static |
| files</howto/static-files/index>` for more details about usage. |
| |
| .. warning:: |
| |
| This should be an (initially empty) destination directory for collecting |
| your static files from their permanent locations into one directory for |
| ease of deployment; it is **not** a place to store your static files |
| permanently. You should do that in directories that will be found by |
| :doc:`staticfiles</ref/contrib/staticfiles>`'s |
| :setting:`finders<STATICFILES_FINDERS>`, which by default, are |
| ``'static/'`` app sub-directories and any directories you include in |
| :setting:`STATICFILES_DIRS`). |
| |
| 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: ``"/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.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 <date>`. |
| |
| See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`. |
| |
| .. setting:: TIME_INPUT_FORMATS |
| |
| TIME_INPUT_FORMATS |
| ------------------ |
| |
| Default:: |
| |
| ( |
| '%H:%M:%S', # '14:30:59' |
| '%H:%M', # '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 |
| <settings-without-django-settings-module>`, or |
| |
| * If you specify ``TIME_ZONE = None``. This will cause Django to fall back to |
| using the system timezone. However, this is discouraged when :setting:`USE_TZ |
| = True <USE_TZ>`, because it makes conversions between local time and UTC |
| less reliable. |
| |
| If Django doesn't set the ``TZ`` environment variable, it's up to you |
| to ensure your processes are running in the correct environment. |
| |
| .. note:: |
| Django cannot reliably use alternate time zones in a Windows environment. |
| If you're running Django on Windows, :setting:`TIME_ZONE` must be set to |
| match the system time zone. |
| |
| .. _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 <deactivate-transaction-management>` and implement your own. |
| |
| .. setting:: USE_ETAGS |
| |
| USE_ETAGS |
| --------- |
| |
| Default: ``False`` |
| |
| A boolean that specifies whether to output the "Etag" header. This saves |
| bandwidth but slows down performance. This is used by the ``CommonMiddleware`` |
| (see :doc:`/topics/http/middleware`) and in the``Cache Framework`` |
| (see :doc:`/topics/cache`). |
| |
| .. setting:: USE_I18N |
| |
| USE_I18N |
| -------- |
| |
| Default: ``True`` |
| |
| A boolean that specifies whether Django's translation system should be enabled. |
| This provides an easy way to turn it off, for performance. If this is set to |
| ``False``, Django will make some optimizations so as not to load the |
| translation machinery. |
| |
| See also :setting:`LANGUAGE_CODE`, :setting:`USE_L10N` and :setting:`USE_TZ`. |
| |
| .. setting:: USE_L10N |
| |
| USE_L10N |
| -------- |
| |
| Default: ``False`` |
| |
| A boolean that specifies if localized formatting of data will be enabled by |
| default or not. If this is set to ``True``, e.g. Django will display numbers and |
| dates using the format of the current locale. |
| |
| See also :setting:`LANGUAGE_CODE`, :setting:`USE_I18N` and :setting:`USE_TZ`. |
| |
| .. note:: |
| |
| The default :file:`settings.py` file created by :djadmin:`django-admin.py |
| startproject <startproject>` includes ``USE_L10N = True`` for convenience. |
| |
| .. setting:: USE_THOUSAND_SEPARATOR |
| |
| USE_THOUSAND_SEPARATOR |
| ---------------------- |
| |
| Default: ``False`` |
| |
| A boolean that specifies whether to display numbers using a thousand separator. |
| When :setting:`USE_L10N` is set to ``True`` and if this is also set to |
| ``True``, Django will use the values of :setting:`THOUSAND_SEPARATOR` and |
| :setting:`NUMBER_GROUPING` to format numbers. |
| |
| See also :setting:`DECIMAL_SEPARATOR`, :setting:`NUMBER_GROUPING` and |
| :setting:`THOUSAND_SEPARATOR`. |
| |
| .. setting:: USE_TZ |
| |
| USE_TZ |
| ------ |
| |
| .. 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 <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 <startproject>` management command will create a simple |
| ``wsgi.py`` file with an ``application`` callable in it, and point this setting |
| to that ``application``. |
| |
| If not set, the return value of ``django.core.wsgi.get_wsgi_application()`` |
| will be used. In this case, the behavior of :djadmin:`runserver` will be |
| identical to previous Django versions. |
| |
| .. setting:: YEAR_MONTH_FORMAT |
| |
| YEAR_MONTH_FORMAT |
| ----------------- |
| |
| Default: ``'F Y'`` |
| |
| The default formatting to use for date fields on Django admin change-list |
| pages -- and, possibly, by other parts of the system -- in cases when only the |
| year and month are displayed. |
| |
| For example, when a Django admin change-list page is being filtered by a date |
| drilldown, the header for a given month displays the month and the year. |
| Different locales have different formats. For example, U.S. English would say |
| "January 2006," whereas another locale might say "2006/January." |
| |
| See :tfilter:`allowed date format strings <date>`. See also |
| :setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` |
| and :setting:`MONTH_DAY_FORMAT`. |
| |
| .. setting:: X_FRAME_OPTIONS |
| |
| X_FRAME_OPTIONS |
| --------------- |
| |
| Default: ``'SAMEORIGIN'`` |
| |
| The default value for the X-Frame-Options header used by |
| :class:`~django.middleware.clickjacking.XFrameOptionsMiddleware`. See the |
| :doc:`clickjacking protection </ref/clickjacking/>` documentation. |
| |
| Deprecated settings |
| =================== |
| |
| .. setting:: AUTH_PROFILE_MODULE |
| |
| AUTH_PROFILE_MODULE |
| ------------------- |
| |
| .. deprecated:: 1.5 |
| With the introduction of :ref:`custom User models <auth-custom-user>`, |
| 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</releases/1.5>` for more information. |
| |
| Default: Not defined |
| |
| The site-specific user profile model used by this site. See |
| :ref:`User profiles <auth-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`. |