mirror of
https://github.com/django/django.git
synced 2024-12-22 09:05:43 +00:00
Added backticks to code literals in various docs.
This commit is contained in:
parent
15b888bb83
commit
51874dd160
@ -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).
|
||||
|
||||
|
@ -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
|
||||
|
@ -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/
|
||||
|
@ -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
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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 <topic-email-console-backend>` 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 <topic-email-file-backend>` email backend can also be useful
|
||||
during development -- this backend dumps the contents of every SMTP connection
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user