Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed #15992 -- Added more references to settings. Thanks, aaugustin.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16290 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information...
commit 49f57a5d28c175b24c215e6329f5fc12a5cccc34 1 parent 61da3cc
@jezdez jezdez authored
Showing with 215 additions and 199 deletions.
  1. +3 −3 docs/faq/admin.txt
  2. +8 −7 docs/faq/models.txt
  3. +1 −1  docs/howto/i18n.txt
  4. +1 −1  docs/internals/contributing/writing-code/unit-tests.txt
  5. +3 −3 docs/internals/deprecation.txt
  6. +1 −1  docs/ref/contrib/admin/index.txt
  7. +1 −1  docs/ref/contrib/gis/geoip.txt
  8. +5 −5 docs/ref/contrib/gis/install.txt
  9. +2 −2 docs/ref/contrib/index.txt
  10. +1 −1  docs/ref/contrib/messages.txt
  11. +4 −4 docs/ref/databases.txt
  12. +15 −14 docs/ref/django-admin.txt
  13. +1 −1  docs/ref/forms/fields.txt
  14. +9 −9 docs/ref/generic-views.txt
  15. +82 −73 docs/ref/settings.txt
  16. +18 −14 docs/ref/templates/builtins.txt
  17. +2 −2 docs/ref/utils.txt
  18. +10 −10 docs/releases/1.0-porting-guide.txt
  19. +2 −2 docs/releases/1.2.txt
  20. +1 −1  docs/releases/1.3-alpha-1.txt
  21. +4 −4 docs/releases/1.3.txt
  22. +1 −1  docs/topics/cache.txt
  23. +2 −2 docs/topics/email.txt
  24. +4 −4 docs/topics/http/file-uploads.txt
  25. +10 −10 docs/topics/http/sessions.txt
  26. +1 −1  docs/topics/http/views.txt
  27. +11 −10 docs/topics/i18n/deployment.txt
  28. +5 −5 docs/topics/i18n/internationalization.txt
  29. +1 −1  docs/topics/logging.txt
  30. +1 −1  docs/topics/settings.txt
  31. +2 −2 docs/topics/templates.txt
  32. +3 −3 docs/topics/testing.txt
View
6 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.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
View
15 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::
View
2  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 ``<language>/LC_MESSAGES/django.(po|mo)``
* ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)`` --
deprecated, see above.
View
2  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
View
6 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
View
2  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/`` ::
View
2  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
View
10 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.
View
4 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
View
2  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 </ref/settings>`
for more information on how this works and why you might need to set it.
View
8 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
View
29 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 ``<appname>/fixtures/foo/bar/mydata.json`` for each installed
application, ``<dirname>/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
=================================
View
2  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
View
18 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:**
View
155 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 <date>`.
.. 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 <date>`.
.. 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 <date>`. See also ``DATE_FORMAT``,
-``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``YEAR_MONTH_FORMAT``.
+See :tfilter:`allowed date format strings <date>`. See also
+:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`,
+:setting:`TIME_FORMAT` and :setting:`YEAR_MONTH_FORMAT`.
.. setting:: NUMBER_GROUPING
@@ -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 <date>`.
-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 <date>`.
-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 <date>`.
.. 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 <date>`. See also ``DATE_FORMAT``,
-``DATETIME_FORMAT``, ``TIME_FORMAT`` and ``MONTH_DAY_FORMAT``.
+See :tfilter:`allowed date format strings <date>`. See also
+:setting:`DATE_FORMAT`, :setting:`DATETIME_FORMAT`, :setting:`TIME_FORMAT`
+and :setting:`MONTH_DAY_FORMAT`.
Deprecated settings
===================
View
32 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`.
View
4 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)
View
20 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 <LOGIN_URL>`.
@@ -454,11 +454,11 @@ LOGIN_URL`` refer to :setting:`settings.LOGIN_URL <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 ``<app>`` in the code below with each app's name:
View
4 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 <translation string>` 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
<format-localization>` infrastructure that allows localizers to specify that
information in a ``formats.py`` file in the corresponding
``django/conf/locale/<locale name>/`` directory.
View
2  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
View
8 docs/releases/1.3.txt
@@ -264,8 +264,8 @@ The GeoDjango test suite is now included when
:ref:`running the Django test suite <running-unit-tests>` with ``runtests.py``
when using :ref:`spatial database backends <spatial-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.
View
2  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',
View
4 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
View
8 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
View
20 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
View
2  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.
View
21 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
View
10 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
----------------------------------------
View
2  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::
View
2  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
View
4 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
=======
View
6 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::
Please sign in to comment.
Something went wrong with that request. Please try again.