diff --git a/docs/faq/usage.txt b/docs/faq/usage.txt index 6cba335c02..c75a296a1e 100644 --- a/docs/faq/usage.txt +++ b/docs/faq/usage.txt @@ -8,7 +8,7 @@ Why do I get an error about importing :envvar:`DJANGO_SETTINGS_MODULE`? Make sure that: * The environment variable :envvar:`DJANGO_SETTINGS_MODULE` is set to a - fully-qualified Python module (i.e. "mysite.settings"). + fully-qualified Python module (i.e. ``mysite.settings``). * Said module is on ``sys.path`` (``import mysite.settings`` should work). diff --git a/docs/howto/custom-management-commands.txt b/docs/howto/custom-management-commands.txt index 68b4a049e0..f2118bee49 100644 --- a/docs/howto/custom-management-commands.txt +++ b/docs/howto/custom-management-commands.txt @@ -287,7 +287,7 @@ the :meth:`~BaseCommand.handle` method must be implemented. Tries to execute this command, performing system checks if needed (as controlled by the :attr:`requires_system_checks` attribute). If the command - raises a :exc:`CommandError`, it's intercepted and printed to stderr. + raises a :exc:`CommandError`, it's intercepted and printed to ``stderr``. .. admonition:: Calling a management command in your code @@ -305,7 +305,8 @@ the :meth:`~BaseCommand.handle` method must be implemented. Uses the system check framework to inspect the entire Django project for potential problems. Serious problems are raised as a :exc:`CommandError`; - warnings are output to stderr; minor notifications are output to stdout. + warnings are output to ``stderr``; minor notifications are output to + ``stdout``. If ``app_configs`` and ``tags`` are both ``None``, all system checks are performed. ``tags`` can be a list of check tags, like ``compatibility`` or @@ -359,11 +360,11 @@ Exception class indicating a problem while executing a management command. If this exception is raised during the execution of a management command from a command line console, it will be caught and turned into a nicely-printed error -message to the appropriate output stream (i.e., stderr); as a result, raising -this exception (with a sensible description of the error) is the preferred way -to indicate that something has gone wrong in the execution of a command. It -accepts the optional ``returncode`` argument to customize the exit status for -the management command to exit with, using :func:`sys.exit`. +message to the appropriate output stream (i.e., ``stderr``); as a result, +raising this exception (with a sensible description of the error) is the +preferred way to indicate that something has gone wrong in the execution of a +command. It accepts the optional ``returncode`` argument to customize the exit +status for the management command to exit with, using :func:`sys.exit`. If a management command is called from code through :func:`~django.core.management.call_command`, it's up to you to catch the diff --git a/docs/ref/contrib/gis/install/postgis.txt b/docs/ref/contrib/gis/install/postgis.txt index c769dcf05c..436e0979d2 100644 --- a/docs/ref/contrib/gis/install/postgis.txt +++ b/docs/ref/contrib/gis/install/postgis.txt @@ -11,10 +11,10 @@ The `psycopg2`_ module is required for use as the database adapter when using GeoDjango with PostGIS. On Debian/Ubuntu, you are advised to install the following packages: -postgresql-x.x, postgresql-x.x-postgis, postgresql-server-dev-x.x, -python-psycopg2 (x.x matching the PostgreSQL version you want to install). -Alternately, you can `build from source`_. Consult the platform-specific -instructions if you are on :ref:`macos` or :ref:`windows`. +``postgresql-x.x``, ``postgresql-x.x-postgis``, ``postgresql-server-dev-x.x``, +and ``python-psycopg2`` (x.x matching the PostgreSQL version you want to +install). Alternately, you can `build from source`_. Consult the +platform-specific instructions if you are on :ref:`macos` or :ref:`windows`. .. _PostGIS: https://postgis.net/ .. _psycopg2: https://www.psycopg.org/ diff --git a/docs/releases/1.3.4.txt b/docs/releases/1.3.4.txt index 54ca809ffc..81f1be20ed 100644 --- a/docs/releases/1.3.4.txt +++ b/docs/releases/1.3.4.txt @@ -20,7 +20,7 @@ as was reported to us recently. The Host header parsing in Django 1.3.3 and Django 1.4.1 -- specifically, ``django.http.HttpRequest.get_host()`` -- was incorrectly handling username/password information in the header. Thus, for example, the following Host header would be accepted by Django when running on -"validsite.com":: +``validsite.com``:: Host: validsite.com:random@evilsite.com diff --git a/docs/releases/1.4.2.txt b/docs/releases/1.4.2.txt index 0f9d18744d..61c42845d3 100644 --- a/docs/releases/1.4.2.txt +++ b/docs/releases/1.4.2.txt @@ -20,7 +20,7 @@ as was reported to us recently. The Host header parsing in Django 1.3.3 and Django 1.4.1 -- specifically, ``django.http.HttpRequest.get_host()`` -- was incorrectly handling username/password information in the header. Thus, for example, the following Host header would be accepted by Django when running on -"validsite.com":: +``validsite.com``:: Host: validsite.com:random@evilsite.com diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 85f1b94a9c..b3b3acda31 100644 --- a/docs/releases/1.4.txt +++ b/docs/releases/1.4.txt @@ -167,7 +167,7 @@ You could import ``mysite.settings``, ``mysite.urls``, and ``mysite.myapp``, but not ``settings``, ``urls``, or ``myapp`` as top-level modules. Anything imported as a top-level module can be placed adjacent to the new -``manage.py``. For instance, to decouple "myapp" from the project module and +``manage.py``. For instance, to decouple ``myapp`` from the project module and import it as just ``myapp``, place it outside the ``mysite/`` directory:: manage.py @@ -1060,7 +1060,7 @@ Session cookies now have the ``httponly`` flag by default Session cookies now include the ``httponly`` attribute by default to help reduce the impact of potential XSS attacks. As a consequence of -this change, session cookie data, including sessionid, is no longer +this change, session cookie data, including ``sessionid``, is no longer accessible from JavaScript in many browsers. For strict backwards compatibility, use ``SESSION_COOKIE_HTTPONLY = False`` in your settings file. diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index 114aa865ed..b907e044e1 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -20,7 +20,6 @@ args async atomicity auth -autoclobber autocommit autocomplete autocompletion @@ -305,8 +304,6 @@ multitenancy multithreaded multithreading multivalued -myapp -mysite mysql mysqlclient naïve @@ -452,7 +449,6 @@ serializability serializable serializer serializers -sessionid shapefile shapefiles sharding @@ -469,9 +465,7 @@ stacktrace stateful staticfile staticfiles -stderr stdlib -stdout storages stylesheet stylesheets @@ -590,7 +584,6 @@ Uvicorn uWSGI validator validators -validsite variadic vendored virtualized diff --git a/docs/topics/email.txt b/docs/topics/email.txt index 3e93a5d44f..2005bbd19b 100644 --- a/docs/topics/email.txt +++ b/docs/topics/email.txt @@ -664,7 +664,7 @@ and that those emails will contain the correct content. The easiest way to configure email for local development is to use the :ref:`console ` email backend. This backend -redirects all email to stdout, allowing you to inspect the content of mail. +redirects all email to ``stdout``, allowing you to inspect the content of mail. The :ref:`file ` email backend can also be useful during development -- this backend dumps the contents of every SMTP connection diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt index a78f1b93fc..9159463c36 100644 --- a/docs/topics/testing/advanced.txt +++ b/docs/topics/testing/advanced.txt @@ -812,7 +812,7 @@ can be useful during testing. approve destroying the existing database. ``sys.exit`` is called if the user does not approve. - * If autoclobber is ``True``, the database will be destroyed + * If ``autoclobber`` is ``True``, the database will be destroyed without consulting the user. ``serialize`` determines if Django serializes the database into an