summaryrefslogtreecommitdiff
path: root/docs/faq
diff options
context:
space:
mode:
authorLuke Plant <L.Plant.98@cantab.net>2011-10-14 00:12:01 +0000
committerLuke Plant <L.Plant.98@cantab.net>2011-10-14 00:12:01 +0000
commitd1e5c55258d624058a93c8cacdb1f25ae7857554 (patch)
treedca859edc2229f68b7511687aa8b333378786633 /docs/faq
parent5109ac370928a5924887424b6d6c803038fcb691 (diff)
downloaddjango-d1e5c55258d624058a93c8cacdb1f25ae7857554.tar.gz
Fixed many more ReST indentation errors, somehow accidentally missed from [16955]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
Diffstat (limited to 'docs/faq')
-rw-r--r--docs/faq/admin.txt20
-rw-r--r--docs/faq/contributing.txt18
-rw-r--r--docs/faq/install.txt10
-rw-r--r--docs/faq/usage.txt58
4 files changed, 53 insertions, 53 deletions
diff --git a/docs/faq/admin.txt b/docs/faq/admin.txt
index a0e3b92c37..8ec7491903 100644
--- a/docs/faq/admin.txt
+++ b/docs/faq/admin.txt
@@ -8,16 +8,16 @@ 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 :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'``.
-
- * Some browsers (Firefox?) don't like to accept cookies from domains that
- 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
- :setting:`SESSION_COOKIE_DOMAIN` accordingly.
+* 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'``.
+
+* Some browsers (Firefox?) don't like to accept cookies from domains that
+ 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
+ :setting:`SESSION_COOKIE_DOMAIN` accordingly.
I can't log in. When I enter a valid username and password, it brings up the login page again, with a "Please enter a correct username and password" error.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
diff --git a/docs/faq/contributing.txt b/docs/faq/contributing.txt
index 2cf4ddddd8..6f2dfd906f 100644
--- a/docs/faq/contributing.txt
+++ b/docs/faq/contributing.txt
@@ -26,17 +26,17 @@ The best way to make sure tickets do not get hung up on the way to checkin is
to make it dead easy, even for someone who may not be intimately familiar with
that area of the code, to understand the problem and verify the fix:
- * Are there clear instructions on how to reproduce the bug? If this
- touches a dependency (such as PIL), a contrib module, or a specific
- database, are those instructions clear enough even for someone not
- familiar with it?
+* Are there clear instructions on how to reproduce the bug? If this
+ touches a dependency (such as PIL), a contrib module, or a specific
+ database, are those instructions clear enough even for someone not
+ familiar with it?
- * If there are several patches attached to the ticket, is it clear what
- each one does, which ones can be ignored and which matter?
+* If there are several patches attached to the ticket, is it clear what
+ each one does, which ones can be ignored and which matter?
- * Does the patch include a unit test? If not, is there a very clear
- explanation why not? A test expresses succinctly what the problem is,
- and shows that the patch actually fixes it.
+* Does the patch include a unit test? If not, is there a very clear
+ explanation why not? A test expresses succinctly what the problem is,
+ and shows that the patch actually fixes it.
If your patch stands no chance of inclusion in Django, we won't ignore it --
we'll just close the ticket. So if your ticket is still open, it doesn't mean
diff --git a/docs/faq/install.txt b/docs/faq/install.txt
index 5ceb9caf52..90b83f18ee 100644
--- a/docs/faq/install.txt
+++ b/docs/faq/install.txt
@@ -4,11 +4,11 @@ FAQ: Installation
How do I get started?
---------------------
- #. `Download the code`_.
- #. Install Django (read the :doc:`installation guide </intro/install>`).
- #. Walk through the :doc:`tutorial </intro/tutorial01>`.
- #. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
- run into trouble.
+#. `Download the code`_.
+#. Install Django (read the :doc:`installation guide </intro/install>`).
+#. Walk through the :doc:`tutorial </intro/tutorial01>`.
+#. Check out the rest of the :doc:`documentation </index>`, and `ask questions`_ if you
+ run into trouble.
.. _`Download the code`: http://www.djangoproject.com/download/
.. _ask questions: http://www.djangoproject.com/community/
diff --git a/docs/faq/usage.txt b/docs/faq/usage.txt
index c11514c4cd..2b185be1a6 100644
--- a/docs/faq/usage.txt
+++ b/docs/faq/usage.txt
@@ -6,21 +6,21 @@ Why do I get an error about importing DJANGO_SETTINGS_MODULE?
Make sure that:
- * The environment variable DJANGO_SETTINGS_MODULE is set to a
- fully-qualified Python module (i.e. "mysite.settings").
+* The environment variable DJANGO_SETTINGS_MODULE is set to a
+ fully-qualified Python module (i.e. "mysite.settings").
- * Said module is on ``sys.path`` (``import mysite.settings`` should work).
+* Said module is on ``sys.path`` (``import mysite.settings`` should work).
- * The module doesn't contain syntax errors (of course).
+* The module doesn't contain syntax errors (of course).
- * If you're using mod_python but *not* using Django's request handler,
- you'll need to work around a mod_python bug related to the use of
- ``SetEnv``; before you import anything from Django you'll need to do
- the following::
+* If you're using mod_python but *not* using Django's request handler,
+ you'll need to work around a mod_python bug related to the use of
+ ``SetEnv``; before you import anything from Django you'll need to do
+ the following::
- os.environ.update(req.subprocess_env)
+ os.environ.update(req.subprocess_env)
- (where ``req`` is the mod_python request object).
+ (where ``req`` is the mod_python request object).
I can't stand your template language. Do I have to use it?
----------------------------------------------------------
@@ -46,25 +46,25 @@ How do I use image and file fields?
Using a :class:`~django.db.models.FileField` or an
:class:`~django.db.models.ImageField` in a model takes a few steps:
- #. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
- the full path to a directory where you'd like Django to store uploaded
- files. (For performance, these files are not stored in the database.)
- Define :setting:`MEDIA_URL` as the base public URL of that directory.
- Make sure that this directory is writable by the Web server's user
- account.
-
- #. Add the :class:`~django.db.models.FileField` or
- :class:`~django.db.models.ImageField` to your model, making sure to
- define the :attr:`~django.db.models.FileField.upload_to` option to tell
- Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
- files.
-
- #. All that will be stored in your database is a path to the file
- (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
- convenience :attr:`~django.core.files.File.url` attribute provided by
- Django. For example, if your :class:`~django.db.models.ImageField` is
- called ``mug_shot``, you can get the absolute path to your image in a
- template with ``{{ object.mug_shot.url }}``.
+#. In your settings file, you'll need to define :setting:`MEDIA_ROOT` as
+ the full path to a directory where you'd like Django to store uploaded
+ files. (For performance, these files are not stored in the database.)
+ Define :setting:`MEDIA_URL` as the base public URL of that directory.
+ Make sure that this directory is writable by the Web server's user
+ account.
+
+#. Add the :class:`~django.db.models.FileField` or
+ :class:`~django.db.models.ImageField` to your model, making sure to
+ define the :attr:`~django.db.models.FileField.upload_to` option to tell
+ Django to which subdirectory of :setting:`MEDIA_ROOT` it should upload
+ files.
+
+#. All that will be stored in your database is a path to the file
+ (relative to :setting:`MEDIA_ROOT`). You'll most likely want to use the
+ convenience :attr:`~django.core.files.File.url` attribute provided by
+ Django. For example, if your :class:`~django.db.models.ImageField` is
+ called ``mug_shot``, you can get the absolute path to your image in a
+ template with ``{{ object.mug_shot.url }}``.
How do I make a variable available to all my templates?
-------------------------------------------------------