Context Navigation

Back to Ticket #9502

Ticket #9502: xref-markup-settings-r9330.diff

File xref-markup-settings-r9330.diff, 45.2 KB (added by Ramiro Morales, 17 years ago)

docs/faq/admin.txt

diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt

-              a
 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
+    * 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'``.
 …
       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.
 -----------------------------------------------------------------------------------------------------------------------------------------------------------

docs/faq/models.txt

diff --git a/docs/faq/models.txt b/docs/faq/models.txt

-              a
 How can I see the raw SQL queries Django is running?
 ----------------------------------------------------
 Make sure your Django ``DEBUG`` setting is set to ``True``. Then, just do
+Make sure your Django :setting:`DEBUG` setting is set to ``True``. Then, just do
 this::
     >>> from django.db import connection
 …
     [{'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
+``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
 …
 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 ``True``. If ``DEBUG`` is ``True``, then
+sure your :setting:`DEBUG` setting is set to ``True``. 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::

docs/howto/deployment/fastcgi.txt

diff --git a/docs/howto/deployment/fastcgi.txt b/docs/howto/deployment/fastcgi.txt

-              a
 In the cases where Django cannot work out the prefix correctly and where you
 want the original value to be used in URLs, you can set the
 ``FORCE_SCRIPT_NAME`` setting in your main ``settings`` file. This sets the
+:setting:`FORCE_SCRIPT_NAME` setting in your main ``settings`` file. This sets the
 script name uniformly for every URL served via that settings file. Thus you'll
 need to use different settings files if you want different sets of URLs to
 have different script names in this case, but that is a rare situation.

docs/internals/contributing.txt

diff --git a/docs/internals/contributing.txt b/docs/internals/contributing.txt

-              a
     ./runtests.py --settings=path.to.django.settings
 Yes, the unit tests need a settings module, but only for database connection
 info, with the ``DATABASE_ENGINE`` setting.
+info, with the :setting:`DATABASE_ENGINE` setting.
 If you're using the ``sqlite3`` database backend, no further settings are
 needed. A temporary database will be created in memory when running the tests.
 …
 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_DATABASE_CHARSET`` in your settings
+you will need to include a value for :setting:`TEST_DATABASE_CHARSET` in your settings
 file.
 If you want to run the full suite of tests, you'll need to install a number of

docs/intro/tutorial01.txt

diff --git a/docs/intro/tutorial01.txt b/docs/intro/tutorial01.txt

-              a
     * :setting:`DATABASE_NAME` -- The name of your database. If you're using
       SQLite, the database will be a file on your computer; in that case,
       ``DATABASE_NAME`` should be the full absolute path, including filename, of
+      :setting:`DATABASE_NAME` should be the full absolute path, including filename, of
       that file. If the file doesn't exist, it will automatically be created
       when you synchronize the database for the first time (see below).

docs/ref/contrib/admin.txt

diff --git a/docs/ref/contrib/admin.txt b/docs/ref/contrib/admin.txt

-              a
 There are five steps in activating the Django admin site:
 . Add ``django.contrib.admin`` to your ``INSTALLED_APPS`` setting.
+. Add ``django.contrib.admin`` to your :setting:`INSTALLED_APPS` setting.
 . Determine which of your application's models should be editable in the
        admin interface.
 …
+            }
             js = ("my_code.js",)
 Keep in mind that this will be prepended with ``MEDIA_URL``. The same rules
+Keep in mind that this will be prepended with :setting:`MEDIA_URL`. The same rules
 apply as :ref:`regular media definitions on forms <topics-forms-media>`.
 Adding custom validation to the admin
 …
 In order to override one or more of them, first create an ``admin`` directory in
 your project's ``templates`` directory. This can be any of the directories you
 specified in ``TEMPLATE_DIRS``.
+specified in :setting:`TEMPLATE_DIRS`.
 Within this ``admin`` directory, create sub-directories named after your app.
 Within these app subdirectories create sub-directories named after your models.
 …
+    )
 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/`` ::

docs/ref/contrib/comments/settings.txt

diff --git a/docs/ref/contrib/comments/settings.txt b/docs/ref/contrib/comments/settings.txt

-              a
 COMMENTS_APP
 ------------
 The app (i.e. entry in ``INSTALLED_APPS``) responsible for all "business logic."
+The app (i.e. entry in :setting:`INSTALLED_APPS`) responsible for all "business logic."
 You can change this to provide custom comment models and forms, though this is
 currently undocumented.

docs/ref/contrib/index.txt

diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt

-              a
     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
+    ``'django.contrib.admin'``) to your :setting:`INSTALLED_APPS` setting and re-run
     ``manage.py syncdb``.
 .. _"batteries included" philosophy: http://docs.python.org/tut/node12.html#batteries-included

docs/ref/databases.txt

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt

-              a
        :setting:`DATABASE_PORT`
 . MySQL option files.
 In other words, if you set the name of the database in ``DATABASE_OPTIONS``,
 this will take precedence over ``DATABASE_NAME``, which would override
+In other words, if you set the name of the database in :setting:`DATABASE_OPTIONS`,
+this will take precedence over :setting:`DATABASE_NAME`, which would override
 anything in a `MySQL option file`_.
 Here's a sample configuration which uses a MySQL option file::

docs/ref/django-admin.txt

diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt

-              a
 ---------
 Many subcommands 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
 …
 .. django-admin:: dbshell
 Runs the command-line client for the database engine specified in your
 ``DATABASE_ENGINE`` setting, with the connection parameters specified in your
 ``DATABASE_USER``, ``DATABASE_PASSWORD``, etc., settings.
+:setting:`DATABASE_ENGINE` setting, with the connection parameters specified in your
+:setting:`DATABASE_USER`, :setting:`DATABASE_PASSWORD`, etc., settings.
     * For PostgreSQL, this runs the ``psql`` command-line client.
     * For MySQL, this runs the ``mysql`` command-line client.
 …
 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.
 …
 The behavior of this command has changed in the Django development version.
 Previously, this command cleared *every* table in the database, including any
 table that Django didn't know about (i.e., tables that didn't have associated
 models and/or weren't in ``INSTALLED_APPS``). Now, the command only clears
+models and/or weren't in :setting:`INSTALLED_APPS`). Now, the command only clears
 tables that are represented by Django models and are activated in
 ``INSTALLED_APPS``.
+:setting:`INSTALLED_APPS`.
 .. django-admin-option:: --noinput
 …
 ---------
 Introspects the database tables in the database pointed-to by the
 ``DATABASE_NAME`` setting and outputs a Django model module (a ``models.py``
+:setting:`DATABASE_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.
 …
 Django will search in three locations for fixtures:
 . In the ``fixtures`` directory of every installed application
 . In any directory named in the ``FIXTURE_DIRS`` setting
+. In any directory named in the :setting:`FIXTURE_DIRS` setting
 . In the literal path named by the fixture
 Django will load any and all fixtures it finds in these locations that match
 …
 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``.
 Note that the order in which fixture files are processed is undefined. However,
 all fixture data is installed as a single transaction, so data in
 …
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 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 :ref:`howto-static-files`.
 Turning off auto-reload
 …
 syncdb
 ------
 Creates the database tables for all apps in ``INSTALLED_APPS`` whose tables
+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
+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
 …
 validate
 --------
 Validates all installed models (according to the ``INSTALLED_APPS`` setting)
+Validates all installed models (according to the :setting:`INSTALLED_APPS` setting)
 and prints validation errors to standard output.
 Default options

docs/ref/forms/fields.txt

diff --git a/docs/ref/forms/fields.txt b/docs/ref/forms/fields.txt

-              a
 .. 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.
 Slightly complex built-in ``Field`` classes
 -------------------------------------------

docs/ref/generic-views.txt

diff --git a/docs/ref/generic-views.txt b/docs/ref/generic-views.txt

-              a
       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:**
 …
       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
 …
       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
 …
       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
 …
       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
 …
       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
 …
       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
 …
       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:**
 …
       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:**

docs/ref/request-response.txt

diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt

-              a
     .. versionadded:: 1.0
     A string representing the current encoding used to decode form submission
     data (or ``None``, which means the ``DEFAULT_CHARSET`` setting is used).
+    data (or ``None``, which means the :setting:`DEFAULT_CHARSET` setting is used).
     You can write to this attribute to change the encoding used when accessing
     the form data. Any subsequent attribute accesses (such as reading from
     ``GET`` or ``POST``) will use the new ``encoding`` value.  Useful if you
     know the form data is not in the ``DEFAULT_CHARSET`` encoding.
+    know the form data is not in the :setting:`DEFAULT_CHARSET` encoding.
 .. attribute:: HttpRequest.GET
 …
     Not defined by Django itself, but will be read if other code (e.g., a custom
     middleware class) sets it. When present, this will be used as the root
     URLconf for the current request, overriding the ``ROOT_URLCONF`` setting.
+    URLconf for the current request, overriding the :setting:`ROOT_URLCONF` setting.
     See :ref:`how-django-processes-a-request` for details.
 Methods
 …
 .. method:: HttpResponse.__init__(content='', mimetype=None, status=200, content_type=DEFAULT_CONTENT_TYPE)
     Instantiates an ``HttpResponse`` object with the given page content (a
     string) and MIME type. The ``DEFAULT_CONTENT_TYPE`` is ``'text/html'``.
+    string) and MIME type. The :setting:`DEFAULT_CONTENT_TYPE` is ``'text/html'``.
     ``content`` can be an iterator or a string. If it's an iterator, it should
     return strings, and those strings will be joined together to form the
 …
     encoding, which makes it more than just a MIME type specification.
     If ``mimetype`` is specified (not ``None``), that value is used.
     Otherwise, ``content_type`` is used. If neither is given, the
     ``DEFAULT_CONTENT_TYPE`` setting is used.
+    :setting:`DEFAULT_CONTENT_TYPE` setting is used.
 .. method:: HttpResponse.__setitem__(header, value)

docs/ref/templates/builtins.txt

diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt

-              a
 ===============================
 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

docs/topics/cache.txt

diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt

-              a
 or directly in memory. This is an important decision that affects your cache's
 performance; yes, some cache types are faster than others.
 Your cache preference goes in the ``CACHE_BACKEND`` setting in your settings
+Your cache preference goes in the :setting:`CACHE_BACKEND` setting in your settings
 file. Here's an explanation of all available values for CACHE_BACKEND.
 Memcached
 …
       (http://www.danga.com/memcached/) and get the Python bindings from the
       "Client APIs" section.
 To use Memcached with Django, set ``CACHE_BACKEND`` to
+To use Memcached with Django, set :setting:`CACHE_BACKEND` to
 ``memcached://ip:port/``, where ``ip`` is the IP address of the Memcached
 daemon and ``port`` is the port on which Memcached is running.
 …
 One excellent feature of Memcached is its ability to share cache over multiple
 servers. To take advantage of this feature, include all server addresses in
 ``CACHE_BACKEND``, separated by semicolons. In this example, the cache is
+:setting:`CACHE_BACKEND`, separated by semicolons. In this example, the cache is
 shared over Memcached instances running on IP address 172.19.26.240 and
 .19.26.242, both on port 11211::
 …
 in your database that is in the proper format that Django's database-cache
 system expects.
 Once you've created that database table, set your ``CACHE_BACKEND`` setting to
+Once you've created that database table, set your :setting:`CACHE_BACKEND` setting to
 ``"db://tablename"``, where ``tablename`` is the name of the database table.
 In this example, the cache table's name is ``my_cache_table``::
 …
 ------------------
 To store cached items on a filesystem, use the ``"file://"`` cache type for
 ``CACHE_BACKEND``. For example, to store cached data in ``/var/tmp/django_cache``,
+:setting:`CACHE_BACKEND`. For example, to store cached data in ``/var/tmp/django_cache``,
 use this setting::
     CACHE_BACKEND = 'file:///var/tmp/django_cache'
 …
 If you want the speed advantages of in-memory caching but don't have the
 capability of running Memcached, consider the local-memory cache backend. This
 cache is multi-process and thread-safe. To use it, set ``CACHE_BACKEND`` to
+cache is multi-process and thread-safe. To use it, set :setting:`CACHE_BACKEND` to
 ``"locmem:///"``. For example::
     CACHE_BACKEND = 'locmem:///'
 …
 various places but a development/test environment on which you don't want to
 cache. As a result, your development environment won't use caching and your
 production environment still will. To activate dummy caching, set
 ``CACHE_BACKEND`` like so::
+:setting:`CACHE_BACKEND` like so::
     CACHE_BACKEND = 'dummy:///'
 …
 While Django includes support for a number of cache backends out-of-the-box,
 sometimes you might want to use a customized cache backend. To use an external
 cache backend with Django, use a Python import path as the scheme portion (the
 part before the initial colon) of the ``CACHE_BACKEND`` URI, like so::
+part before the initial colon) of the :setting:`CACHE_BACKEND` URI, like so::
     CACHE_BACKEND = 'path.to.backend://'
 …
 -----------------------
 All caches may take arguments. They're given in query-string style on the
 ``CACHE_BACKEND`` setting. Valid arguments are:
+:setting:`CACHE_BACKEND` setting. Valid arguments are:
     timeout
         Default timeout, in seconds, to use for the cache. Defaults to 5
 …
 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',
 …
 Then, add the following required settings to your Django settings file:
 * ``CACHE_MIDDLEWARE_SECONDS`` -- The number of seconds each page should be
+* :setting:`CACHE_MIDDLEWARE_SECONDS` -- The number of seconds each page should be
   cached.
 * ``CACHE_MIDDLEWARE_KEY_PREFIX`` -- If the cache is shared across multiple
+* :setting:`CACHE_MIDDLEWARE_KEY_PREFIX` -- If the cache is shared across multiple
   sites using the same Django installation, set this to the name of the site,
   or some other string that is unique to this Django instance, to prevent key
   collisions. Use an empty string if you don't care.
 The cache middleware caches every page that doesn't have GET or POST
 parameters. Optionally, if the ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is
+parameters. Optionally, if the :setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY` setting is
 ``True``, only anonymous requests (i.e., not those made by a logged-in user)
 will be cached. This is a simple and effective way of disabling caching for any
 user-specific pages (include Django's admin interface). Note that if you use
 ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY``, you should make sure you've activated
+:setting:`CACHE_MIDDLEWARE_ANONYMOUS_ONLY`, you should make sure you've activated
 ``AuthenticationMiddleware``.
 Additionally, the cache middleware automatically sets a few headers in each
 …
 * Sets the ``Last-Modified`` header to the current date/time when a fresh
   (uncached) version of the page is requested.
 * Sets the ``Expires`` header to the current date/time plus the defined
   ``CACHE_MIDDLEWARE_SECONDS``.
+  :setting:`CACHE_MIDDLEWARE_SECONDS`.
 * Sets the ``Cache-Control`` header to give a max age for the page -- again,
   from the ``CACHE_MIDDLEWARE_SECONDS`` setting.
+  from the :setting:`CACHE_MIDDLEWARE_SECONDS` setting.
 See :ref:`topics-http-middleware` for more on middleware.
 …
 If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in
 its ``Cache-Control`` header) then the page will be cached until the expiry
 time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in
+time, rather than :setting:`CACHE_MIDDLEWARE_SECONDS`. Using the decorators in
 ``django.views.decorators.cache`` you can easily set a view's expiry time
 (using the ``cache_control`` decorator) or disable caching for a view (using
 the ``never_cache`` decorator). See the `using other headers`__ section for
 …
 API to store objects in the cache with any level of granularity you like.
 The cache API is simple. The cache module, ``django.core.cache``, exports a
 ``cache`` object that's automatically created from the ``CACHE_BACKEND``
+``cache`` object that's automatically created from the :setting:`CACHE_BACKEND`
 setting::
     >>> from django.core.cache import cache
 …
     'hello, world!'
 The ``timeout_seconds`` argument is optional and defaults to the ``timeout``
 argument in the ``CACHE_BACKEND`` setting (explained above).
+argument in the :setting:`CACHE_BACKEND` setting (explained above).
 If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::
 …
 For explanation of Cache-Control HTTP directives, see the `Cache-Control spec`_.
 (Note that the caching middleware already sets the cache header's max-age with
 the value of the ``CACHE_MIDDLEWARE_SETTINGS`` setting. If you use a custom
+the value of the :setting:`CACHE_MIDDLEWARE_SETTINGS` setting. If you use a custom
 ``max_age`` in a ``cache_control`` decorator, the decorator will take
 precedence, and the header values will be merged correctly.)
 …
 ===========================
 If you use caching middleware, it's important to put each half in the right
 place within the ``MIDDLEWARE_CLASSES`` setting. That's because the cache
+place within the :setting:`MIDDLEWARE_CLASSES` setting. That's because the cache
 middleware needs to know which headers by which to vary the cache storage.
 Middleware always adds something to the ``Vary`` response header when it can.

docs/topics/db/transactions.txt

diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt

-              a
 transactions.
 To activate this feature, just add the ``TransactionMiddleware`` middleware to
 your ``MIDDLEWARE_CLASSES`` setting::
+your :setting:`MIDDLEWARE_CLASSES` setting::
     MIDDLEWARE_CLASSES = (
         'django.contrib.sessions.middleware.SessionMiddleware',
 …
 =================================================
 Control freaks can totally disable all transaction management by setting
 ``DISABLE_TRANSACTION_MANAGEMENT`` to ``True`` in the Django settings file.
+:setting:`DISABLE_TRANSACTION_MANAGEMENT` to ``True`` in the Django settings file.
 If you do this, Django won't provide any automatic transaction management
 whatsoever. Middleware will no longer implicitly commit transactions, and

docs/topics/email.txt

diff --git a/docs/topics/email.txt b/docs/topics/email.txt

-              a
       possible exceptions, all of which are subclasses of ``SMTPException``.
     * ``auth_user``: The optional username to use to authenticate to the SMTP
       server. If this isn't provided, Django will use the value of the
       ``EMAIL_HOST_USER`` setting.
+      :setting:`EMAIL_HOST_USER` setting.
     * ``auth_password``: The optional password to use to authenticate to the
       SMTP server. If this isn't provided, Django will use the value of the
       ``EMAIL_HOST_PASSWORD`` setting.
+      :setting:`EMAIL_HOST_PASSWORD` setting.
 .. _smtplib docs: http://docs.python.org/library/smtplib.html

docs/topics/files.txt

diff --git a/docs/topics/files.txt b/docs/topics/files.txt

-              a
 ======================  ===================================================
 ``location``            Optional. Absolute path to the directory that will
                         hold the files. If omitted, it will be set to the
                         value of your ``MEDIA_ROOT`` setting.
+                        value of your :setting:`MEDIA_ROOT` setting.
 ``base_url``            Optional. URL that serves the files stored at this
                         location. If omitted, it will default to the value
                         of your ``MEDIA_URL`` setting.
+                        of your :setting:`MEDIA_URL` setting.
 ======================  ===================================================
 For example, the following code will store uploaded files under
 ``/media/photos`` regardless of what your ``MEDIA_ROOT`` setting is::
+``/media/photos`` regardless of what your :setting:`MEDIA_ROOT` setting is::
     from django.db import models
     from django.core.files.storage import FileSystemStorage

docs/topics/http/file-uploads.txt

diff --git a/docs/topics/http/file-uploads.txt b/docs/topics/http/file-uploads.txt

-              a
 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
+handlers are initially defined in the :setting:`FILE_UPLOAD_HANDLERS` setting, which
 defaults to::
     ("django.core.files.uploadhandler.MemoryFileUploadHandler",
 …
 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
+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

docs/topics/http/sessions.txt

diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt

-              a
 To enable session functionality, do the following:
     * Edit the ``MIDDLEWARE_CLASSES`` setting and make sure
       ``MIDDLEWARE_CLASSES`` contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
+    * Edit the :setting:`MIDDLEWARE_CLASSES` setting and make sure
+      :setting:`MIDDLEWARE_CLASSES` contains ``'django.contrib.sessions.middleware.SessionMiddleware'``.
       The default ``settings.py`` created by ``django-admin.py startproject`` has
       ``SessionMiddleware`` activated.
     * Add ``'django.contrib.sessions'`` to your ``INSTALLED_APPS`` setting,
+    * Add ``'django.contrib.sessions'`` to your :setting:`INSTALLED_APPS` setting,
       and run ``manage.py syncdb`` to install the single database table
       that stores session data.
 …
    see `configuring the session engine`_.
 If you don't want to use sessions, you might as well remove the
 ``SessionMiddleware`` line from ``MIDDLEWARE_CLASSES`` and ``'django.contrib.sessions'``
 from your ``INSTALLED_APPS``. It'll save you a small bit of overhead.
+``SessionMiddleware`` line from :setting:`MIDDLEWARE_CLASSES` and ``'django.contrib.sessions'``
+from your :setting:`INSTALLED_APPS`. It'll save you a small bit of overhead.
 Configuring the session engine
 ==============================
 …
 Using file-based sessions
 -------------------------
 To use file-based sessions, set the ``SESSION_ENGINE`` setting to
+To use file-based sessions, set the :setting:`SESSION_ENGINE` setting to
 ``"django.contrib.sessions.backends.file"``.
 You might also want to set the ``SESSION_FILE_PATH`` setting (which defaults
+You might also want to set the :setting:`SESSION_FILE_PATH` setting (which defaults
 to output from ``tempfile.gettempdir()``, most likely ``/tmp``) to control
 where Django stores session files. Be sure to check that your Web server has
 permissions to read and write to this location.
 …
 Using cache-based sessions
 --------------------------
 To store session data using Django's cache system, set ``SESSION_ENGINE``
+To store session data using Django's cache system, set :setting:`SESSION_ENGINE`
 to ``"django.contrib.sessions.backends.cache"``. You'll want to make sure
 you've configured your cache; see the :ref:`cache documentation <topics-cache>` for details.
 …
     request.session.modified = True
 To change this default behavior, set the ``SESSION_SAVE_EVERY_REQUEST`` setting
 to ``True``. If ``SESSION_SAVE_EVERY_REQUEST`` is ``True``, Django will save
+To change this default behavior, set the :setting:`SESSION_SAVE_EVERY_REQUEST` setting
+to ``True``. If :setting:`SESSION_SAVE_EVERY_REQUEST` is ``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
+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
 …
 ===============================================
 You can control whether the session framework uses browser-length sessions vs.
 persistent sessions with the ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` setting.
+persistent sessions with the :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` setting.
 By default, ``SESSION_EXPIRE_AT_BROWSER_CLOSE`` is set to ``False``, which
+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
 ``SESSION_COOKIE_AGE``. Use this if you don't want people to have to log in
+: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
+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.

docs/topics/http/urls.txt

diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt

-              a
 algorithm the system follows to determine which Python code to execute:
 . Django determines the root URLconf module to use. Ordinarily,
        this is the value of the ``ROOT_URLCONF`` setting, but if the incoming
+       this is the value of the :setting:`ROOT_URLCONF` setting, but if the incoming
        ``HttpRequest`` object has an attribute called ``urlconf``, its value
        will be used in place of the ``ROOT_URLCONF`` setting.
+       will be used in place of the :setting:`ROOT_URLCONF` setting.
 . Django loads that Python module and looks for the variable
        ``urlpatterns``. This should be a Python list, in the format returned by

docs/topics/http/views.txt

diff --git a/docs/topics/http/views.txt b/docs/topics/http/views.txt

-              a
 .. 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.
 …
       in the 404.
     * The 404 view is passed a ``RequestContext`` and will have access to
       variables supplied by your ``TEMPLATE_CONTEXT_PROCESSORS`` setting (e.g.,
       ``MEDIA_URL``).
+      variables supplied by your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting (e.g.,
+      :setting:`MEDIA_URL`).
     * If ``DEBUG`` is set to ``True`` (in your settings module), then your 404
+    * If :setting:`DEBUG` is set to ``True`` (in your settings module), then your 404
       view will never be used, and the traceback will be displayed instead.
 The 500 (server error) view

docs/topics/i18n.txt

diff --git a/docs/topics/i18n.txt b/docs/topics/i18n.txt

-              a
 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.
 If you do need internationalization: three steps
 ================================================
 …
 Each ``RequestContext`` has access to three translation-specific variables:
     * ``LANGUAGES`` is a list of tuples in which the first element is the
+    * :setting:`LANGUAGES` is a list of tuples in which the first element is the
       language code and the second is the language name (translated into the
       currently active locale).
 …
 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
+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.
 …
       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',
 …
       In Django version 0.96 and before, the cookie's name is hard-coded to
       ``django_language``. In Django 1,0, The cookie name is set by the
       ``LANGUAGE_COOKIE_NAME`` setting. (The default name is
+      :setting:`LANGUAGE_COOKIE_NAME` setting. (The default name is
       ``django_language``.)
     * Failing that, it looks at the ``Accept-Language`` HTTP header. This
 …
       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:
 …
     * 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')),
 …
       .. _LANGUAGES setting: ../settings/#languages
     * 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
 …
       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
 …
       Technical message IDs are easily recognized; they're all upper case. You
       don't translate the message ID as with other messages, you provide the
       correct local variant on the provided English value. For example, with
       ``DATETIME_FORMAT`` (or ``DATE_FORMAT`` or ``TIME_FORMAT``), this would
+      :setting:`DATETIME_FORMAT` (or :setting:`DATE_FORMAT` or :setting:`TIME_FORMAT`), this would
       be the format string that you want to use in your language. The format
       is identical to the format strings used by the ``now`` template tag.
 …
     * ``$APPPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PROJECTPATH/locale/<language>/LC_MESSAGES/django.(po|mo)``
     * All paths listed in ``LOCALE_PATHS`` in your settings file are
+    * All paths listed in :setting:`LOCALE_PATHS` in your settings file are
       searched in that order for ``<language>/LC_MESSAGES/django.(po|mo)``
     * ``$PYTHONPATH/django/conf/locale/<language>/LC_MESSAGES/django.(po|mo)``
 …
 to produce the binary ``django.mo`` files that are used by ``gettext``.
 You can also run ``django-admin.py compilemessages --settings=path.to.settings``
 to make the compiler process all the directories in your ``LOCALE_PATHS``
+to make the compiler process all the directories in your :setting:`LOCALE_PATHS`
 setting.
 Application message files are a bit complicated to discover -- they need the
 …
 parameter set in request. If session support is enabled, the view
 saves the language choice in the user's session. Otherwise, it saves the
 language choice in a cookie that is by default named ``django_language``.
 (The name can be changed through the ``LANGUAGE_COOKIE_NAME`` setting if you're
+(The name can be changed through the :setting:`LANGUAGE_COOKIE_NAME` setting if you're
 using the Django development version.)
 After setting the language choice, Django redirects the user, following 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
+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.
 …
 signs in the URL. This is especially useful if your pages use code from
 different apps and this changes often and you don't want to pull in one big
 catalog file. As a security measure, these values can only be either
 ``django.conf`` or any package from the ``INSTALLED_APPS`` setting.
+``django.conf`` or any package from the :setting:`INSTALLED_APPS` setting.
 Using the JavaScript translation catalog
 ----------------------------------------

docs/topics/templates.txt

diff --git a/docs/topics/templates.txt b/docs/topics/templates.txt

-              a
 ``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 value of the :setting:`TEMPLATE_STRING_IF_INVALID` setting, which is set to ``''``
 (the empty string) by default.
 See `Using the built-in reference`_, below, for help on finding what variables

docs/topics/testing.txt

diff --git a/docs/topics/testing.txt b/docs/topics/testing.txt

-              a
 ``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
+the value of that attribute as the :setting:`ROOT_URLCONF` for the duration of that
 test.
 For example::

Download in other formats:

Original Format

Issues

Context Navigation

Ticket #9502: xref-markup-settings-r9330.diff

docs/faq/admin.txt

docs/faq/models.txt

docs/howto/deployment/fastcgi.txt

docs/internals/contributing.txt

docs/intro/tutorial01.txt

docs/ref/contrib/admin.txt

docs/ref/contrib/comments/settings.txt

docs/ref/contrib/index.txt

docs/ref/databases.txt

docs/ref/django-admin.txt

docs/ref/forms/fields.txt

docs/ref/generic-views.txt

docs/ref/request-response.txt

docs/ref/templates/builtins.txt

docs/topics/cache.txt

docs/topics/db/transactions.txt

docs/topics/email.txt

docs/topics/files.txt

docs/topics/http/file-uploads.txt

docs/topics/http/sessions.txt

docs/topics/http/urls.txt

docs/topics/http/views.txt

docs/topics/i18n.txt

docs/topics/templates.txt

docs/topics/testing.txt

Download in other formats:

Django Links

Learn More

Get Involved

Get Help

Follow Us

Support Us