diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt index ac2e594ed2..32cea67479 100644 --- a/docs/faq/admin.txt +++ b/docs/faq/admin.txt @@ -8,8 +8,8 @@ The login cookie isn't being set correctly, because the domain of the cookie sent out by Django doesn't match the domain in your browser. Try these two things: - * Set the ``SESSION_COOKIE_DOMAIN`` setting in your admin config file - to match your domain. For example, if you're going to + * Set the :setting:`SESSION_COOKIE_DOMAIN` setting in your admin config + file to match your domain. For example, if you're going to "http://www.example.com/admin/" in your browser, in "myproject.settings" you should set ``SESSION_COOKIE_DOMAIN = 'www.example.com'``. @@ -17,7 +17,7 @@ things: don't have dots in them. If you're running the admin site on "localhost" or another domain that doesn't have a dot in it, try going to "localhost.localdomain" or "127.0.0.1". And set - ``SESSION_COOKIE_DOMAIN`` accordingly. + :setting:`SESSION_COOKIE_DOMAIN` accordingly. I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error. ----------------------------------------------------------------------------------------------------------------------------------------------------------- diff --git a/docs/faq/models.txt b/docs/faq/models.txt index 5911d9f487..6699bfe2be 100644 --- a/docs/faq/models.txt +++ b/docs/faq/models.txt @@ -6,16 +6,17 @@ FAQ: Databases and models How can I see the raw SQL queries Django is running? ---------------------------------------------------- -Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do -this:: +Make sure your Django :setting:`DEBUG` setting is set to ``True``. +Then, just do this:: >>> from django.db import connection >>> connection.queries [{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date FROM polls_polls', 'time': '0.002'}] -``connection.queries`` is only available if ``DEBUG`` is ``True``. It's a list -of dictionaries in order of query execution. Each dictionary has the following:: +``connection.queries`` is only available if :setting:`DEBUG` is ``True``. +It's a list of dictionaries in order of query execution. Each dictionary has +the following:: ``sql`` -- The raw SQL statement ``time`` -- How long the statement took to execute, in seconds. @@ -89,13 +90,13 @@ Why is Django leaking memory? Django isn't known to leak memory. If you find your Django processes are allocating more and more memory, with no sign of releasing it, check to make -sure your ``DEBUG`` setting is set to ``False``. If ``DEBUG`` is ``True``, then -Django saves a copy of every SQL statement it has executed. +sure your :setting:`DEBUG` setting is set to ``False``. If :setting:`DEBUG` +is ``True``, then Django saves a copy of every SQL statement it has executed. (The queries are saved in ``django.db.connection.queries``. See `How can I see the raw SQL queries Django is running?`_.) -To fix the problem, set ``DEBUG`` to ``False``. +To fix the problem, set :setting:`DEBUG` to ``False``. If you need to clear the query list manually at any point in your functions, just call ``reset_queries()``, like this:: diff --git a/docs/howto/i18n.txt b/docs/howto/i18n.txt index 37439ae5a2..4a056d07f8 100644 --- a/docs/howto/i18n.txt +++ b/docs/howto/i18n.txt @@ -55,7 +55,7 @@ message file specific to the project you are composing. The choice is yours. All message file repositories are structured the same way. They are: - * All paths listed in ``LOCALE_PATHS`` in your settings file are + * All paths listed in :setting:`LOCALE_PATHS` in your settings file are searched for ``/LC_MESSAGES/django.(po|mo)`` * ``$PROJECTPATH/locale//LC_MESSAGES/django.(po|mo)`` -- deprecated, see above. diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index fd9024e1a9..926a7d85af 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -85,7 +85,7 @@ details for each database: You will also need to ensure that your database uses UTF-8 as the default character set. If your database server doesn't use UTF-8 as a default charset, -you will need to include a value for ``TEST_CHARSET`` in the settings +you will need to include a value for :setting:`TEST_CHARSET` in the settings dictionary for the applicable database. Running only some of the tests diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 95114fb78b..01e4500178 100644 --- a/docs/internals/deprecation.txt +++ b/docs/internals/deprecation.txt @@ -170,9 +170,9 @@ their deprecation, as per the :ref:`Django deprecation policy and :class:`django.contrib.auth.context_processors.PermLookupDict`, respectively. - * The ``MEDIA_URL`` or ``STATIC_URL`` settings are required to end - with a trailing slash to ensure there is a consistent way to - combine paths in templates. + * The :setting:`MEDIA_URL` or :setting:`STATIC_URL` settings are + required to end with a trailing slash to ensure there is a consistent + way to combine paths in templates. * 1.6 * The compatibility modules ``django.utils.copycompat`` and diff --git a/docs/ref/contrib/admin/index.txt b/docs/ref/contrib/admin/index.txt index 8c7a69ceaf..e5aecb4622 100644 --- a/docs/ref/contrib/admin/index.txt +++ b/docs/ref/contrib/admin/index.txt @@ -1765,7 +1765,7 @@ In this example, we register the default ``AdminSite`` instance ) Above we used ``admin.autodiscover()`` to automatically load the -``INSTALLED_APPS`` admin.py modules. +:setting:`INSTALLED_APPS` admin.py modules. In this example, we register the ``AdminSite`` instance ``myproject.admin.admin_site`` at the URL ``/myadmin/`` :: diff --git a/docs/ref/contrib/gis/geoip.txt b/docs/ref/contrib/gis/geoip.txt index 784d69eb53..6503be7c3f 100644 --- a/docs/ref/contrib/gis/geoip.txt +++ b/docs/ref/contrib/gis/geoip.txt @@ -18,7 +18,7 @@ the GeoIP C libary and either the GeoIP `Country`__ or `City`__ datasets in binary format (the CSV files will not work!). These datasets may be `downloaded from MaxMind`__. Grab the ``GeoIP.dat.gz`` and ``GeoLiteCity.dat.gz`` and unzip them in a directory corresponding to what you set -``GEOIP_PATH`` with in your settings. See the example and reference below +:setting:`GEOIP_PATH` with in your settings. See the example and reference below for more details. __ http://www.maxmind.com/app/c diff --git a/docs/ref/contrib/gis/install.txt b/docs/ref/contrib/gis/install.txt index 8b785b8741..82df82793c 100644 --- a/docs/ref/contrib/gis/install.txt +++ b/docs/ref/contrib/gis/install.txt @@ -184,9 +184,9 @@ If using a binary package of GEOS (e.g., on Ubuntu), you may need to :ref:`binut ~~~~~~~~~~~~~~~~~~~~~ If your GEOS library is in a non-standard location, or you don't want to -modify the system's library path then the :setting:`GEOS_LIBRARY_PATH` setting -may be added to your Django settings file with the full path to the GEOS -C library. For example:: +modify the system's library path then the :setting:`GEOS_LIBRARY_PATH` +setting may be added to your Django settings file with the full path to the +GEOS C library. For example:: GEOS_LIBRARY_PATH = '/home/bob/local/lib/libgeos_c.so' @@ -592,8 +592,8 @@ Now, the ``spatialite`` command can be used to initialize a spatial database:: __ http://www.gaia-gis.it/spatialite/resources.html -Add ``django.contrib.gis`` to ``INSTALLED_APPS`` ------------------------------------------------- +Add ``django.contrib.gis`` to :setting:`INSTALLED_APPS` +------------------------------------------------------- Like other Django contrib applications, you will *only* need to add :mod:`django.contrib.gis` to :setting:`INSTALLED_APPS` in your settings. diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt index 56ac9fd136..f62c8fc36e 100644 --- a/docs/ref/contrib/index.txt +++ b/docs/ref/contrib/index.txt @@ -14,8 +14,8 @@ those packages have. For most of these add-ons -- specifically, the add-ons that include either models or template tags -- you'll need to add the package name (e.g., - ``'django.contrib.admin'``) to your ``INSTALLED_APPS`` setting and re-run - ``manage.py syncdb``. + ``'django.contrib.admin'``) to your :setting:`INSTALLED_APPS` setting and + re-run ``manage.py syncdb``. .. _"batteries included" philosophy: http://docs.python.org/tutorial/stdlib.html#batteries-included diff --git a/docs/ref/contrib/messages.txt b/docs/ref/contrib/messages.txt index a23faef54d..ceead9d23c 100644 --- a/docs/ref/contrib/messages.txt +++ b/docs/ref/contrib/messages.txt @@ -386,7 +386,7 @@ SESSION_COOKIE_DOMAIN Default: ``None`` The storage backends that use cookies -- ``CookieStorage`` and -``FallbackStorage`` -- use the value of ``SESSION_COOKIE_DOMAIN`` in +``FallbackStorage`` -- use the value of :setting:`SESSION_COOKIE_DOMAIN` in setting their cookies. See the :doc:`settings documentation ` for more information on how this works and why you might need to set it. diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt index 82c780cb0f..8d8e1e8154 100644 --- a/docs/ref/databases.txt +++ b/docs/ref/databases.txt @@ -262,8 +262,8 @@ Connection settings are used in this order: :setting:`HOST`, :setting:`PORT` 3. MySQL option files. -In other words, if you set the name of the database in ``OPTIONS``, -this will take precedence over ``NAME``, which would override +In other words, if you set the name of the database in :setting:`OPTIONS`, +this will take precedence over :setting:`NAME`, which would override anything in a `MySQL option file`_. Here's a sample configuration which uses a MySQL option file:: @@ -574,7 +574,7 @@ Your Django settings.py file should look something like this for Oracle:: If you don't use a ``tnsnames.ora`` file or a similar naming method that recognizes the SID ("xe" in this example), then fill in both -``HOST`` and ``PORT`` like so:: +:setting:`HOST` and :setting:`PORT` like so:: DATABASES = { 'default': { @@ -587,7 +587,7 @@ recognizes the SID ("xe" in this example), then fill in both } } -You should supply both ``HOST`` and ``PORT``, or leave both +You should supply both :setting:`HOST` and :setting:`PORT`, or leave both as empty strings. Threaded option diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt index f7fd2d9a7d..6aac4ced92 100644 --- a/docs/ref/django-admin.txt +++ b/docs/ref/django-admin.txt @@ -57,7 +57,7 @@ App names --------- Many commands take a list of "app names." An "app name" is the basename of -the package containing your models. For example, if your ``INSTALLED_APPS`` +the package containing your models. For example, if your :setting:`INSTALLED_APPS` contains the string ``'mysite.blog'``, the app name is ``blog``. Determining the version @@ -126,7 +126,7 @@ dbshell Runs the command-line client for the database engine specified in your ``ENGINE`` setting, with the connection parameters specified in your -``USER``, ``PASSWORD``, etc., settings. +:setting:`USER`, :setting:`PASSWORD`, etc., settings. * For PostgreSQL, this runs the ``psql`` command-line client. * For MySQL, this runs the ``mysql`` command-line client. @@ -151,8 +151,9 @@ Displays differences between the current settings file and Django's default settings. Settings that don't appear in the defaults are followed by ``"###"``. For -example, the default settings don't define ``ROOT_URLCONF``, so -``ROOT_URLCONF`` is followed by ``"###"`` in the output of ``diffsettings``. +example, the default settings don't define :setting:`ROOT_URLCONF`, so +:setting:`ROOT_URLCONF` is followed by ``"###"`` in the output of +``diffsettings``. Note that Django's default settings live in ``django/conf/global_settings.py``, if you're ever curious to see the full list of defaults. @@ -245,7 +246,7 @@ inspectdb .. django-admin:: inspectdb Introspects the database tables in the database pointed-to by the -``NAME`` setting and outputs a Django model module (a ``models.py`` +:setting:`NAME` setting and outputs a Django model module (a ``models.py`` file) to standard output. Use this if you have a legacy database with which you'd like to use Django. @@ -309,7 +310,7 @@ fixture can be distributed over multiple directories, in multiple applications. Django will search in three locations for fixtures: 1. In the ``fixtures`` directory of every installed application - 2. In any directory named in the ``FIXTURE_DIRS`` setting + 2. In any directory named in the :setting:`FIXTURE_DIRS` setting 3. In the literal path named by the fixture Django will load any and all fixtures it finds in these locations that match @@ -340,7 +341,7 @@ directories will be included in the search path. For example:: would search ``/fixtures/foo/bar/mydata.json`` for each installed application, ``/foo/bar/mydata.json`` for each directory in -``FIXTURE_DIRS``, and the literal path ``foo/bar/mydata.json``. +:setting:`FIXTURE_DIRS`, and the literal path ``foo/bar/mydata.json``. When fixture files are processed, the data is saved to the database as is. Model defined ``save`` methods and ``pre_save`` signals are not called. @@ -742,7 +743,7 @@ Serving static files with the development server ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By default, the development server doesn't serve any static files for your site -(such as CSS files, images, things under ``MEDIA_URL`` and so forth). If +(such as CSS files, images, things under :setting:`MEDIA_URL` and so forth). If you want to configure Django to serve static media, read :doc:`/howto/static-files`. shell @@ -912,13 +913,13 @@ syncdb .. django-admin:: syncdb -Creates the database tables for all apps in ``INSTALLED_APPS`` whose tables -have not already been created. +Creates the database tables for all apps in :setting:`INSTALLED_APPS` whose +tables have not already been created. Use this command when you've added new applications to your project and want to install them in the database. This includes any apps shipped with Django that -might be in ``INSTALLED_APPS`` by default. When you start a new project, run -this command to install the default apps. +might be in :setting:`INSTALLED_APPS` by default. When you start a new project, +run this command to install the default apps. .. admonition:: Syncdb will not alter existing tables @@ -1032,8 +1033,8 @@ validate .. django-admin:: validate -Validates all installed models (according to the ``INSTALLED_APPS`` setting) -and prints validation errors to standard output. +Validates all installed models (according to the :setting:`INSTALLED_APPS` +setting) and prints validation errors to standard output. Commands provided by applications ================================= diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt index 3bc0659c3d..96f1be949b 100644 --- a/docs/ref/forms/fields.txt +++ b/docs/ref/forms/fields.txt @@ -764,7 +764,7 @@ Takes the following optional arguments: .. attribute:: URLField.validator_user_agent String used as the user-agent used when checking for a URL's existence. - Defaults to the value of the ``URL_VALIDATOR_USER_AGENT`` setting. + Defaults to the value of the :setting:`URL_VALIDATOR_USER_AGENT` setting. .. versionchanged:: 1.2 The URLField previously did not recognize URLs as valid that contained an IDN diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt index 54114d07a6..a787869c2b 100644 --- a/docs/ref/generic-views.txt +++ b/docs/ref/generic-views.txt @@ -58,7 +58,7 @@ which is a dictionary of the parameters captured in the URL. just before rendering the template. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. **Example:** @@ -198,7 +198,7 @@ a date in the *future* are not included unless you set ``allow_future`` to the view's template. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -290,7 +290,7 @@ to ``True``. this is ``False``. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -377,7 +377,7 @@ date in the *future* are not displayed unless you set ``allow_future`` to determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -465,7 +465,7 @@ in the *future* are not displayed unless you set ``allow_future`` to ``True``. determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -550,7 +550,7 @@ you set ``allow_future`` to ``True``. determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -660,7 +660,7 @@ future, the view will throw a 404 error by default, unless you set to use in the template context. By default, this is ``'object'``. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. * ``allow_future``: A boolean specifying whether to include "future" objects on this page, where "future" means objects in which the field @@ -738,7 +738,7 @@ A page representing a list of objects. determining the variable's name. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. **Template name:** @@ -852,7 +852,7 @@ A page representing an individual object. to use in the template context. By default, this is ``'object'``. * ``mimetype``: The MIME type to use for the resulting document. Defaults - to the value of the ``DEFAULT_CONTENT_TYPE`` setting. + to the value of the :setting:`DEFAULT_CONTENT_TYPE` setting. **Template name:** diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index 4716fabea7..60448d2c26 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -86,7 +86,7 @@ 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')``, +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. @@ -102,7 +102,7 @@ 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 +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`. @@ -634,9 +634,9 @@ locale-dictated format has higher precedence and will be applied instead. See :tfilter:`allowed date format strings `. .. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. + This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. -See also ``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATE_FORMAT``. +See also :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATE_FORMAT`. .. setting:: DATE_INPUT_FORMATS @@ -657,7 +657,7 @@ 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``. +See also :setting:`DATETIME_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`. .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior @@ -674,9 +674,9 @@ locale-dictated format has higher precedence and will be applied instead. See :tfilter:`allowed date format strings `. .. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. + This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. -See also ``DATE_FORMAT``, ``TIME_FORMAT`` and ``SHORT_DATETIME_FORMAT``. +See also :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. .. setting:: DATETIME_INPUT_FORMATS @@ -697,7 +697,7 @@ 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``. +See also :setting:`DATE_INPUT_FORMATS` and :setting:`TIME_INPUT_FORMATS`. .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior @@ -720,11 +720,12 @@ 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. +It is also important to remember that when running with :setting:`DEBUG` +turned on, Django will remember every SQL query it executes. This is useful +when you are debugging, but on a production server, it will rapidly consume +memory. -Never deploy a site into production with ``DEBUG`` turned on. +Never deploy a site into production with :setting:`DEBUG` turned on. .. _django/views/debug.py: http://code.djangoproject.com/browser/django/trunk/django/views/debug.py @@ -757,7 +758,7 @@ 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 +manually specified. Used with :setting:`DEFAULT_CONTENT_TYPE` to construct the ``Content-Type`` header. .. setting:: DEFAULT_CONTENT_TYPE @@ -768,8 +769,8 @@ 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. +isn't manually specified. Used with :setting:`DEFAULT_CHARSET` to construct +the ``Content-Type`` header. .. setting:: DEFAULT_FILE_STORAGE @@ -855,7 +856,7 @@ Default: ``'localhost'`` The host to use for sending email. -See also ``EMAIL_PORT``. +See also :setting:`EMAIL_PORT`. .. setting:: EMAIL_HOST_PASSWORD @@ -864,12 +865,12 @@ 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. +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 ``EMAIL_HOST_USER``. +See also :setting:`EMAIL_HOST_USER`. .. setting:: EMAIL_HOST_USER @@ -878,10 +879,10 @@ EMAIL_HOST_USER Default: ``''`` (Empty string) -Username to use for the SMTP server defined in ``EMAIL_HOST``. If empty, -Django won't attempt authentication. +Username to use for the SMTP server defined in :setting:`EMAIL_HOST`. +If empty, Django won't attempt authentication. -See also ``EMAIL_HOST_PASSWORD``. +See also :setting:`EMAIL_HOST_PASSWORD`. .. setting:: EMAIL_PORT @@ -890,7 +891,7 @@ EMAIL_PORT Default: ``25`` -Port to use for the SMTP server defined in ``EMAIL_HOST``. +Port to use for the SMTP server defined in :setting:`EMAIL_HOST`. .. setting:: EMAIL_SUBJECT_PREFIX @@ -1037,8 +1038,8 @@ 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 +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/ @@ -1048,10 +1049,12 @@ like:: __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``. +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 @@ -1100,7 +1103,7 @@ Default: ``()`` (Empty tuple) A tuple of IP addresses, as strings, that: - * See debug comments, when ``DEBUG`` is ``True`` + * See debug comments, when :setting:`DEBUG` is ``True`` * Receive X headers if the ``XViewMiddleware`` is installed (see :doc:`/topics/http/middleware`) @@ -1122,8 +1125,8 @@ 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 ``SESSION_COOKIE_NAME``). See +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 @@ -1147,12 +1150,13 @@ This specifies which languages are available for language selection. See 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. +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:: @@ -1167,7 +1171,7 @@ settings file:: 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. +``gettext()`` in any code that uses :setting:`LANGUAGES` at runtime. .. setting:: LOCALE_PATHS @@ -1263,7 +1267,7 @@ MANAGERS Default: ``()`` (Empty tuple) -A tuple in the same format as ``ADMINS`` that specifies who should get +A tuple in the same format as :setting:`ADMINS` that specifies who should get broken-link notifications when ``SEND_BROKEN_LINK_EMAILS=True``. .. setting:: MEDIA_ROOT @@ -1368,8 +1372,9 @@ drilldown, the header for a given day displays the day and month. Different locales have different formats. For example, U.S. English would say "January 1," whereas Spanish might say "1 Enero." -See :tfilter:`allowed date format strings `. See also ``DATE_FORMAT``, -``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``YEAR_MONTH_FORMAT``. +See :tfilter:`allowed date format strings `. See also +:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, +:setting:`TIME_FORMAT` and :setting:`YEAR_MONTH_FORMAT`. .. setting:: NUMBER_GROUPING @@ -1463,10 +1468,10 @@ SEND_BROKEN_LINK_EMAILS Default: ``False`` -Whether to send an email to the ``MANAGERS`` each time somebody visits a -Django-powered page that is 404ed with a non-empty referer (i.e., a broken +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 ``IGNORABLE_404_URLS`` and +:doc:`/topics/http/middleware`). See also :setting:`IGNORABLE_404_URLS` and :doc:`/howto/error-reporting`. .. setting:: SERIALIZATION_MODULES @@ -1490,7 +1495,7 @@ SERVER_EMAIL Default: ``'root@localhost'`` The email address that error messages come from, such as those sent to -``ADMINS`` and ``MANAGERS``. +:setting:`ADMINS` and :setting:`MANAGERS`. .. setting:: SESSION_COOKIE_AGE @@ -1539,7 +1544,8 @@ 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`. +should be different from :setting:`LANGUAGE_COOKIE_NAME`). +See the :doc:`/topics/http/sessions`. .. setting:: SESSION_COOKIE_PATH @@ -1629,7 +1635,7 @@ templates. Note that if :setting:`USE_L10N` is set to ``True``, then the corresponding locale-dictated format has higher precedence and will be applied. See :tfilter:`allowed date format strings `. -See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``. +See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. .. setting:: SHORT_DATETIME_FORMAT @@ -1645,7 +1651,7 @@ templates. Note that if :setting:`USE_L10N` is set to ``True``, then the corresponding locale-dictated format has higher precedence and will be applied. See :tfilter:`allowed date format strings `. -See also ``DATE_FORMAT`` and ``SHORT_DATETIME_FORMAT``. +See also :setting:`DATE_FORMAT` and :setting:`SHORT_DATETIME_FORMAT`. .. setting:: SIGNING_BACKEND @@ -1767,10 +1773,10 @@ 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 +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 ``DEBUG``. +See also :setting:`DEBUG`. .. setting:: TEMPLATE_DIRS @@ -1802,9 +1808,9 @@ module, subsequent items are passed to the ``Loader`` during initialization. See .. versionchanged:: 1.2 The class-based API for template loaders was introduced in Django 1.2 - although the ``TEMPLATE_LOADERS`` setting will accept strings that specify - function-based loaders until compatibility with them is completely removed in - Django 1.4. + although the :setting:`TEMPLATE_LOADERS` setting will accept strings + that specify function-based loaders until compatibility with them is + completely removed in Django 1.4. .. setting:: TEMPLATE_STRING_IF_INVALID @@ -1838,10 +1844,11 @@ THOUSAND_SEPARATOR .. versionadded:: 1.2 -Default ``,`` (Comma) +Default: ``,`` (Comma) Default thousand separator used when formatting numbers. This setting is -used only when ``NUMBER_GROUPING`` and ``USE_THOUSAND_SEPARATOR`` are set. +used only when :setting:`NUMBER_GROUPING` and :setting:`USE_THOUSAND_SEPARATOR` +are set. See also :setting:`NUMBER_GROUPING`, :setting:`DECIMAL_SEPARATOR` and :setting:`USE_THOUSAND_SEPARATOR`. @@ -1859,9 +1866,9 @@ locale-dictated format has higher precedence and will be applied instead. See :tfilter:`allowed date format strings `. .. versionchanged:: 1.2 - This setting can now be overriden by setting ``USE_L10N`` to ``True``. + This setting can now be overriden by setting :setting:`USE_L10N` to ``True``. -See also ``DATE_FORMAT`` and ``DATETIME_FORMAT``. +See also :setting:`DATE_FORMAT` and :setting:`DATETIME_FORMAT`. .. setting:: TIME_INPUT_FORMATS @@ -1878,7 +1885,7 @@ 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``. +See also :setting:`DATE_INPUT_FORMATS` and :setting:`DATETIME_INPUT_FORMATS`. .. _datetime: http://docs.python.org/library/datetime.html#strftime-strptime-behavior @@ -1897,7 +1904,7 @@ A string representing the time zone for this installation, or 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.) +that -- ``'Europe/London'`` -- as your :setting:`TIME_ZONE` setting.) Note that this is the time zone to which Django will convert all dates/times -- not necessarily the timezone of the server. For @@ -1905,7 +1912,7 @@ 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 +zone you specify in the :setting:`TIME_ZONE` setting. Thus, all your views and models will automatically operate in the correct time zone. However, Django won't set the ``TZ`` environment variable under the following conditions: @@ -1962,7 +1969,7 @@ 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`` +See also :setting:`USE_L10N` .. setting:: USE_L10N @@ -1971,13 +1978,13 @@ USE_L10N .. versionadded:: 1.2 -Default ``False`` +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`` +See also :setting:`USE_I18N` and :setting:`LANGUAGE_CODE` .. setting:: USE_THOUSAND_SEPARATOR @@ -1986,14 +1993,15 @@ USE_THOUSAND_SEPARATOR .. versionadded:: 1.2 -Default ``False`` +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. +If this is set to ``True``, Django will use values from +:setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING` from current +locale, to format the number. :setting:`USE_L10N` must be set to ``True``, +in order to format numbers. -See also ``THOUSAND_SEPARATOR`` and ``NUMBER_GROUPING``. +See also :setting:`THOUSAND_SEPARATOR` and :setting:`NUMBER_GROUPING`. .. setting:: YEAR_MONTH_FORMAT @@ -2011,8 +2019,9 @@ drilldown, the header for a given month displays the month and the year. Different locales have different formats. For example, U.S. English would say "January 2006," whereas another locale might say "2006/January." -See :tfilter:`allowed date format strings `. See also ``DATE_FORMAT``, -``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``. +See :tfilter:`allowed date format strings `. See also +:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT` +and :setting:`MONTH_DAY_FORMAT`. Deprecated settings =================== diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt index 4c8c0e6fe4..b70205952a 100644 --- a/docs/ref/templates/builtins.txt +++ b/docs/ref/templates/builtins.txt @@ -1307,10 +1307,11 @@ If ``value`` is a ``datetime`` object (e.g., the result of ``datetime.datetime.now()``), the output will be the string ``'Wed 09 Jan 2008'``. -The format passed can be one of the predefined ones ``DATE_FORMAT``, -``DATETIME_FORMAT``, ``SHORT_DATE_FORMAT`` or ``SHORT_DATETIME_FORMAT``, or a -custom format that uses the format specifiers shown in the table above. Note -that predefined formats may vary depending on the current locale. +The format passed can be one of the predefined ones :setting:`DATE_FORMAT`, +:setting:`DATETIME_FORMAT`, :setting:`SHORT_DATE_FORMAT` or +:setting:`SHORT_DATETIME_FORMAT`, or a custom format that uses the format +specifiers shown in the table above. Note that predefined formats may vary +depending on the current locale. Assuming that :setting:`USE_L10N` is ``True`` and :setting:`LANGUAGE_CODE` is, for example, ``"es"``, then for:: @@ -1941,9 +1942,9 @@ time Formats a time according to the given format. -Given format can be the predefined one ``TIME_FORMAT``, or a custom format, -same as the :tfilter:`date` filter. Note that the predefined format is locale- -dependant. +Given format can be the predefined one :setting:`TIME_FORMAT`, or a custom +format, same as the :tfilter:`date` filter. Note that the predefined format +is locale-dependant. The time filter will only accept parameters in the format string that relate to the time of day, not the date (for obvious reasons). If you need to @@ -2243,7 +2244,7 @@ Other tags and filter libraries ------------------------------- Django comes with a couple of other template-tag libraries that you have to -enable explicitly in your ``INSTALLED_APPS`` setting and enable in your +enable explicitly in your :setting:`INSTALLED_APPS` setting and enable in your template with the ``{% load %}`` tag. django.contrib.humanize @@ -2274,15 +2275,18 @@ i18n Provides a couple of templatetags that allow specifying translatable text in Django templates. It is slightly different from the libraries described -above because you don't need to add any application to the ``INSTALLED_APPS`` -setting but rather set :setting:`USE_I18N` to True, then loading it with -``{% load i18n %}``. See :ref:`specifying-translation-strings-in-template-code`. +above because you don't need to add any application to the +:setting:`INSTALLED_APPS` setting but rather set :setting:`USE_I18N` to True, +then loading it with ``{% load i18n %}``. + +See :ref:`specifying-translation-strings-in-template-code`. l10n ~~~~ Provides a couple of templatetags that allow control over the localization of values in Django templates. It is slightly different from the libraries described -above because you don't need to add any application to the ``INSTALLED_APPS``; -you only need to load the library using ``{% load l10n %}``. See -:ref:`topic-l10n-templates`. +above because you don't need to add any application to the :setting:`INSTALLED_APPS`; +you only need to load the library using ``{% load l10n %}``. + +See :ref:`topic-l10n-templates`. diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt index 6cf527c239..2b06548aa2 100644 --- a/docs/ref/utils.txt +++ b/docs/ref/utils.txt @@ -61,8 +61,8 @@ to distinguish caches by the ``Accept-language`` header. Each header is only added if it isn't already set. - ``cache_timeout`` is in seconds. The ``CACHE_MIDDLEWARE_SECONDS`` setting - is used by default. + ``cache_timeout`` is in seconds. The :setting:`CACHE_MIDDLEWARE_SECONDS` + setting is used by default. .. function:: add_never_cache_headers(response) diff --git a/docs/releases/1.0-porting-guide.txt b/docs/releases/1.0-porting-guide.txt index e12b34e6e4..45a0270dd7 100644 --- a/docs/releases/1.0-porting-guide.txt +++ b/docs/releases/1.0-porting-guide.txt @@ -443,10 +443,10 @@ The old :exc:`EnvironmentError` has split into an :exc:`ImportError` when Django fails to find the settings module and a :exc:`RuntimeError` when you try to reconfigure settings after having already used them -``LOGIN_URL`` has moved -~~~~~~~~~~~~~~~~~~~~~~~ +:setting:`LOGIN_URL` has moved +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The ``LOGIN_URL`` constant moved from ``django.contrib.auth`` into the +The :setting:`LOGIN_URL` constant moved from ``django.contrib.auth`` into the ``settings`` module. Instead of using ``from django.contrib.auth import LOGIN_URL`` refer to :setting:`settings.LOGIN_URL `. @@ -454,11 +454,11 @@ LOGIN_URL`` refer to :setting:`settings.LOGIN_URL `. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In 0.96, if a URL didn't end in a slash or have a period in the final -component of its path, and ``APPEND_SLASH`` was True, Django would redirect -to the same URL, but with a slash appended to the end. Now, Django checks to -see whether the pattern without the trailing slash would be matched by -something in your URL patterns. If so, no redirection takes place, because it -is assumed you deliberately wanted to catch that pattern. +component of its path, and :setting:`APPEND_SLASH` was True, Django would +redirect to the same URL, but with a slash appended to the end. Now, Django +checks to see whether the pattern without the trailing slash would be matched +by something in your URL patterns. If so, no redirection takes place, because +it is assumed you deliberately wanted to catch that pattern. For most people, this won't require any changes. Some people, though, have URL patterns that look like this:: @@ -548,8 +548,8 @@ need to reload your data. Do this after you have made the change to using **Back up your database first!** For SQLite, this means making a copy of the single file that stores the - database (the name of that file is the ``DATABASE_NAME`` in your settings.py - file). + database (the name of that file is the :setting:`DATABASE_NAME` in your + settings.py file). To upgrade each application to use a ``DecimalField``, you can do the following, replacing ```` in the code below with each app's name: diff --git a/docs/releases/1.2.txt b/docs/releases/1.2.txt index ef29c39794..1f32f15f9d 100644 --- a/docs/releases/1.2.txt +++ b/docs/releases/1.2.txt @@ -1076,8 +1076,8 @@ Up to version 1.1 Django used technical message IDs to provide localizers the possibility to translate date and time formats. They were translatable :term:`translation strings ` that could be recognized because they were all upper case (for example -``DATETIME_FORMAT``, ``DATE_FORMAT``, ``TIME_FORMAT``). They have been -deprecated in favor of the new :ref:`Format localization +:setting:`DATETIME_FORMAT`, :setting:`DATE_FORMAT`, :setting:`TIME_FORMAT`). +They have been deprecated in favor of the new :ref:`Format localization ` infrastructure that allows localizers to specify that information in a ``formats.py`` file in the corresponding ``django/conf/locale//`` directory. diff --git a/docs/releases/1.3-alpha-1.txt b/docs/releases/1.3-alpha-1.txt index ed2ba36fc8..e134cf1a28 100644 --- a/docs/releases/1.3-alpha-1.txt +++ b/docs/releases/1.3-alpha-1.txt @@ -249,7 +249,7 @@ framework, we have "fixed" the problem by making the list of prohibited words an empty list. If you want to restore the old behavior, simply put a -``PROFANITIES_LIST`` setting in your settings file that includes the +:setting:`PROFANITIES_LIST` setting in your settings file that includes the words that you want to prohibit (see the `commit that implemented this change`_ if you want to see the list of words that was historically prohibited). However, if avoiding profanities is important to you, you diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 562cd1f2d4..c2276f8fcf 100644 --- a/docs/releases/1.3.txt +++ b/docs/releases/1.3.txt @@ -264,8 +264,8 @@ The GeoDjango test suite is now included when :ref:`running the Django test suite ` with ``runtests.py`` when using :ref:`spatial database backends `. -``MEDIA_URL`` and ``STATIC_URL`` must end in a slash -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +:setting:`MEDIA_URL` and :setting:`STATIC_URL` must end in a slash +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Previously, the :setting:`MEDIA_URL` setting only required a trailing slash if it contained a suffix beyond the domain name. @@ -581,7 +581,7 @@ gettext domain): * Now it is possible to override the translations shipped with applications by using the :setting:`LOCALE_PATHS` setting whose translations have now higher - precedence than the translations of ``INSTALLED_APPS`` applications. + precedence than the translations of :setting:`INSTALLED_APPS` applications. The relative priority among the values listed in this setting has also been modified so the paths listed first have higher precedence than the ones listed later. @@ -589,7 +589,7 @@ gettext domain): * The ``locale`` subdirectory of the directory containing the settings, that usually coincides with and is know as the *project directory* is being deprecated in this release as a source of translations. (the precedence of - these translations is intermediate between applications and ``LOCALE_PATHS`` + these translations is intermediate between applications and :setting:`LOCALE_PATHS` translations). See the `corresponding deprecated features section`_ of this document. diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index 070c6699c8..0dbe8446b0 100644 --- a/docs/topics/cache.txt +++ b/docs/topics/cache.txt @@ -420,7 +420,7 @@ Once the cache is set up, the simplest way to use caching is to cache your entire site. You'll need to add ``'django.middleware.cache.UpdateCacheMiddleware'`` and ``'django.middleware.cache.FetchFromCacheMiddleware'`` to your -``MIDDLEWARE_CLASSES`` setting, as in this example:: +:setting:`MIDDLEWARE_CLASSES` setting, as in this example:: MIDDLEWARE_CLASSES = ( 'django.middleware.cache.UpdateCacheMiddleware', diff --git a/docs/topics/email.txt b/docs/topics/email.txt index bbb2c1f431..5979951ac4 100644 --- a/docs/topics/email.txt +++ b/docs/topics/email.txt @@ -509,8 +509,8 @@ Defining a custom email backend ------------------------------- If you need to change how emails are sent you can write your own email -backend. The ``EMAIL_BACKEND`` setting in your settings file is then the -Python import path for your backend class. +backend. The :setting:`EMAIL_BACKEND` setting in your settings file is then +the Python import path for your backend class. Custom email backends should subclass ``BaseEmailBackend`` that is located in the ``django.core.mail.backends.base`` module. A custom email backend must diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt index af4ab6423a..532695334a 100644 --- a/docs/topics/http/file-uploads.txt +++ b/docs/topics/http/file-uploads.txt @@ -225,8 +225,8 @@ Upload Handlers When a user uploads a file, Django passes off the file data to an *upload handler* -- a small class that handles file data as it gets uploaded. Upload -handlers are initially defined in the ``FILE_UPLOAD_HANDLERS`` setting, which -defaults to:: +handlers are initially defined in the :setting:`FILE_UPLOAD_HANDLERS` setting, +which defaults to:: ("django.core.files.uploadhandler.MemoryFileUploadHandler", "django.core.files.uploadhandler.TemporaryFileUploadHandler",) @@ -246,8 +246,8 @@ Modifying upload handlers on the fly Sometimes particular views require different upload behavior. In these cases, you can override upload handlers on a per-request basis by modifying ``request.upload_handlers``. By default, this list will contain the upload -handlers given by ``FILE_UPLOAD_HANDLERS``, but you can modify the list as you -would any other list. +handlers given by :setting:`FILE_UPLOAD_HANDLERS`, but you can modify the list +as you would any other list. For instance, suppose you've written a ``ProgressBarUploadHandler`` that provides feedback on upload progress to some sort of AJAX widget. You'd add this diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt index 1fd6a5c031..8529f5362d 100644 --- a/docs/topics/http/sessions.txt +++ b/docs/topics/http/sessions.txt @@ -23,7 +23,7 @@ To enable session functionality, do the following: has ``SessionMiddleware`` activated. If you don't want to use sessions, you might as well remove the -``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and +``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and ``'django.contrib.sessions'`` from your :setting:`INSTALLED_APPS`. It'll save you a small bit of overhead. @@ -39,7 +39,7 @@ Using database-backed sessions ------------------------------ If you want to use a database-backed session, you need to add -``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting. +``'django.contrib.sessions'`` to your :setting:`INSTALLED_APPS` setting. Once you have configured your installation, run ``manage.py syncdb`` to install the single database table that stores session data. @@ -359,8 +359,8 @@ setting to ``True``. When set to ``True``, Django will save the session to the database on every single request. Note that the session cookie is only sent when a session has been created or -modified. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, the session cookie -will be sent on every request. +modified. If :setting:`SESSION_SAVE_EVERY_REQUEST` is ``True``, the session +cookie will be sent on every request. Similarly, the ``expires`` part of a session cookie is updated each time the session cookie is sent. @@ -372,15 +372,15 @@ You can control whether the session framework uses browser-length sessions vs. persistent sessions with the :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` setting. -By default, ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``False``, which -means session cookies will be stored in users' browsers for as long as +By default, :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``False``, +which means session cookies will be stored in users' browsers for as long as :setting:`SESSION_COOKIE_AGE`. Use this if you don't want people to have to log in every time they open a browser. -If ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``True``, Django will use -browser-length cookies -- cookies that expire as soon as the user closes his or -her browser. Use this if you want people to have to log in every time they open -a browser. +If :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` is set to ``True``, Django will +use browser-length cookies -- cookies that expire as soon as the user closes +his or her browser. Use this if you want people to have to log in every time +they open a browser. This setting is a global default and can be overwritten at a per-session level by explicitly calling the :meth:`~backends.base.SessionBase.set_expiry` method diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt index cfdd00817b..99359ab4ad 100644 --- a/docs/topics/http/views.txt +++ b/docs/topics/http/views.txt @@ -48,7 +48,7 @@ Let's step through this code one line at a time: .. admonition:: Django's Time Zone - Django includes a ``TIME_ZONE`` setting that defaults to + Django includes a :setting:`TIME_ZONE` setting that defaults to ``America/Chicago``. This probably isn't where you live, so you might want to change it in your settings file. diff --git a/docs/topics/i18n/deployment.txt b/docs/topics/i18n/deployment.txt index 75dfd879ab..f06fa5e191 100644 --- a/docs/topics/i18n/deployment.txt +++ b/docs/topics/i18n/deployment.txt @@ -13,7 +13,7 @@ use internationalization, you should take the two seconds to set optimizations so as not to load the internationalization machinery. You'll probably also want to remove ``'django.core.context_processors.i18n'`` -from your ``TEMPLATE_CONTEXT_PROCESSORS`` setting. +from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting. .. note:: @@ -47,22 +47,22 @@ Django uses this language as the default translation -- the final attempt if no other translator finds a translation. If all you want to do is run Django with your native language, and a language -file is available for it, all you need to do is set ``LANGUAGE_CODE``. +file is available for it, all you need to do is set :setting:`LANGUAGE_CODE`. If you want to let each individual user specify which language he or she prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language selection based on data from the request. It customizes content for each user. To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'`` -to your ``MIDDLEWARE_CLASSES`` setting. Because middleware order matters, you -should follow these guidelines: +to your :setting:`MIDDLEWARE_CLASSES` setting. Because middleware order +matters, you should follow these guidelines: * Make sure it's one of the first middlewares installed. * It should come after ``SessionMiddleware``, because ``LocaleMiddleware`` makes use of session data. * If you use ``CacheMiddleware``, put ``LocaleMiddleware`` after it. -For example, your ``MIDDLEWARE_CLASSES`` might look like this:: +For example, your :setting:`MIDDLEWARE_CLASSES` might look like this:: MIDDLEWARE_CLASSES = ( 'django.contrib.sessions.middleware.SessionMiddleware', @@ -81,7 +81,7 @@ following this algorithm: * Failing that, it looks for a cookie. - The name of the cookie used is set by the ``LANGUAGE_COOKIE_NAME`` + The name of the cookie used is set by the :setting:`LANGUAGE_COOKIE_NAME` setting. (The default name is ``django_language``.) * Failing that, it looks at the ``Accept-Language`` HTTP header. This @@ -89,7 +89,7 @@ following this algorithm: prefer, in order by priority. Django tries each language in the header until it finds one with available translations. - * Failing that, it uses the global ``LANGUAGE_CODE`` setting. + * Failing that, it uses the global :setting:`LANGUAGE_CODE` setting. .. _locale-middleware-notes: @@ -107,7 +107,7 @@ Notes: * Only languages listed in the :setting:`LANGUAGES` setting can be selected. If you want to restrict the language selection to a subset of provided languages (because your application doesn't provide all those languages), - set ``LANGUAGES`` to a list of languages. For example:: + set :setting:`LANGUAGES` to a list of languages. For example:: LANGUAGES = ( ('de', _('German')), @@ -118,7 +118,7 @@ Notes: selection to German and English (and any sublanguage, like de-ch or en-us). - * If you define a custom ``LANGUAGES`` setting, as explained in the + * If you define a custom :setting:`LANGUAGES` setting, as explained in the previous bullet, it's OK to mark the languages as translation strings -- but use a "dummy" ``ugettext()`` function, not the one in ``django.utils.translation``. You should *never* import @@ -139,7 +139,8 @@ Notes: 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* ``ugettext()`` in any code that uses ``LANGUAGES`` at runtime. + *real* ``ugettext()`` in any code that uses :setting:`LANGUAGES` at + runtime. * The ``LocaleMiddleware`` can only select languages for which there is a Django-provided base translation. If you want to provide translations diff --git a/docs/topics/i18n/internationalization.txt b/docs/topics/i18n/internationalization.txt index c9da4c36da..d4c436e39a 100644 --- a/docs/topics/i18n/internationalization.txt +++ b/docs/topics/i18n/internationalization.txt @@ -674,9 +674,9 @@ You hook it up like this:: ) Each string in ``packages`` should be in Python dotted-package syntax (the -same format as the strings in ``INSTALLED_APPS``) and should refer to a package -that contains a ``locale`` directory. If you specify multiple packages, all -those catalogs are merged into one catalog. This is useful if you have +same format as the strings in :setting:`INSTALLED_APPS`) and should refer to a +package that contains a ``locale`` directory. If you specify multiple packages, +all those catalogs are merged into one catalog. This is useful if you have JavaScript that uses strings from different applications. The precedence of translations is such that the packages appearing later in the @@ -707,8 +707,8 @@ the ones appearing first having higher precedence than the ones appearing later. .. versionchanged:: 1.3 - Directories listed in ``LOCALE_PATHS`` weren't included in the lookup - algorithm until version 1.3. + Directories listed in :setting:`LOCALE_PATHS` weren't included in the + lookup algorithm until version 1.3. Using the JavaScript translation catalog ---------------------------------------- diff --git a/docs/topics/logging.txt b/docs/topics/logging.txt index 3507793765..651a92ff34 100644 --- a/docs/topics/logging.txt +++ b/docs/topics/logging.txt @@ -486,7 +486,7 @@ Python logging module. The ``include_html`` argument of ``AdminEmailHandler`` is used to control whether the traceback email includes an HTML attachment containing the full content of the debug Web page that would have been - produced if ``DEBUG`` were ``True``. To set this value in your + produced if :setting:`DEBUG` were ``True``. To set this value in your configuration, include it in the handler definition for ``django.utils.log.AdminEmailHandler``, like this:: diff --git a/docs/topics/settings.txt b/docs/topics/settings.txt index 6d96190a90..61ddf8cf32 100644 --- a/docs/topics/settings.txt +++ b/docs/topics/settings.txt @@ -209,7 +209,7 @@ provides the default settings as the ``default_settings`` argument (or as the first positional argument) in the call to ``configure()``. In this example, default settings are taken from ``myapp_defaults``, and the -``DEBUG`` setting is set to ``True``, regardless of its value in +:setting:`DEBUG` setting is set to ``True``, regardless of its value in ``myapp_defaults``:: from django.conf import settings diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt index 3f56c9ea01..80cfafd614 100644 --- a/docs/topics/templates.txt +++ b/docs/topics/templates.txt @@ -101,8 +101,8 @@ In the above example, ``{{ section.title }}`` will be replaced with the ``title`` attribute of the ``section`` object. If you use a variable that doesn't exist, the template system will insert -the value of the ``TEMPLATE_STRING_IF_INVALID`` setting, which is set to ``''`` -(the empty string) by default. +the value of the :setting:`TEMPLATE_STRING_IF_INVALID` setting, which is set +to ``''`` (the empty string) by default. Filters ======= diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt index 07049fddb1..3f25dfff9f 100644 --- a/docs/topics/testing.txt +++ b/docs/topics/testing.txt @@ -383,7 +383,7 @@ entirely!). If you want to use a different database name, specify Aside from using a separate database, the test runner will otherwise use all of the same database settings you have in your settings file: :setting:`ENGINE`, :setting:`USER`, :setting:`HOST`, etc. The test -database is created by the user specified by ``USER``, so you'll need +database is created by the user specified by :setting:`USER`, so you'll need to make sure that the given user account has sufficient privileges to create a new database on the system. @@ -1309,8 +1309,8 @@ In order to provide a reliable URL space for your test, ``django.test.TestCase`` provides the ability to customize the URLconf configuration for the duration of the execution of a test suite. If your ``TestCase`` instance defines an ``urls`` attribute, the ``TestCase`` will use -the value of that attribute as the ``ROOT_URLCONF`` for the duration of that -test. +the value of that attribute as the :setting:`ROOT_URLCONF` for the duration +of that test. For example::