diff options
Diffstat (limited to 'parts/django/docs/ref/settings.txt')
| -rw-r--r-- | parts/django/docs/ref/settings.txt | 1836 |
1 files changed, 0 insertions, 1836 deletions
diff --git a/parts/django/docs/ref/settings.txt b/parts/django/docs/ref/settings.txt deleted file mode 100644 index ab1f28c..0000000 --- a/parts/django/docs/ref/settings.txt +++ /dev/null @@ -1,1836 +0,0 @@ -======== -Settings -======== - -.. contents:: - :local: - :depth: 1 - -Available settings -================== - -Here's a full list of all available settings, in alphabetical order, and their -default values. - -.. setting:: ABSOLUTE_URL_OVERRIDES - -ABSOLUTE_URL_OVERRIDES ----------------------- - -Default: ``{}`` (Empty dictionary) - -A dictionary mapping ``"app_label.model_name"`` strings to functions that take -a model object and return its URL. This is a way of overriding -``get_absolute_url()`` methods on a per-installation basis. Example:: - - ABSOLUTE_URL_OVERRIDES = { - 'blogs.weblog': lambda o: "/blogs/%s/" % o.slug, - 'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), - } - -Note that the model name used in this setting should be all lower-case, regardless -of the case of the actual model class name. - -.. setting:: ADMIN_FOR - -ADMIN_FOR ---------- - -Default: ``()`` (Empty tuple) - -Used for admin-site settings modules, this should be a tuple of settings -modules (in the format ``'foo.bar.baz'``) for which this site is an admin. - -The admin site uses this in its automatically-introspected documentation of -models, views and template tags. - -.. setting:: ADMIN_MEDIA_PREFIX - -ADMIN_MEDIA_PREFIX ------------------- - -Default: ``'/media/'`` - -The URL prefix for admin media -- CSS, JavaScript and images used by -the Django administrative interface. Make sure to use a trailing -slash, and to have this be different from the ``MEDIA_URL`` setting -(since the same URL cannot be mapped onto two different sets of -files). - -.. 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 e-mail these people -with the full exception information. Each member of the tuple should be a tuple -of (Full name, e-mail address). Example:: - - (('John', 'john@example.com'), ('Mary', 'mary@example.com')) - -Note that Django will e-mail *all* of these people whenever an error happens. -See :doc:`/howto/error-reporting` for more information. - -.. setting:: ALLOWED_INCLUDE_ROOTS - -ALLOWED_INCLUDE_ROOTS ---------------------- - -Default: ``()`` (Empty tuple) - -A tuple of strings representing allowed prefixes for the ``{% ssi %}`` template -tag. This is a security measure, so that template authors can't access files -that they shouldn't be accessing. - -For example, if ``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 ``APPEND_SLASH`` setting is only used if -:class:`~django.middleware.common.CommonMiddleware` is installed -(see :doc:`/topics/http/middleware`). See also :setting:`PREPEND_WWW`. - -.. setting:: AUTHENTICATION_BACKENDS - -AUTHENTICATION_BACKENDS ------------------------ - -Default: ``('django.contrib.auth.backends.ModelBackend',)`` - -A tuple of authentication backend classes (as strings) to use when attempting to -authenticate a user. See the :doc:`authentication backends documentation -</ref/authbackends>` for details. - -.. setting:: AUTH_PROFILE_MODULE - -AUTH_PROFILE_MODULE -------------------- - -Default: Not defined - -The site-specific user profile model used by this site. See -:ref:`auth-profiles`. - -.. setting:: CACHE_BACKEND - -CACHE_BACKEND -------------- - -Default: ``'locmem://'`` - -The cache backend to use. See :doc:`/topics/cache`. - -.. 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 the :doc:`cache documentation </topics/cache>` for more information. - -.. 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. - -.. setting:: CSRF_COOKIE_DOMAIN - -CSRF_COOKIE_DOMAIN ------------------- - -.. versionadded:: 1.2 - -Default: ``None`` - -The domain to be used when setting the CSRF cookie. This can be useful for -allowing cross-subdomain requests to be exluded from the normal cross site -request forgery protection. It should be set to a string such as -``".lawrence.com"`` to allow a POST request from a form on one subdomain to be -accepted by accepted by a view served from another subdomain. - -.. setting:: CSRF_COOKIE_NAME - -CSRF_COOKIE_NAME ----------------- - -.. versionadded:: 1.2 - -Default: ``'csrftoken'`` - -The name of the cookie to use for the CSRF authentication token. This can be whatever you -want. See :doc:`/ref/contrib/csrf`. - -.. setting:: CSRF_FAILURE_VIEW - -CSRF_FAILURE_VIEW ------------------ - -.. versionadded:: 1.2 - -Default: ``'django.views.csrf.csrf_failure'`` - -A dotted path to the view function to be used when an incoming request -is rejected by the CSRF protection. The function should have this signature:: - - def csrf_failure(request, reason="") - -where ``reason`` is a short message (intended for developers or logging, not for -end users) indicating the reason the request was rejected. See -:doc:`/ref/contrib/csrf`. - - -.. setting:: DATABASES - -DATABASES ---------- - -.. versionadded:: 1.2 - -Default: ``{}`` (Empty dictionary) - -A dictionary containing the settings for all databases to be used with -Django. It is a nested dictionary whose contents maps database aliases -to a dictionary containing the options for an individual database. - -The :setting:`DATABASES` setting must configure a ``default`` database; -any number of additional databases may also be specified. - -The simplest possible settings file is for a single-database setup using -SQLite. This can be configured using the following:: - - DATABASES = { - 'default': { - 'ENGINE': 'django.db.backends.sqlite3', - 'NAME': 'mydatabase' - } - } - -For other database backends, or more complex SQLite configurations, other options -will be required. The following inner options are available. - -.. setting:: ENGINE - -ENGINE -~~~~~~ - -Default: ``''`` (Empty string) - -The database backend to use. The built-in database backends are: - - * ``'django.db.backends.postgresql_psycopg2'`` - * ``'django.db.backends.postgresql'`` - * ``'django.db.backends.mysql'`` - * ``'django.db.backends.sqlite3'`` - * ``'django.db.backends.oracle'`` - -You can use a database backend that doesn't ship with Django by setting -``ENGINE`` to a fully-qualified path (i.e. -``mypackage.backends.whatever``). Writing a whole new database backend from -scratch is left as an exercise to the reader; see the other backends for -examples. - -.. note:: - Prior to Django 1.2, you could use a short version of the backend name - to reference the built-in database backends (e.g., you could use - ``'sqlite3'`` to refer to the SQLite backend). This format has been - deprecated, and will be removed in Django 1.4. - -.. setting:: HOST - -HOST -~~~~ - -Default: ``''`` (Empty string) - -Which host to use when connecting to the database. An empty string means -localhost. Not used with SQLite. - -If this value starts with a forward slash (``'/'``) and you're using MySQL, -MySQL will connect via a Unix socket to the specified socket. For example:: - - "HOST": '/var/run/mysql' - -If you're using MySQL and this value *doesn't* start with a forward slash, then -this value is assumed to be the host. - -If you're using PostgreSQL, an empty string means to use a Unix domain socket -for the connection, rather than a network connection to localhost. If you -explicitly need to use a TCP/IP connection on the local machine with -PostgreSQL, specify ``localhost`` here. - -.. setting:: NAME - -NAME -~~~~ - -Default: ``''`` (Empty string) - -The name of the database to use. For SQLite, it's the full path to the database -file. When specifying the path, always use forward slashes, even on Windows -(e.g. ``C:/homes/user/mysite/sqlite3.db``). - -.. setting:: OPTIONS - -OPTIONS -~~~~~~~ - -Default: ``{}`` (Empty dictionary) - -Extra parameters to use when connecting to the database. Available parameters -vary depending on your database backend. - -Some information on available parameters can be found in the -:doc:`Database Backends </ref/databases>` documentation. For more information, -consult your backend module's own documentation. - -.. setting:: PASSWORD - -PASSWORD -~~~~~~~~ - -Default: ``''`` (Empty string) - -The password to use when connecting to the database. Not used with SQLite. - -.. setting:: PORT - -PORT -~~~~ - -Default: ``''`` (Empty string) - -The port to use when connecting to the database. An empty string means the -default port. Not used with SQLite. - -.. setting:: USER - -USER -~~~~ - -Default: ``''`` (Empty string) - -The username to use when connecting to the database. Not used with SQLite. - -.. setting:: TEST_CHARSET - -TEST_CHARSET -~~~~~~~~~~~~ - -Default: ``None`` - -The character set encoding used to create the test database. The value of this -string is passed directly through to the database, so its format is -backend-specific. - -Supported for the PostgreSQL_ (``postgresql``, ``postgresql_psycopg2``) and -MySQL_ (``mysql``) backends. - -.. _PostgreSQL: http://www.postgresql.org/docs/8.2/static/multibyte.html -.. _MySQL: http://dev.mysql.com/doc/refman/5.0/en/charset-database.html - -.. setting:: TEST_COLLATION - -TEST_COLLATION -~~~~~~~~~~~~~~ - -Default: ``None`` - -The collation order to use when creating the test database. This value is -passed directly to the backend, so its format is backend-specific. - -Only supported for the ``mysql`` backend (see the `MySQL manual`_ for details). - -.. _MySQL manual: MySQL_ - -.. setting:: TEST_DEPENDENCIES - -TEST_DEPENDENCIES -~~~~~~~~~~~~~~~~~ - -.. versionadded:: 1.2.4 - -Default: ``['default']``, for all databases other than ``default``, -which has no dependencies. - -The creation-order dependencies of the database. See the documentation -on :ref:`controlling the creation order of test databases -<topics-testing-creation-dependencies>` for details. - -.. setting:: TEST_MIRROR - -TEST_MIRROR -~~~~~~~~~~~ - -Default: ``None`` - -The alias of the database that this database should mirror during -testing. - -This setting exists to allow for testing of master/slave -configurations of multiple databases. See the documentation on -:ref:`testing master/slave configurations -<topics-testing-masterslave>` for details. - -.. setting:: TEST_NAME - -TEST_NAME -~~~~~~~~~ - -Default: ``None`` - -The name of database to use when running the test suite. - -If the default value (``None``) is used with the SQLite database engine, the -tests will use a memory resident database. For all other database engines the -test database will use the name ``'test_' + DATABASE_NAME``. - -See :doc:`/topics/testing`. - -.. setting:: TEST_USER - -TEST_USER -~~~~~~~~~ - -Default: ``None`` - -This is an Oracle-specific setting. - -The username to use when connecting to the Oracle database that will be used -when running tests. - -.. setting:: DATABASE_ROUTERS - -DATABASE_ROUTERS ----------------- - -.. versionadded:: 1.2 - -Default: ``[]`` (Empty list) - -The list of routers that will be used to determine which database -to use when performing a database queries. - -See the documentation on :ref:`automatic database routing in multi -database configurations <topics-db-multi-db-routing>`. - -.. setting:: DATE_FORMAT - -DATE_FORMAT ------------ - -Default: ``'N j, Y'`` (e.g. ``Feb. 4, 2003``) - -The default formatting to use for displaying date fields in any part of the -system. Note that if :setting:`USE_L10N` is set to ``True``, then the -locale-dictated format has higher precedence and will be applied instead. See -:tfilter:`allowed date format strings <date>`. - -.. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. - -See also ``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATE_FORMAT``. - -.. setting:: DATE_INPUT_FORMATS - -DATE_INPUT_FORMATS ------------------- - -.. versionadded:: 1.2 - -Default:: - - ('%Y-%m-%d', '%m/%d/%Y', '%m/%d/%y', '%b %d %Y', - '%b %d, %Y', '%d %b %Y', '%d %b, %Y', '%B %d %Y', - '%B %d, %Y', '%d %B %Y', '%d %B, %Y') - -A tuple of formats that will be accepted when inputting data on a date -field. Formats will be tried in order, using the first valid. -Note that these format strings are specified in Python's datetime_ module -syntax, that is different from the one used by Django for formatting dates -to be displayed. - -See also ``DATETIME_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``. - -.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior - -.. setting:: DATETIME_FORMAT - -DATETIME_FORMAT ---------------- - -Default: ``'N j, Y, P'`` (e.g. ``Feb. 4, 2003, 4 p.m.``) - -The default formatting to use for displaying datetime fields in any part of the -system. Note that if :setting:`USE_L10N` is set to ``True``, then the -locale-dictated format has higher precedence and will be applied instead. See -:tfilter:`allowed date format strings <date>`. - -.. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. - -See also ``DATE_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATETIME_FORMAT``. - -.. setting:: DATETIME_INPUT_FORMATS - -DATETIME_INPUT_FORMATS ----------------------- - -.. versionadded:: 1.2 - -Default:: - - ('%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M', '%Y-%m-%d', - '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M', '%m/%d/%Y', - '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y') - -A tuple of formats that will be accepted when inputting data on a datetime -field. Formats will be tried in order, using the first valid. -Note that these format strings are specified in Python's datetime_ module -syntax, that is different from the one used by Django for formatting dates -to be displayed. - -See also ``DATE_INPUT_FORMATS`` and ``TIME_INPUT_FORMATS``. - -.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior - -.. setting:: DEBUG - -DEBUG ------ - -Default: ``False`` - -A boolean that turns on/off debug mode. - -If you define custom settings, `django/views/debug.py`_ has a ``HIDDEN_SETTINGS`` -regular expression which will hide from the DEBUG view anything that contains -``'SECRET'``, ``'PASSWORD'``, ``'PROFANITIES'``, or ``'SIGNATURE'``. This allows -untrusted users to be able to give backtraces without seeing sensitive (or -offensive) settings. - -Still, note that there are always going to be sections of your debug output that -are inappropriate for public consumption. File paths, configuration options, and -the like all give attackers extra information about your server. - -It is also important to remember that when running with ``DEBUG`` turned on, Django -will remember every SQL query it executes. This is useful when you are debugging, -but on a production server, it will rapidly consume memory. - -Never deploy a site into production with ``DEBUG`` turned on. - -.. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py - -DEBUG_PROPAGATE_EXCEPTIONS --------------------------- - -.. versionadded:: 1.0 - -Default: ``False`` - -If set to True, Django's normal exception handling of view functions -will be suppressed, and exceptions will propagate upwards. This can -be useful for some test setups, and should never be used on a live -site. - -.. setting:: DECIMAL_SEPARATOR - -DECIMAL_SEPARATOR ------------------ - -.. versionadded:: 1.2 - -Default: ``'.'`` (Dot) - -Default decimal separator used when formatting decimal numbers. - -.. setting:: DEFAULT_CHARSET - -DEFAULT_CHARSET ---------------- - -Default: ``'utf-8'`` - -Default charset to use for all ``HttpResponse`` objects, if a MIME type isn't -manually specified. Used with ``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 ``DEFAULT_CHARSET`` to construct the -``Content-Type`` header. - -.. 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 e-mail address to use for various automated correspondence from the -site manager(s). - -.. setting:: DEFAULT_INDEX_TABLESPACE - -DEFAULT_INDEX_TABLESPACE ------------------------- - -.. versionadded:: 1.0 - -Default: ``''`` (Empty string) - -Default tablespace to use for indexes on fields that don't specify -one, if the backend supports it. - -.. setting:: DEFAULT_TABLESPACE - -DEFAULT_TABLESPACE ------------------- - -.. versionadded:: 1.0 - -Default: ``''`` (Empty string) - -Default tablespace to use for models that don't specify one, if the -backend supports it. - -.. setting:: DISALLOWED_USER_AGENTS - -DISALLOWED_USER_AGENTS ----------------------- - -Default: ``()`` (Empty tuple) - -List of compiled regular expression objects representing User-Agent strings that -are not allowed to visit any page, systemwide. Use this for bad robots/crawlers. -This is only used if ``CommonMiddleware`` is installed (see -:doc:`/topics/http/middleware`). - -.. setting:: EMAIL_BACKEND - -EMAIL_BACKEND -------------- - -.. versionadded:: 1.2 - -Default: ``'django.core.mail.backends.smtp.EmailBackend'`` - -The backend to use for sending emails. For the list of available backends see -:doc:`/topics/email`. - -.. setting:: EMAIL_FILE_PATH - -EMAIL_FILE_PATH ---------------- - -.. versionadded:: 1.2 - -Default: Not defined - -The directory used by the ``file`` email backend to store output files. - -.. setting:: EMAIL_HOST - -EMAIL_HOST ----------- - -Default: ``'localhost'`` - -The host to use for sending e-mail. - -See also ``EMAIL_PORT``. - -.. setting:: EMAIL_HOST_PASSWORD - -EMAIL_HOST_PASSWORD -------------------- - -Default: ``''`` (Empty string) - -Password to use for the SMTP server defined in ``EMAIL_HOST``. This setting is -used in conjunction with ``EMAIL_HOST_USER`` when authenticating to the SMTP -server. If either of these settings is empty, Django won't attempt -authentication. - -See also ``EMAIL_HOST_USER``. - -.. setting:: EMAIL_HOST_USER - -EMAIL_HOST_USER ---------------- - -Default: ``''`` (Empty string) - -Username to use for the SMTP server defined in ``EMAIL_HOST``. If empty, -Django won't attempt authentication. - -See also ``EMAIL_HOST_PASSWORD``. - -.. setting:: EMAIL_PORT - -EMAIL_PORT ----------- - -Default: ``25`` - -Port to use for the SMTP server defined in ``EMAIL_HOST``. - -.. setting:: EMAIL_SUBJECT_PREFIX - -EMAIL_SUBJECT_PREFIX --------------------- - -Default: ``'[Django] '`` - -Subject-line prefix for e-mail 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 -------------- - -.. versionadded:: 1.0 - -Default: ``False`` - -Whether to use a TLS (secure) connection when talking to the SMTP server. - -.. setting:: FILE_CHARSET - -FILE_CHARSET ------------- - -.. versionadded:: 1.0 - -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 --------------------- - -.. versionadded:: 1.0 - -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 ---------------------------- - -.. versionadded:: 1.0 - -Default: ``2621440`` (i.e. 2.5 MB). - -The maximum size (in bytes) that an upload will be before it gets streamed to -the file system. See :doc:`/topics/files` for details. - -.. setting:: FILE_UPLOAD_PERMISSIONS - -FILE_UPLOAD_PERMISSIONS ------------------------ - -Default: ``None`` - -The numeric mode (i.e. ``0644``) to set newly uploaded files to. For -more information about what these modes mean, see the `documentation for -os.chmod`_ - -If this isn't given or is ``None``, you'll get operating-system -dependent behavior. On most platforms, temporary files will have a mode -of ``0600``, and files saved from memory will be saved using the -system's standard umask. - -.. warning:: - - **Always prefix the mode with a 0.** - - If you're not familiar with file modes, please note that the leading - ``0`` is very important: it indicates an octal number, which is the - way that modes must be specified. If you try to use ``644``, you'll - get totally incorrect behavior. - - -.. _documentation for os.chmod: http://docs.python.org/library/os.html#os.chmod - -.. setting:: FILE_UPLOAD_TEMP_DIR - -FILE_UPLOAD_TEMP_DIR --------------------- - -.. versionadded:: 1.0 - -Default: ``None`` - -The directory to store data temporarily while uploading files. If ``None``, -Django will use the standard temporary directory for the operating system. For -example, this will default to '/tmp' on \*nix-style operating systems. - -See :doc:`/topics/files` for details. - -.. setting:: FIRST_DAY_OF_WEEK - -FIRST_DAY_OF_WEEK ------------------ - -.. versionadded:: 1.2 - -Default: ``0`` (Sunday) - -Number representing the first day of the week. This is especially useful -when displaying a calendar. This value is only used when not using -format internationalization, or when a format cannot be found for the -current locale. - -The value must be an integer from 0 to 6, where 0 means Sunday, 1 means -Monday and so on. - -.. setting:: FIXTURE_DIRS - -FIXTURE_DIRS -------------- - -Default: ``()`` (Empty tuple) - -List of locations of the fixture data files, in search order. Note that -these paths should use Unix-style forward slashes, even on Windows. See -:doc:`/topics/testing`. - -FORCE_SCRIPT_NAME ------------------- - -Default: ``None`` - -If not ``None``, this will be used as the value of the ``SCRIPT_NAME`` -environment variable in any HTTP request. This setting can be used to override -the server-provided value of ``SCRIPT_NAME``, which may be a rewritten version -of the preferred value or not supplied at all. - -.. setting:: FORMAT_MODULE_PATH - -FORMAT_MODULE_PATH ------------------- - -.. versionadded:: 1.2 - -Default: ``None`` - -A full Python path to a Python package that contains format definitions for -project locales. If not ``None``, Django will check for a ``formats.py`` -file, under the directory named as the current locale, and will use the -formats defined on this file. - -For example, if ``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 ``DATE_FORMAT``, ``TIME_FORMAT``, ``DATETIME_FORMAT``, -``YEAR_MONTH_FORMAT``, ``MONTH_DAY_FORMAT``, ``SHORT_DATE_FORMAT``, -``SHORT_DATETIME_FORMAT``, ``FIRST_DAY_OF_WEEK``, ``DECIMAL_SEPARATOR``, -``THOUSAND_SEPARATOR`` and ``NUMBER_GROUPING``. - -.. setting:: IGNORABLE_404_ENDS - -IGNORABLE_404_ENDS ------------------- - -Default: ``('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi', 'favicon.ico', '.php')`` - -See also ``IGNORABLE_404_STARTS`` and ``Error reporting via e-mail``. - -.. setting:: IGNORABLE_404_STARTS - -IGNORABLE_404_STARTS --------------------- - -Default: ``('/cgi-bin/', '/_vti_bin', '/_vti_inf')`` - -A tuple of strings that specify beginnings of URLs that should be ignored by -the 404 e-mailer. See ``SEND_BROKEN_LINK_EMAILS``, ``IGNORABLE_404_ENDS`` and -the :doc:`/howto/error-reporting`. - -.. 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 ``DEBUG`` is ``True`` - * Receive X headers if the ``XViewMiddleware`` is installed (see - :doc:`/topics/http/middleware`) - -.. setting:: LANGUAGE_CODE - -LANGUAGE_CODE -------------- - -Default: ``'en-us'`` - -A string representing the language code for this installation. This should be in -standard :term:`language format<language code>`. For example, U.S. English is -``"en-us"``. See :doc:`/topics/i18n/index`. - -.. setting:: LANGUAGE_COOKIE_NAME - -LANGUAGE_COOKIE_NAME --------------------- - -.. versionadded:: 1.0 - -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 ``SESSION_COOKIE_NAME``). See -:doc:`/topics/i18n/index`. - -.. setting:: LANGUAGES - -LANGUAGES ---------- - -Default: A tuple of all available languages. This list is continually growing -and including a copy here would inevitably become rapidly out of date. You can -see the current list of translated languages by looking in -``django/conf/global_settings.py`` (or view the `online source`_). - -.. _online source: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py - -The list is a tuple of two-tuples in the format ``(language code, language -name)``, the ``language code`` part should be a -:term:`language name<language code>` -- for example, ``('ja', 'Japanese')``. -This specifies which languages are available for language selection. See -:doc:`/topics/i18n/index`. - -Generally, the default value should suffice. Only set this setting if you want -to restrict language selection to a subset of the Django-provided languages. - -If you define a custom ``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 ``LANGUAGES`` at runtime. - -.. setting:: LOCALE_PATHS - -LOCALE_PATHS ------------- - -Default: ``()`` (Empty tuple) - -A tuple of directories where Django looks for translation files. -See :ref:`using-translations-in-your-own-projects`. - -.. setting:: LOGIN_REDIRECT_URL - -LOGIN_REDIRECT_URL ------------------- - -.. versionadded:: 1.0 - -Default: ``'/accounts/profile/'`` - -The URL where requests are redirected after login when the -``contrib.auth.login`` view gets no ``next`` parameter. - -This is used by the :func:`~django.contrib.auth.decorators.login_required` -decorator, for example. - -.. setting:: LOGIN_URL - -LOGIN_URL ---------- - -.. versionadded:: 1.0 - -Default: ``'/accounts/login/'`` - -The URL where requests are redirected for login, especially when using the -:func:`~django.contrib.auth.decorators.login_required` decorator. - -.. setting:: LOGOUT_URL - -LOGOUT_URL ----------- - -.. versionadded:: 1.0 - -Default: ``'/accounts/logout/'`` - -LOGIN_URL counterpart. - -.. setting:: MANAGERS - -MANAGERS --------- - -Default: ``()`` (Empty tuple) - -A tuple in the same format as ``ADMINS`` that specifies who should get -broken-link notifications when ``SEND_BROKEN_LINK_EMAILS=True``. - -.. setting:: MEDIA_ROOT - -MEDIA_ROOT ----------- - -Default: ``''`` (Empty string) - -Absolute path to the directory that holds media for this installation. -Example: ``"/home/media/media.lawrence.com/"`` See also ``MEDIA_URL``. - -.. setting:: MEDIA_URL - -MEDIA_URL ---------- - -Default: ``''`` (Empty string) - -URL that handles the media served from ``MEDIA_ROOT``. -Example: ``"http://media.lawrence.com"`` - -Note that this should have a trailing slash if it has a path component. - -Good: ``"http://www.example.com/static/"`` -Bad: ``"http://www.example.com/static"`` - -.. setting:: MIDDLEWARE_CLASSES - -MESSAGE_LEVEL -------------- - -.. versionadded:: 1.2 - -Default: `messages.INFO` - -Sets the minimum message level that will be recorded by the messages -framework. See the :doc:`messages documentation </ref/contrib/messages>` for -more details. - -MESSAGE_STORAGE ---------------- - -.. versionadded:: 1.2 - -Default: ``'django.contrib.messages.storage.user_messages.LegacyFallbackStorage'`` - -Controls where Django stores message data. See the -:doc:`messages documentation </ref/contrib/messages>` for more details. - -MESSAGE_TAGS ------------- - -.. versionadded:: 1.2 - -Default:: - - {messages.DEBUG: 'debug', - messages.INFO: 'info', - messages.SUCCESS: 'success', - messages.WARNING: 'warning', - messages.ERROR: 'error',} - -Sets the mapping of message levels to message tags. See the -:doc:`messages documentation </ref/contrib/messages>` for more details. - -MIDDLEWARE_CLASSES ------------------- - -Default:: - - ('django.middleware.common.CommonMiddleware', - 'django.contrib.sessions.middleware.SessionMiddleware', - 'django.middleware.csrf.CsrfViewMiddleware', - 'django.contrib.auth.middleware.AuthenticationMiddleware', - 'django.contrib.messages.middleware.MessageMiddleware',) - -A tuple of middleware classes to use. See :doc:`/topics/http/middleware`. - -.. versionchanged:: 1.2 - ``'django.contrib.messages.middleware.MessageMiddleware'`` was added to the - default. For more information, see the :doc:`messages documentation - </ref/contrib/messages>`. - -.. setting:: MONTH_DAY_FORMAT - -MONTH_DAY_FORMAT ----------------- - -Default: ``'F j'`` - -The default formatting to use for date fields on Django admin change-list -pages -- and, possibly, by other parts of the system -- in cases when only the -month and day are displayed. - -For example, when a Django admin change-list page is being filtered by a date -drilldown, the header for a given day displays the day and month. Different -locales have different formats. For example, U.S. English would say -"January 1," whereas Spanish might say "1 Enero." - -See :tfilter:`allowed date format strings <date>`. See also ``DATE_FORMAT``, -``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``YEAR_MONTH_FORMAT``. - -.. setting:: NUMBER_GROUPING - -NUMBER_GROUPING ----------------- - -.. versionadded:: 1.2 - -Default: ``0`` - -Number of digits grouped together on the integer part of a number. Common use -is to display a thousand separator. If this setting is ``0``, then, no grouping -will be applied to the number. If this setting is greater than ``0`` then the -setting :setting:`THOUSAND_SEPARATOR` will be used as the separator between those -groups. - -See also :setting:`THOUSAND_SEPARATOR` and :setting:`USE_THOUSAND_SEPARATOR`. - -.. setting:: PASSWORD_RESET_TIMEOUT_DAYS - -PASSWORD_RESET_TIMEOUT_DAYS ---------------------------- - -Default: ``3`` - -The number of days a password reset link is valid for. Used by the -:mod:`django.contrib.auth` password reset mechanism. - -.. setting:: PREPEND_WWW - -PREPEND_WWW ------------ - -Default: ``False`` - -Whether to prepend the "www." subdomain to URLs that don't have it. This is only -used if :class:`~django.middleware.common.CommonMiddleware` is installed -(see :doc:`/topics/http/middleware`). See also :setting:`APPEND_SLASH`. - -.. setting:: PROFANITIES_LIST - -PROFANITIES_LIST ----------------- - -A tuple of profanities, as strings, that will trigger a validation error when -the ``hasNoProfanities`` validator is called. - -We don't list the default values here, because that would be profane. To see -the default values, see the file `django/conf/global_settings.py`_. - -.. _django/conf/global_settings.py: http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py - -.. setting:: RESTRUCTUREDTEXT_FILTER_SETTINGS - -RESTRUCTUREDTEXT_FILTER_SETTINGS --------------------------------- - -Default: ``{}`` - -A dictionary containing settings for the ``restructuredtext`` markup filter from -the :doc:`django.contrib.markup application </ref/contrib/markup>`. They override -the default writer settings. See the Docutils restructuredtext `writer settings -docs`_ for details. - -.. _writer settings docs: http://docutils.sourceforge.net/docs/user/config.html#html4css1-writer - -.. setting:: ROOT_URLCONF - -ROOT_URLCONF ------------- - -Default: Not defined - -A string representing the full Python import path to your root URLconf. For example: -``"mydjangoapps.urls"``. Can be overridden on a per-request basis by -setting the attribute ``urlconf`` on the incoming ``HttpRequest`` -object. See :ref:`how-django-processes-a-request` for details. - -.. setting:: SECRET_KEY - -SECRET_KEY ----------- - -Default: ``''`` (Empty string) - -A secret key for this particular Django installation. Used to provide a seed in -secret-key hashing algorithms. Set this to a random string -- the longer, the -better. ``django-admin.py startproject`` creates one automatically. - -.. setting:: SEND_BROKEN_LINK_EMAILS - -SEND_BROKEN_LINK_EMAILS ------------------------ - -Default: ``False`` - -Whether to send an e-mail to the ``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 ``IGNORABLE_404_STARTS``, -``IGNORABLE_404_ENDS`` 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 e-mail address that error messages come from, such as those sent to -``ADMINS`` and ``MANAGERS``. - -.. setting:: SESSION_COOKIE_AGE - -SESSION_COOKIE_AGE ------------------- - -Default: ``1209600`` (2 weeks, in seconds) - -The age of session cookies, in seconds. See :doc:`/topics/http/sessions`. - -.. setting:: SESSION_COOKIE_DOMAIN - -SESSION_COOKIE_DOMAIN ---------------------- - -Default: ``None`` - -The domain to use for session cookies. Set this to a string such as -``".lawrence.com"`` for cross-domain cookies, or use ``None`` for a standard -domain cookie. See the :doc:`/topics/http/sessions`. - -.. setting:: SESSION_COOKIE_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 ``LANGUAGE_COOKIE_NAME``). See the :doc:`/topics/http/sessions`. - -.. setting:: SESSION_COOKIE_PATH - -SESSION_COOKIE_PATH -------------------- - -.. versionadded:: 1.0 - -Default: ``'/'`` - -The path set on the session cookie. This should either match the URL path of your -Django installation or be parent of that path. - -This is useful if you have multiple Django instances running under the same -hostname. They can use different cookie paths, and each instance will only see -its own session cookie. - -.. setting:: SESSION_COOKIE_SECURE - -SESSION_COOKIE_SECURE ---------------------- - -Default: ``False`` - -Whether to use a secure cookie for the session cookie. If this is set to -``True``, the cookie will be marked as "secure," which means browsers may -ensure that the cookie is only sent under an HTTPS connection. -See the :doc:`/topics/http/sessions`. - -.. setting:: SESSION_ENGINE - -SESSION_ENGINE --------------- - -.. versionadded:: 1.0 - -.. versionchanged:: 1.1 - The ``cached_db`` backend was added - -Default: ``django.contrib.sessions.backends.db`` - -Controls where Django stores session data. Valid values are: - - * ``'django.contrib.sessions.backends.db'`` - * ``'django.contrib.sessions.backends.file'`` - * ``'django.contrib.sessions.backends.cache'`` - * ``'django.contrib.sessions.backends.cached_db'`` - -See :doc:`/topics/http/sessions`. - -.. setting:: SESSION_EXPIRE_AT_BROWSER_CLOSE - -SESSION_EXPIRE_AT_BROWSER_CLOSE -------------------------------- - -Default: ``False`` - -Whether to expire the session when the user closes his or her browser. -See the :doc:`/topics/http/sessions`. - -.. setting:: SESSION_FILE_PATH - -SESSION_FILE_PATH ------------------ - -.. versionadded:: 1.0 - -Default: ``None`` - -If you're using file-based session storage, this sets the directory in -which Django will store session data. See :doc:`/topics/http/sessions`. When -the default value (``None``) is used, Django will use the standard temporary -directory for the system. - -.. setting:: SESSION_SAVE_EVERY_REQUEST - -SESSION_SAVE_EVERY_REQUEST --------------------------- - -Default: ``False`` - -Whether to save the session data on every request. See -:doc:`/topics/http/sessions`. - -.. setting:: SHORT_DATE_FORMAT - -SHORT_DATE_FORMAT ------------------ - -.. versionadded:: 1.2 - -Default: ``m/d/Y`` (e.g. ``12/31/2003``) - -An available formatting that can be used for displaying date fields on -templates. Note that if :setting:`USE_L10N` is set to ``True``, then the -corresponding locale-dictated format has higher precedence and will be applied. -See :tfilter:`allowed date format strings <date>`. - -See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``. - -.. setting:: SHORT_DATETIME_FORMAT - -SHORT_DATETIME_FORMAT ---------------------- - -.. versionadded:: 1.2 - -Default: ``m/d/Y P`` (e.g. ``12/31/2003 4 p.m.``) - -An available formatting that can be used for displaying datetime fields on -templates. Note that if :setting:`USE_L10N` is set to ``True``, then the -corresponding locale-dictated format has higher precedence and will be applied. -See :tfilter:`allowed date format strings <date>`. - -See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``. - -.. 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:: 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.contrib.messages.context_processors.messages") - -A tuple of callables that are used to populate the context in ``RequestContext``. -These callables take a request object as their argument and return a dictionary -of items to be merged into the context. - -.. versionchanged:: 1.2 - ``"django.contrib.messages.context_processors.messages"`` was added to the - default. For more information, see the :doc:`messages documentation - </ref/contrib/messages>`. - -.. versionchanged:: 1.2 - The auth context processor was moved in this release from its old location - ``django.core.context_processors.auth`` to - ``django.contrib.auth.context_processors.auth``. - -.. setting:: TEMPLATE_DEBUG - -TEMPLATE_DEBUG --------------- - -Default: ``False`` - -A boolean that turns on/off template debug mode. If this is ``True``, the fancy -error page will display a detailed report for any ``TemplateSyntaxError``. This -report contains the relevant snippet of the template, with the appropriate line -highlighted. - -Note that Django only displays fancy error pages if ``DEBUG`` is ``True``, so -you'll want to set that to take advantage of this setting. - -See also ``DEBUG``. - -.. setting:: TEMPLATE_DIRS - -TEMPLATE_DIRS -------------- - -Default: ``()`` (Empty tuple) - -List of locations of the template source files, in search order. Note that -these paths should use Unix-style forward slashes, even on Windows. - -See :doc:`/topics/templates`. - -.. setting:: TEMPLATE_LOADERS - -TEMPLATE_LOADERS ----------------- - -Default:: - - ('django.template.loaders.filesystem.Loader', - 'django.template.loaders.app_directories.Loader') - -A tuple of template loader classes, specified as strings. Each ``Loader`` class -knows how to import templates from a particular source. Optionally, a tuple can be -used instead of a string. The first item in the tuple should be the ``Loader``'s -module, subsequent items are passed to the ``Loader`` during initialization. See -:doc:`/ref/templates/api`. - -.. setting:: TEMPLATE_STRING_IF_INVALID - -TEMPLATE_STRING_IF_INVALID --------------------------- - -Default: ``''`` (Empty string) - -Output, as a string, that the template system should use for invalid (e.g. -misspelled) variables. See :ref:`invalid-template-variables`.. - -.. setting:: TEST_RUNNER - -TEST_RUNNER ------------ - -Default: ``'django.test.simple.DjangoTestSuiteRunner'`` - -.. versionchanged:: 1.2 - Prior to 1.2, test runners were a function, not a class. - -The name of the class to use for starting the test suite. See -:doc:`/topics/testing`. - -.. _Testing Django Applications: ../testing/ - -.. setting:: THOUSAND_SEPARATOR - -THOUSAND_SEPARATOR ------------------- - -.. versionadded:: 1.2 - -Default ``,`` (Comma) - -Default thousand separator used when formatting numbers. This setting is -used only when ``NUMBER_GROUPING`` and ``USE_THOUSAND_SEPARATOR`` are set. - -See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and -:setting:`USE_THOUSAND_SEPARATOR`. - -.. setting:: TIME_FORMAT - -TIME_FORMAT ------------ - -Default: ``'P'`` (e.g. ``4 p.m.``) - -The default formatting to use for displaying time fields in any part of the -system. Note that if :setting:`USE_L10N` is set to ``True``, then the -locale-dictated format has higher precedence and will be applied instead. See -:tfilter:`allowed date format strings <date>`. - -.. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. - -See also ``DATE_FORMAT`` and ``DATETIME_FORMAT``. - -.. setting:: TIME_INPUT_FORMATS - -TIME_INPUT_FORMATS ------------------- - -.. versionadded:: 1.2 - -Default: ``('%H:%M:%S', '%H:%M')`` - -A tuple of formats that will be accepted when inputting data on a time -field. Formats will be tried in order, using the first valid. -Note that these format strings are specified in Python's datetime_ module -syntax, that is different from the one used by Django for formatting dates -to be displayed. - -See also ``DATE_INPUT_FORMATS`` and ``DATETIME_INPUT_FORMATS``. - -.. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior - -.. setting:: TIME_ZONE - -TIME_ZONE ---------- - -Default: ``'America/Chicago'`` - -.. versionchanged:: 1.2 - ``None`` was added as an allowed value. - -A string representing the time zone for this installation, or -``None``. `See available choices`_. (Note that list of available -choices lists more than one on the same line; you'll want to use just -one of the choices for a given time zone. For instance, one line says -``'Europe/London GB GB-Eire'``, but you should use the first bit of -that -- ``'Europe/London'`` -- as your ``TIME_ZONE`` setting.) - -Note that this is the time zone to which Django will convert all -dates/times -- not necessarily the timezone of the server. For -example, one server may serve multiple Django-powered sites, each with -a separate time-zone setting. - -Normally, Django sets the ``os.environ['TZ']`` variable to the time -zone you specify in the ``TIME_ZONE`` setting. Thus, all your views -and models will automatically operate in the correct time zone. -However, Django won't set the ``TZ`` environment variable under the -following conditions: - - * If you're using the manual configuration option as described in - :ref:`manually configuring settings - <settings-without-django-settings-module>`, or - - * If you specify ``TIME_ZONE = None``. This will cause Django to fall - back to using the system timezone. - -If Django doesn't set the ``TZ`` environment variable, it's up to you -to ensure your processes are running in the correct environment. - -.. note:: - Django cannot reliably use alternate time zones in a Windows - environment. If you're running Django on Windows, this variable - must be set to match the system timezone. - - -.. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE - -.. setting:: URL_VALIDATOR_USER_AGENT - -URL_VALIDATOR_USER_AGENT ------------------------- - -Default: ``Django/<version> (http://www.djangoproject.com/)`` - -The string to use as the ``User-Agent`` header when checking to see if URLs -exist (see the ``verify_exists`` option on :class:`~django.db.models.URLField`). - -.. setting:: USE_ETAGS - -USE_ETAGS ---------- - -Default: ``False`` - -A boolean that specifies whether to output the "Etag" header. This saves -bandwidth but slows down performance. This is only used if ``CommonMiddleware`` -is installed (see :doc:`/topics/http/middleware`). - -.. setting:: USE_I18N - -USE_I18N --------- - -Default: ``True`` - -A boolean that specifies whether Django's internationalization system should be -enabled. This provides an easy way to turn it off, for performance. If this is -set to ``False``, Django will make some optimizations so as not to load the -internationalization machinery. - -See also ``USE_L10N`` - -.. setting:: USE_L10N - -USE_L10N --------- - -.. versionadded:: 1.2 - -Default ``False`` - -A boolean that specifies if data will be localized by default or not. If this -is set to ``True``, e.g. Django will display numbers and dates using the -format of the current locale. - -See also ``USE_I18N`` and ``LANGUAGE_CODE`` - -.. setting:: USE_THOUSAND_SEPARATOR - -USE_THOUSAND_SEPARATOR ----------------------- - -.. versionadded:: 1.2 - -Default ``False`` - -A boolean that specifies wheter to display numbers using a thousand separator. -If this is set to ``True``, Django will use values from ``THOUSAND_SEPARATOR`` -and ``NUMBER_GROUPING`` from current locale, to format the number. -``USE_L10N`` must be set to ``True``, in order to format numbers. - -See also ``THOUSAND_SEPARATOR`` and ``NUMBER_GROUPING``. - -.. setting:: YEAR_MONTH_FORMAT - -YEAR_MONTH_FORMAT ------------------ - -Default: ``'F Y'`` - -The default formatting to use for date fields on Django admin change-list -pages -- and, possibly, by other parts of the system -- in cases when only the -year and month are displayed. - -For example, when a Django admin change-list page is being filtered by a date -drilldown, the header for a given month displays the month and the year. -Different locales have different formats. For example, U.S. English would say -"January 2006," whereas another locale might say "2006/January." - -See :tfilter:`allowed date format strings <date>`. See also ``DATE_FORMAT``, -``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``. - -Deprecated settings -=================== - -.. setting:: DATABASE_ENGINE - -DATABASE_ENGINE ---------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`ENGINE` in - :setting:`DATABASES`. - -.. setting:: DATABASE_HOST - -DATABASE_HOST -------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`HOST` in - :setting:`DATABASES`. - -.. setting:: DATABASE_NAME - -DATABASE_NAME -------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`NAME` in - :setting:`DATABASES`. - -.. setting:: DATABASE_OPTIONS - -DATABASE_OPTIONS ----------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`OPTIONS` in - :setting:`DATABASES`. - -.. setting:: DATABASE_PASSWORD - -DATABASE_PASSWORD ------------------ - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`PASSWORD` in - :setting:`DATABASES`. - -.. setting:: DATABASE_PORT - -DATABASE_PORT -------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`PORT` in - :setting:`DATABASES`. - -.. setting:: DATABASE_USER - -DATABASE_USER -------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`USER` in - :setting:`DATABASES`. - -.. setting:: TEST_DATABASE_CHARSET - -TEST_DATABASE_CHARSET ---------------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`TEST_CHARSET` in - :setting:`DATABASES`. - -.. setting:: TEST_DATABASE_COLLATION - -TEST_DATABASE_COLLATION ------------------------ - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`TEST_COLLATION` in - :setting:`DATABASES`. - -.. setting:: TEST_DATABASE_NAME - -TEST_DATABASE_NAME ------------------- - -.. deprecated:: 1.2 - This setting has been replaced by :setting:`TEST_NAME` in - :setting:`DATABASES`. - |