mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-10-30 09:06:13 +00:00
Code Issues 32 Releases Wiki Activity

Refs #36485 -- Rewrapped docs to 79 columns line length.

Browse Source 
Lines in the docs files were manually adjusted to conform to the
79 columns limit per line (plus newline), improving readability and
consistency across the content.
This commit is contained in:
David Smith
2025-07-25 10:24:17 +01:00
committed by nessita
parent 4286a23df6
commit f81e6e3a53
230 changed files with 3250 additions and 2914 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/releases/0.96.txt
View File

@@ -98,9 +98,9 @@ Backslash escaping changed
--------------------------
The Django database API now escapes backslashes given as query parameters. If
you have any database API code that matches backslashes, and it was working before
(despite the lack of escaping), you'll have to change your code to "unescape" the
slashes one level.
you have any database API code that matches backslashes, and it was working
before (despite the lack of escaping), you'll have to change your code to
"unescape" the slashes one level.
For example, this used to work::
@@ -206,14 +206,16 @@ The test framework
Django now includes a test framework so you can start transmuting fear into
boredom (with apologies to Kent Beck). You can write tests based on
:mod:`doctest` or :mod:`unittest` and test your views with a simple test client.
:mod:`doctest` or :mod:`unittest` and test your views with a simple test
client.
There is also new support for "fixtures" -- initial data, stored in any of the
supported :doc:`serialization formats </topics/serialization>`, that will be
loaded into your database at the start of your tests. This makes testing with
real data much easier.
See :doc:`the testing documentation </topics/testing/index>` for the full details.
See :doc:`the testing documentation </topics/testing/index>` for the full
details.
Improvements to the admin interface
-----------------------------------

52
docs/releases/1.0-porting-guide.txt
View File

@@ -5,14 +5,15 @@ Porting your apps from Django 0.96 to 1.0
Django 1.0 breaks compatibility with 0.96 in some areas.
This guide will help you port 0.96 projects and apps to 1.0. The first part of
this document includes the common changes needed to run with 1.0. If after going
through the first part your code still breaks, check the section `Less-common
Changes`_ for a list of a bunch of less-common compatibility issues.
this document includes the common changes needed to run with 1.0. If after
going through the first part your code still breaks, check the section
`Less-common Changes`_ for a list of a bunch of less-common compatibility
issues.
.. seealso::
The :doc:`1.0 release notes </releases/1.0>`. That document explains the new
features in 1.0 more deeply; the porting guide is more concerned with
The :doc:`1.0 release notes </releases/1.0>`. That document explains the
new features in 1.0 more deeply; the porting guide is more concerned with
helping you quickly update your code.
Common changes
@@ -83,7 +84,8 @@ see `the admin`_ below for more details.
Example
~~~~~~~
Below is an example ``models.py`` file with all the changes you'll need to make:
Below is an example ``models.py`` file with all the changes you'll need to
make:
Old (0.96) ``models.py``::
@@ -127,14 +129,14 @@ The Admin
One of the biggest changes in 1.0 is the new admin. The Django administrative
interface (``django.contrib.admin``) has been completely refactored; admin
definitions are now completely decoupled from model definitions, the framework
has been rewritten to use Django's new form-handling library and redesigned with
extensibility and customization in mind.
has been rewritten to use Django's new form-handling library and redesigned
with extensibility and customization in mind.
Practically, this means you'll need to rewrite all of your ``class Admin``
declarations. You've already seen in `models`_ above how to replace your ``class
Admin`` with an ``admin.site.register()`` call in an ``admin.py`` file. Below are
some more details on how to rewrite that ``Admin`` declaration into the new
syntax.
declarations. You've already seen in `models`_ above how to replace your
``class Admin`` with an ``admin.site.register()`` call in an ``admin.py`` file.
Below are some more details on how to rewrite that ``Admin`` declaration into
the new syntax.
Use new inline syntax
~~~~~~~~~~~~~~~~~~~~~
@@ -210,8 +212,8 @@ New (1.0)::
* More detailed information about the changes and the reasons behind them
can be found on the `NewformsAdminBranch wiki page`__
* The new admin comes with a ton of new features; you can read about them in
the :doc:`admin documentation </ref/contrib/admin/index>`.
* The new admin comes with a ton of new features; you can read about them
in the :doc:`admin documentation </ref/contrib/admin/index>`.
__ https://code.djangoproject.com/wiki/NewformsAdminBranch
@@ -301,10 +303,10 @@ Old (0.96) New (1.0)
Work with file fields using the new API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The internal implementation of :class:`django.db.models.FileField` have changed.
A visible result of this is that the way you access special attributes (URL,
filename, image size, etc.) of these model fields has changed. You will need to
make the following changes, assuming your model's
The internal implementation of :class:`django.db.models.FileField` have
changed. A visible result of this is that the way you access special attributes
(URL, filename, image size, etc.) of these model fields has changed. You will
need to make the following changes, assuming your model's
:class:`~django.db.models.FileField` is called ``myfile``:
=================================== ========================
@@ -358,8 +360,8 @@ Less-common changes
===================
The following changes are smaller, more localized changes. They should only
affect more advanced users, but it's probably worth reading through the list and
checking your code for these things.
affect more advanced users, but it's probably worth reading through the list
and checking your code for these things.
Signals
-------
@@ -370,8 +372,8 @@ Signals
:class:`~django.dispatch.Signal` object instead of through module methods in
``django.dispatch.dispatcher``.
* Remove any use of the ``Anonymous`` and ``Any`` sender options; they no longer
exist. You can still receive signals sent by any sender by using
* Remove any use of the ``Anonymous`` and ``Any`` sender options; they no
longer exist. You can still receive signals sent by any sender by using
``sender=None``
* Make any custom signals you've declared into instances of
@@ -502,7 +504,8 @@ New (1.0)::
The ``LazyDate`` helper class no longer exists.
Default field values and query arguments can both be callable objects, so
instances of ``LazyDate`` can be replaced with a reference to ``datetime.datetime.now``:
instances of ``LazyDate`` can be replaced with a reference to
``datetime.datetime.now``:
Old (0.96)::
@@ -631,7 +634,8 @@ Accessing ``HTTPResponse`` headers
``django.http.HttpResponse.headers`` has been renamed to ``_headers`` and
:class:`~django.http.HttpResponse` now supports containment checking directly.
So use ``if header in response:`` instead of ``if header in response.headers:``.
So use ``if header in response:`` instead of ``if header in
response.headers:``.
Generic relations
-----------------

4
docs/releases/1.0.2.txt
View File

@@ -7,8 +7,8 @@ Welcome to Django 1.0.2!
This is the second "bugfix" release in the Django 1.0 series,
improving the stability and performance of the Django 1.0 codebase. As
such, Django 1.0.2 contains no new features (and, pursuant to
:doc:`our compatibility policy </misc/api-stability>`, maintains backwards compatibility with Django
1.0.0), but does contain a number of fixes and other
:doc:`our compatibility policy </misc/api-stability>`, maintains backwards
compatibility with Django 1.0.0), but does contain a number of fixes and other
improvements. Django 1.0.2 is a recommended upgrade for any
development or deployment currently using or targeting Django 1.0.

96
docs/releases/1.0.txt
View File

@@ -4,20 +4,21 @@ Django 1.0 release notes
Welcome to Django 1.0!
We've been looking forward to this moment for over three years, and it's finally
here. Django 1.0 represents the largest milestone in Django's development to
date: a web framework that a group of perfectionists can truly be proud of.
We've been looking forward to this moment for over three years, and it's
finally here. Django 1.0 represents the largest milestone in Django's
development to date: a web framework that a group of perfectionists can truly
be proud of.
Django 1.0 represents over three years of community development as an Open
Source project. Django's received contributions from hundreds of developers,
been translated into fifty languages, and today is used by developers on every
continent and in every kind of job.
An interesting historical note: when Django was first released in July 2005, the
initial released version of Django came from an internal repository at revision
number 8825. Django 1.0 represents revision 8961 of our public repository. It
seems fitting that our 1.0 release comes at the moment where community
contributions overtake those made privately.
An interesting historical note: when Django was first released in July 2005,
the initial released version of Django came from an internal repository at
revision number 8825. Django 1.0 represents revision 8961 of our public
repository. It seems fitting that our 1.0 release comes at the moment where
community contributions overtake those made privately.
Stability and forwards-compatibility
====================================
@@ -77,9 +78,9 @@ Refactored admin application
----------------------------
The Django administrative interface (``django.contrib.admin``) has been
completely refactored; admin definitions are now completely decoupled from model
definitions (no more ``class Admin`` declaration in models!), rewritten to use
Django's new form-handling library (introduced in the 0.96 release as
completely refactored; admin definitions are now completely decoupled from
model definitions (no more ``class Admin`` declaration in models!), rewritten
to use Django's new form-handling library (introduced in the 0.96 release as
``django.newforms``, and now available as simply ``django.forms``) and
redesigned with extensibility and customization in mind. Full documentation for
the admin application is available online in the official Django documentation:
@@ -90,8 +91,8 @@ Improved Unicode handling
-------------------------
Django's internals have been refactored to use Unicode throughout; this
drastically simplifies the task of dealing with non-Western-European content and
data in Django. Additionally, utility functions have been provided to ease
drastically simplifies the task of dealing with non-Western-European content
and data in Django. Additionally, utility functions have been provided to ease
interoperability with third-party libraries and systems which may or may not
handle Unicode gracefully. Details are available in Django's Unicode-handling
documentation.
@@ -102,24 +103,25 @@ An improved ORM
---------------
Django's object-relational mapper -- the component which provides the mapping
between Django model classes and your database, and which mediates your database
queries -- has been dramatically improved by a massive refactoring. For most
users of Django this is backwards-compatible; the public-facing API for database
querying underwent a few minor changes, but most of the updates took place in
the ORM's internals. A guide to the changes, including backwards-incompatible
modifications and mentions of new features opened up by this refactoring, is
`available on the Django wiki`__.
between Django model classes and your database, and which mediates your
database queries -- has been dramatically improved by a massive refactoring.
For most users of Django this is backwards-compatible; the public-facing API
for database querying underwent a few minor changes, but most of the updates
took place in the ORM's internals. A guide to the changes, including
backwards-incompatible modifications and mentions of new features opened up by
this refactoring, is `available on the Django wiki`__.
__ https://code.djangoproject.com/wiki/QuerysetRefactorBranch
Automatic escaping of template variables
----------------------------------------
To provide improved security against cross-site scripting (XSS) vulnerabilities,
Django's template system now automatically escapes the output of variables. This
behavior is configurable, and allows both variables and larger template
constructs to be marked as safe (requiring no escaping) or unsafe (requiring
escaping). A full guide to this feature is in the documentation for the
To provide improved security against cross-site scripting (XSS)
vulnerabilities, Django's template system now automatically escapes the output
of variables. This behavior is configurable, and allows both variables and
larger template constructs to be marked as safe (requiring no escaping) or
unsafe (requiring escaping). A full guide to this feature is in the
documentation for the
:ttag:`autoescape` tag.
``django.contrib.gis`` (GeoDjango)
@@ -129,8 +131,8 @@ A project over a year in the making, this adds world-class GIS (`Geographic
Information Systems`_) support to Django, in the form of a ``contrib``
application. Its documentation is currently being maintained externally, and
will be merged into the main Django documentation shortly. Huge thanks go to
Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts in
creating and completing this feature.
Justin Bronn, Jeremy Dunck, Brett Hoerner and Travis Pinney for their efforts
in creating and completing this feature.
See :doc:`GeoDjango </ref/contrib/gis/index>` for details.
@@ -142,8 +144,8 @@ Pluggable file storage
Django's built-in ``FileField`` and ``ImageField`` now can take advantage of
pluggable file-storage backends, allowing extensive customization of where and
how uploaded files get stored by Django. For details, see :doc:`the files
documentation </topics/files>`; big thanks go to Marty Alchin for putting in the
hard work to get this completed.
documentation </topics/files>`; big thanks go to Marty Alchin for putting in
the hard work to get this completed.
Jython compatibility
--------------------
@@ -159,18 +161,20 @@ Jython 2.5 release.
Generic relations in forms and admin
------------------------------------
Classes are now included in ``django.contrib.contenttypes`` which can be used to
support generic relations in both the admin interface and in end-user forms. See
:ref:`the documentation for generic relations <generic-relations>` for details.
Classes are now included in ``django.contrib.contenttypes`` which can be used
to support generic relations in both the admin interface and in end-user forms.
See :ref:`the documentation for generic relations <generic-relations>` for
details.
``INSERT``/``UPDATE`` distinction
---------------------------------
Although Django's default behavior of having a model's ``save()`` method
automatically determine whether to perform an ``INSERT`` or an ``UPDATE`` at the
SQL level is suitable for the majority of cases, there are occasional situations
where forcing one or the other is useful. As a result, models can now support an
additional parameter to ``save()`` which can force a specific operation.
automatically determine whether to perform an ``INSERT`` or an ``UPDATE`` at
the SQL level is suitable for the majority of cases, there are occasional
situations where forcing one or the other is useful. As a result, models can
now support an additional parameter to ``save()`` which can force a specific
operation.
See :ref:`ref-models-force-insert` for details.
@@ -181,8 +185,8 @@ Django's ``CacheMiddleware`` has been split into three classes:
``CacheMiddleware`` itself still exists and retains all of its previous
functionality, but it is now built from two separate middleware classes which
handle the two parts of caching (inserting into and reading from the cache)
separately, offering additional flexibility for situations where combining these
functions into a single middleware posed problems.
separately, offering additional flexibility for situations where combining
these functions into a single middleware posed problems.
Full details, including updated notes on appropriate use, are in :doc:`the
caching documentation </topics/cache>`.
@@ -197,9 +201,9 @@ increasing its flexibility and customizability.
Removal of deprecated features
------------------------------
A number of features and methods which had previously been marked as deprecated,
and which were scheduled for removal prior to the 1.0 release, are no longer
present in Django. These include imports of the form library from
A number of features and methods which had previously been marked as
deprecated, and which were scheduled for removal prior to the 1.0 release, are
no longer present in Django. These include imports of the form library from
``django.newforms`` (now located simply at ``django.forms``), the
``form_for_model`` and ``form_for_instance`` helper functions (which have been
replaced by ``ModelForm``) and a number of deprecated features which were
@@ -216,9 +220,9 @@ Multi-table model inheritance with ``to_field``
-----------------------------------------------
If you're using :ref:`multiple table model inheritance
<multi-table-inheritance>`, be aware of this caveat: child models using a custom
``parent_link`` and ``to_field`` will cause database integrity errors. A set of
models like the following are **not valid**::
<multi-table-inheritance>`, be aware of this caveat: child models using a
custom ``parent_link`` and ``to_field`` will cause database integrity errors. A
set of models like the following are **not valid**::
class Parent(models.Model):
name = models.CharField(max_length=10)
@@ -237,7 +241,9 @@ Caveats with support of certain databases
-----------------------------------------
Django attempts to support as many features as possible on all database
backends. However, not all database backends are alike, and in particular many of the supported database differ greatly from version to version. It's a good idea to checkout our :doc:`notes on supported database </ref/databases>`:
backends. However, not all database backends are alike, and in particular many
of the supported database differ greatly from version to version. It's a good
idea to checkout our :doc:`notes on supported database </ref/databases>`:
- :ref:`mysql-notes`
- :ref:`sqlite-notes`

4
docs/releases/1.1.2.txt
View File

@@ -49,8 +49,8 @@ will improve protection against Cross-Site Request Forgery (CSRF)
attacks. This feature requires the use of a new :ttag:`csrf_token`
template tag in all forms that Django renders.
To make it easier to support both 1.1.X and 1.2.X versions of Django with
the same templates, we have decided to introduce the :ttag:`csrf_token` template
To make it easier to support both 1.1.X and 1.2.X versions of Django with the
same templates, we have decided to introduce the :ttag:`csrf_token` template
tag to the 1.1.X branch. In the 1.1.X branch, :ttag:`csrf_token` does nothing -
it has no effect on templates or form processing. However, it means that the
same template will work with Django 1.2.

79
docs/releases/1.1.txt
View File

@@ -86,11 +86,12 @@ set by some proxy configurations.
It has been demonstrated that this mechanism cannot be made reliable enough for
general-purpose use, and that (despite documentation to the contrary) its
inclusion in Django may lead application developers to assume that the value of
``REMOTE_ADDR`` is "safe" or in some way reliable as a source of authentication.
``REMOTE_ADDR`` is "safe" or in some way reliable as a source of
authentication.
While not directly a security issue, we've decided to remove this middleware
with the Django 1.1 release. It has been replaced with a class that does nothing
other than raise a ``DeprecationWarning``.
with the Django 1.1 release. It has been replaced with a class that does
nothing other than raise a ``DeprecationWarning``.
If you've been relying on this middleware, the easiest upgrade path is:
@@ -124,10 +125,10 @@ Changes to how model formsets are saved
In Django 1.1, :class:`~django.forms.models.BaseModelFormSet` now calls
``ModelForm.save()``.
This is backwards-incompatible if you were modifying ``self.initial`` in a model
formset's ``__init__``, or if you relied on the internal ``_total_form_count``
or ``_initial_form_count`` attributes of BaseFormSet. Those attributes are now
public methods.
This is backwards-incompatible if you were modifying ``self.initial`` in a
model formset's ``__init__``, or if you relied on the internal
``_total_form_count`` or ``_initial_form_count`` attributes of BaseFormSet.
Those attributes are now public methods.
Fixed the ``join`` filter's escaping behavior
---------------------------------------------
@@ -224,11 +225,11 @@ A number of features have been added to Django's model layer:
"Unmanaged" models
~~~~~~~~~~~~~~~~~~
You can now control whether or not Django manages the life-cycle of the database
tables for a model using the :attr:`~Options.managed` model option. This
defaults to ``True``, meaning that Django will create the appropriate database
tables in ``syncdb`` and remove them as part of the ``reset``
command. That is, Django *manages* the database table's lifecycle.
You can now control whether or not Django manages the life-cycle of the
database tables for a model using the :attr:`~Options.managed` model option.
This defaults to ``True``, meaning that Django will create the appropriate
database tables in ``syncdb`` and remove them as part of the ``reset`` command.
That is, Django *manages* the database table's lifecycle.
If you set this to ``False``, however, no database table creating or deletion
will be automatically performed for this model. This is useful if the model
@@ -275,15 +276,16 @@ Test performance improvements
.. currentmodule:: django.test
Tests written using Django's :doc:`testing framework </topics/testing/index>` now run
dramatically faster (as much as 10 times faster in many cases).
Tests written using Django's :doc:`testing framework </topics/testing/index>`
now run dramatically faster (as much as 10 times faster in many cases).
This was accomplished through the introduction of transaction-based tests: when
using :class:`django.test.TestCase`, your tests will now be run in a transaction
which is rolled back when finished, instead of by flushing and re-populating the
database. This results in an immense speedup for most types of unit tests. See
the documentation for :class:`TestCase` and :class:`TransactionTestCase` for a
full description, and some important notes on database support.
using :class:`django.test.TestCase`, your tests will now be run in a
transaction which is rolled back when finished, instead of by flushing and
re-populating the database. This results in an immense speedup for most types
of unit tests. See the documentation for :class:`TestCase` and
:class:`TransactionTestCase` for a full description, and some important notes
on database support.
Test client improvements
------------------------
@@ -339,11 +341,11 @@ URL namespaces
Django 1.1 improves :ref:`named URL patterns <naming-url-patterns>` with the
introduction of URL "namespaces."
In short, this feature allows the same group of URLs, from the same application,
to be included in a Django URLConf multiple times, with varying (and potentially
nested) named prefixes which will be used when performing reverse resolution. In
other words, reusable applications like Django's admin interface may be
registered multiple times without URL conflicts.
In short, this feature allows the same group of URLs, from the same
application, to be included in a Django URLConf multiple times, with varying
(and potentially nested) named prefixes which will be used when performing
reverse resolution. In other words, reusable applications like Django's admin
interface may be registered multiple times without URL conflicts.
For full details, see :ref:`the documentation on defining URL namespaces
<topics-http-defining-url-namespaces>`.
@@ -391,22 +393,21 @@ Other new features and changes introduced since Django 1.0 include:
* The ``include()`` function in Django URLconf modules can now accept sequences
of URL patterns (generated by ``patterns()``) in addition to module names.
* Instances of Django forms (see :doc:`the forms overview </topics/forms/index>`)
now have two additional methods, ``hidden_fields()`` and ``visible_fields()``,
which return the list of hidden -- i.e., ``<input type="hidden">`` -- and
visible fields on the form, respectively.
* Instances of Django forms (see :doc:`the forms overview
</topics/forms/index>`) now have two additional methods, ``hidden_fields()``
and ``visible_fields()``, which return the list of hidden -- i.e.,
``<input type="hidden">`` -- and visible fields on the form, respectively.
* The ``redirect_to`` generic view
now accepts an additional keyword argument
``permanent``. If ``permanent`` is ``True``, the view will emit an HTTP
permanent redirect (status code 301). If ``False``, the view will emit an HTTP
temporary redirect (status code 302).
now accepts an additional keyword argument ``permanent``. If ``permanent`` is
``True``, the view will emit an HTTP permanent redirect (status code 301). If
``False``, the view will emit an HTTP temporary redirect (status code 302).
* A new database lookup type -- ``week_day`` -- has been added for ``DateField``
and ``DateTimeField``. This type of lookup accepts a number between 1 (Sunday)
and 7 (Saturday), and returns objects where the field value matches that day
of the week. See :ref:`the full list of lookup types <field-lookups>` for
details.
* A new database lookup type -- ``week_day`` -- has been added for
``DateField`` and ``DateTimeField``. This type of lookup accepts a number
between 1 (Sunday) and 7 (Saturday), and returns objects where the field
value matches that day of the week. See :ref:`the full list of lookup types
<field-lookups>` for details.
* The ``{% for %}`` tag in Django's template language now accepts an optional
``{% empty %}`` clause, to be displayed when ``{% for %}`` is asked to loop
@@ -453,7 +454,7 @@ Django:
* :doc:`How to contribute to Django </internals/contributing/index>`
Contributions on any level -- developing code, writing documentation or simply
triaging tickets and helping to test proposed bugfixes -- are always welcome and
appreciated.
triaging tickets and helping to test proposed bugfixes -- are always welcome
and appreciated.
And that's the way it is.

2
docs/releases/1.10.3.txt
View File

@@ -26,7 +26,7 @@ DNS rebinding vulnerability when ``DEBUG=True``
Older versions of Django don't validate the ``Host`` header against
``settings.ALLOWED_HOSTS`` when ``settings.DEBUG=True``. This makes them
vulnerable to a `DNS rebinding attack
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
<https://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`__.
While Django doesn't ship a module that allows remote code execution, this is
at least a cross-site scripting vector, which could be quite serious if

34
docs/releases/1.10.txt
View File

@@ -92,9 +92,10 @@ Minor features
it easier to add custom tools in this case.
* The :class:`~django.contrib.admin.models.LogEntry` model now stores change
messages in a JSON structure so that the message can be dynamically translated
using the current active language. A new ``LogEntry.get_change_message()``
method is now the preferred way of retrieving the change message.
messages in a JSON structure so that the message can be dynamically
translated using the current active language. A new
``LogEntry.get_change_message()`` method is now the preferred way of
retrieving the change message.
* Selected objects for fields in ``ModelAdmin.raw_id_fields`` now have a link
to object's change form.
@@ -286,10 +287,10 @@ Forms
a ``minlength`` attribute if the field has a ``min_length``.
* Required form fields now have the ``required`` HTML attribute. Set the new
:attr:`Form.use_required_attribute <django.forms.Form.use_required_attribute>`
attribute to ``False`` to disable it. The ``required`` attribute isn't
included on forms of formsets because the browser validation may not be
correct when adding and deleting formsets.
:attr:`Form.use_required_attribute
<django.forms.Form.use_required_attribute>` attribute to ``False`` to disable
it. The ``required`` attribute isn't included on forms of formsets because
the browser validation may not be correct when adding and deleting formsets.
Generic Views
~~~~~~~~~~~~~
@@ -387,12 +388,12 @@ Models
* Reverse foreign keys from proxy models are now propagated to their
concrete class. The reverse relation attached by a
:class:`~django.db.models.ForeignKey` pointing to a proxy model is now
accessible as a descriptor on the proxied model class and may be referenced in
queryset filtering.
accessible as a descriptor on the proxied model class and may be referenced
in queryset filtering.
* The new :meth:`Field.rel_db_type() <django.db.models.Field.rel_db_type>`
method returns the database column data type for fields such as ``ForeignKey``
and ``OneToOneField`` that point to another field.
method returns the database column data type for fields such as
``ForeignKey`` and ``OneToOneField`` that point to another field.
* The :attr:`~django.db.models.Func.arity` class attribute is added to
:class:`~django.db.models.Func`. This attribute can be used to set the number
@@ -755,10 +756,9 @@ custom lookup for it. For example::
aggregate function now returns a ``float`` instead of ``decimal.Decimal``.
(It's still wrapped in a measure of square meters.)
* The default :class:`~django.contrib.gis.geos.GEOSGeometry` representation (WKT
output) is trimmed by default. That is, instead of
``POINT (23.0000000000000000 5.5000000000000000)``, you'll get
``POINT (23 5.5)``.
* The default :class:`~django.contrib.gis.geos.GEOSGeometry` representation
(WKT output) is trimmed by default. That is, instead of ``POINT
(23.0000000000000000 5.5000000000000000)``, you'll get ``POINT (23 5.5)``.
Maximum size of a request body and the number of GET/POST parameters is limited
-------------------------------------------------------------------------------
@@ -903,8 +903,8 @@ Miscellaneous
might be possible to use :attr:`~django.db.models.FileField.upload_to` also.
* The subject of mail sent by ``AdminEmailHandler`` is no longer truncated at
989 characters. If you were counting on a limited length, truncate the subject
yourself.
989 characters. If you were counting on a limited length, truncate the
subject yourself.
* Private expressions ``django.db.models.expressions.Date`` and ``DateTime``
are removed. The new :class:`~django.db.models.functions.Trunc` expressions

4
docs/releases/1.11.13.txt
View File

@@ -18,5 +18,5 @@ Bugfixes
* Fixed a regression in Django 1.11.12 where ``QuerySet.values()`` or
``values_list()`` after combining an annotated and unannotated queryset with
``union()``, ``difference()``, or ``intersection()`` crashed due to mismatching
columns (:ticket:`29286`).
``union()``, ``difference()``, or ``intersection()`` crashed due to
mismatching columns (:ticket:`29286`).

3
docs/releases/1.11.5.txt
View File

@@ -23,7 +23,8 @@ Bugfixes
* Added compatibility for ``cx_Oracle`` 6 (:ticket:`28498`).
* Fixed select widget rendering when option values are tuples (:ticket:`28502`).
* Fixed select widget rendering when option values are tuples
(:ticket:`28502`).
* Django 1.11 inadvertently changed the sequence and trigger naming scheme on
Oracle. This causes errors on INSERTs for some tables if

4
docs/releases/1.11.9.txt
View File

@@ -9,8 +9,8 @@ Django 1.11.9 fixes several bugs in 1.11.8.
Bugfixes
========
* Fixed a regression in Django 1.11 that added newlines between ``MultiWidget``'s
subwidgets (:ticket:`28890`).
* Fixed a regression in Django 1.11 that added newlines between
``MultiWidget``'s subwidgets (:ticket:`28890`).
* Fixed incorrect class-based model index name generation for models with
quoted ``db_table`` (:ticket:`28876`).

38
docs/releases/1.11.txt
View File

@@ -104,8 +104,8 @@ Minor features
20%.
* The :class:`~django.contrib.auth.views.LoginView` and
:class:`~django.contrib.auth.views.LogoutView` class-based views supersede the
deprecated ``login()`` and ``logout()`` function-based views.
:class:`~django.contrib.auth.views.LogoutView` class-based views supersede
the deprecated ``login()`` and ``logout()`` function-based views.
* The :class:`~django.contrib.auth.views.PasswordChangeView`,
:class:`~django.contrib.auth.views.PasswordChangeDoneView`,
@@ -115,8 +115,8 @@ Minor features
:class:`~django.contrib.auth.views.PasswordResetCompleteView` class-based
views supersede the deprecated ``password_change()``,
``password_change_done()``, ``password_reset()``, ``password_reset_done()``,
``password_reset_confirm()``, and ``password_reset_complete()`` function-based
views.
``password_reset_confirm()``, and ``password_reset_complete()``
function-based views.
* The new ``post_reset_login`` attribute for
:class:`~django.contrib.auth.views.PasswordResetConfirmView` allows
@@ -143,17 +143,18 @@ Minor features
* Added password validators ``help_text`` to
:class:`~django.contrib.auth.forms.UserCreationForm`.
* The ``HttpRequest`` is now passed to :func:`~django.contrib.auth.authenticate`
which in turn passes it to the authentication backend if it accepts a
``request`` argument.
* The ``HttpRequest`` is now passed to
:func:`~django.contrib.auth.authenticate` which in turn passes it to the
authentication backend if it accepts a ``request`` argument.
* The :func:`~django.contrib.auth.signals.user_login_failed` signal now
receives a ``request`` argument.
* :class:`~django.contrib.auth.forms.PasswordResetForm` supports custom user
models that use an email field named something other than ``'email'``.
Set :attr:`CustomUser.EMAIL_FIELD
<django.contrib.auth.models.CustomUser.EMAIL_FIELD>` to the name of the field.
models that use an email field named something other than ``'email'``. Set
:attr:`CustomUser.EMAIL_FIELD
<django.contrib.auth.models.CustomUser.EMAIL_FIELD>` to the name of the
field.
* :func:`~django.contrib.auth.get_user_model` can now be called at import time,
even in modules that define models.
@@ -231,10 +232,10 @@ Minor features
Cache
~~~~~
* Memcached backends now pass the contents of :setting:`OPTIONS <CACHES-OPTIONS>`
as keyword arguments to the client constructors, allowing for more advanced
control of client behavior. See the :ref:`cache arguments <cache_arguments>`
documentation for examples.
* Memcached backends now pass the contents of
:setting:`OPTIONS <CACHES-OPTIONS>` as keyword arguments to the client
constructors, allowing for more advanced control of client behavior. See the
:ref:`cache arguments <cache_arguments>` documentation for examples.
* Memcached backends now allow defining multiple servers as a comma-delimited
string in :setting:`LOCATION <CACHES-LOCATION>`, for convenience with
@@ -506,7 +507,8 @@ backends.
* The ``DatabaseOperations.datetime_cast_time_sql()`` method is added to
support the :lookup:`time` lookup. It accepts a ``field_name`` and ``tzname``
arguments and returns the SQL necessary to cast a datetime value to time value.
arguments and returns the SQL necessary to cast a datetime value to time
value.
* To enable ``FOR UPDATE SKIP LOCKED`` support, set
``DatabaseFeatures.has_select_for_update_skip_locked = True``.
@@ -831,9 +833,9 @@ Miscellaneous
``contrib.auth.views.logout_then_login()`` is deprecated.
* ``contrib.auth``’s ``password_change()``, ``password_change_done()``,
``password_reset()``, ``password_reset_done()``, ``password_reset_confirm()``,
and ``password_reset_complete()`` function-based views are deprecated in favor
of new class-based views
``password_reset()``, ``password_reset_done()``,
``password_reset_confirm()``, and ``password_reset_complete()``
function-based views are deprecated in favor of new class-based views
:class:`~django.contrib.auth.views.PasswordChangeView`,
:class:`~django.contrib.auth.views.PasswordChangeDoneView`,
:class:`~django.contrib.auth.views.PasswordResetView`,

63
docs/releases/1.2.txt
View File

@@ -49,8 +49,8 @@ These are just the highlights; full details and a complete list of features
Wherever possible these features have been introduced in a backwards-compatible
manner per :doc:`our API stability policy </misc/api-stability>` policy.
However, a handful of features *have* changed in ways that, for some users, will be
backwards-incompatible. The big changes are:
However, a handful of features *have* changed in ways that, for some users,
will be backwards-incompatible. The big changes are:
* Support for Python 2.3 has been dropped. See the full notes
below.
@@ -139,13 +139,13 @@ perform any validation of the instance's data.
Improved CSRF protection
------------------------
Django now has much improved protection against :doc:`Cross-Site Request Forgery
(CSRF) attacks</ref/csrf>`. This type of attack occurs when a malicious
Django now has much improved protection against :doc:`Cross-Site Request
Forgery (CSRF) attacks</ref/csrf>`. This type of attack occurs when a malicious
website contains a link, a form button or some JavaScript that is intended to
perform some action on your website, using the credentials of a logged-in user
who visits the malicious site in their browser. A related type of attack, "login
CSRF," where an attacking site tricks a user's browser into logging into a site
with someone else's credentials, is also covered.
who visits the malicious site in their browser. A related type of attack,
"login CSRF," where an attacking site tricks a user's browser into logging into
a site with someone else's credentials, is also covered.
.. _messages-framework:
@@ -184,8 +184,8 @@ Relaxed requirements for usernames
----------------------------------
The built-in :class:`~django.contrib.auth.models.User` model's
:attr:`~django.contrib.auth.models.User.username` field now allows a wider range
of characters, including ``@``, ``+``, ``.`` and ``-`` characters.
:attr:`~django.contrib.auth.models.User.username` field now allows a wider
range of characters, including ``@``, ``+``, ``.`` and ``-`` characters.
Email backends
--------------
@@ -297,8 +297,8 @@ Both the :djadmin:`test` subcommand of ``django-admin.py`` and the
``--failfast`` option. When specified, this option causes the test runner to
exit after encountering a failure instead of continuing with the test run. In
addition, the handling of ``Ctrl-C`` during a test run has been improved to
trigger a graceful exit from the test run that reports details of the tests that
were run before the interruption.
trigger a graceful exit from the test run that reports details of the tests
that were run before the interruption.
``BigIntegerField``
-------------------
@@ -308,11 +308,11 @@ Models can now use a 64-bit :class:`~django.db.models.BigIntegerField` type.
Improved localization
---------------------
Django's :doc:`internationalization framework </topics/i18n/index>` has been expanded
with locale-aware formatting and form processing. That means, if enabled, dates
and numbers on templates will be displayed using the format specified for the
current locale. Django will also use localized formats when parsing data in
forms. See :doc:`/topics/i18n/formatting` for more details.
Django's :doc:`internationalization framework </topics/i18n/index>` has been
expanded with locale-aware formatting and form processing. That means, if
enabled, dates and numbers on templates will be displayed using the format
specified for the current locale. Django will also use localized formats when
parsing data in forms. See :doc:`/topics/i18n/formatting` for more details.
``readonly_fields`` in ``ModelAdmin``
-------------------------------------
@@ -631,24 +631,24 @@ wrapping other objects of unknown type.
In Django 1.1 and earlier, it handled introspection in a non-standard way,
depending on wrapped objects implementing a public method named
``get_all_members()``. Since this could easily lead to name clashes, it has been
changed to use the standard Python introspection method, involving
``get_all_members()``. Since this could easily lead to name clashes, it has
been changed to use the standard Python introspection method, involving
``__members__`` and ``__dir__()``.
If you used ``LazyObject`` in your own code
and implemented the ``get_all_members()`` method for wrapped objects, you'll need
to make a couple of changes:
and implemented the ``get_all_members()`` method for wrapped objects, you'll
need to make a couple of changes:
First, if your class does not have special requirements for introspection (i.e.,
you have not implemented ``__getattr__()`` or other methods that allow for
attributes not discoverable by normal mechanisms), you can simply remove the
``get_all_members()`` method. The default implementation on ``LazyObject`` will
do the right thing.
First, if your class does not have special requirements for introspection
(i.e., you have not implemented ``__getattr__()`` or other methods that allow
for attributes not discoverable by normal mechanisms), you can simply remove
the ``get_all_members()`` method. The default implementation on ``LazyObject``
will do the right thing.
If you have more complex requirements for introspection, first rename the
``get_all_members()`` method to ``__dir__()``. This is the standard
introspection method for Python 2.6 and above. If you require support for Python
versions earlier than 2.6, add the following code to the class::
introspection method for Python 2.6 and above. If you require support for
Python versions earlier than 2.6, add the following code to the class::
__members__ = property(lambda self: self.__dir__())
@@ -743,9 +743,9 @@ will need to update your FormSet and/or admin definitions.
``email_re``
------------
An undocumented regular expression for validating email addresses has been moved
from ``django.form.fields`` to ``django.core.validators``. You will need to
update your imports if you are using it.
An undocumented regular expression for validating email addresses has been
moved from ``django.form.fields`` to ``django.core.validators``. You will need
to update your imports if you are using it.
.. _deprecated-features-1.2:
@@ -911,7 +911,8 @@ User Messages API
The API for storing messages in the user ``Message`` model (via
``user.message_set.create``) is now deprecated and will be removed in Django
1.4 according to the standard :doc:`release process </internals/release-process>`.
1.4 according to the standard
:doc:`release process </internals/release-process>`.
To upgrade your code, you need to replace any instances of this::

14
docs/releases/1.3.6.txt
View File

@@ -16,11 +16,11 @@ Host header poisoning
Some parts of Django -- independent of end-user-written applications -- make
use of full URLs, including domain name, which are generated from the HTTP Host
header. Django's documentation has for some time contained notes advising users
on how to configure web servers to ensure that only valid Host headers can reach
the Django application. However, it has been reported to us that even with the
recommended web server configurations there are still techniques available for
tricking many common web servers into supplying the application with an
incorrect and possibly malicious Host header.
on how to configure web servers to ensure that only valid Host headers can
reach the Django application. However, it has been reported to us that even
with the recommended web server configurations there are still techniques
available for tricking many common web servers into supplying the application
with an incorrect and possibly malicious Host header.
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which
should contain an explicit list of valid host/domain names for this site. A
@@ -32,8 +32,8 @@ The default value for this setting in Django 1.3.6 is ``['*']`` (matching any
host), for backwards-compatibility, but we strongly encourage all sites to set
a more restrictive value.
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests.
This host validation is disabled when ``DEBUG`` is ``True`` or when running
tests.
XML deserialization
===================

20
docs/releases/1.3.txt
View File

@@ -69,10 +69,10 @@ provided, along with a completely generic view base class that can be
used as the basis for reusable applications that can be easily
extended.
See :doc:`the documentation on class-based generic views</topics/class-based-views/index>`
for more details. There is also a document to help you `convert
your function-based generic views to class-based
views <https://raw.githubusercontent.com/django/django/ea9dc9f4b03ae034c1dc080730422dda7a9c2e47/docs/topics/generic-views-migration.txt>`_.
See :doc:`the documentation on class-based generic views
</topics/class-based-views/index>` for more details. There is also a document
to help you `convert your function-based generic views to class-based views
<https://raw.githubusercontent.com/django/django/ea9dc9f4b03ae034c1dc080730422dda7a9c2e47/docs/topics/generic-views-migration.txt>`__.
Logging
-------
@@ -520,9 +520,9 @@ behavior:
u'&lt;bound method User.get_full_name of &lt;...
This has been resolved in Django 1.3 - the result in both cases will be ``u'Joe
Bloggs'``. Although the previous behavior was not useful for a template language
designed for web designers, and was never deliberately supported, it is possible
that some templates may be broken by this change.
Bloggs'``. Although the previous behavior was not useful for a template
language designed for web designers, and was never deliberately supported, it
is possible that some templates may be broken by this change.
Use of custom SQL to load initial data in tests
-----------------------------------------------
@@ -580,9 +580,9 @@ gettext domain):
* The ``locale`` subdirectory of the directory containing the settings, that
usually coincides with and is known as the *project directory* is being
deprecated in this release as a source of translations. (the precedence of
these translations is intermediate between applications and :setting:`LOCALE_PATHS`
translations). See the `corresponding deprecated features section`_
of this document.
these translations is intermediate between applications and
:setting:`LOCALE_PATHS` translations). See the `corresponding deprecated
features section`_ of this document.
For translatable literals found in JavaScript code (``'djangojs'`` gettext
domain):

12
docs/releases/1.4.13.txt
View File

@@ -23,10 +23,10 @@ types. Therefore, Django would remove the header if the request was made by
Internet Explorer.
To remedy this, the special behavior for these older Internet Explorer versions
has been removed, and the ``Vary`` header is no longer stripped from the response.
In addition, modifications to the ``Cache-Control`` header for all Internet Explorer
requests with a ``Content-Disposition`` header have also been removed as they
were found to have similar issues.
has been removed, and the ``Vary`` header is no longer stripped from the
response. In addition, modifications to the ``Cache-Control`` header for all
Internet Explorer requests with a ``Content-Disposition`` header have also been
removed as they were found to have similar issues.
Malformed redirect URLs from user input not correctly validated
===============================================================
@@ -43,5 +43,5 @@ The security checks for these redirects (namely
URLs, such as ``http:\\\\\\djangoproject.com``, which are accepted by some
browsers with more liberal URL parsing.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be able
to handle and correctly validate these malformed URLs.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be
able to handle and correctly validate these malformed URLs.

22
docs/releases/1.4.14.txt
View File

@@ -24,20 +24,20 @@ File upload denial-of-service
Before this release, Django's file upload handing in its default configuration
may degrade to producing a huge number of ``os.stat()`` system calls when a
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may
produce a huge data-dependent slowdown that slowly worsens over time. The net
result is that given enough time, a user with the ability to upload files can
cause poor performance in the upload handler, eventually causing it to become
very slow simply by uploading 0-byte files. At this point, even a slow network
connection and few HTTP requests would be all that is necessary to make a site
unavailable.
We've remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
:meth:`Storage.get_available_name()
We've remedied the issue by changing the algorithm for generating file names if
a file with the uploaded name already exists. :meth:`Storage.get_available_name
<django.core.files.storage.Storage.get_available_name>` now appends an
underscore plus a random 7 character alphanumeric string (e.g. ``"_x3a1gho"``),
rather than iterating through an underscore followed by a number (e.g. ``"_1"``,
``"_2"``, etc.).
rather than iterating through an underscore followed by a number (e.g.
``"_1"``, ``"_2"``, etc.).
``RemoteUserMiddleware`` session hijacking
==========================================

6
docs/releases/1.4.2.txt
View File

@@ -50,9 +50,11 @@ Other bugfixes and changes
* Subclass HTMLParser only for appropriate Python versions (#18239).
* Added batch_size argument to qs.bulk_create() (#17788).
* Fixed a small regression in the admin filters where wrongly formatted dates passed as url parameters caused an unhandled ValidationError (#18530).
* Fixed a small regression in the admin filters where wrongly formatted dates
passed as url parameters caused an unhandled ValidationError (#18530).
* Fixed an endless loop bug when accessing permissions in templates (#18979)
* Fixed some Python 2.5 compatibility issues
* Fixed an issue with quoted filenames in Content-Disposition header (#19006)
* Made the context option in ``trans`` and ``blocktrans`` tags accept literals wrapped in single quotes (#18881).
* Made the context option in ``trans`` and ``blocktrans`` tags accept literals
wrapped in single quotes (#18881).
* Numerous documentation improvements and fixes.

16
docs/releases/1.4.4.txt
View File

@@ -17,11 +17,11 @@ Host header poisoning
Some parts of Django -- independent of end-user-written applications -- make
use of full URLs, including domain name, which are generated from the HTTP Host
header. Django's documentation has for some time contained notes advising users
on how to configure web servers to ensure that only valid Host headers can reach
the Django application. However, it has been reported to us that even with the
recommended web server configurations there are still techniques available for
tricking many common web servers into supplying the application with an
incorrect and possibly malicious Host header.
on how to configure web servers to ensure that only valid Host headers can
reach the Django application. However, it has been reported to us that even
with the recommended web server configurations there are still techniques
available for tricking many common web servers into supplying the application
with an incorrect and possibly malicious Host header.
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing
an explicit list of valid host/domain names for this site. A request with a
@@ -33,7 +33,8 @@ The default value for this setting in Django 1.4.4 is ``['*']`` (matching any
host), for backwards-compatibility, but we strongly encourage all sites to set
a more restrictive value.
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests.
This host validation is disabled when ``DEBUG`` is ``True`` or when running
tests.
XML deserialization
@@ -82,7 +83,8 @@ to users with change permission for that model.
Other bugfixes and changes
==========================
* Prevented transaction state from leaking from one request to the next (#19707).
* Prevented transaction state from leaking from one request to the next
(#19707).
* Changed an SQL command syntax to be MySQL 4 compatible (#19702).
* Added backwards-compatibility with old unsalted MD5 passwords (#18144).
* Numerous documentation improvements and fixes.

91
docs/releases/1.4.txt
View File

@@ -21,10 +21,11 @@ handling date/times. When enabled, this Django will store date/times in UTC,
use timezone-aware objects internally, and translate them to users' local
timezones for display.
If you're upgrading an existing project to Django 1.4, switching to the timezone
aware mode may take some care: the new mode disallows some rather sloppy
behavior that used to be accepted. We encourage anyone who's upgrading to check
out the :ref:`timezone migration guide <time-zones-migration-guide>` and the
If you're upgrading an existing project to Django 1.4, switching to the
timezone aware mode may take some care: the new mode disallows some rather
sloppy behavior that used to be accepted. We encourage anyone who's upgrading
to check out the :ref:`timezone migration guide <time-zones-migration-guide>`
and the
:ref:`timezone FAQ <time-zones-faq>` for useful pointers.
Other notable new features in Django 1.4 include:
@@ -63,9 +64,9 @@ required Python version. Django is tested and supported on Python 2.5, 2.6 and
2.7.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.5 or newer as their default
version. If you're still using Python 2.4, however, you'll need to stick to
Django 1.3 until you can upgrade. Per :doc:`our support policy
operating-system vendors today are shipping Python 2.5 or newer as their
default version. If you're still using Python 2.4, however, you'll need to
stick to Django 1.3 until you can upgrade. Per :doc:`our support policy
</internals/release-process>`, Django 1.3 will continue to receive security
support until the release of Django 1.5.
@@ -274,10 +275,10 @@ Improved password hashing
Django's auth system (``django.contrib.auth``) stores passwords using a one-way
algorithm. Django 1.3 uses the SHA1_ algorithm, but increasing processor speeds
and theoretical attacks have revealed that SHA1 isn't as secure as we'd like.
Thus, Django 1.4 introduces a new password storage system: by default Django now
uses the PBKDF2_ algorithm (as recommended by NIST_). You can also easily choose
a different algorithm (including the popular bcrypt_ algorithm). For more
details, see :ref:`auth_password_storage`.
Thus, Django 1.4 introduces a new password storage system: by default Django
now uses the PBKDF2_ algorithm (as recommended by NIST_). You can also easily
choose a different algorithm (including the popular bcrypt_ algorithm). For
more details, see :ref:`auth_password_storage`.
.. _sha1: https://en.wikipedia.org/wiki/SHA1
.. _pbkdf2: https://en.wikipedia.org/wiki/PBKDF2
@@ -306,8 +307,8 @@ Multiple sort in admin interface
--------------------------------
The admin change list now supports sorting on multiple columns. It respects all
elements of the :attr:`~django.contrib.admin.ModelAdmin.ordering` attribute, and
sorting on multiple columns by clicking on headers is designed to mimic the
elements of the :attr:`~django.contrib.admin.ModelAdmin.ordering` attribute,
and sorting on multiple columns by clicking on headers is designed to mimic the
behavior of desktop GUIs. We also added a
:meth:`~django.contrib.admin.ModelAdmin.get_ordering` method for specifying the
ordering dynamically (i.e., depending on the request).
@@ -431,8 +432,8 @@ number of positional or keyword arguments. For example::
...
return ...
Then, in the template, any number of arguments may be passed to the template tag.
For example:
Then, in the template, any number of arguments may be passed to the template
tag. For example:
.. code-block:: html+django
@@ -495,8 +496,8 @@ CSRF improvements
We've made various improvements to our CSRF features, including the
:func:`~django.views.decorators.csrf.ensure_csrf_cookie` decorator, which can
help with AJAX-heavy sites; protection for PUT and DELETE requests; and the
:setting:`CSRF_COOKIE_SECURE` and :setting:`CSRF_COOKIE_PATH` settings, which can
improve the security and usefulness of CSRF protection. See the :doc:`CSRF
:setting:`CSRF_COOKIE_SECURE` and :setting:`CSRF_COOKIE_PATH` settings, which
can improve the security and usefulness of CSRF protection. See the :doc:`CSRF
docs </ref/csrf>` for more information.
Error report filtering
@@ -593,8 +594,8 @@ Django 1.4 also includes several smaller improvements worth noting:
MySQL with the InnoDB database engine.
* A new 403 response handler has been added as
``'django.views.defaults.permission_denied'``. You can set your own handler by
setting the value of :data:`django.conf.urls.handler403`. See the
``'django.views.defaults.permission_denied'``. You can set your own handler
by setting the value of :data:`django.conf.urls.handler403`. See the
documentation about :ref:`the 403 (HTTP Forbidden) view<http_forbidden_view>`
for more information.
@@ -609,9 +610,9 @@ Django 1.4 also includes several smaller improvements worth noting:
* The :ttag:`if` template tag now supports ``{% elif %}`` clauses.
* If your Django app is behind a proxy, you might find the new
:setting:`SECURE_PROXY_SSL_HEADER` setting useful. It solves the problem of your
proxy "eating" the fact that a request came in via HTTPS. But only use this
setting if you know what you're doing.
:setting:`SECURE_PROXY_SSL_HEADER` setting useful. It solves the problem of
your proxy "eating" the fact that a request came in via HTTPS. But only use
this setting if you know what you're doing.
* A new, plain-text, version of the HTTP 500 status code internal error page
served when :setting:`DEBUG` is ``True`` is now sent to the client when
@@ -634,8 +635,8 @@ Django 1.4 also includes several smaller improvements worth noting:
``DISTINCT ON``.
The ``distinct()`` ``QuerySet`` method now accepts an optional list of model
field names. If specified, then the ``DISTINCT`` statement is limited to these
fields. This is only supported in PostgreSQL.
field names. If specified, then the ``DISTINCT`` statement is limited to
these fields. This is only supported in PostgreSQL.
For more details, see the documentation for
:meth:`~django.db.models.query.QuerySet.distinct`.
@@ -797,10 +798,11 @@ instance:
* ``contrib.comments`` form security hash
* Consequences: The user will see the validation error "Security hash failed."
* Consequences: The user will see the validation error "Security hash
failed."
* Time period: The amount of time you expect users to take filling out comment
forms.
* Time period: The amount of time you expect users to take filling out
comment forms.
* ``FormWizard`` security hash
@@ -1026,9 +1028,9 @@ keyword argument.
``django.core.template_loaders``
--------------------------------
This was an alias to ``django.template.loader`` since 2005, and we've removed it
without emitting a warning due to the length of the deprecation. If your code
still referenced this, please use ``django.template.loader`` instead.
This was an alias to ``django.template.loader`` since 2005, and we've removed
it without emitting a warning due to the length of the deprecation. If your
code still referenced this, please use ``django.template.loader`` instead.
``django.db.models.fields.URLField.verify_exists``
--------------------------------------------------
@@ -1147,11 +1149,12 @@ changed, which may break any custom tags that use this class.
Loading some incomplete fixtures no longer works
------------------------------------------------
Prior to 1.4, a default value was inserted for fixture objects that were missing
a specific date or datetime value when auto_now or auto_now_add was set for the
field. This was something that should not have worked, and in 1.4 loading such
incomplete fixtures will fail. Because fixtures are a raw import, they should
explicitly specify all field values, regardless of field options on the model.
Prior to 1.4, a default value was inserted for fixture objects that were
missing a specific date or datetime value when auto_now or auto_now_add was set
for the field. This was something that should not have worked, and in 1.4
loading such incomplete fixtures will fail. Because fixtures are a raw import,
they should explicitly specify all field values, regardless of field options on
the model.
Development Server Multithreading
---------------------------------
@@ -1254,16 +1257,17 @@ disable this backward-compatibility shim and deprecation warning.
-----------------------------
Until Django 1.3, the ``include()``, ``patterns()``, and ``url()`` functions,
plus :data:`~django.conf.urls.handler404` and :data:`~django.conf.urls.handler500`
were located in a ``django.conf.urls.defaults`` module.
plus :data:`~django.conf.urls.handler404` and
:data:`~django.conf.urls.handler500` were located in a
``django.conf.urls.defaults`` module.
In Django 1.4, they live in :mod:`django.conf.urls`.
``django.contrib.databrowse``
-----------------------------
Databrowse has not seen active development for some time, and this does not show
any sign of changing. There had been a suggestion for a `GSOC project`_ to
Databrowse has not seen active development for some time, and this does not
show any sign of changing. There had been a suggestion for a `GSOC project`_ to
integrate the functionality of databrowse into the admin, but no progress was
made. While Databrowse has been deprecated, an enhancement of
``django.contrib.admin`` providing a similar feature set is still possible.
@@ -1301,9 +1305,9 @@ path is needed due to use in existing ``manage.py`` files.
``is_safe`` and ``needs_autoescape`` attributes of template filters
-------------------------------------------------------------------
Two flags, ``is_safe`` and ``needs_autoescape``, define how each template filter
interacts with Django's auto-escaping behavior. They used to be attributes of
the filter function::
Two flags, ``is_safe`` and ``needs_autoescape``, define how each template
filter interacts with Django's auto-escaping behavior. They used to be
attributes of the filter function::
@register.filter
def noop(value):
@@ -1321,7 +1325,8 @@ Now, the flags are keyword arguments of :meth:`@register.filter
def noop(value):
return value
See :ref:`filters and auto-escaping <filters-auto-escaping>` for more information.
See :ref:`filters and auto-escaping <filters-auto-escaping>` for more
information.
Wildcard expansion of application names in ``INSTALLED_APPS``
-------------------------------------------------------------

4
docs/releases/1.5.1.txt
View File

@@ -4,8 +4,8 @@ Django 1.5.1 release notes
*March 28, 2013*
This is Django 1.5.1, a bugfix release for Django 1.5. It's completely backwards
compatible with Django 1.5, but includes a handful of fixes.
This is Django 1.5.1, a bugfix release for Django 1.5. It's completely
backwards compatible with Django 1.5, but includes a handful of fixes.
The biggest fix is for a memory leak introduced in Django 1.5. Under certain
circumstances, repeated iteration over querysets could leak memory - sometimes

12
docs/releases/1.5.8.txt
View File

@@ -23,10 +23,10 @@ types. Therefore, Django would remove the header if the request was made by
Internet Explorer.
To remedy this, the special behavior for these older Internet Explorer versions
has been removed, and the ``Vary`` header is no longer stripped from the response.
In addition, modifications to the ``Cache-Control`` header for all Internet Explorer
requests with a ``Content-Disposition`` header have also been removed as they
were found to have similar issues.
has been removed, and the ``Vary`` header is no longer stripped from the
response. In addition, modifications to the ``Cache-Control`` header for all
Internet Explorer requests with a ``Content-Disposition`` header have also been
removed as they were found to have similar issues.
Malformed redirect URLs from user input not correctly validated
===============================================================
@@ -43,5 +43,5 @@ The security checks for these redirects (namely
URLs, such as ``http:\\\\\\djangoproject.com``, which are accepted by some
browsers with more liberal URL parsing.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be able
to handle and correctly validate these malformed URLs.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be
able to handle and correctly validate these malformed URLs.

22
docs/releases/1.5.9.txt
View File

@@ -24,20 +24,20 @@ File upload denial-of-service
Before this release, Django's file upload handing in its default configuration
may degrade to producing a huge number of ``os.stat()`` system calls when a
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may
produce a huge data-dependent slowdown that slowly worsens over time. The net
result is that given enough time, a user with the ability to upload files can
cause poor performance in the upload handler, eventually causing it to become
very slow simply by uploading 0-byte files. At this point, even a slow network
connection and few HTTP requests would be all that is necessary to make a site
unavailable.
We've remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
:meth:`Storage.get_available_name()
We've remedied the issue by changing the algorithm for generating file names if
a file with the uploaded name already exists. :meth:`Storage.get_available_name
<django.core.files.storage.Storage.get_available_name>` now appends an
underscore plus a random 7 character alphanumeric string (e.g. ``"_x3a1gho"``),
rather than iterating through an underscore followed by a number (e.g. ``"_1"``,
``"_2"``, etc.).
rather than iterating through an underscore followed by a number (e.g.
``"_1"``, ``"_2"``, etc.).
``RemoteUserMiddleware`` session hijacking
==========================================

84
docs/releases/1.5.txt
View File

@@ -18,11 +18,11 @@ Overview
The biggest new feature in Django 1.5 is the `configurable User model`_. Before
Django 1.5, applications that wanted to use Django's auth framework
(:mod:`django.contrib.auth`) were forced to use Django's definition of a "user".
In Django 1.5, you can now swap out the ``User`` model for one that you write
yourself. This could be a simple extension to the existing ``User`` model -- for
example, you could add a Twitter or Facebook ID field -- or you could completely
replace the ``User`` with one totally customized for your site.
(:mod:`django.contrib.auth`) were forced to use Django's definition of a
"user". In Django 1.5, you can now swap out the ``User`` model for one that you
write yourself. This could be a simple extension to the existing ``User`` model
-- for example, you could add a Twitter or Facebook ID field -- or you could
completely replace the ``User`` with one totally customized for your site.
Django 1.5 is also the first release with `Python 3 support`_! We're labeling
this support "experimental" because we don't yet consider it production-ready,
@@ -50,11 +50,11 @@ However, as with previous releases, Django 1.5 ships with some minor
:ref:`backwards incompatible changes <backwards-incompatible-1.5>`; people
upgrading from previous versions of Django should read that list carefully.
One deprecated feature worth noting is the shift to "new-style" :ttag:`url` tag.
Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
One deprecated feature worth noting is the shift to "new-style" :ttag:`url`
tag. Prior to Django 1.3, syntax like ``{% url myview %}`` was interpreted
incorrectly (Django considered ``"myview"`` to be a literal name of a view, not
a template variable named ``myview``). Django 1.3 and above introduced the
``{% load url from future %}`` syntax to bring in the corrected behavior where
a template variable named ``myview``). Django 1.3 and above introduced the ``{%
load url from future %}`` syntax to bring in the corrected behavior where
``myview`` was seen as a variable.
The upshot of this is that if you are not using ``{% load url from future %}``
@@ -69,16 +69,16 @@ Django 1.5 requires Python 2.6.5 or above, though we **highly recommend**
Python 2.7.3 or above. Support for Python 2.5 and below has been dropped.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.6 or newer as their default
version. If you're still using Python 2.5, however, you'll need to stick to
Django 1.4 until you can upgrade your Python version. Per :doc:`our support
policy </internals/release-process>`, Django 1.4 will continue to receive
security support until the release of Django 1.6.
operating-system vendors today are shipping Python 2.6 or newer as their
default version. If you're still using Python 2.5, however, you'll need to
stick to Django 1.4 until you can upgrade your Python version. Per :doc:`our
support policy </internals/release-process>`, Django 1.4 will continue to
receive security support until the release of Django 1.6.
Django 1.5 does not run on a Jython final release, because Jython's latest
release doesn't currently support Python 2.6. However, Jython currently does
offer an alpha release featuring 2.7 support, and Django 1.5 supports that alpha
release.
offer an alpha release featuring 2.7 support, and Django 1.5 supports that
alpha release.
Python 3 support
----------------
@@ -200,28 +200,30 @@ tag's content.
Retrieval of ``ContentType`` instances associated with proxy models
-------------------------------------------------------------------
The methods :meth:`ContentTypeManager.get_for_model() <django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
and :meth:`ContentTypeManager.get_for_models() <django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
have a new keyword argument – respectively ``for_concrete_model`` and ``for_concrete_models``.
By passing ``False`` using this argument it is now possible to retrieve the
:class:`ContentType <django.contrib.contenttypes.models.ContentType>`
associated with proxy models.
The methods :meth:`ContentTypeManager.get_for_model()
<django.contrib.contenttypes.models.ContentTypeManager.get_for_model()>`
and :meth:`ContentTypeManager.get_for_models()
<django.contrib.contenttypes.models.ContentTypeManager.get_for_models()>`
have a new keyword argument – respectively ``for_concrete_model`` and
``for_concrete_models``. By passing ``False`` using this argument it is now
possible to retrieve the :class:`ContentType
<django.contrib.contenttypes.models.ContentType>` associated with proxy models.
New ``view`` variable in class-based views context
--------------------------------------------------
In all :doc:`generic class-based views </topics/class-based-views/index>`
(or any class-based view inheriting from ``ContextMixin``), the context dictionary
contains a ``view`` variable that points to the ``View`` instance.
(or any class-based view inheriting from ``ContextMixin``), the context
dictionary contains a ``view`` variable that points to the ``View`` instance.
GeoDjango
---------
* :class:`~django.contrib.gis.geos.LineString` and
:class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support the
:meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate` and
:meth:`~django.contrib.gis.geos.GEOSGeometry.project` methods
(so-called linear referencing).
:class:`~django.contrib.gis.geos.MultiLineString` GEOS objects now support
the :meth:`~django.contrib.gis.geos.GEOSGeometry.interpolate` and
:meth:`~django.contrib.gis.geos.GEOSGeometry.project` methods (so-called
linear referencing).
* The ``wkb`` and ``hex`` properties of
:class:`~django.contrib.gis.geos.GEOSGeometry` objects preserve the Z
@@ -305,10 +307,10 @@ Django 1.5 also includes several smaller improvements worth noting:
in templates.
* It's not required any more to have ``404.html`` and ``500.html`` templates in
the root templates directory. Django will output some basic error messages for
both situations when those templates are not found. It's still recommended as
good practice to provide those templates in order to present pretty error
pages to the user.
the root templates directory. Django will output some basic error messages
for both situations when those templates are not found. It's still
recommended as good practice to provide those templates in order to present
pretty error pages to the user.
* :mod:`django.contrib.auth` provides a new signal that is emitted
whenever a user fails to login successfully. See
@@ -425,8 +427,8 @@ Non-form data in HTTP requests
------------------------------
:attr:`request.POST <django.http.HttpRequest.POST>` will no longer include data
posted via HTTP requests with non form-specific content-types in the header.
In prior versions, data posted with content-types other than
posted via HTTP requests with non form-specific content-types in the header. In
prior versions, data posted with content-types other than
:mimetype:`multipart/form-data` or
:mimetype:`application/x-www-form-urlencoded` would still end up represented in
the :attr:`request.POST <django.http.HttpRequest.POST>` attribute. Developers
@@ -606,8 +608,8 @@ tests are now executed in the following order:
* First, all unit tests (including :class:`unittest.TestCase`,
:class:`~django.test.SimpleTestCase`, :class:`~django.test.TestCase` and
:class:`~django.test.TransactionTestCase`) are run with no particular ordering
guaranteed nor enforced among them.
:class:`~django.test.TransactionTestCase`) are run with no particular
ordering guaranteed nor enforced among them.
* Then any other tests (e.g. doctests) that may alter the database without
restoring it to its original state are run.
@@ -679,8 +681,8 @@ Miscellaneous
needs. The new default value is ``0o666`` (octal) and the current umask value
is first masked out.
* The :class:`F expressions <django.db.models.F>` supported bitwise operators by
``&`` and ``|``. These operators are now available using ``.bitand()`` and
* The :class:`F expressions <django.db.models.F>` supported bitwise operators
by ``&`` and ``|``. These operators are now available using ``.bitand()`` and
``.bitor()`` instead. The removal of ``&`` and ``|`` was done to be
consistent with :ref:`Q() expressions <complex-lookups-with-q>` and
``QuerySet`` combining where the operators are used as boolean AND and OR
@@ -692,9 +694,9 @@ Miscellaneous
and now F() expressions will always use the same relations as other lookups
within the same ``filter()`` call.
* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you need
HTML validation against pre-HTML5 Strict DTDs, you should add a div around it
in your pages.
* The :ttag:`csrf_token` template tag is no longer enclosed in a div. If you
need HTML validation against pre-HTML5 Strict DTDs, you should add a div
around it in your pages.
* The template tags library ``adminmedia``, which only contained the
deprecated template tag ``{% admin_media_prefix %}``, was removed.

9
docs/releases/1.6.1.txt
View File

@@ -50,10 +50,11 @@ Bug fixes
(#21530).
* Re-added missing search result count and reset link in changelist admin view
(#21510).
* The current language is no longer saved to the session by ``LocaleMiddleware``
on every response, but rather only after a logout (#21473).
* Fixed a crash when executing ``runserver`` on non-English systems and when the
formatted date in its output contained non-ASCII characters (#21358).
* The current language is no longer saved to the session by
``LocaleMiddleware`` on every response, but rather only after a logout
(#21473).
* Fixed a crash when executing ``runserver`` on non-English systems and when
the formatted date in its output contained non-ASCII characters (#21358).
* Fixed a crash in the debug view after an exception occurred on Python ≥ 3.3
(#21443).
* Fixed a crash in :class:`~django.db.models.ImageField` on some platforms

4
docs/releases/1.6.3.txt
View File

@@ -172,8 +172,8 @@ Other bugfixes and changes
* Wrapped database exceptions in ``_set_autocommit``
(:ticket:`22321`).
* Fixed atomicity when closing a database connection or when the database server
disconnects (:ticket:`21239` and :ticket:`21202`)
* Fixed atomicity when closing a database connection or when the database
server disconnects (:ticket:`21239` and :ticket:`21202`)
* Fixed regression in ``prefetch_related`` that caused the related objects
query to include an unnecessary join

16
docs/releases/1.6.5.txt
View File

@@ -23,10 +23,10 @@ types. Therefore, Django would remove the header if the request was made by
Internet Explorer.
To remedy this, the special behavior for these older Internet Explorer versions
has been removed, and the ``Vary`` header is no longer stripped from the response.
In addition, modifications to the ``Cache-Control`` header for all Internet Explorer
requests with a ``Content-Disposition`` header have also been removed as they
were found to have similar issues.
has been removed, and the ``Vary`` header is no longer stripped from the
response. In addition, modifications to the ``Cache-Control`` header for all
Internet Explorer requests with a ``Content-Disposition`` header have also been
removed as they were found to have similar issues.
Issue: Malformed redirect URLs from user input not correctly validated
======================================================================
@@ -43,8 +43,8 @@ The security checks for these redirects (namely
URLs, such as ``http:\\\\\\djangoproject.com``, which are accepted by some
browsers with more liberal URL parsing.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be able
to handle and correctly validate these malformed URLs.
To remedy this, the validation in ``is_safe_url()`` has been tightened to be
able to handle and correctly validate these malformed URLs.
Bugfixes
========
@@ -55,8 +55,8 @@ Bugfixes
* Fixed ``pgettext_lazy`` crash when receiving bytestring content on Python 2
(:ticket:`22565`).
* Fixed the SQL generated when filtering by a negated ``Q`` object that contains
a ``F`` object. (:ticket:`22429`).
* Fixed the SQL generated when filtering by a negated ``Q`` object that
contains a ``F`` object. (:ticket:`22429`).
* Avoided overwriting data fetched by ``select_related()`` in certain cases
which could cause minor performance regressions

21
docs/releases/1.6.6.txt
View File

@@ -24,20 +24,21 @@ File upload denial-of-service
Before this release, Django's file upload handing in its default configuration
may degrade to producing a huge number of ``os.stat()`` system calls when a
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may produce
a huge data-dependent slowdown that slowly worsens over time. The net result is
that given enough time, a user with the ability to upload files can cause poor
performance in the upload handler, eventually causing it to become very slow
simply by uploading 0-byte files. At this point, even a slow network connection
and few HTTP requests would be all that is necessary to make a site unavailable.
duplicate filename is uploaded. Since ``stat()`` may invoke IO, this may
produce a huge data-dependent slowdown that slowly worsens over time. The net
result is that given enough time, a user with the ability to upload files can
cause poor performance in the upload handler, eventually causing it to become
very slow simply by uploading 0-byte files. At this point, even a slow network
connection and few HTTP requests would be all that is necessary to make a site
unavailable.
We've remedied the issue by changing the algorithm for generating file names
if a file with the uploaded name already exists.
:meth:`Storage.get_available_name()
<django.core.files.storage.Storage.get_available_name>` now appends an
underscore plus a random 7 character alphanumeric string (e.g. ``"_x3a1gho"``),
rather than iterating through an underscore followed by a number (e.g. ``"_1"``,
``"_2"``, etc.).
rather than iterating through an underscore followed by a number (e.g.
``"_1"``, ``"_2"``, etc.).
``RemoteUserMiddleware`` session hijacking
==========================================
@@ -90,8 +91,8 @@ Bugfixes
* Prevented ``UnicodeDecodeError`` in ``runserver`` with non-UTF-8 and
non-English locale (:ticket:`23265`).
* Fixed JavaScript errors while editing multi-geometry objects in the OpenLayers
widget (:ticket:`23137`, :ticket:`23293`).
* Fixed JavaScript errors while editing multi-geometry objects in the
OpenLayers widget (:ticket:`23137`, :ticket:`23293`).
* Prevented a crash on Python 3 with query strings containing unencoded
non-ASCII characters (:ticket:`22996`).

117
docs/releases/1.6.txt
View File

@@ -1,6 +1,6 @@
=========================
Django 1.6 release notes
=========================
========================
Django 1.6 release notes
========================
.. note::
@@ -10,11 +10,11 @@
a very dear friend and developer.
Malcolm was a long-time contributor to Django, a model community member, a
brilliant mind, and a friend. His contributions to Django — and to many other
open source projects — are nearly impossible to enumerate. Many on the core
Django team had their first patches reviewed by him; his mentorship enriched
us. His consideration, patience, and dedication will always be an inspiration
to us.
brilliant mind, and a friend. His contributions to Django — and to many
other open source projects — are nearly impossible to enumerate. Many on
the core Django team had their first patches reviewed by him; his
mentorship enriched us. His consideration, patience, and dedication will
always be an inspiration to us.
This release of Django is for Malcolm.
@@ -126,9 +126,10 @@ binary data in the database.
GeoDjango form widgets
----------------------
GeoDjango now provides :doc:`form fields and widgets </ref/contrib/gis/forms-api>`
for its geo-specialized fields. They are OpenLayers-based by default, but they
can be customized to use any other JS framework.
GeoDjango now provides :doc:`form fields and widgets
</ref/contrib/gis/forms-api>` for its geo-specialized fields. They are
OpenLayers-based by default, but they can be customized to use any other JS
framework.
``check`` management command added for verifying compatibility
--------------------------------------------------------------
@@ -341,10 +342,11 @@ Minor features
:ref:`see the updated recommendation <raising-validation-error>` for raising
a ``ValidationError``.
* :class:`~django.contrib.admin.ModelAdmin` now preserves filters on the list view
after creating, editing or deleting an object. It's possible to restore the previous
behavior of clearing filters by setting the
:attr:`~django.contrib.admin.ModelAdmin.preserve_filters` attribute to ``False``.
* :class:`~django.contrib.admin.ModelAdmin` now preserves filters on the list
view after creating, editing or deleting an object. It's possible to restore
the previous behavior of clearing filters by setting the
:attr:`~django.contrib.admin.ModelAdmin.preserve_filters` attribute to
``False``.
* Added
:meth:`FormMixin.get_prefix<django.views.generic.edit.FormMixin.get_prefix>`
@@ -450,8 +452,8 @@ Custom user models in tests
---------------------------
The introduction of the new test runner has also slightly changed the way that
test models are imported. As a result, any test that overrides ``AUTH_USER_MODEL``
to test behavior with one of Django's test user models (
test models are imported. As a result, any test that overrides
``AUTH_USER_MODEL`` to test behavior with one of Django's test user models (
``django.contrib.auth.tests.custom_user.CustomUser`` and
``django.contrib.auth.tests.custom_user.ExtensionUser``) must now
explicitly import the User model in your test module::
@@ -471,7 +473,8 @@ error reporting:
.. code-block:: pytb
ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed
ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that
has not been installed
Time zone-aware ``day``, ``month``, and ``week_day`` lookups
------------------------------------------------------------
@@ -652,10 +655,11 @@ hardcoded sentence:
*Hold down "Control", or "Command" on a Mac, to select more than one.*
(or its translation to the active locale) imposed as the help legend shown along
them if neither :attr:`model <django.db.models.Field.help_text>` nor :attr:`form
<django.forms.Field.help_text>` ``help_text`` attributes were specified by the
user (or this string was appended to any ``help_text`` that was provided).
(or its translation to the active locale) imposed as the help legend shown
along them if neither :attr:`model <django.db.models.Field.help_text>` nor
:attr:`form <django.forms.Field.help_text>` ``help_text`` attributes were
specified by the user (or this string was appended to any ``help_text`` that
was provided).
Since this happened at the model layer, there was no way to prevent the text
from appearing in cases where it wasn't applicable such as form fields that
@@ -871,8 +875,8 @@ Miscellaneous
corresponding field type.
* Form field's :attr:`~django.forms.Field.error_messages` that contain a
placeholder should now always use a named placeholder (``"Value '%(value)s' is
too big"`` instead of ``"Value '%s' is too big"``). See the corresponding
placeholder should now always use a named placeholder (``"Value '%(value)s'
is too big"`` instead of ``"Value '%s' is too big"``). See the corresponding
field documentation for details about the names of the placeholders. The
changes in 1.6 particularly affect :class:`~django.forms.DecimalField` and
:class:`~django.forms.ModelMultipleChoiceField`.
@@ -949,10 +953,10 @@ Miscellaneous
release: blank passwords are now valid.
* The admin :attr:`~django.contrib.admin.ModelAdmin.changelist_view` previously
accepted a ``pop`` GET parameter to signify it was to be displayed in a popup.
This parameter has been renamed to ``_popup`` to be consistent with the rest
of the admin views. You should update your custom templates if they use the
previous parameter name.
accepted a ``pop`` GET parameter to signify it was to be displayed in a
popup. This parameter has been renamed to ``_popup`` to be consistent with
the rest of the admin views. You should update your custom templates if they
use the previous parameter name.
* :meth:`~django.core.validators.validate_email` now accepts email addresses
with ``localhost`` as the domain.
@@ -964,11 +968,12 @@ Miscellaneous
been removed. Use ``socket.error`` provided by the standard library instead.
This change was also released in Django 1.5.5.
* The signature of :meth:`django.views.generic.base.RedirectView.get_redirect_url`
has changed and now accepts positional arguments as well (``*args, **kwargs``).
Any unnamed captured group will now be passed to ``get_redirect_url()``
which may result in a ``TypeError`` if you don't update the signature of your
custom method.
* The signature of
:meth:`django.views.generic.base.RedirectView.get_redirect_url` has changed
and now accepts positional arguments as well (``*args, **kwargs``). Any
unnamed captured group will now be passed to ``get_redirect_url()`` which may
result in a ``TypeError`` if you don't update the signature of your custom
method.
.. _deprecated-features-1.6:
@@ -992,7 +997,8 @@ current APIs are deprecated:
Django's comment framework has been deprecated and is no longer supported. It
will be available in Django 1.6 and 1.7, and removed in Django 1.8. Most users
will be better served with a custom solution, or a hosted product like Disqus__.
will be better served with a custom solution, or a hosted product like
Disqus__.
The code formerly known as ``django.contrib.comments`` is `still available
in an external repository`__.
@@ -1131,9 +1137,10 @@ must support old Django versions, you should write::
return get_queryset() # etc
In the general case of a custom manager that both implements its own
``get_queryset`` method and calls that method, and needs to work with older Django
versions, and libraries that have not been updated yet, it is useful to define
a ``get_queryset_compat`` method as below and use it internally to your manager::
``get_queryset`` method and calls that method, and needs to work with older
Django versions, and libraries that have not been updated yet, it is useful to
define a ``get_queryset_compat`` method as below and use it internally to your
manager::
class YourCustomManager(models.Manager):
def get_queryset(self):
@@ -1152,8 +1159,8 @@ a ``get_queryset_compat`` method as below and use it internally to your manager:
return get_queryset()
This helps to minimize the changes that are needed, but also works correctly in
the case of subclasses (such as ``RelatedManagers`` from Django 1.5) which might
override either ``get_query_set`` or ``get_queryset``.
the case of subclasses (such as ``RelatedManagers`` from Django 1.5) which
might override either ``get_query_set`` or ``get_queryset``.
``shortcut`` view and URLconf
@@ -1179,23 +1186,23 @@ with::
``ModelForm`` without ``fields`` or ``exclude``
-----------------------------------------------
Previously, if you wanted a :class:`~django.forms.ModelForm` to use all fields on
the model, you could simply omit the ``Meta.fields`` attribute, and all fields
would be used.
Previously, if you wanted a :class:`~django.forms.ModelForm` to use all fields
on the model, you could simply omit the ``Meta.fields`` attribute, and all
fields would be used.
This can lead to security problems where fields are added to the model and,
unintentionally, automatically become editable by end users. In some cases,
particular with boolean fields, it is possible for this problem to be completely
invisible. This is a form of `Mass assignment vulnerability
particular with boolean fields, it is possible for this problem to be
completely invisible. This is a form of `Mass assignment vulnerability
<https://en.wikipedia.org/wiki/Mass_assignment_vulnerability>`_.
For this reason, this behavior is deprecated, and using the ``Meta.exclude``
option is strongly discouraged. Instead, all fields that are intended for
inclusion in the form should be listed explicitly in the ``fields`` attribute.
If this security concern really does not apply in your case, there is a shortcut
to explicitly indicate that all fields should be used - use the special value
``"__all__"`` for the fields attribute::
If this security concern really does not apply in your case, there is a
shortcut to explicitly indicate that all fields should be used - use the
special value ``"__all__"`` for the fields attribute::
class MyModelForm(ModelForm):
class Meta:
@@ -1220,9 +1227,9 @@ The generic views :class:`~django.views.generic.edit.CreateView` and
security problem described in the section above, because they can automatically
create a ``ModelForm`` that uses all fields for a model.
For this reason, if you use these views for editing models, you must also supply
the ``fields`` attribute (new in Django 1.6), which is a list of model fields
and works in the same way as the :class:`~django.forms.ModelForm`
For this reason, if you use these views for editing models, you must also
supply the ``fields`` attribute (new in Django 1.6), which is a list of model
fields and works in the same way as the :class:`~django.forms.ModelForm`
``Meta.fields`` attribute. Alternatively, you can set the ``form_class``
attribute to a ``ModelForm`` that explicitly defines the fields to be used.
Defining an ``UpdateView`` or ``CreateView`` subclass to be used with a model
@@ -1233,10 +1240,10 @@ but without an explicit list of fields is deprecated.
Munging of help text of model form fields for ``ManyToManyField`` fields
------------------------------------------------------------------------
All special handling of the ``help_text`` attribute of ``ManyToManyField`` model
fields performed by standard model or model form fields as described in
All special handling of the ``help_text`` attribute of ``ManyToManyField``
model fields performed by standard model or model form fields as described in
:ref:`m2m-help_text` above is deprecated and will be removed in Django 1.8.
Help text of these fields will need to be handled either by applications, custom
form fields or widgets, just like happens with the rest of the model field
types.
Help text of these fields will need to be handled either by applications,
custom form fields or widgets, just like happens with the rest of the model
field types.

3
docs/releases/1.7.1.txt
View File

@@ -15,7 +15,8 @@ Bugfixes
* Added a more helpful error message if you try to migrate an app without first
creating the ``contenttypes`` table (:ticket:`22411`).
* Modified migrations dependency algorithm to avoid possible infinite recursion.
* Modified migrations dependency algorithm to avoid possible infinite
recursion.
* Fixed a ``UnicodeDecodeError`` when the ``flush`` error message contained
Unicode characters (:ticket:`22882`).

26
docs/releases/1.7.2.txt
View File

@@ -19,8 +19,8 @@ Bugfixes
SQLite (:ticket:`23702`).
* Added a warning for duplicate models when a module is reloaded. Previously a
``RuntimeError`` was raised every time two models clashed in the app registry.
(:ticket:`23621`).
``RuntimeError`` was raised every time two models clashed in the app
registry. (:ticket:`23621`).
* Prevented :djadmin:`flush` from loading initial data for migrated apps
(:ticket:`23699`).
@@ -87,8 +87,8 @@ Bugfixes
* Fixed a regression with dynamically generated inlines and allowed field
references in the admin (:ticket:`23754`).
* Fixed an infinite loop bug for certain cyclic migration dependencies, and made
the error message for cyclic dependencies much more helpful.
* Fixed an infinite loop bug for certain cyclic migration dependencies, and
made the error message for cyclic dependencies much more helpful.
* Added missing ``index_together`` handling for SQLite (:ticket:`23880`).
@@ -137,9 +137,9 @@ Bugfixes
* Fixed ``timesince`` filter translations in Korean (:ticket:`23989`).
* Fixed the SQLite ``SchemaEditor`` to properly add defaults in the absence of
a user specified ``default``. For example, a ``CharField`` with ``blank=True``
didn't set existing rows to an empty string which resulted in a crash when
adding the ``NOT NULL`` constraint (:ticket:`23987`).
a user specified ``default``. For example, a ``CharField`` with
``blank=True`` didn't set existing rows to an empty string which resulted in
a crash when adding the ``NOT NULL`` constraint (:ticket:`23987`).
* ``makemigrations`` no longer prompts for a default value when adding
``TextField()`` or ``CharField()`` without a ``default`` (:ticket:`23405`).
@@ -163,10 +163,10 @@ Bugfixes
* Fixed admindocs crash on apps installed as eggs (:ticket:`23525`).
* Changed migrations autodetector to generate an ``AlterModelOptions`` operation
instead of ``DeleteModel`` and ``CreateModel`` operations when changing
``Meta.managed``. This prevents data loss when changing ``managed`` from
``False`` to ``True`` and vice versa (:ticket:`24037`).
* Changed migrations autodetector to generate an ``AlterModelOptions``
operation instead of ``DeleteModel`` and ``CreateModel`` operations when
changing ``Meta.managed``. This prevents data loss when changing ``managed``
from ``False`` to ``True`` and vice versa (:ticket:`24037`).
* Enabled the ``sqlsequencereset`` command on apps with migrations
(:ticket:`24054`).
@@ -187,8 +187,8 @@ Bugfixes
* Restored the ability to use more than five levels of subqueries
(:ticket:`23758`).
* Fixed crash when ``ValidationError`` is initialized with a ``ValidationError``
that is initialized with a dictionary (:ticket:`24008`).
* Fixed crash when ``ValidationError`` is initialized with a
``ValidationError`` that is initialized with a dictionary (:ticket:`24008`).
* Prevented a crash on apps without migrations when running ``migrate --list``
(:ticket:`23366`).

8
docs/releases/1.7.9.txt
View File

@@ -46,10 +46,10 @@ unexpected newlines.
:func:`~django.core.validators.validate_ipv4_address`,
:func:`~django.core.validators.validate_slug`, and
:class:`~django.core.validators.URLValidator` are also affected, however, as
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
and ``URLField`` form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are using
these validators outside of the form fields.
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``,
``SlugField``, and ``URLField`` form fields which use these validators all
strip the input, so the possibility of newlines entering your data only exists
if you are using these validators outside of the form fields.
The undocumented, internally unused ``validate_integer()`` function is now
stricter as it validates using a regular expression instead of simply casting

173
docs/releases/1.7.txt
View File

@@ -23,11 +23,11 @@ The Django 1.6 series is the last to support Python 2.6. Django 1.7 is the
first release to support Python 3.4.
This change should affect only a small number of Django users, as most
operating-system vendors today are shipping Python 2.7 or newer as their default
version. If you're still using Python 2.6, however, you'll need to stick to
Django 1.6 until you can upgrade your Python version. Per :doc:`our support
policy </internals/release-process>`, Django 1.6 will continue to receive
security support until the release of Django 1.8.
operating-system vendors today are shipping Python 2.7 or newer as their
default version. If you're still using Python 2.6, however, you'll need to
stick to Django 1.6 until you can upgrade your Python version. Per :doc:`our
support policy </internals/release-process>`, Django 1.6 will continue to
receive security support until the release of Django 1.8.
.. _whats-new-1.7:
@@ -37,9 +37,9 @@ What's new in Django 1.7
Schema migrations
-----------------
Django now has built-in support for schema migrations. It allows models
to be updated, changed, and deleted by creating migration files that represent
the model changes and which can be run on any development, staging or production
Django now has built-in support for schema migrations. It allows models to be
updated, changed, and deleted by creating migration files that represent the
model changes and which can be run on any development, staging or production
database.
Migrations are covered in :doc:`their own documentation</topics/migrations>`,
@@ -58,15 +58,18 @@ but a few of the key features are:
new signals have slightly different arguments. Check the
documentation for details.
* The ``allow_syncdb`` method on database routers is now called ``allow_migrate``,
but still performs the same function. Routers with ``allow_syncdb`` methods
will still work, but that method name is deprecated and you should change
it as soon as possible (nothing more than renaming is required).
* The ``allow_syncdb`` method on database routers is now called
``allow_migrate``, but still performs the same function. Routers with
``allow_syncdb`` methods will still work, but that method name is deprecated
and you should change it as soon as possible (nothing more than renaming is
required).
* ``initial_data`` fixtures are no longer loaded for apps with migrations; if
you want to load initial data for an app, we suggest you create a migration for
your application and define a :class:`~django.db.migrations.operations.RunPython`
or :class:`~django.db.migrations.operations.RunSQL` operation in the ``operations`` section of the migration.
you want to load initial data for an app, we suggest you create a migration
for your application and define a
:class:`~django.db.migrations.operations.RunPython` or
:class:`~django.db.migrations.operations.RunSQL` operation in the
``operations`` section of the migration.
* Test rollback behavior is different for apps with migrations; in particular,
Django will no longer emulate rollbacks on non-transactional databases or
@@ -129,18 +132,20 @@ This method takes no arguments, and returns a tuple of four items:
* ``name``: The field's attribute name on its parent model, or ``None`` if it
is not part of a model
* ``path``: A dotted, Python path to the class of this field, including the class name.
* ``path``: A dotted, Python path to the class of this field, including the
class name.
* ``args``: Positional arguments, as a list
* ``kwargs``: Keyword arguments, as a dict
These four values allow any field to be serialized into a file, as well as
allowing the field to be copied safely, both essential parts of these new features.
allowing the field to be copied safely, both essential parts of these new
features.
This change should not affect you unless you write custom Field subclasses;
if you do, you may need to reimplement the ``deconstruct()`` method if your
subclass changes the method signature of ``__init__`` in any way. If your
field just inherits from a built-in Django field and doesn't override ``__init__``,
no changes are necessary.
field just inherits from a built-in Django field and doesn't override
``__init__``, no changes are necessary.
If you do need to override ``deconstruct()``, a good place to start is the
built-in Django fields (``django/db/models/fields/__init__.py``) as several
@@ -507,7 +512,8 @@ Minor features
subclassed to override the permissions that collected static files and
directories receive by setting the
:attr:`~django.core.files.storage.FileSystemStorage.file_permissions_mode`
and :attr:`~django.core.files.storage.FileSystemStorage.directory_permissions_mode`
and
:attr:`~django.core.files.storage.FileSystemStorage.directory_permissions_mode`
parameters. See :djadmin:`collectstatic` for example usage.
* The ``CachedStaticFilesStorage`` backend gets a sibling class called
@@ -519,8 +525,9 @@ Minor features
when running the :djadmin:`collectstatic` management command and should
be a less expensive alternative for remote storages such as Amazon S3.
See the :class:`~django.contrib.staticfiles.storage.ManifestStaticFilesStorage`
docs for more information.
See the
:class:`~django.contrib.staticfiles.storage.ManifestStaticFilesStorage` docs
for more information.
* :djadmin:`findstatic` now accepts verbosity flag level 2, meaning it will
show the relative paths of the directories it searched. See
@@ -608,9 +615,9 @@ Forms
* The ``<label>`` and ``<input>`` tags rendered by
:class:`~django.forms.RadioSelect` and
:class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
Each radio button or checkbox includes an ``id_for_label`` attribute to
output the element's ID.
buttons or checkboxes now include ``for`` and ``id`` attributes,
respectively. Each radio button or checkbox includes an ``id_for_label``
attribute to output the element's ID.
* The ``<textarea>`` tags rendered by :class:`~django.forms.Textarea` now
include a ``maxlength`` attribute if the :class:`~django.db.models.TextField`
@@ -784,20 +791,22 @@ Models
* Custom intermediate models having more than one foreign key to any of the
models participating in a many-to-many relationship are now permitted,
provided you explicitly specify which foreign keys should be used by setting
the new :attr:`ManyToManyField.through_fields <django.db.models.ManyToManyField.through_fields>`
argument.
the new :attr:`ManyToManyField.through_fields
<django.db.models.ManyToManyField.through_fields>` argument.
* Assigning a model instance to a non-relation field will now throw an error.
Previously this used to work if the field accepted integers as input as it
took the primary key.
* Integer fields are now validated against database backend specific min and
max values based on their :meth:`internal_type <django.db.models.Field.get_internal_type>`.
Previously model field validation didn't prevent values out of their associated
column data type range from being saved resulting in an integrity error.
max values based on their :meth:`internal_type
<django.db.models.Field.get_internal_type>`. Previously model field
validation didn't prevent values out of their associated column data type
range from being saved resulting in an integrity error.
* It is now possible to explicitly :meth:`~django.db.models.query.QuerySet.order_by`
a relation ``_id`` field by using its attribute name.
* It is now possible to explicitly
:meth:`~django.db.models.query.QuerySet.order_by` a relation ``_id`` field by
using its attribute name.
Signals
~~~~~~~
@@ -824,8 +833,8 @@ Templates
* ``Context`` objects can now be compared for equality (internally, this
uses :meth:`Context.flatten() <django.template.Context.flatten>` so the
internal structure of each ``Context``'s stack doesn't matter as long as their
flattened version is identical).
internal structure of each ``Context``'s stack doesn't matter as long as
their flattened version is identical).
* The :ttag:`widthratio` template tag now accepts an ``"as"`` parameter to
capture the result in a variable.
@@ -877,7 +886,8 @@ Requests and Responses
relative URLs.
* The new :class:`~django.http.JsonResponse` subclass of
:class:`~django.http.HttpResponse` helps easily create JSON-encoded responses.
:class:`~django.http.HttpResponse` helps easily create JSON-encoded
responses.
Tests
~~~~~
@@ -919,11 +929,11 @@ Validators
* :class:`~django.core.validators.RegexValidator` now accepts the optional
:attr:`~django.core.validators.RegexValidator.flags` and
Boolean :attr:`~django.core.validators.RegexValidator.inverse_match` arguments.
The :attr:`~django.core.validators.RegexValidator.inverse_match` attribute
determines if the :exc:`~django.core.exceptions.ValidationError` should
be raised when the regular expression pattern matches (``True``) or does not
match (``False``, by default) the provided ``value``. The
Boolean :attr:`~django.core.validators.RegexValidator.inverse_match`
arguments. The :attr:`~django.core.validators.RegexValidator.inverse_match`
attribute determines if the :exc:`~django.core.exceptions.ValidationError`
should be raised when the regular expression pattern matches (``True``) or
does not match (``False``, by default) the provided ``value``. The
:attr:`~django.core.validators.RegexValidator.flags` attribute sets the flags
used when compiling a regular expression string.
@@ -955,17 +965,18 @@ should be renamed to ``allow_migrate``, there is a subtle difference in which
models get passed to these methods.
For apps with migrations, ``allow_migrate`` will now get passed
:ref:`historical models <historical-models>`, which are special versioned models
without custom attributes, methods or managers. Make sure your ``allow_migrate``
methods are only referring to fields or other items in ``model._meta``.
:ref:`historical models <historical-models>`, which are special versioned
models without custom attributes, methods or managers. Make sure your
``allow_migrate`` methods are only referring to fields or other items in
``model._meta``.
initial_data
------------
Apps with migrations will not load ``initial_data`` fixtures when they have
finished migrating. Apps without migrations will continue to load these fixtures
during the phase of ``migrate`` which emulates the old ``syncdb`` behavior,
but any new apps will not have this support.
finished migrating. Apps without migrations will continue to load these
fixtures during the phase of ``migrate`` which emulates the old ``syncdb``
behavior, but any new apps will not have this support.
Instead, you are encouraged to load initial data in migrations if you need it
(using the ``RunPython`` operation and your model classes);
@@ -1218,8 +1229,8 @@ model implemented a custom ``get_queryset()``).
Fixing the issues introduced some backward incompatible changes:
- The default implementation of ``remove()`` for ``ForeignKey`` related managers
changed from a series of ``Model.save()`` calls to a single
- The default implementation of ``remove()`` for ``ForeignKey`` related
managers changed from a series of ``Model.save()`` calls to a single
``QuerySet.update()`` call. The change means that ``pre_save`` and
``post_save`` signals aren't sent anymore. You can use the ``bulk=False``
keyword argument to revert to the previous behavior.
@@ -1326,9 +1337,9 @@ Miscellaneous
two ``Model`` instances without primary key values won't be considered
equal (unless they are the same instance).
* The :meth:`django.db.models.Model.__hash__` method will now raise ``TypeError``
when called on an instance without a primary key value. This is done to
avoid mutable ``__hash__`` values in containers.
* The :meth:`django.db.models.Model.__hash__` method will now raise
``TypeError`` when called on an instance without a primary key value. This is
done to avoid mutable ``__hash__`` values in containers.
* :class:`~django.db.models.AutoField` columns in SQLite databases will now be
created using the ``AUTOINCREMENT`` option, which guarantees monotonic
@@ -1357,9 +1368,9 @@ Miscellaneous
(similarly to what one gets with :setting:`DEBUG = True <DEBUG>` at
development-time) has been moved to a new class that lives in the
``staticfiles`` application (the one actually in charge of such feature):
:class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase`. In other
words, ``LiveServerTestCase`` itself is less powerful but at the same time
has less magic.
:class:`django.contrib.staticfiles.testing.StaticLiveServerTestCase`. In
other words, ``LiveServerTestCase`` itself is less powerful but at the same
time has less magic.
Rationale behind this is removal of dependency of non-contrib code on
contrib applications.
@@ -1431,7 +1442,8 @@ Miscellaneous
* As part of the :doc:`System check framework </ref/checks>`, :ref:`fields,
models, and model managers <field-checking>` all implement a ``check()``
method that is registered with the check framework. If you have an existing
method called ``check()`` on one of these objects, you will need to rename it.
method called ``check()`` on one of these objects, you will need to rename
it.
* As noted above in the "Cache" section of "Minor Features", defining the
:setting:`TIMEOUT <CACHES-TIMEOUT>` argument of the
@@ -1535,11 +1547,10 @@ Custom SQL location for models package
Previously, if models were organized in a package (``myapp/models/``) rather
than simply ``myapp/models.py``, Django would look for initial SQL data in
``myapp/models/sql/``. This bug has been fixed so that Django
will search ``myapp/sql/`` as documented. After this issue was fixed, migrations
were added which deprecates initial SQL data. Thus, while this change still
exists, the deprecation is irrelevant as the entire feature will be removed in
Django 1.9.
``myapp/models/sql/``. This bug has been fixed so that Django will search
``myapp/sql/`` as documented. After this issue was fixed, migrations were added
which deprecates initial SQL data. Thus, while this change still exists, the
deprecation is irrelevant as the entire feature will be removed in Django 1.9.
Reorganization of ``django.contrib.sites``
------------------------------------------
@@ -1566,9 +1577,10 @@ Reorganization of ``django.contrib.contenttypes``
-------------------------------------------------
Since ``django.contrib.contenttypes.generic`` defined both admin and model
related objects, an import of this module could trigger unexpected side effects.
As a consequence, its contents were split into :mod:`~django.contrib.contenttypes`
submodules and the ``django.contrib.contenttypes.generic`` module is deprecated:
related objects, an import of this module could trigger unexpected side
effects. As a consequence, its contents were split into
:mod:`~django.contrib.contenttypes` submodules and the
``django.contrib.contenttypes.generic`` module is deprecated:
* :class:`~django.contrib.contenttypes.fields.GenericForeignKey` and
:class:`~django.contrib.contenttypes.fields.GenericRelation` now live in
@@ -1584,9 +1596,10 @@ submodules and the ``django.contrib.contenttypes.generic`` module is deprecated:
``syncdb``
----------
The ``syncdb`` command has been deprecated in favor of the new :djadmin:`migrate`
command. ``migrate`` takes the same arguments as ``syncdb`` used to plus a few
more, so it's safe to just change the name you're calling and nothing else.
The ``syncdb`` command has been deprecated in favor of the new
:djadmin:`migrate` command. ``migrate`` takes the same arguments as ``syncdb``
used to plus a few more, so it's safe to just change the name you're calling
and nothing else.
``util`` modules renamed to ``utils``
-------------------------------------
@@ -1725,9 +1738,9 @@ The ``django.contrib.admin.validation`` module is deprecated.
``django.db.backends.DatabaseValidation.validate_field``
--------------------------------------------------------
This method is deprecated in favor of a new ``check_field`` method.
The functionality required by ``check_field()`` is the same as that provided
by ``validate_field()``, but the output format is different. Third-party database
This method is deprecated in favor of a new ``check_field`` method. The
functionality required by ``check_field()`` is the same as that provided by
``validate_field()``, but the output format is different. Third-party database
backends needing this functionality should provide an implementation of
``check_field()``.
@@ -1743,9 +1756,9 @@ will be removed in Django 1.9. You can simply remove the
``django.utils.text.javascript_quote``
--------------------------------------
``javascript_quote()`` was an undocumented function present in ``django.utils.text``.
It was used internally in the ``javascript_catalog()`` view
whose implementation was changed to make use of ``json.dumps()`` instead.
``javascript_quote()`` was an undocumented function present in
``django.utils.text``. It was used internally in the ``javascript_catalog()``
view whose implementation was changed to make use of ``json.dumps()`` instead.
If you were relying on this function to provide safe output from untrusted
strings, you should use ``django.utils.html.escapejs`` or the
:tfilter:`escapejs` template filter.
@@ -1756,14 +1769,14 @@ If all you need is to generate valid JavaScript strings, you can simply use
---------------------------------------------------
The ``django.utils.html.fix_ampersands`` method and the ``fix_ampersands``
template filter are deprecated, as the escaping of ampersands is already taken care
of by Django's standard HTML escaping features. Combining this with ``fix_ampersands``
would either result in double escaping, or, if the output is assumed to be safe,
a risk of introducing XSS vulnerabilities. Along with ``fix_ampersands``,
``django.utils.html.clean_html`` is deprecated, an undocumented function that calls
``fix_ampersands``.
As this is an accelerated deprecation, ``fix_ampersands`` and ``clean_html``
will be removed in Django 1.8.
template filter are deprecated, as the escaping of ampersands is already taken
care of by Django's standard HTML escaping features. Combining this with
``fix_ampersands`` would either result in double escaping, or, if the output is
assumed to be safe, a risk of introducing XSS vulnerabilities. Along with
``fix_ampersands``, ``django.utils.html.clean_html`` is deprecated, an
undocumented function that calls ``fix_ampersands``. As this is an accelerated
deprecation, ``fix_ampersands`` and ``clean_html`` will be removed in Django
1.8.
Reorganization of database test settings
----------------------------------------

7
docs/releases/1.8.1.txt
View File

@@ -51,9 +51,10 @@ Bugfixes
``django.conf.urls.url()`` which is deprecated in Django 1.8
(:ticket:`24635`).
* Fixed queries where an expression was referenced in ``order_by()``, but wasn't
part of the select clause. An example query is
``qs.annotate(foo=F('field')).values('pk').order_by('foo'))`` (:ticket:`24615`).
* Fixed queries where an expression was referenced in ``order_by()``, but
wasn't part of the select clause. An example query is
``qs.annotate(foo=F('field')).values('pk').order_by('foo'))``
(:ticket:`24615`).
* Fixed a database table name quoting regression (:ticket:`24605`).

12
docs/releases/1.8.3.txt
View File

@@ -51,10 +51,10 @@ unexpected newlines.
:func:`~django.core.validators.validate_ipv4_address`,
:func:`~django.core.validators.validate_slug`, and
:class:`~django.core.validators.URLValidator` are also affected, however, as
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
and ``URLField`` form fields which use these validators all strip the input, so
the possibility of newlines entering your data only exists if you are using
these validators outside of the form fields.
of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``,
``SlugField``, and ``URLField`` form fields which use these validators all
strip the input, so the possibility of newlines entering your data only exists
if you are using these validators outside of the form fields.
The undocumented, internally unused ``validate_integer()`` function is now
stricter as it validates using a regular expression instead of simply casting
@@ -64,8 +64,8 @@ Denial-of-service possibility in URL validation
===============================================
:class:`~django.core.validators.URLValidator` included a regular expression
that was extremely slow to evaluate against certain invalid inputs. This regular
expression has been simplified and optimized.
that was extremely slow to evaluate against certain invalid inputs. This
regular expression has been simplified and optimized.
Bugfixes
========

137
docs/releases/1.8.txt
View File

@@ -165,7 +165,8 @@ Minor features
* You can now specify :attr:`ModelAdmin.show_full_result_count
<django.contrib.admin.ModelAdmin.show_full_result_count>` to control whether
or not the full count of objects should be displayed on a filtered admin page.
or not the full count of objects should be displayed on a filtered admin
page.
* The ``AdminSite.password_change()`` method now has an ``extra_context``
parameter.
@@ -219,7 +220,8 @@ Minor features
available.
* It is now allowed to include a subquery as a geographic lookup argument, for
example ``City.objects.filter(point__within=Country.objects.filter(continent='Africa').values('mpoly'))``.
example
``City.objects.filter(point__within=Country.objects.filter(continent='Africa').values('mpoly'))``.
* The SpatiaLite backend now supports ``Collect`` and ``Extent`` aggregates
when the database version is 3.0 or later.
@@ -280,10 +282,10 @@ Database backends
* The MySQL backend no longer strips microseconds from ``datetime`` values as
MySQL 5.6.4 and up supports fractional seconds depending on the declaration
of the datetime field (when ``DATETIME`` includes fractional precision greater
than 0). New datetime database columns created with Django 1.8 and MySQL 5.6.4
and up will support microseconds. See the :ref:`MySQL database notes
<mysql-fractional-seconds>` for more details.
of the datetime field (when ``DATETIME`` includes fractional precision
greater than 0). New datetime database columns created with Django 1.8 and
MySQL 5.6.4 and up will support microseconds. See the :ref:`MySQL database
notes <mysql-fractional-seconds>` for more details.
* The MySQL backend no longer creates explicit indexes for foreign keys when
using the InnoDB storage engine, as MySQL already creates them automatically.
@@ -350,11 +352,11 @@ Forms
override the top list choice label when :class:`~django.forms.DateField`
is not required.
* After an :class:`~django.forms.ImageField` has been cleaned and validated, the
``UploadedFile`` object will have an additional ``image`` attribute containing
the Pillow ``Image`` instance used to check if the file was a valid image. It
will also update ``UploadedFile.content_type`` with the image's content type
as determined by Pillow.
* After an :class:`~django.forms.ImageField` has been cleaned and validated,
the ``UploadedFile`` object will have an additional ``image`` attribute
containing the Pillow ``Image`` instance used to check if the file was a
valid image. It will also update ``UploadedFile.content_type`` with the
image's content type as determined by Pillow.
* You can now pass a callable that returns an iterable of choices when
instantiating a :class:`~django.forms.ChoiceField`.
@@ -362,8 +364,9 @@ Forms
Generic Views
~~~~~~~~~~~~~
* Generic views that use :class:`~django.views.generic.list.MultipleObjectMixin`
may now specify the ordering applied to the
* Generic views that use
:class:`~django.views.generic.list.MultipleObjectMixin` may now specify the
ordering applied to the
:attr:`~django.views.generic.list.MultipleObjectMixin.queryset` by setting
:attr:`~django.views.generic.list.MultipleObjectMixin.ordering` or overriding
:meth:`~django.views.generic.list.MultipleObjectMixin.get_ordering`.
@@ -375,12 +378,13 @@ Generic Views
so that it'll perform its lookup using both the primary key and the slug.
* The :meth:`~django.views.generic.edit.FormMixin.get_form` method doesn't
require a ``form_class`` to be provided anymore. If not provided ``form_class``
defaults to :meth:`~django.views.generic.edit.FormMixin.get_form_class`.
require a ``form_class`` to be provided anymore. If not provided
``form_class`` defaults to
:meth:`~django.views.generic.edit.FormMixin.get_form_class`.
* Placeholders in :attr:`ModelFormMixin.success_url
<django.views.generic.edit.ModelFormMixin.success_url>` now support the Python
:py:meth:`str.format` syntax. The legacy ``%(<foo>)s`` syntax is still
<django.views.generic.edit.ModelFormMixin.success_url>` now support the
Python :py:meth:`str.format` syntax. The legacy ``%(<foo>)s`` syntax is still
supported but will be removed in Django 1.10.
Internationalization
@@ -455,8 +459,8 @@ Middleware
attribute allows you to customize the redirects issued by the middleware.
* A debug message will be logged to the ``django.request`` logger when a
middleware raises a :exc:`~django.core.exceptions.MiddlewareNotUsed` exception
in :setting:`DEBUG` mode.
middleware raises a :exc:`~django.core.exceptions.MiddlewareNotUsed`
exception in :setting:`DEBUG` mode.
Migrations
~~~~~~~~~~
@@ -528,7 +532,8 @@ Models
<django.db.models.Model.refresh_from_db>`.
* You can now get the set of deferred fields for a model using
:meth:`Model.get_deferred_fields() <django.db.models.Model.get_deferred_fields>`.
:meth:`Model.get_deferred_fields()
<django.db.models.Model.get_deferred_fields>`.
* Model field ``default``’s are now used when primary key field's are set to
``None``.
@@ -556,8 +561,8 @@ System Check Framework
Templates
~~~~~~~~~
* :tfilter:`urlize` now supports domain-only links that include characters after
the top-level domain (e.g. ``djangoproject.com/`` and
* :tfilter:`urlize` now supports domain-only links that include characters
after the top-level domain (e.g. ``djangoproject.com/`` and
``djangoproject.com/download/``).
* :tfilter:`urlize` doesn't treat exclamation marks at the end of a domain or
@@ -648,8 +653,8 @@ Tests
* Added test client support for file uploads with file-like objects.
* A shared cache is now used when testing with an SQLite in-memory database when
using Python 3.4+ and SQLite 3.7.13+. This allows sharing the database
* A shared cache is now used when testing with an SQLite in-memory database
when using Python 3.4+ and SQLite 3.7.13+. This allows sharing the database
between threads.
Validators
@@ -694,7 +699,8 @@ Assigning unsaved objects to relations raises an error
.. note::
To more easily allow in-memory usage of models, this change was reverted in
Django 1.8.4 and replaced with a check during ``model.save()``. For example:
Django 1.8.4 and replaced with a check during ``model.save()``. For
example:
.. code-block:: pycon
@@ -840,8 +846,8 @@ your current fields). A migration for
Support for PostgreSQL versions older than 9.0
----------------------------------------------
The end of upstream support periods was reached in July 2014 for PostgreSQL 8.4.
As a consequence, Django 1.8 sets 9.0 as the minimum PostgreSQL version it
The end of upstream support periods was reached in July 2014 for PostgreSQL
8.4. As a consequence, Django 1.8 sets 9.0 as the minimum PostgreSQL version it
officially supports.
This also includes dropping support for PostGIS 1.3 and 1.4 as these versions
@@ -877,11 +883,12 @@ creating a test user). The exact privileges required now are detailed in
``AbstractUser.last_login`` allows null values
----------------------------------------------
The :attr:`AbstractUser.last_login <django.contrib.auth.models.User.last_login>`
field now allows null values. Previously, it defaulted to the time when the user
was created which was misleading if the user never logged in. If you are using
the default user (:class:`django.contrib.auth.models.User`), run the database
migration included in ``contrib.auth``.
The :attr:`AbstractUser.last_login
<django.contrib.auth.models.User.last_login>` field now allows null values.
Previously, it defaulted to the time when the user was created which was
misleading if the user never logged in. If you are using the default user
(:class:`django.contrib.auth.models.User`), run the database migration included
in ``contrib.auth``.
If you are using a custom user model that inherits from ``AbstractUser``,
you'll need to run :djadmin:`makemigrations` and generate a migration for your
@@ -917,14 +924,14 @@ for users who haven't logged in, you can run this query::
Priority of context processors for ``TemplateResponse`` brought in line with ``render``
---------------------------------------------------------------------------------------
The :class:`~django.template.response.TemplateResponse` constructor is designed to be a
drop-in replacement for the :func:`~django.shortcuts.render` function. However,
it had a slight incompatibility, in that for ``TemplateResponse``, context data
from the passed in context dictionary could be shadowed by context data returned
from context processors, whereas for ``render`` it was the other way
around. This was a bug, and the behavior of ``render`` is more appropriate,
since it allows the globally defined context processors to be overridden locally
in the view. If you were relying on the fact context data in a
The :class:`~django.template.response.TemplateResponse` constructor is designed
to be a drop-in replacement for the :func:`~django.shortcuts.render` function.
However, it had a slight incompatibility, in that for ``TemplateResponse``,
context data from the passed in context dictionary could be shadowed by context
data returned from context processors, whereas for ``render`` it was the other
way around. This was a bug, and the behavior of ``render`` is more appropriate,
since it allows the globally defined context processors to be overridden
locally in the view. If you were relying on the fact context data in a
``TemplateResponse`` could be overridden using a context processor, you will
need to change your code.
@@ -1281,9 +1288,9 @@ written (and is better written) as::
url("^other/$", views.otherview),
)
Thus ``patterns()`` serves little purpose and is a burden when teaching new users
(answering the newbie's question "why do I need this empty string as the first
argument to ``patterns()``?"). For these reasons, we are deprecating it.
Thus ``patterns()`` serves little purpose and is a burden when teaching new
users (answering the newbie's question "why do I need this empty string as the
first argument to ``patterns()``?"). For these reasons, we are deprecating it.
Updating your code is as simple as ensuring that ``urlpatterns`` is a list of
``django.conf.urls.url()`` instances. For example::
@@ -1362,10 +1369,12 @@ the ``url`` that references :func:`django.contrib.sitemaps.views.sitemap`::
name="django.contrib.sitemaps.views.sitemap",
)
to ensure compatibility when reversing by Python path is removed in Django 1.10.
to ensure compatibility when reversing by Python path is removed in Django
1.10.
Similarly for GIS sitemaps, add ``name='django.contrib.gis.sitemaps.views.kml'``
or ``name='django.contrib.gis.sitemaps.views.kmz'``.
Similarly for GIS sitemaps, add
``name='django.contrib.gis.sitemaps.views.kml'`` or
``name='django.contrib.gis.sitemaps.views.kmz'``.
If you are using a Python path for the :setting:`LOGIN_URL` or
:setting:`LOGIN_REDIRECT_URL` setting, use the name of the ``url()`` instead.
@@ -1376,10 +1385,10 @@ Aggregate methods and modules
-----------------------------
The ``django.db.models.sql.aggregates`` and
``django.contrib.gis.db.models.sql.aggregates`` modules (both private API), have
been deprecated as ``django.db.models.aggregates`` and
``django.contrib.gis.db.models.aggregates`` are now also responsible
for SQL generation. The old modules will be removed in Django 1.10.
``django.contrib.gis.db.models.sql.aggregates`` modules (both private API),
have been deprecated as ``django.db.models.aggregates`` and
``django.contrib.gis.db.models.aggregates`` are now also responsible for SQL
generation. The old modules will be removed in Django 1.10.
If you were using the old modules, see :doc:`Query Expressions
</ref/models/expressions>` for instructions on rewriting custom aggregates
@@ -1487,9 +1496,9 @@ It's a legacy option that should no longer be necessary.
----------------
``django.db.models.fields.subclassing.SubfieldBase`` has been deprecated and
will be removed in Django 1.10. Historically, it was used to handle fields where
type conversion was needed when loading from the database, but it was not used
in ``.values()`` calls or in aggregates. It has been replaced with
will be removed in Django 1.10. Historically, it was used to handle fields
where type conversion was needed when loading from the database, but it was not
used in ``.values()`` calls or in aggregates. It has been replaced with
:meth:`~django.db.models.Field.from_db_value`.
The new approach doesn't call the :meth:`~django.db.models.Field.to_python`
@@ -1522,7 +1531,7 @@ sure to provide a default value for the ``form_class`` argument since it's
now optional.
Rendering templates loaded by :func:`~django.template.loader.get_template` with a :class:`~django.template.Context`
---------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------
The return type of :func:`~django.template.loader.get_template` has changed
in Django 1.8: instead of a :class:`django.template.Template`, it returns a
@@ -1638,21 +1647,21 @@ deprecated: you should rename your ``qn`` arguments to ``compiler``, and call
Default value of ``RedirectView.permanent``
-------------------------------------------
The default value of the
:attr:`RedirectView.permanent <django.views.generic.base.RedirectView.permanent>`
attribute will change from ``True`` to ``False`` in Django 1.9.
The default value of the :attr:`RedirectView.permanent
<django.views.generic.base.RedirectView.permanent>` attribute will change from
``True`` to ``False`` in Django 1.9.
Using ``AuthenticationMiddleware`` without ``SessionAuthenticationMiddleware``
------------------------------------------------------------------------------
``django.contrib.auth.middleware.SessionAuthenticationMiddleware`` was
added in Django 1.7. In Django 1.7.2, its functionality was moved to
``auth.get_user()`` and, for backwards compatibility, enabled only if
``django.contrib.auth.middleware.SessionAuthenticationMiddleware`` was added in
Django 1.7. In Django 1.7.2, its functionality was moved to ``auth.get_user()``
and, for backwards compatibility, enabled only if
``'django.contrib.auth.middleware.SessionAuthenticationMiddleware'`` appears in
``MIDDLEWARE_CLASSES``.
In Django 1.10, session verification will be enabled regardless of whether or not
``SessionAuthenticationMiddleware`` is enabled (at which point
In Django 1.10, session verification will be enabled regardless of whether or
not ``SessionAuthenticationMiddleware`` is enabled (at which point
``SessionAuthenticationMiddleware`` will have no significance). You can add it
to your ``MIDDLEWARE_CLASSES`` sometime before then to opt-in. Please read the
:ref:`upgrade considerations <session-invalidation-on-password-change>` first.
@@ -1784,8 +1793,8 @@ remove usage of these features.
deprecation warning in the latter class.
* Usage of the hardcoded *Hold down "Control", or "Command" on a Mac, to select
more than one.* string to override or append to user-provided ``help_text`` in
forms for ``ManyToMany`` model fields is not performed by Django anymore
more than one.* string to override or append to user-provided ``help_text``
in forms for ``ManyToMany`` model fields is not performed by Django anymore
either at the model or forms layer.
* The ``Model._meta.get_(add|change|delete)_permission`` methods are removed.

4
docs/releases/1.9.2.txt
View File

@@ -95,8 +95,8 @@ Bugfixes
* Fixed a regression in Django 1.8.5 that broke copying a ``SimpleLazyObject``
with ``copy.copy()`` (:ticket:`26122`).
* Always included ``geometry_field`` in the GeoJSON serializer output regardless
of the ``fields`` parameter (:ticket:`26138`).
* Always included ``geometry_field`` in the GeoJSON serializer output
regardless of the ``fields`` parameter (:ticket:`26138`).
* Fixed the ``contrib.gis`` map widgets when using
``USE_THOUSAND_SEPARATOR=True`` (:ticket:`20415`).

4
docs/releases/1.9.5.txt
View File

@@ -47,5 +47,5 @@ Bugfixes
* Fixed a migrations crash on SQLite when renaming the primary key of a model
containing a ``ForeignKey`` to ``'self'`` (:ticket:`26384`).
* Fixed ``JSONField`` inadvertently escaping its contents when displaying values
after failed form validation (:ticket:`25532`).
* Fixed ``JSONField`` inadvertently escaping its contents when displaying
values after failed form validation (:ticket:`25532`).

31
docs/releases/1.9.txt
View File

@@ -103,16 +103,18 @@ implementation, though:
method does not take a ``request`` argument. The current request is available
in ``self.request``.
* The custom ``test_func()`` of :class:`~django.contrib.auth.mixins.UserPassesTestMixin`
does not take a ``user`` argument. The current user is available in
``self.request.user``.
* The custom ``test_func()`` of
:class:`~django.contrib.auth.mixins.UserPassesTestMixin` does not take a
``user`` argument. The current user is available in ``self.request.user``.
* The :attr:`permission_required <django.contrib.auth.mixins.PermissionRequiredMixin>`
* The
:attr:`permission_required <django.contrib.auth.mixins.PermissionRequiredMixin>`
attribute supports a string (defining one permission) or a list/tuple of
strings (defining multiple permissions) that need to be fulfilled to grant
access.
* The new :attr:`~django.contrib.auth.mixins.AccessMixin.permission_denied_message`
* The new
:attr:`~django.contrib.auth.mixins.AccessMixin.permission_denied_message`
attribute allows passing a message to the ``PermissionDenied`` exception.
.. _django-braces: https://django-braces.readthedocs.io/en/latest/index.html
@@ -210,7 +212,8 @@ Minor features
:func:`~django.contrib.auth.decorators.permission_required` accepts all
kinds of iterables, not only list and tuples.
* The new :class:`~django.contrib.auth.middleware.PersistentRemoteUserMiddleware`
* The new
:class:`~django.contrib.auth.middleware.PersistentRemoteUserMiddleware`
makes it possible to use ``REMOTE_USER`` for setups where the header is only
populated on login pages instead of every request in the session.
@@ -767,8 +770,9 @@ behavior.
Filesystem-based template loaders catch more specific exceptions
----------------------------------------------------------------
When using the :class:`filesystem.Loader <django.template.loaders.filesystem.Loader>`
or :class:`app_directories.Loader <django.template.loaders.app_directories.Loader>`
When using the
:class:`filesystem.Loader <django.template.loaders.filesystem.Loader>` or
:class:`app_directories.Loader <django.template.loaders.app_directories.Loader>`
template loaders, earlier versions of Django raised a
:exc:`~django.template.TemplateDoesNotExist` error if a template source existed
but was unreadable. This could happen under many circumstances, such as if
@@ -935,8 +939,8 @@ define built-in libraries via the ``'builtins'`` key of :setting:`OPTIONS
``simple_tag`` now wraps tag output in ``conditional_escape``
-------------------------------------------------------------
In general, template tags do not autoescape their contents, and this behavior is
:ref:`documented <tags-auto-escaping>`. For tags like
In general, template tags do not autoescape their contents, and this behavior
is :ref:`documented <tags-auto-escaping>`. For tags like
:class:`~django.template.Library.inclusion_tag`, this is not a problem because
the included template will perform autoescaping. For ``assignment_tag()``,
the output will be escaped when it is used as a variable in the template.
@@ -1135,7 +1139,8 @@ Miscellaneous
* The ``FlatPage.enable_comments`` field is removed from the ``FlatPageAdmin``
as it's unused by the application. If your project or a third-party app makes
use of it, :ref:`create a custom ModelAdmin <flatpages-admin>` to add it back.
use of it, :ref:`create a custom ModelAdmin <flatpages-admin>` to add it
back.
* The return value of
:meth:`~django.test.runner.DiscoverRunner.setup_databases` and the first
@@ -1349,8 +1354,8 @@ Miscellaneous
* The ``check_aggregate_support()`` method of
``django.db.backends.base.BaseDatabaseOperations`` has been deprecated and
will be removed in Django 2.0. The more general ``check_expression_support()``
should be used instead.
will be removed in Django 2.0. The more general
``check_expression_support()`` should be used instead.
* ``django.forms.extras`` is deprecated. You can find
:class:`~django.forms.SelectDateWidget` in ``django.forms.widgets``

4
docs/releases/2.0.1.txt
View File

@@ -9,8 +9,8 @@ Django 2.0.1 fixes several bugs in 2.0.
Bugfixes
========
* Fixed a regression in Django 1.11 that added newlines between ``MultiWidget``'s
subwidgets (:ticket:`28890`).
* Fixed a regression in Django 1.11 that added newlines between
``MultiWidget``'s subwidgets (:ticket:`28890`).
* Fixed incorrect class-based model index name generation for models with
quoted ``db_table`` (:ticket:`28876`).

4
docs/releases/2.0.5.txt
View File

@@ -21,5 +21,5 @@ Bugfixes
* Fixed a regression in Django 2.0.4 where ``QuerySet.values()`` or
``values_list()`` after combining an annotated and unannotated queryset with
``union()``, ``difference()``, or ``intersection()`` crashed due to mismatching
columns (:ticket:`29286`).
``union()``, ``difference()``, or ``intersection()`` crashed due to
mismatching columns (:ticket:`29286`).

13
docs/releases/2.0.txt
View File

@@ -387,8 +387,9 @@ backends.
* To enable support for :class:`~django.db.models.expressions.Window`
expressions, set ``DatabaseFeatures.supports_over_clause`` to ``True``. You
may need to customize the ``DatabaseOperations.window_start_rows_start_end()``
and/or ``window_start_range_start_end()`` methods.
may need to customize the
``DatabaseOperations.window_start_rows_start_end()`` and/or
``window_start_range_start_end()`` methods.
* Third-party database backends should add a
``DatabaseOperations.cast_char_field_without_max_length`` attribute with the
@@ -542,11 +543,11 @@ rebuild tables using a script similar to this::
This script hasn't received extensive testing and needs adaption for various
cases such as multiple databases. Feel free to contribute improvements.
In addition, because of a table alteration limitation of SQLite, it's prohibited
to perform :class:`~django.db.migrations.operations.RenameModel` and
In addition, because of a table alteration limitation of SQLite, it's
prohibited to perform :class:`~django.db.migrations.operations.RenameModel` and
:class:`~django.db.migrations.operations.RenameField` operations on models or
fields referenced by other models in a transaction. In order to allow migrations
containing these operations to be applied, you must set the
fields referenced by other models in a transaction. In order to allow
migrations containing these operations to be applied, you must set the
``Migration.atomic`` attribute to ``False``.
Miscellaneous

28
docs/releases/2.1.txt
View File

@@ -76,10 +76,11 @@ Minor features
per model <admin-templates-overridden-per-app-or-model>` (besides overridden
globally).
* The admin change list and change form object tools can now be :ref:`overridden
per app, per model, or globally <admin-templates-overridden-per-app-or-model>`
with ``change_list_object_tools.html`` and
``change_form_object_tools.html`` templates.
* The admin change list and change form object tools can now be
:ref:`overridden per app, per model, or globally
<admin-templates-overridden-per-app-or-model>` with
``change_list_object_tools.html`` and ``change_form_object_tools.html``
templates.
* :meth:`.InlineModelAdmin.has_add_permission` is now passed the parent object
as the second positional argument, ``obj``.
@@ -148,8 +149,8 @@ Management Commands
* The :class:`~django.core.management.BaseCommand` class now uses a custom help
formatter so that the standard options like ``--verbosity`` or ``--settings``
appear last in the help output, giving a more prominent position to subclassed
command's options.
appear last in the help output, giving a more prominent position to
subclassed command's options.
Migrations
~~~~~~~~~~
@@ -272,9 +273,9 @@ supports PostgreSQL 9.4 and higher.
Removed ``BCryptPasswordHasher`` from the default ``PASSWORD_HASHERS`` setting
------------------------------------------------------------------------------
If you used bcrypt with Django 1.4 or 1.5 (before ``BCryptSHA256PasswordHasher``
was added in Django 1.6), you might have some passwords that use the
``BCryptPasswordHasher`` hasher.
If you used bcrypt with Django 1.4 or 1.5 (before
``BCryptSHA256PasswordHasher`` was added in Django 1.6), you might have some
passwords that use the ``BCryptPasswordHasher`` hasher.
You can check if that's the case like this::
@@ -382,10 +383,11 @@ Miscellaneous
conflicts with the class given to model fields named "box".
* Since the admin's ``actions.html``, ``change_list_results.html``,
``date_hierarchy.html``, ``pagination.html``, ``prepopulated_fields_js.html``,
``search_form.html``, and ``submit_line.html`` templates can now be
overridden per app or per model, you may need to rename existing templates
with those names that were written for a different purpose.
``date_hierarchy.html``, ``pagination.html``,
``prepopulated_fields_js.html``, ``search_form.html``, and
``submit_line.html`` templates can now be overridden per app or per model,
you may need to rename existing templates with those names that were written
for a different purpose.
* ``QuerySet.raw()`` now caches its results like regular querysets. Use
``iterator()`` if you don't want caching.

6
docs/releases/2.2.3.txt
View File

@@ -18,9 +18,9 @@ requests made via HTTP as using HTTPS. This entails incorrect results for
requests would not be redirected to HTTPS in accordance with
:setting:`SECURE_SSL_REDIRECT`.
``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it is
configured, and the appropriate header is set on the request, for both HTTP and
HTTPS requests.
``HttpRequest.scheme`` now respects :setting:`SECURE_PROXY_SSL_HEADER`, if it
is configured, and the appropriate header is set on the request, for both HTTP
and HTTPS requests.
If you deploy Django behind a reverse-proxy that forwards HTTP requests, and
that connects to Django via HTTPS, be sure to verify that your application

6
docs/releases/3.0.txt
View File

@@ -358,9 +358,9 @@ Tests
new :option:`test -k` option.
* HTML comparison, as used by
:meth:`~django.test.SimpleTestCase.assertHTMLEqual`, now treats text, character
references, and entity references that refer to the same character as
equivalent.
:meth:`~django.test.SimpleTestCase.assertHTMLEqual`, now treats text,
character references, and entity references that refer to the same character
as equivalent.
* :class:`~django.test.runner.DiscoverRunner` can now spawn a debugger at each
error or failure using the :option:`test --pdb` option.

4
docs/releases/4.1.txt
View File

@@ -247,8 +247,8 @@ Forms
transitional renderers will be deprecated, for removal in Django 6.0. The
``FORM_RENDERER`` declaration can be removed at that time.
* If the new ``<div>`` output style is not appropriate for your project, you should
define a renderer subclass specifying
* If the new ``<div>`` output style is not appropriate for your project, you
should define a renderer subclass specifying
:attr:`~django.forms.renderers.BaseRenderer.form_template_name` and
:attr:`~django.forms.renderers.BaseRenderer.formset_template_name` for your
required style, and set :setting:`FORM_RENDERER` accordingly.

6
docs/releases/5.0.2.txt
View File

@@ -35,9 +35,9 @@ Bugfixes
management command when a base queryset used ``prefetch_related()``
(:ticket:`35159`).
* Fixed a regression in Django 5.0 that caused the ``request_finished`` signal to
sometimes not be fired when running Django through an ASGI server, resulting
in potential resource leaks (:ticket:`35059`).
* Fixed a regression in Django 5.0 that caused the ``request_finished`` signal
to sometimes not be fired when running Django through an ASGI server,
resulting in potential resource leaks (:ticket:`35059`).
* Fixed a bug in Django 5.0 that caused a migration crash on MySQL when adding
a ``BinaryField``, ``TextField``, ``JSONField``, or ``GeometryField`` with a

5
docs/releases/5.1.txt
View File

@@ -98,8 +98,9 @@ unauthenticated requests by using the new
support setting ``login_url`` or ``redirect_field_name`` via the
:class:`~django.contrib.auth.mixins.LoginRequiredMixin`.
To enable this, add ``"django.contrib.auth.middleware.LoginRequiredMiddleware"``
to your :setting:`MIDDLEWARE` setting.
To enable this, add
``"django.contrib.auth.middleware.LoginRequiredMiddleware"`` to your
:setting:`MIDDLEWARE` setting.
Minor features
--------------

7
docs/releases/5.2.4.txt
View File

@@ -9,9 +9,10 @@ Django 5.2.4 fixes several bugs in 5.2.3.
Bugfixes
========
* Fixed a regression in Django 5.2.2 where :meth:`HttpRequest.get_preferred_type()
<django.http.HttpRequest.get_preferred_type>` incorrectly preferred more
specific media types with a lower quality (:ticket:`36447`).
* Fixed a regression in Django 5.2.2 where
:meth:`HttpRequest.get_preferred_type() <django.http.HttpRequest.get_preferred_type>`
incorrectly preferred more specific media types with a lower quality
(:ticket:`36447`).
* Fixed a regression in Django 5.2.3 where ``Value(None, JSONField())`` used in
a :class:`~django.db.models.expressions.When` condition was incorrectly

57
docs/releases/security.txt
View File

@@ -713,8 +713,9 @@ Versions affected
August 1, 2019 - :cve:`2019-14232`
----------------------------------
Denial-of-service possibility in ``django.utils.text.Truncator``. `Full
description <https://www.djangoproject.com/weblog/2019/aug/01/security-releases/>`__
Denial-of-service possibility in ``django.utils.text.Truncator``.
`Full description
<https://www.djangoproject.com/weblog/2019/aug/01/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -726,8 +727,9 @@ Versions affected
July 1, 2019 - :cve:`2019-12781`
--------------------------------
Incorrect HTTP detection with reverse-proxy connecting via HTTPS. `Full
description <https://www.djangoproject.com/weblog/2019/jul/01/security-releases/>`__
Incorrect HTTP detection with reverse-proxy connecting via HTTPS.
`Full description
<https://www.djangoproject.com/weblog/2019/jul/01/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -739,8 +741,9 @@ Versions affected
June 3, 2019 - :cve:`2019-12308`
--------------------------------
XSS via "Current URL" link generated by ``AdminURLFieldWidget``. `Full
description <https://www.djangoproject.com/weblog/2019/jun/03/security-releases/>`__
XSS via "Current URL" link generated by ``AdminURLFieldWidget``.
`Full description
<https://www.djangoproject.com/weblog/2019/jun/03/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -855,8 +858,9 @@ Versions affected
September 5, 2017 - :cve:`2017-12794`
-------------------------------------
Possible XSS in traceback section of technical 500 debug page. `Full
description <https://www.djangoproject.com/weblog/2017/sep/05/security-releases/>`__
Possible XSS in traceback section of technical 500 debug page.
`Full description
<https://www.djangoproject.com/weblog/2017/sep/05/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -867,8 +871,9 @@ Versions affected
April 4, 2017 - :cve:`2017-7234`
--------------------------------
Open redirect vulnerability in ``django.views.static.serve()``. `Full
description <https://www.djangoproject.com/weblog/2017/apr/04/security-releases/>`__
Open redirect vulnerability in ``django.views.static.serve()``.
`Full description
<https://www.djangoproject.com/weblog/2017/apr/04/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -881,7 +886,8 @@ April 4, 2017 - :cve:`2017-7233`
--------------------------------
Open redirect and possible XSS attack via user-supplied numeric redirect URLs.
`Full description <https://www.djangoproject.com/weblog/2017/apr/04/security-releases/>`__
`Full description
<https://www.djangoproject.com/weblog/2017/apr/04/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -906,8 +912,9 @@ Versions affected
November 1, 2016 - :cve:`2016-9013`
-----------------------------------
User with hardcoded password created when running tests on Oracle. `Full
description <https://www.djangoproject.com/weblog/2016/nov/01/security-releases/>`__
User with hardcoded password created when running tests on Oracle.
`Full description
<https://www.djangoproject.com/weblog/2016/nov/01/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -994,7 +1001,8 @@ August 18, 2015 - :cve:`2015-5963` / :cve:`2015-5964`
-----------------------------------------------------
Denial-of-service possibility in ``logout()`` view by filling session store.
`Full description <https://www.djangoproject.com/weblog/2015/aug/18/security-releases/>`__
`Full description
<https://www.djangoproject.com/weblog/2015/aug/18/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -1017,8 +1025,9 @@ Versions affected
July 8, 2015 - :cve:`2015-5144`
-------------------------------
Header injection possibility since validators accept newlines in input. `Full
description <https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
Header injection possibility since validators accept newlines in input.
`Full description
<https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -1030,8 +1039,9 @@ Versions affected
July 8, 2015 - :cve:`2015-5143`
-------------------------------
Denial-of-service possibility by filling session store. `Full
description <https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
Denial-of-service possibility by filling session store.
`Full description
<https://www.djangoproject.com/weblog/2015/jul/08/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -1054,8 +1064,9 @@ Versions affected
March 18, 2015 - :cve:`2015-2317`
---------------------------------
Mitigated possible XSS attack via user-supplied redirect URLs. `Full
description <https://www.djangoproject.com/weblog/2015/mar/18/security-releases/>`__
Mitigated possible XSS attack via user-supplied redirect URLs.
`Full description
<https://www.djangoproject.com/weblog/2015/mar/18/security-releases/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -1145,7 +1156,8 @@ August 20, 2014 - :cve:`2014-0483`
----------------------------------
Data leakage via querystring manipulation in admin.
`Full description <https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
`Full description
<https://www.djangoproject.com/weblog/2014/aug/20/security/>`__
Versions affected
~~~~~~~~~~~~~~~~~
@@ -1276,7 +1288,8 @@ Denial-of-service via large passwords. `Full description
Versions affected
~~~~~~~~~~~~~~~~~
* Django 1.4 :commit:`(patch <3f3d887a6844ec2db743fee64c9e53e04d39a368>` and :commit:`Python compatibility fix) <6903d1690a92aa040adfb0c8eb37cf62e4206714>`
* Django 1.4 :commit:`(patch <3f3d887a6844ec2db743fee64c9e53e04d39a368>` and
:commit:`Python compatibility fix) <6903d1690a92aa040adfb0c8eb37cf62e4206714>`
* Django 1.5 :commit:`(patch) <22b74fa09d7ccbc8c52270d648a0da7f3f0fa2bc>`
September 10, 2013 - :cve:`2013-4315`