mirror of https://github.com/django/django.git
Fixed versionchanged indentation in docs/.
This commit is contained in:
parent
a71a2ea756
commit
5c517ec218
|
@ -112,17 +112,18 @@ The Storage Class
|
||||||
available for new content to be written to on the target storage
|
available for new content to be written to on the target storage
|
||||||
system.
|
system.
|
||||||
|
|
||||||
|
If a file with ``name`` already exists, an underscore plus a random
|
||||||
|
7 character alphanumeric string is appended to the filename before
|
||||||
|
the extension.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
If a file with ``name`` already exists, an underscore plus a random 7
|
Previously, an underscore followed by a number (e.g. ``"_1"``,
|
||||||
character alphanumeric string is appended to the filename before the
|
``"_2"``, etc.) was appended to the filename until an available
|
||||||
extension.
|
name in the destination directory was found. A malicious user could
|
||||||
|
exploit this deterministic algorithm to create a denial-of-service
|
||||||
Previously, an underscore followed by a number (e.g. ``"_1"``, ``"_2"``,
|
attack. This change was also made in Django 1.6.6, 1.5.9, and
|
||||||
etc.) was appended to the filename until an available name in the
|
1.4.14.
|
||||||
destination directory was found. A malicious user could exploit this
|
|
||||||
deterministic algorithm to create a denial-of-service attack. This
|
|
||||||
change was also made in Django 1.6.6, 1.5.9, and 1.4.14.
|
|
||||||
|
|
||||||
.. method:: get_valid_name(name)
|
.. method:: get_valid_name(name)
|
||||||
|
|
||||||
|
|
|
@ -819,12 +819,14 @@ If you need to clear the list of related fields added by past calls of
|
||||||
|
|
||||||
>>> without_relations = queryset.select_related(None)
|
>>> without_relations = queryset.select_related(None)
|
||||||
|
|
||||||
|
Chaining ``select_related`` calls works in a similar way to other methods -
|
||||||
|
that is that ``select_related('foo', 'bar')`` is equivalent to
|
||||||
|
``select_related('foo').select_related('bar')``.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
Chaining ``select_related`` calls now works in a similar way to other methods -
|
Previously the latter would have been equivalent to
|
||||||
that is that ``select_related('foo', 'bar')`` is equivalent to
|
``select_related('bar')``.
|
||||||
``select_related('foo').select_related('bar')``. Previously the latter would
|
|
||||||
have been equivalent to ``select_related('bar')``.
|
|
||||||
|
|
||||||
prefetch_related
|
prefetch_related
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
|
@ -1142,14 +1142,16 @@ If ``this_value`` is 175, ``max_value`` is 200, and ``max_width`` is 100, the
|
||||||
image in the above example will be 88 pixels wide
|
image in the above example will be 88 pixels wide
|
||||||
(because 175/200 = .875; .875 * 100 = 87.5 which is rounded up to 88).
|
(because 175/200 = .875; .875 * 100 = 87.5 which is rounded up to 88).
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
|
||||||
|
|
||||||
In some cases you might want to capture the result of ``widthratio`` in a
|
In some cases you might want to capture the result of ``widthratio`` in a
|
||||||
variable. It can be useful, for instance, in a :ttag:`blocktrans` like this::
|
variable. It can be useful, for instance, in a :ttag:`blocktrans` like this::
|
||||||
|
|
||||||
{% widthratio this_value max_value max_width as width %}
|
{% widthratio this_value max_value max_width as width %}
|
||||||
{% blocktrans %}The width is: {{ width }}{% endblocktrans %}
|
{% blocktrans %}The width is: {{ width }}{% endblocktrans %}
|
||||||
|
|
||||||
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
|
The ability to use "as" with this tag like in the example above was added.
|
||||||
|
|
||||||
.. templatetag:: with
|
.. templatetag:: with
|
||||||
|
|
||||||
with
|
with
|
||||||
|
|
|
@ -578,8 +578,6 @@ over them:
|
||||||
</ol>
|
</ol>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
|
|
||||||
.. versionchanged:: 1.8
|
|
||||||
|
|
||||||
Non-field errors (and/or hidden field errors that are rendered at the top of
|
Non-field errors (and/or hidden field errors that are rendered at the top of
|
||||||
the form when using helpers like ``form.as_p()``) will be rendered with an
|
the form when using helpers like ``form.as_p()``) will be rendered with an
|
||||||
additional class of ``nonfield`` to help distinguish them from field-specific
|
additional class of ``nonfield`` to help distinguish them from field-specific
|
||||||
|
@ -591,6 +589,10 @@ errors. For example, ``{{ form.non_field_errors }}`` would look like:
|
||||||
<li>Generic validation error</li>
|
<li>Generic validation error</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
|
||||||
|
.. versionchanged:: 1.8
|
||||||
|
|
||||||
|
The "nonfield" class as described in the example above was added.
|
||||||
|
|
||||||
See :doc:`/ref/forms/api` for more on errors, styling, and working with form
|
See :doc:`/ref/forms/api` for more on errors, styling, and working with form
|
||||||
attributes in templates.
|
attributes in templates.
|
||||||
|
|
||||||
|
|
|
@ -97,8 +97,8 @@ configuration instructions for the `using database-backed sessions`_.
|
||||||
|
|
||||||
.. versionchanged:: 1.7
|
.. versionchanged:: 1.7
|
||||||
|
|
||||||
Before version 1.7, the ``cached_db`` backend always used the ``default`` cache
|
Before version 1.7, the ``cached_db`` backend always used the ``default``
|
||||||
rather than the :setting:`SESSION_CACHE_ALIAS`.
|
cache rather than the :setting:`SESSION_CACHE_ALIAS`.
|
||||||
|
|
||||||
Using file-based sessions
|
Using file-based sessions
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
Loading…
Reference in New Issue