<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Django 1.3 release notes — Django 1.8.19 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '1.8.19',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="top" title="Django 1.8.19 documentation" href="../contents.html" />
<link rel="up" title="Release notes" href="index.html" />
<link rel="next" title="Django 1.2.7 release notes" href="1.2.7.html" />
<link rel="prev" title="Django 1.3.1 release notes" href="1.3.1.html" />
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
if (!django_template_builtins) {
// templatebuiltins.js missing, do nothing.
return;
}
$(document).ready(function() {
// Hyperlink Django template tags and filters
var base = "../ref/templates/builtins.html";
if (base == "#") {
// Special case for builtins.html itself
base = "";
}
// Tags are keywords, class '.k'
$("div.highlight\\-html\\+django span.k").each(function(i, elem) {
var tagname = $(elem).text();
if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
var fragment = tagname.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
}
});
// Filters are functions, class '.nf'
$("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
var filtername = $(elem).text();
if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
var fragment = filtername.replace(/_/, '-');
$(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
}
});
});
})(jQuery);
</script>
</head>
<body role="document">
<div class="document">
<div id="custom-doc" class="yui-t6">
<div id="hd">
<h1><a href="../index.html">Django 1.8.19 documentation</a></h1>
<div id="global-nav">
<a title="Home page" href="../index.html">Home</a> |
<a title="Table of contents" href="../contents.html">Table of contents</a> |
<a title="Global index" href="../genindex.html">Index</a> |
<a title="Module index" href="../py-modindex.html">Modules</a>
</div>
<div class="nav">
« <a href="1.3.1.html" title="Django 1.3.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.2.7.html" title="Django 1.2.7 release notes">next</a> »</div>
</div>
<div id="bd">
<div id="yui-main">
<div class="yui-b">
<div class="yui-g" id="releases-1.3">
<div class="section" id="s-django-1-3-release-notes">
<span id="django-1-3-release-notes"></span><h1>Django 1.3 release notes<a class="headerlink" href="#django-1-3-release-notes" title="Permalink to this headline">¶</a></h1>
<p><em>March 23, 2011</em></p>
<p>Welcome to Django 1.3!</p>
<p>Nearly a year in the making, Django 1.3 includes quite a few <a class="reference internal" href="#whats-new-1-3"><span class="std std-ref">new features</span></a> and plenty of bug fixes and improvements to existing features.
These release notes cover the new features in 1.3, as well as some
<a class="reference internal" href="#backwards-incompatible-changes-1-3"><span class="std std-ref">backwards-incompatible changes</span></a>
you’ll want to be aware of when upgrading from Django 1.2 or older versions.</p>
<div class="section" id="s-overview">
<span id="overview"></span><h2>Overview<a class="headerlink" href="#overview" title="Permalink to this headline">¶</a></h2>
<p>Django 1.3’s focus has mostly been on resolving smaller, long-standing
feature requests, but that hasn’t prevented a few fairly significant
new features from landing, including:</p>
<ul class="simple">
<li>A framework for writing <a class="reference internal" href="#class-based-views">class-based views</a>.</li>
<li>Built-in support for <a class="reference internal" href="#logging">using Python’s logging facilities</a>.</li>
<li>Contrib support for <a class="reference internal" href="#extended-static-files-handling">easy handling of static files</a>.</li>
<li>Django’s testing framework now supports (and ships with a copy of)
<a class="reference internal" href="#unittest2-support">the unittest2 library</a>.</li>
</ul>
<p>Wherever possible, of course, new features are introduced in a
backwards-compatible manner per <a class="reference internal" href="../misc/api-stability.html"><span class="doc">our API stability policy</span></a> policy. As a result of this policy, Django 1.3
<a class="reference internal" href="#deprecated-features-1-3"><span class="std std-ref">begins the deprecation process for some features</span></a>.</p>
</div>
<div class="section" id="s-python-compatibility">
<span id="python-compatibility"></span><h2>Python compatibility<a class="headerlink" href="#python-compatibility" title="Permalink to this headline">¶</a></h2>
<p>The release of Django 1.2 was notable for having the first shift in
Django’s Python compatibility policy; prior to Django 1.2, Django
supported any 2.x version of Python from 2.3 up. As of Django 1.2, the
minimum requirement was raised to Python 2.4.</p>
<p>Django 1.3 continues to support Python 2.4, but will be the final
Django release series to do so; beginning with Django 1.4, the minimum
supported Python version will be 2.5. A document outlining our full
timeline for deprecating Python 2.x and moving to Python 3.x will be
published shortly after the release of Django 1.3.</p>
</div>
<div class="section" id="s-what-s-new-in-django-1-3">
<span id="s-whats-new-1-3"></span><span id="what-s-new-in-django-1-3"></span><span id="whats-new-1-3"></span><h2>What’s new in Django 1.3<a class="headerlink" href="#what-s-new-in-django-1-3" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-class-based-views">
<span id="class-based-views"></span><h3>Class-based views<a class="headerlink" href="#class-based-views" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 adds a framework that allows you to use a class as a view.
This means you can compose a view out of a collection of methods that
can be subclassed and overridden to provide common views of data without
having to write too much code.</p>
<p>Analogs of all the old function-based generic views have been
provided, along with a completely generic view base class that can be
used as the basis for reusable applications that can be easily
extended.</p>
<p>See <a class="reference internal" href="../topics/class-based-views/index.html"><span class="doc">the documentation on class-based generic views</span></a>
for more details. There is also a document to help you <a class="reference external" href="https://docs.djangoproject.com/en/1.4/topics/generic-views-migration/">convert
your function-based generic views to class-based
views</a>.</p>
</div>
<div class="section" id="s-logging">
<span id="logging"></span><h3>Logging<a class="headerlink" href="#logging" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 adds framework-level support for Python’s <code class="docutils literal"><span class="pre">logging</span></code>
module. This means you can now easily configure and control logging
as part of your Django project. A number of logging handlers and
logging calls have been added to Django’s own code as well – most
notably, the error emails sent on a HTTP 500 server error are now
handled as a logging activity. See <a class="reference internal" href="../topics/logging.html"><span class="doc">the documentation on Django’s
logging interface</span></a> for more details.</p>
</div>
<div class="section" id="s-extended-static-files-handling">
<span id="extended-static-files-handling"></span><h3>Extended static files handling<a class="headerlink" href="#extended-static-files-handling" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 ships with a new contrib app –
<code class="docutils literal"><span class="pre">django.contrib.staticfiles</span></code> – to help developers handle the static
media files (images, CSS, JavaScript, etc.) that are needed to render
a complete web page.</p>
<p>In previous versions of Django, it was common to place static assets
in <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_ROOT"><code class="xref std std-setting docutils literal"><span class="pre">MEDIA_ROOT</span></code></a> along with user-uploaded files, and serve
them both at <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_URL"><code class="xref std std-setting docutils literal"><span class="pre">MEDIA_URL</span></code></a>. Part of the purpose of introducing
the <code class="docutils literal"><span class="pre">staticfiles</span></code> app is to make it easier to keep static files
separate from user-uploaded files. Static assets should now go in
<code class="docutils literal"><span class="pre">static/</span></code> subdirectories of your apps or in other static assets
directories listed in <a class="reference internal" href="../ref/settings.html#std:setting-STATICFILES_DIRS"><code class="xref std std-setting docutils literal"><span class="pre">STATICFILES_DIRS</span></code></a>, and will be served
at <a class="reference internal" href="../ref/settings.html#std:setting-STATIC_URL"><code class="xref std std-setting docutils literal"><span class="pre">STATIC_URL</span></code></a>.</p>
<p>See the <a class="reference internal" href="../ref/contrib/staticfiles.html"><span class="doc">reference documentation of the app</span></a>
for more details or learn how to <a class="reference internal" href="../howto/static-files/index.html"><span class="doc">manage static files</span></a>.</p>
</div>
<div class="section" id="s-unittest2-support">
<span id="unittest2-support"></span><h3>unittest2 support<a class="headerlink" href="#unittest2-support" title="Permalink to this headline">¶</a></h3>
<p>Python 2.7 introduced some major changes to the <code class="docutils literal"><span class="pre">unittest</span></code> library,
adding some extremely useful features. To ensure that every Django
project can benefit from these new features, Django ships with a copy
of <a class="reference external" href="https://pypi.python.org/pypi/unittest2">unittest2</a>, a copy of the Python 2.7 unittest library, backported
for Python 2.4 compatibility.</p>
<p>To access this library, Django provides the <code class="docutils literal"><span class="pre">django.utils.unittest</span></code>
module alias. If you are using Python 2.7, or you have installed
<code class="docutils literal"><span class="pre">unittest2</span></code> locally, Django will map the alias to the installed
version of the unittest library. Otherwise, Django will use its own
bundled version of unittest2.</p>
<p>To take advantage of this alias, simply use:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django.utils</span> <span class="k">import</span> <span class="n">unittest</span>
</pre></div>
</div>
<p>wherever you would have historically used:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">unittest</span>
</pre></div>
</div>
<p>If you want to continue to use the base unittest library, you can –
you just won’t get any of the nice new unittest2 features.</p>
</div>
<div class="section" id="s-transaction-context-managers">
<span id="transaction-context-managers"></span><h3>Transaction context managers<a class="headerlink" href="#transaction-context-managers" title="Permalink to this headline">¶</a></h3>
<p>Users of Python 2.5 and above may now use transaction management functions as
<a class="reference external" href="https://docs.python.org/glossary.html#term-context-manager">context managers</a>. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">with</span> <span class="n">transaction</span><span class="o">.</span><span class="n">autocommit</span><span class="p">():</span>
<span class="c1"># ...</span>
</pre></div>
</div>
</div>
<div class="section" id="s-configurable-delete-cascade">
<span id="configurable-delete-cascade"></span><h3>Configurable delete-cascade<a class="headerlink" href="#configurable-delete-cascade" title="Permalink to this headline">¶</a></h3>
<p><a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey" title="django.db.models.ForeignKey"><code class="xref py py-class docutils literal"><span class="pre">ForeignKey</span></code></a> and
<a class="reference internal" href="../ref/models/fields.html#django.db.models.OneToOneField" title="django.db.models.OneToOneField"><code class="xref py py-class docutils literal"><span class="pre">OneToOneField</span></code></a> now accept an
<a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.on_delete" title="django.db.models.ForeignKey.on_delete"><code class="xref py py-attr docutils literal"><span class="pre">on_delete</span></code></a> argument to customize behavior
when the referenced object is deleted. Previously, deletes were always
cascaded; available alternatives now include set null, set default, set to any
value, protect, or do nothing.</p>
<p>For more information, see the <a class="reference internal" href="../ref/models/fields.html#django.db.models.ForeignKey.on_delete" title="django.db.models.ForeignKey.on_delete"><code class="xref py py-attr docutils literal"><span class="pre">on_delete</span></code></a>
documentation.</p>
</div>
<div class="section" id="s-contextual-markers-and-comments-for-translatable-strings">
<span id="contextual-markers-and-comments-for-translatable-strings"></span><h3>Contextual markers and comments for translatable strings<a class="headerlink" href="#contextual-markers-and-comments-for-translatable-strings" title="Permalink to this headline">¶</a></h3>
<p>For translation strings with ambiguous meaning, you can now
use the <code class="docutils literal"><span class="pre">pgettext</span></code> function to specify the context of the string.</p>
<p>And if you just want to add some information for translators, you
can also add special translator comments in the source.</p>
<p>For more information, see <a class="reference internal" href="../topics/i18n/translation.html#contextual-markers"><span class="std std-ref">Contextual markers</span></a> and
<a class="reference internal" href="../topics/i18n/translation.html#translator-comments"><span class="std std-ref">Comments for translators</span></a>.</p>
</div>
<div class="section" id="s-improvements-to-built-in-template-tags">
<span id="improvements-to-built-in-template-tags"></span><h3>Improvements to built-in template tags<a class="headerlink" href="#improvements-to-built-in-template-tags" title="Permalink to this headline">¶</a></h3>
<p>A number of improvements have been made to Django’s built-in template tags:</p>
<ul class="simple">
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal"><span class="pre">include</span></code></a> tag now accepts a <code class="docutils literal"><span class="pre">with</span></code> option, allowing
you to specify context variables to the included template</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-include"><code class="xref std std-ttag docutils literal"><span class="pre">include</span></code></a> tag now accepts an <code class="docutils literal"><span class="pre">only</span></code> option, allowing
you to exclude the current context from the included context</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-with"><code class="xref std std-ttag docutils literal"><span class="pre">with</span></code></a> tag now allows you to define multiple context
variables in a single <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-with"><code class="xref std std-ttag docutils literal"><span class="pre">with</span></code></a> block.</li>
<li>The <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-load"><code class="xref std std-ttag docutils literal"><span class="pre">load</span></code></a> tag now accepts a <code class="docutils literal"><span class="pre">from</span></code> argument, allowing
you to load a single tag or filter from a library.</li>
</ul>
</div>
<div class="section" id="s-templateresponse">
<span id="templateresponse"></span><h3>TemplateResponse<a class="headerlink" href="#templateresponse" title="Permalink to this headline">¶</a></h3>
<p>It can sometimes be beneficial to allow decorators or middleware to
modify a response <em>after</em> it has been constructed by the view. For
example, you may want to change the template that is used, or put
additional data into the context.</p>
<p>However, you can’t (easily) modify the content of a basic
<a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></a> after it has been constructed. To
overcome this limitation, Django 1.3 adds a new
<a class="reference internal" href="../ref/template-response.html#django.template.response.TemplateResponse" title="django.template.response.TemplateResponse"><code class="xref py py-class docutils literal"><span class="pre">TemplateResponse</span></code></a> class. Unlike basic
<a class="reference internal" href="../ref/request-response.html#django.http.HttpResponse" title="django.http.HttpResponse"><code class="xref py py-class docutils literal"><span class="pre">HttpResponse</span></code></a> objects,
<a class="reference internal" href="../ref/template-response.html#django.template.response.TemplateResponse" title="django.template.response.TemplateResponse"><code class="xref py py-class docutils literal"><span class="pre">TemplateResponse</span></code></a> objects retain the details
of the template and context that was provided by the view to compute
the response. The final output of the response is not computed until
it is needed, later in the response process.</p>
<p>For more details, see the <a class="reference internal" href="../ref/template-response.html"><span class="doc">documentation</span></a>
on the <a class="reference internal" href="../ref/template-response.html#django.template.response.TemplateResponse" title="django.template.response.TemplateResponse"><code class="xref py py-class docutils literal"><span class="pre">TemplateResponse</span></code></a> class.</p>
</div>
<div class="section" id="s-caching-changes">
<span id="caching-changes"></span><h3>Caching changes<a class="headerlink" href="#caching-changes" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 sees the introduction of several improvements to the
Django’s caching infrastructure.</p>
<p>Firstly, Django now supports multiple named caches. In the same way
that Django 1.2 introduced support for multiple database connections,
Django 1.3 allows you to use the new <a class="reference internal" href="../ref/settings.html#std:setting-CACHES"><code class="xref std std-setting docutils literal"><span class="pre">CACHES</span></code></a> setting to
define multiple named cache connections.</p>
<p>Secondly, <a class="reference internal" href="../topics/cache.html#cache-versioning"><span class="std std-ref">versioning</span></a>, <a class="reference internal" href="../topics/cache.html#cache-key-prefixing"><span class="std std-ref">site-wide
prefixing</span></a> and <a class="reference internal" href="../topics/cache.html#cache-key-transformation"><span class="std std-ref">transformation</span></a> have been added to the cache API.</p>
<p>Thirdly, <a class="reference internal" href="../topics/cache.html#using-vary-headers"><span class="std std-ref">cache key creation</span></a> has been
updated to take the request query string into account on <code class="docutils literal"><span class="pre">GET</span></code>
requests.</p>
<p>Finally, support for <a class="reference external" href="http://sendapatch.se/projects/pylibmc/">pylibmc</a> has been added to the memcached cache
backend.</p>
<p>For more details, see the <a class="reference internal" href="../topics/cache.html"><span class="doc">documentation on
caching in Django</span></a>.</p>
</div>
<div class="section" id="s-permissions-for-inactive-users">
<span id="permissions-for-inactive-users"></span><h3>Permissions for inactive users<a class="headerlink" href="#permissions-for-inactive-users" title="Permalink to this headline">¶</a></h3>
<p>If you provide a custom auth backend with <code class="docutils literal"><span class="pre">supports_inactive_user</span></code>
set to <code class="docutils literal"><span class="pre">True</span></code>, an inactive <code class="docutils literal"><span class="pre">User</span></code> instance will check the backend
for permissions. This is useful for further centralizing the
permission handling. See the <a class="reference internal" href="../topics/auth/index.html"><span class="doc">authentication docs</span></a>
for more details.</p>
</div>
<div class="section" id="s-geodjango">
<span id="geodjango"></span><h3>GeoDjango<a class="headerlink" href="#geodjango" title="Permalink to this headline">¶</a></h3>
<p>The GeoDjango test suite is now included when
<a class="reference internal" href="../internals/contributing/writing-code/unit-tests.html#running-unit-tests"><span class="std std-ref">running the Django test suite</span></a> with <code class="docutils literal"><span class="pre">runtests.py</span></code>
when using <a class="reference internal" href="../ref/contrib/gis/db-api.html#spatial-backends"><span class="std std-ref">spatial database backends</span></a>.</p>
</div>
<div class="section" id="s-media-url-and-static-url-must-end-in-a-slash">
<span id="media-url-and-static-url-must-end-in-a-slash"></span><h3><a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_URL"><code class="xref std std-setting docutils literal"><span class="pre">MEDIA_URL</span></code></a> and <a class="reference internal" href="../ref/settings.html#std:setting-STATIC_URL"><code class="xref std std-setting docutils literal"><span class="pre">STATIC_URL</span></code></a> must end in a slash<a class="headerlink" href="#media-url-and-static-url-must-end-in-a-slash" title="Permalink to this headline">¶</a></h3>
<p>Previously, the <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_URL"><code class="xref std std-setting docutils literal"><span class="pre">MEDIA_URL</span></code></a> setting only required a trailing slash if
it contained a suffix beyond the domain name.</p>
<p>A trailing slash is now <em>required</em> for <a class="reference internal" href="../ref/settings.html#std:setting-MEDIA_URL"><code class="xref std std-setting docutils literal"><span class="pre">MEDIA_URL</span></code></a> and the new
<a class="reference internal" href="../ref/settings.html#std:setting-STATIC_URL"><code class="xref std std-setting docutils literal"><span class="pre">STATIC_URL</span></code></a> setting as long as it is not blank. This ensures there is
a consistent way to combine paths in templates.</p>
<p>Project settings which provide either of both settings without a trailing
slash will now raise a <code class="docutils literal"><span class="pre">PendingDeprecationWarning</span></code>.</p>
<p>In Django 1.4 this same condition will raise <code class="docutils literal"><span class="pre">DeprecationWarning</span></code>,
and in Django 1.5 will raise an <code class="docutils literal"><span class="pre">ImproperlyConfigured</span></code> exception.</p>
</div>
<div class="section" id="s-everything-else">
<span id="everything-else"></span><h3>Everything else<a class="headerlink" href="#everything-else" title="Permalink to this headline">¶</a></h3>
<p>Django <a class="reference internal" href="1.1.html"><span class="doc">1.1</span></a> and <a class="reference internal" href="1.2.html"><span class="doc">1.2</span></a> added
lots of big ticket items to Django, like multiple-database support,
model validation, and a session-based messages framework. However,
this focus on big features came at the cost of lots of smaller
features.</p>
<p>To compensate for this, the focus of the Django 1.3 development
process has been on adding lots of smaller, long standing feature
requests. These include:</p>
<ul class="simple">
<li>Improved tools for accessing and manipulating the current
<a class="reference internal" href="../ref/contrib/sites.html#django.contrib.sites.models.Site" title="django.contrib.sites.models.Site"><code class="xref py py-class docutils literal"><span class="pre">Site</span></code></a> object in
<a class="reference internal" href="../ref/contrib/sites.html"><span class="doc">the sites framework</span></a>.</li>
<li>A <a class="reference internal" href="../topics/testing/advanced.html#django.test.RequestFactory" title="django.test.RequestFactory"><code class="xref py py-class docutils literal"><span class="pre">RequestFactory</span></code></a> for mocking requests
in tests.</li>
<li>A new test assertion –
<a class="reference internal" href="../topics/testing/tools.html#django.test.TransactionTestCase.assertNumQueries" title="django.test.TransactionTestCase.assertNumQueries"><code class="xref py py-meth docutils literal"><span class="pre">assertNumQueries()</span></code></a> – making it
easier to test the database activity associated with a view.</li>
<li>Support for lookups spanning relations in admin’s
<a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.ModelAdmin.list_filter" title="django.contrib.admin.ModelAdmin.list_filter"><code class="xref py py-attr docutils literal"><span class="pre">list_filter</span></code></a>.</li>
<li>Support for <a class="reference external" href="https://www.owasp.org/index.php/HTTPOnly">HTTPOnly</a> cookies.</li>
<li><a class="reference internal" href="../topics/email.html#django.core.mail.mail_admins" title="django.core.mail.mail_admins"><code class="xref py py-meth docutils literal"><span class="pre">mail_admins()</span></code></a> and
<a class="reference internal" href="../topics/email.html#django.core.mail.mail_managers" title="django.core.mail.mail_managers"><code class="xref py py-meth docutils literal"><span class="pre">mail_managers()</span></code></a> now support easily attaching
HTML content to messages.</li>
<li><a class="reference internal" href="../topics/email.html#django.core.mail.EmailMessage" title="django.core.mail.EmailMessage"><code class="xref py py-class docutils literal"><span class="pre">EmailMessage</span></code></a> now supports CC’s.</li>
<li>Error emails now include more of the detail and formatting of the
debug server error page.</li>
<li><a class="reference internal" href="../howto/custom-template-tags.html#django.template.Library.simple_tag" title="django.template.Library.simple_tag"><code class="xref py py-meth docutils literal"><span class="pre">simple_tag()</span></code></a> now accepts a
<code class="docutils literal"><span class="pre">takes_context</span></code> argument, making it easier to write simple
template tags that require access to template context.</li>
<li>A new <a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.render" title="django.shortcuts.render"><code class="xref py py-meth docutils literal"><span class="pre">render()</span></code></a> shortcut – an alternative
to <a class="reference internal" href="../topics/http/shortcuts.html#django.shortcuts.render_to_response" title="django.shortcuts.render_to_response"><code class="xref py py-meth docutils literal"><span class="pre">render_to_response()</span></code></a> providing a
<a class="reference internal" href="../ref/templates/api.html#django.template.RequestContext" title="django.template.RequestContext"><code class="xref py py-class docutils literal"><span class="pre">RequestContext</span></code></a> by default.</li>
<li>Support for combining <a class="reference internal" href="../ref/models/expressions.html#django.db.models.F" title="django.db.models.F"><code class="xref py py-class docutils literal"><span class="pre">F</span> <span class="pre">expressions</span></code></a>
with timedelta values when retrieving or updating database values.</li>
</ul>
</div>
</div>
<div class="section" id="s-backwards-incompatible-changes-in-1-3">
<span id="s-backwards-incompatible-changes-1-3"></span><span id="backwards-incompatible-changes-in-1-3"></span><span id="backwards-incompatible-changes-1-3"></span><h2>Backwards-incompatible changes in 1.3<a class="headerlink" href="#backwards-incompatible-changes-in-1-3" title="Permalink to this headline">¶</a></h2>
<div class="section" id="s-csrf-validation-now-applies-to-ajax-requests">
<span id="csrf-validation-now-applies-to-ajax-requests"></span><h3>CSRF validation now applies to AJAX requests<a class="headerlink" href="#csrf-validation-now-applies-to-ajax-requests" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.2.5, Django’s CSRF-prevention system exempted AJAX
requests from CSRF verification; due to <a class="reference external" href="https://www.djangoproject.com/weblog/2011/feb/08/security/">security issues</a> reported to
us, however, <em>all</em> requests are now subjected to CSRF
verification. Consult <a class="reference internal" href="../ref/csrf.html"><span class="doc">the Django CSRF documentation</span></a> for details on how to handle CSRF verification in
AJAX requests.</p>
</div>
<div class="section" id="s-restricted-filters-in-admin-interface">
<span id="restricted-filters-in-admin-interface"></span><h3>Restricted filters in admin interface<a class="headerlink" href="#restricted-filters-in-admin-interface" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.2.5, the Django administrative interface allowed
filtering on any model field or relation – not just those specified
in <code class="docutils literal"><span class="pre">list_filter</span></code> – via query string manipulation. Due to security
issues reported to us, however, query string lookup arguments in the
admin must be for fields or relations specified in <code class="docutils literal"><span class="pre">list_filter</span></code> or
<code class="docutils literal"><span class="pre">date_hierarchy</span></code>.</p>
</div>
<div class="section" id="s-deleting-a-model-doesn-t-delete-associated-files">
<span id="deleting-a-model-doesn-t-delete-associated-files"></span><h3>Deleting a model doesn’t delete associated files<a class="headerlink" href="#deleting-a-model-doesn-t-delete-associated-files" title="Permalink to this headline">¶</a></h3>
<p>In earlier Django versions, when a model instance containing a
<a class="reference internal" href="../ref/models/fields.html#django.db.models.FileField" title="django.db.models.FileField"><code class="xref py py-class docutils literal"><span class="pre">FileField</span></code></a> was deleted,
<a class="reference internal" href="../ref/models/fields.html#django.db.models.FileField" title="django.db.models.FileField"><code class="xref py py-class docutils literal"><span class="pre">FileField</span></code></a> took it upon itself to also delete the
file from the backend storage. This opened the door to several data-loss
scenarios, including rolled-back transactions and fields on different models
referencing the same file. In Django 1.3, when a model is deleted the
<a class="reference internal" href="../ref/models/fields.html#django.db.models.FileField" title="django.db.models.FileField"><code class="xref py py-class docutils literal"><span class="pre">FileField</span></code></a>’s <code class="docutils literal"><span class="pre">delete()</span></code> method won’t be called. If
you need cleanup of orphaned files, you’ll need to handle it yourself (for
instance, with a custom management command that can be run manually or
scheduled to run periodically via e.g. cron).</p>
</div>
<div class="section" id="s-passwordinput-default-rendering-behavior">
<span id="passwordinput-default-rendering-behavior"></span><h3>PasswordInput default rendering behavior<a class="headerlink" href="#passwordinput-default-rendering-behavior" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../ref/forms/widgets.html#django.forms.PasswordInput" title="django.forms.PasswordInput"><code class="xref py py-class docutils literal"><span class="pre">PasswordInput</span></code></a> form widget, intended for use
with form fields which represent passwords, accepts a boolean keyword
argument <code class="docutils literal"><span class="pre">render_value</span></code> indicating whether to send its data back to
the browser when displaying a submitted form with errors. Prior to
Django 1.3, this argument defaulted to <code class="docutils literal"><span class="pre">True</span></code>, meaning that the
submitted password would be sent back to the browser as part of the
form. Developers who wished to add a bit of additional security by
excluding that value from the redisplayed form could instantiate a
<a class="reference internal" href="../ref/forms/widgets.html#django.forms.PasswordInput" title="django.forms.PasswordInput"><code class="xref py py-class docutils literal"><span class="pre">PasswordInput</span></code></a> passing <code class="docutils literal"><span class="pre">render_value=False</span></code> .</p>
<p>Due to the sensitive nature of passwords, however, Django 1.3 takes
this step automatically; the default value of <code class="docutils literal"><span class="pre">render_value</span></code> is now
<code class="docutils literal"><span class="pre">False</span></code>, and developers who want the password value returned to the
browser on a submission with errors (the previous behavior) must now
explicitly indicate this. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">LoginForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">Form</span><span class="p">):</span>
<span class="n">username</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">max_length</span><span class="o">=</span><span class="mi">100</span><span class="p">)</span>
<span class="n">password</span> <span class="o">=</span> <span class="n">forms</span><span class="o">.</span><span class="n">CharField</span><span class="p">(</span><span class="n">widget</span><span class="o">=</span><span class="n">forms</span><span class="o">.</span><span class="n">PasswordInput</span><span class="p">(</span><span class="n">render_value</span><span class="o">=</span><span class="kc">True</span><span class="p">))</span>
</pre></div>
</div>
</div>
<div class="section" id="s-clearable-default-widget-for-filefield">
<span id="clearable-default-widget-for-filefield"></span><h3>Clearable default widget for FileField<a class="headerlink" href="#clearable-default-widget-for-filefield" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 now includes a <a class="reference internal" href="../ref/forms/widgets.html#django.forms.ClearableFileInput" title="django.forms.ClearableFileInput"><code class="xref py py-class docutils literal"><span class="pre">ClearableFileInput</span></code></a> form widget
in addition to <a class="reference internal" href="../ref/forms/widgets.html#django.forms.FileInput" title="django.forms.FileInput"><code class="xref py py-class docutils literal"><span class="pre">FileInput</span></code></a>. <code class="docutils literal"><span class="pre">ClearableFileInput</span></code> renders
with a checkbox to clear the field’s value (if the field has a value and is not
required); <code class="docutils literal"><span class="pre">FileInput</span></code> provided no means for clearing an existing file from
a <code class="docutils literal"><span class="pre">FileField</span></code>.</p>
<p><code class="docutils literal"><span class="pre">ClearableFileInput</span></code> is now the default widget for a <code class="docutils literal"><span class="pre">FileField</span></code>, so
existing forms including <code class="docutils literal"><span class="pre">FileField</span></code> without assigning a custom widget will
need to account for the possible extra checkbox in the rendered form output.</p>
<p>To return to the previous rendering (without the ability to clear the
<code class="docutils literal"><span class="pre">FileField</span></code>), use the <code class="docutils literal"><span class="pre">FileInput</span></code> widget in place of
<code class="docutils literal"><span class="pre">ClearableFileInput</span></code>. For instance, in a <code class="docutils literal"><span class="pre">ModelForm</span></code> for a hypothetical
<code class="docutils literal"><span class="pre">Document</span></code> model with a <code class="docutils literal"><span class="pre">FileField</span></code> named <code class="docutils literal"><span class="pre">document</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">django</span> <span class="k">import</span> <span class="n">forms</span>
<span class="kn">from</span> <span class="nn">myapp.models</span> <span class="k">import</span> <span class="n">Document</span>
<span class="k">class</span> <span class="nc">DocumentForm</span><span class="p">(</span><span class="n">forms</span><span class="o">.</span><span class="n">ModelForm</span><span class="p">):</span>
<span class="k">class</span> <span class="nc">Meta</span><span class="p">:</span>
<span class="n">model</span> <span class="o">=</span> <span class="n">Document</span>
<span class="n">widgets</span> <span class="o">=</span> <span class="p">{</span><span class="s1">'document'</span><span class="p">:</span> <span class="n">forms</span><span class="o">.</span><span class="n">FileInput</span><span class="p">}</span>
</pre></div>
</div>
</div>
<div class="section" id="s-new-index-on-database-session-table">
<span id="new-index-on-database-session-table"></span><h3>New index on database session table<a class="headerlink" href="#new-index-on-database-session-table" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.3, the database table used by the database backend
for the <a class="reference internal" href="../topics/http/sessions.html"><span class="doc">sessions</span></a> app had no index on
the <code class="docutils literal"><span class="pre">expire_date</span></code> column. As a result, date-based queries on the
session table – such as the query that is needed to purge old
sessions – would be very slow if there were lots of sessions.</p>
<p>If you have an existing project that is using the database session
backend, you don’t have to do anything to accommodate this change.
However, you may get a significant performance boost if you manually
add the new index to the session table. The SQL that will add the
index can be found by running the <a class="reference internal" href="../ref/django-admin.html#django-admin-sqlindexes"><code class="xref std std-djadmin docutils literal"><span class="pre">sqlindexes</span></code></a> admin
command:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="n">python</span> <span class="n">manage</span><span class="o">.</span><span class="n">py</span> <span class="n">sqlindexes</span> <span class="n">sessions</span>
</pre></div>
</div>
</div>
<div class="section" id="s-no-more-naughty-words">
<span id="no-more-naughty-words"></span><h3>No more naughty words<a class="headerlink" href="#no-more-naughty-words" title="Permalink to this headline">¶</a></h3>
<p>Django has historically provided (and enforced) a list of profanities.
The comments app has enforced this list of profanities, preventing people from
submitting comments that contained one of those profanities.</p>
<p>Unfortunately, the technique used to implement this profanities list
was woefully naive, and prone to the <a class="reference external" href="https://en.wikipedia.org/wiki/Scunthorpe_problem">Scunthorpe problem</a>. Improving
the built-in filter to fix this problem would require significant
effort, and since natural language processing isn’t the normal domain
of a web framework, we have “fixed” the problem by making the list of
prohibited words an empty list.</p>
<p>If you want to restore the old behavior, simply put a
<code class="docutils literal"><span class="pre">PROFANITIES_LIST</span></code> setting in your settings file that includes the
words that you want to prohibit (see the <a class="reference external" href="https://code.djangoproject.com/changeset/13996">commit that implemented this
change</a> if you want to see the list of words that was historically
prohibited). However, if avoiding profanities is important to you, you
would be well advised to seek out a better, less naive approach to the
problem.</p>
</div>
<div class="section" id="s-localflavor-changes">
<span id="localflavor-changes"></span><h3>Localflavor changes<a class="headerlink" href="#localflavor-changes" title="Permalink to this headline">¶</a></h3>
<p>Django 1.3 introduces the following backwards-incompatible changes to
local flavors:</p>
<ul class="simple">
<li>Canada (ca) – The province “Newfoundland and Labrador” has had its
province code updated to “NL”, rather than the older “NF”. In
addition, the Yukon Territory has had its province code corrected to
“YT”, instead of “YK”.</li>
<li>Indonesia (id) – The province “Nanggroe Aceh Darussalam (NAD)” has
been removed from the province list in favor of the new official
designation “Aceh (ACE)”.</li>
<li>United States of America (us) – The list of “states” used by
<code class="docutils literal"><span class="pre">USStateField</span></code> has expanded to include Armed Forces postal
codes. This is backwards-incompatible if you were relying on
<code class="docutils literal"><span class="pre">USStateField</span></code> not including them.</li>
</ul>
</div>
<div class="section" id="s-formset-updates">
<span id="formset-updates"></span><h3>FormSet updates<a class="headerlink" href="#formset-updates" title="Permalink to this headline">¶</a></h3>
<p>In Django 1.3 <code class="docutils literal"><span class="pre">FormSet</span></code> creation behavior is modified slightly. Historically
the class didn’t make a distinction between not being passed data and being
passed empty dictionary. This was inconsistent with behavior in other parts of
the framework. Starting with 1.3 if you pass in empty dictionary the
<code class="docutils literal"><span class="pre">FormSet</span></code> will raise a <code class="docutils literal"><span class="pre">ValidationError</span></code>.</p>
<p>For example with a <code class="docutils literal"><span class="pre">FormSet</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="k">class</span> <span class="nc">ArticleForm</span><span class="p">(</span><span class="n">Form</span><span class="p">):</span>
<span class="gp">... </span> <span class="n">title</span> <span class="o">=</span> <span class="n">CharField</span><span class="p">()</span>
<span class="gp">... </span> <span class="n">pub_date</span> <span class="o">=</span> <span class="n">DateField</span><span class="p">()</span>
<span class="gp">>>> </span><span class="n">ArticleFormSet</span> <span class="o">=</span> <span class="n">formset_factory</span><span class="p">(</span><span class="n">ArticleForm</span><span class="p">)</span>
</pre></div>
</div>
<p>the following code will raise a <code class="docutils literal"><span class="pre">ValidationError</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">ArticleFormSet</span><span class="p">({})</span>
<span class="gt">Traceback (most recent call last):</span>
<span class="c">...</span>
<span class="gr">ValidationError</span>: <span class="n">[u'ManagementForm data is missing or has been tampered with']</span>
</pre></div>
</div>
<p>if you need to instantiate an empty <code class="docutils literal"><span class="pre">FormSet</span></code>, don’t pass in the data or use
<code class="docutils literal"><span class="pre">None</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">formset</span> <span class="o">=</span> <span class="n">ArticleFormSet</span><span class="p">()</span>
<span class="gp">>>> </span><span class="n">formset</span> <span class="o">=</span> <span class="n">ArticleFormSet</span><span class="p">(</span><span class="n">data</span><span class="o">=</span><span class="kc">None</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="s-callables-in-templates">
<span id="callables-in-templates"></span><h3>Callables in templates<a class="headerlink" href="#callables-in-templates" title="Permalink to this headline">¶</a></h3>
<p>Previously, a callable in a template would only be called automatically as part
of the variable resolution process if it was retrieved via attribute
lookup. This was an inconsistency that could result in confusing and unhelpful
behavior:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">Template</span><span class="p">(</span><span class="s2">"{{ user.get_full_name }}"</span><span class="p">)</span><span class="o">.</span><span class="n">render</span><span class="p">(</span><span class="n">Context</span><span class="p">({</span><span class="s1">'user'</span><span class="p">:</span> <span class="n">user</span><span class="p">}))</span>
<span class="go">u'Joe Bloggs'</span>
<span class="gp">>>> </span><span class="n">Template</span><span class="p">(</span><span class="s2">"{{ full_name }}"</span><span class="p">)</span><span class="o">.</span><span class="n">render</span><span class="p">(</span><span class="n">Context</span><span class="p">({</span><span class="s1">'full_name'</span><span class="p">:</span> <span class="n">user</span><span class="o">.</span><span class="n">get_full_name</span><span class="p">}))</span>
<span class="go">u'&lt;bound method User.get_full_name of &lt;...</span>
</pre></div>
</div>
<p>This has been resolved in Django 1.3 - the result in both cases will be <code class="docutils literal"><span class="pre">u'Joe</span>
<span class="pre">Bloggs'</span></code>. 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.</p>
</div>
<div class="section" id="s-use-of-custom-sql-to-load-initial-data-in-tests">
<span id="use-of-custom-sql-to-load-initial-data-in-tests"></span><h3>Use of custom SQL to load initial data in tests<a class="headerlink" href="#use-of-custom-sql-to-load-initial-data-in-tests" title="Permalink to this headline">¶</a></h3>
<p>Django provides a custom SQL hooks as a way to inject hand-crafted SQL
into the database synchronization process. One of the possible uses
for this custom SQL is to insert data into your database. If your
custom SQL contains <code class="docutils literal"><span class="pre">INSERT</span></code> statements, those insertions will be
performed every time your database is synchronized. This includes the
synchronization of any test databases that are created when you run a
test suite.</p>
<p>However, in the process of testing the Django 1.3, it was discovered
that this feature has never completely worked as advertised. When
using database backends that don’t support transactions, or when using
a TransactionTestCase, data that has been inserted using custom SQL
will not be visible during the testing process.</p>
<p>Unfortunately, there was no way to rectify this problem without
introducing a backwards incompatibility. Rather than leave
SQL-inserted initial data in an uncertain state, Django now enforces
the policy that data inserted by custom SQL will <em>not</em> be visible
during testing.</p>
<p>This change only affects the testing process. You can still use custom
SQL to load data into your production database as part of the syncdb
process. If you require data to exist during test conditions, you
should either insert it using <a class="reference internal" href="../topics/testing/tools.html#topics-testing-fixtures"><span class="std std-ref">test fixtures</span></a>, or using the <code class="docutils literal"><span class="pre">setUp()</span></code> method of your
test case.</p>
</div>
<div class="section" id="s-changed-priority-of-translation-loading">
<span id="changed-priority-of-translation-loading"></span><h3>Changed priority of translation loading<a class="headerlink" href="#changed-priority-of-translation-loading" title="Permalink to this headline">¶</a></h3>
<p>Work has been done to simplify, rationalize and properly document the algorithm
used by Django at runtime to build translations from the different translations
found on disk, namely:</p>
<p>For translatable literals found in Python code and templates (<code class="docutils literal"><span class="pre">'django'</span></code>
gettext domain):</p>
<ul class="simple">
<li>Priorities of translations included with applications listed in the
<a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a> setting were changed. To provide a behavior
consistent with other parts of Django that also use such setting (templates,
etc.) now, when building the translation that will be made available, the
apps listed first have higher precedence than the ones listed later.</li>
<li>Now it is possible to override the translations shipped with applications by
using the <a class="reference internal" href="../ref/settings.html#std:setting-LOCALE_PATHS"><code class="xref std std-setting docutils literal"><span class="pre">LOCALE_PATHS</span></code></a> setting whose translations have now higher
precedence than the translations of <a class="reference internal" href="../ref/settings.html#std:setting-INSTALLED_APPS"><code class="xref std std-setting docutils literal"><span class="pre">INSTALLED_APPS</span></code></a> applications.
The relative priority among the values listed in this setting has also been
modified so the paths listed first have higher precedence than the
ones listed later.</li>
<li>The <code class="docutils literal"><span class="pre">locale</span></code> subdirectory of the directory containing the settings, that
usually coincides with and is known as the <em>project directory</em> is being
deprecated in this release as a source of translations. (the precedence of
these translations is intermediate between applications and <a class="reference internal" href="../ref/settings.html#std:setting-LOCALE_PATHS"><code class="xref std std-setting docutils literal"><span class="pre">LOCALE_PATHS</span></code></a>
translations). See the <a class="reference internal" href="#loading-of-project-level-translations">corresponding deprecated features section</a>
of this document.</li>
</ul>
<p>For translatable literals found in JavaScript code (<code class="docutils literal"><span class="pre">'djangojs'</span></code> gettext
domain):</p>
<ul class="simple">
<li>Similarly to the <code class="docutils literal"><span class="pre">'django'</span></code> domain translations: Overriding of
translations shipped with applications by using the <a class="reference internal" href="../ref/settings.html#std:setting-LOCALE_PATHS"><code class="xref std std-setting docutils literal"><span class="pre">LOCALE_PATHS</span></code></a>
setting is now possible for this domain too. These translations have higher
precedence than the translations of Python packages passed to the
<a class="reference internal" href="../topics/i18n/translation.html#javascript-catalog-view"><span class="std std-ref">javascript_catalog view</span></a>. Paths listed first
have higher precedence than the ones listed later.</li>
<li>Translations under the <code class="docutils literal"><span class="pre">locale</span></code> subdirectory of the <em>project directory</em>
have never been taken in account for JavaScript translations and remain in
the same situation considering the deprecation of such location.</li>
</ul>
</div>
<div class="section" id="s-transaction-management">
<span id="transaction-management"></span><h3>Transaction management<a class="headerlink" href="#transaction-management" title="Permalink to this headline">¶</a></h3>
<p>When using managed transactions – that is, anything but the default
autocommit mode – it is important when a transaction is marked as
“dirty”. Dirty transactions are committed by the <code class="docutils literal"><span class="pre">commit_on_success</span></code>
decorator or the <code class="docutils literal"><span class="pre">django.middleware.transaction.TransactionMiddleware</span></code>, and
<code class="docutils literal"><span class="pre">commit_manually</span></code> forces them to be closed explicitly; clean transactions
“get a pass”, which means they are usually rolled back at the end of a request
when the connection is closed.</p>
<p>Until Django 1.3, transactions were only marked dirty when Django was
aware of a modifying operation performed in them; that is, either some
model was saved, some bulk update or delete was performed, or the user
explicitly called <code class="docutils literal"><span class="pre">transaction.set_dirty()</span></code>. In Django 1.3, a
transaction is marked dirty when <em>any</em> database operation is
performed.</p>
<p>As a result of this change, you no longer need to set a transaction
dirty explicitly when you execute raw SQL or use a data-modifying
<code class="docutils literal"><span class="pre">SELECT</span></code>. However, you <em>do</em> need to explicitly close any read-only
transactions that are being managed using <code class="docutils literal"><span class="pre">commit_manually()</span></code>. For example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="nd">@transaction</span><span class="o">.</span><span class="n">commit_manually</span>
<span class="k">def</span> <span class="nf">my_view</span><span class="p">(</span><span class="n">request</span><span class="p">,</span> <span class="n">name</span><span class="p">):</span>
<span class="n">obj</span> <span class="o">=</span> <span class="n">get_object_or_404</span><span class="p">(</span><span class="n">MyObject</span><span class="p">,</span> <span class="n">name__iexact</span><span class="o">=</span><span class="n">name</span><span class="p">)</span>
<span class="k">return</span> <span class="n">render_to_response</span><span class="p">(</span><span class="s1">'template'</span><span class="p">,</span> <span class="p">{</span><span class="s1">'object'</span><span class="p">:</span><span class="n">obj</span><span class="p">})</span>
</pre></div>
</div>
<p>Prior to Django 1.3, this would work without error. However, under
Django 1.3, this will raise a
<a class="reference internal" href="../ref/exceptions.html#django.db.transaction.TransactionManagementError" title="django.db.transaction.TransactionManagementError"><code class="xref py py-class docutils literal"><span class="pre">TransactionManagementError</span></code></a> because
the read operation that retrieves the <code class="docutils literal"><span class="pre">MyObject</span></code> instance leaves the
transaction in a dirty state.</p>
</div>
<div class="section" id="s-no-password-reset-for-inactive-users">
<span id="no-password-reset-for-inactive-users"></span><h3>No password reset for inactive users<a class="headerlink" href="#no-password-reset-for-inactive-users" title="Permalink to this headline">¶</a></h3>
<p>Prior to Django 1.3, inactive users were able to request a password reset email
and reset their password. In Django 1.3 inactive users will receive the same
message as a nonexistent account.</p>
</div>
<div class="section" id="s-password-reset-view-now-accepts-from-email">
<span id="password-reset-view-now-accepts-from-email"></span><h3>Password reset view now accepts <code class="docutils literal"><span class="pre">from_email</span></code><a class="headerlink" href="#password-reset-view-now-accepts-from-email" title="Permalink to this headline">¶</a></h3>
<p>The <a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.views.password_reset" title="django.contrib.auth.views.password_reset"><code class="xref py py-func docutils literal"><span class="pre">django.contrib.auth.views.password_reset()</span></code></a> view now accepts a
<code class="docutils literal"><span class="pre">from_email</span></code> parameter, which is passed to the <code class="docutils literal"><span class="pre">password_reset_form</span></code>’s
<code class="docutils literal"><span class="pre">save()</span></code> method as a keyword argument. If you are using this view with a
custom password reset form, then you will need to ensure your form’s <code class="docutils literal"><span class="pre">save()</span></code>
method accepts this keyword argument.</p>
</div>
</div>
<div class="section" id="s-features-deprecated-in-1-3">
<span id="s-deprecated-features-1-3"></span><span id="features-deprecated-in-1-3"></span><span id="deprecated-features-1-3"></span><h2>Features deprecated in 1.3<a class="headerlink" href="#features-deprecated-in-1-3" title="Permalink to this headline">¶</a></h2>
<p>Django 1.3 deprecates some features from earlier releases.
These features are still supported, but will be gradually phased out
over the next few release cycles.</p>
<p>Code taking advantage of any of the features below will raise a
<code class="docutils literal"><span class="pre">PendingDeprecationWarning</span></code> in Django 1.3. This warning will be
silent by default, but may be turned on using Python’s <code class="xref py py-mod docutils literal"><span class="pre">warnings</span></code>
module, or by running Python with a <code class="docutils literal"><span class="pre">-Wd</span></code> or <code class="docutils literal"><span class="pre">-Wall</span></code> flag.</p>
<p>In Django 1.4, these warnings will become a <code class="docutils literal"><span class="pre">DeprecationWarning</span></code>,
which is <em>not</em> silent. In Django 1.5 support for these features will
be removed entirely.</p>
<div class="admonition seealso">
<p class="first admonition-title">See also</p>
<p class="last">For more details, see the documentation <a class="reference internal" href="../internals/release-process.html"><span class="doc">Django’s release process</span></a> and our <a class="reference internal" href="../internals/deprecation.html"><span class="doc">deprecation timeline</span></a>.</p>
</div>
<div class="section" id="s-mod-python-support">
<span id="mod-python-support"></span><h3><code class="docutils literal"><span class="pre">mod_python</span></code> support<a class="headerlink" href="#mod-python-support" title="Permalink to this headline">¶</a></h3>
<p>The <code class="docutils literal"><span class="pre">mod_python</span></code> library has not had a release since 2007 or a commit since
2008. The Apache Foundation board voted to remove <code class="docutils literal"><span class="pre">mod_python</span></code> from the set
of active projects in its version control repositories, and its lead developer
has shifted all of his efforts toward the lighter, slimmer, more stable, and
more flexible <code class="docutils literal"><span class="pre">mod_wsgi</span></code> backend.</p>
<p>If you are currently using the <code class="docutils literal"><span class="pre">mod_python</span></code> request handler, you
should redeploy your Django projects using another request handler.
<a class="reference internal" href="../howto/deployment/wsgi/modwsgi.html"><span class="doc">mod_wsgi</span></a> is the request handler
recommended by the Django project, but <a class="reference internal" href="../howto/deployment/fastcgi.html"><span class="doc">FastCGI</span></a> is also supported. Support for
<code class="docutils literal"><span class="pre">mod_python</span></code> deployment will be removed in Django 1.5.</p>
</div>
<div class="section" id="s-function-based-generic-views">
<span id="function-based-generic-views"></span><h3>Function-based generic views<a class="headerlink" href="#function-based-generic-views" title="Permalink to this headline">¶</a></h3>
<p>As a result of the introduction of class-based generic views, the
function-based generic views provided by Django have been deprecated.
The following modules and the views they contain have been deprecated:</p>
<ul class="simple">
<li><code class="docutils literal"><span class="pre">django.views.generic.create_update</span></code></li>
<li><code class="docutils literal"><span class="pre">django.views.generic.date_based</span></code></li>
<li><code class="docutils literal"><span class="pre">django.views.generic.list_detail</span></code></li>
<li><code class="docutils literal"><span class="pre">django.views.generic.simple</span></code></li>
</ul>
</div>
<div class="section" id="s-test-client-response-template-attribute">
<span id="test-client-response-template-attribute"></span><h3>Test client response <code class="docutils literal"><span class="pre">template</span></code> attribute<a class="headerlink" href="#test-client-response-template-attribute" title="Permalink to this headline">¶</a></h3>
<p>Django’s <a class="reference internal" href="../topics/testing/tools.html#test-client"><span class="std std-ref">test client</span></a> returns
<a class="reference internal" href="../topics/testing/tools.html#django.test.Response" title="django.test.Response"><code class="xref py py-class docutils literal"><span class="pre">Response</span></code></a> objects annotated with extra testing
information. In Django versions prior to 1.3, this included a <code class="docutils literal"><span class="pre">template</span></code>
attribute containing information about templates rendered in generating the
response: either None, a single <a class="reference internal" href="../ref/templates/api.html#django.template.Template" title="django.template.Template"><code class="xref py py-class docutils literal"><span class="pre">Template</span></code></a> object, or a
list of <a class="reference internal" href="../ref/templates/api.html#django.template.Template" title="django.template.Template"><code class="xref py py-class docutils literal"><span class="pre">Template</span></code></a> objects. This inconsistency in
return values (sometimes a list, sometimes not) made the attribute difficult
to work with.</p>
<p>In Django 1.3 the <code class="docutils literal"><span class="pre">template</span></code> attribute is deprecated in favor of a new
<a class="reference internal" href="../topics/testing/tools.html#django.test.Response.templates" title="django.test.Response.templates"><code class="xref py py-attr docutils literal"><span class="pre">templates</span></code></a> attribute, which is always a
list, even if it has only a single element or no elements.</p>
</div>
<div class="section" id="s-djangotestrunner">
<span id="djangotestrunner"></span><h3><code class="docutils literal"><span class="pre">DjangoTestRunner</span></code><a class="headerlink" href="#djangotestrunner" title="Permalink to this headline">¶</a></h3>
<p>As a result of the introduction of support for unittest2, the features
of <code class="docutils literal"><span class="pre">django.test.simple.DjangoTestRunner</span></code> (including fail-fast
and Ctrl-C test termination) have been made redundant. In view of this
redundancy, <code class="docutils literal"><span class="pre">DjangoTestRunner</span></code> has been turned into an empty placeholder
class, and will be removed entirely in Django 1.5.</p>
</div>
<div class="section" id="s-changes-to-url-and-ssi">
<span id="changes-to-url-and-ssi"></span><h3>Changes to <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><code class="xref std std-ttag docutils literal"><span class="pre">url</span></code></a> and <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-ssi"><code class="xref std std-ttag docutils literal"><span class="pre">ssi</span></code></a><a class="headerlink" href="#changes-to-url-and-ssi" title="Permalink to this headline">¶</a></h3>
<p>Most template tags will allow you to pass in either constants or
variables as arguments – for example:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">extends</span> <span class="s2">"base.html"</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>allows you to specify a base template as a constant, but if you have a
context variable <code class="docutils literal"><span class="pre">templ</span></code> that contains the value <code class="docutils literal"><span class="pre">base.html</span></code>:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">extends</span> <span class="n">templ</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>is also legal.</p>
<p>However, due to an accident of history, the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><code class="xref std std-ttag docutils literal"><span class="pre">url</span></code></a> and
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-ssi"><code class="xref std std-ttag docutils literal"><span class="pre">ssi</span></code></a> are different. These tags use the second, quoteless
syntax, but interpret the argument as a constant. This means it isn’t
possible to use a context variable as the target of a <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><code class="xref std std-ttag docutils literal"><span class="pre">url</span></code></a> and
<a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-ssi"><code class="xref std std-ttag docutils literal"><span class="pre">ssi</span></code></a> tag.</p>
<p>Django 1.3 marks the start of the process to correct this historical
accident. Django 1.3 adds a new template library – <code class="docutils literal"><span class="pre">future</span></code> – that
provides alternate implementations of the <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-url"><code class="xref std std-ttag docutils literal"><span class="pre">url</span></code></a> and <a class="reference internal" href="../ref/templates/builtins.html#std:templatetag-ssi"><code class="xref std std-ttag docutils literal"><span class="pre">ssi</span></code></a>
template tags. This <code class="docutils literal"><span class="pre">future</span></code> library implement behavior that makes
the handling of the first argument consistent with the handling of all
other variables. So, an existing template that contains:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">url</span> <span class="n">sample</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>should be replaced with:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="o">%</span> <span class="n">load</span> <span class="n">url</span> <span class="kn">from</span> <span class="nn">future</span> <span class="o">%</span><span class="p">}</span>
<span class="p">{</span><span class="o">%</span> <span class="n">url</span> <span class="s1">'sample'</span> <span class="o">%</span><span class="p">}</span>
</pre></div>
</div>
<p>The tags implementing the old behavior have been deprecated, and in
Django 1.5, the old behavior will be replaced with the new behavior.
To ensure compatibility with future versions of Django, existing
templates should be modified to use the new <code class="docutils literal"><span class="pre">future</span></code> libraries and
syntax.</p>
</div>
<div class="section" id="s-changes-to-the-login-methods-of-the-admin">
<span id="changes-to-the-login-methods-of-the-admin"></span><h3>Changes to the login methods of the admin<a class="headerlink" href="#changes-to-the-login-methods-of-the-admin" title="Permalink to this headline">¶</a></h3>
<p>In previous version the admin app defined login methods in multiple locations
and ignored the almost identical implementation in the already used auth app.
A side effect of this duplication was the missing adoption of the changes made
in <a class="reference external" href="https://code.djangoproject.com/changeset/12634">r12634</a> to support a broader set of characters for usernames.</p>
<p>This release refactors the admin’s login mechanism to use a subclass of the
<a class="reference internal" href="../topics/auth/default.html#django.contrib.auth.forms.AuthenticationForm" title="django.contrib.auth.forms.AuthenticationForm"><code class="xref py py-class docutils literal"><span class="pre">AuthenticationForm</span></code></a> instead of a manual
form validation. The previously undocumented method
<code class="docutils literal"><span class="pre">'django.contrib.admin.sites.AdminSite.display_login_form'</span></code> has been removed
in favor of a new <a class="reference internal" href="../ref/contrib/admin/index.html#django.contrib.admin.AdminSite.login_form" title="django.contrib.admin.AdminSite.login_form"><code class="xref py py-attr docutils literal"><span class="pre">login_form</span></code></a>
attribute.</p>
</div>
<div class="section" id="s-reset-and-sqlreset-management-commands">
<span id="reset-and-sqlreset-management-commands"></span><h3><code class="docutils literal"><span class="pre">reset</span></code> and <code class="docutils literal"><span class="pre">sqlreset</span></code> management commands<a class="headerlink" href="#reset-and-sqlreset-management-commands" title="Permalink to this headline">¶</a></h3>
<p>Those commands have been deprecated. The <code class="docutils literal"><span class="pre">flush</span></code> and <code class="docutils literal"><span class="pre">sqlflush</span></code> commands
can be used to delete everything. You can also use ALTER TABLE or DROP TABLE
statements manually.</p>
</div>
<div class="section" id="s-id1">
<span id="id1"></span><h3>GeoDjango<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li>The function-based <a class="reference internal" href="../ref/settings.html#std:setting-TEST_RUNNER"><code class="xref std std-setting docutils literal"><span class="pre">TEST_RUNNER</span></code></a> previously used to execute
the GeoDjango test suite, <code class="docutils literal"><span class="pre">django.contrib.gis.tests.run_gis_tests</span></code>, was
deprecated for the class-based runner,
<code class="docutils literal"><span class="pre">django.contrib.gis.tests.GeoDjangoTestSuiteRunner</span></code>.</li>
<li>Previously, calling
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.transform" title="django.contrib.gis.geos.GEOSGeometry.transform"><code class="xref py py-meth docutils literal"><span class="pre">transform()</span></code></a> would
silently do nothing when GDAL wasn’t available. Now, a
<a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSException" title="django.contrib.gis.geos.GEOSException"><code class="xref py py-class docutils literal"><span class="pre">GEOSException</span></code></a> is properly raised
to indicate possible faulty application code. A warning is now
raised if <a class="reference internal" href="../ref/contrib/gis/geos.html#django.contrib.gis.geos.GEOSGeometry.transform" title="django.contrib.gis.geos.GEOSGeometry.transform"><code class="xref py py-meth docutils literal"><span class="pre">transform()</span></code></a> is
called when the SRID of the geometry is less than 0 or <code class="docutils literal"><span class="pre">None</span></code>.</li>
</ul>
</div>
<div class="section" id="s-czbirthnumberfield-clean">
<span id="czbirthnumberfield-clean"></span><h3><code class="docutils literal"><span class="pre">CZBirthNumberField.clean</span></code><a class="headerlink" href="#czbirthnumberfield-clean" title="Permalink to this headline">¶</a></h3>
<p>Previously this field’s <code class="docutils literal"><span class="pre">clean()</span></code> method accepted a second, gender, argument
which allowed stronger validation checks to be made, however since this
argument could never actually be passed from the Django form machinery it is
now pending deprecation.</p>
</div>
<div class="section" id="s-compatcookie">
<span id="compatcookie"></span><h3><code class="docutils literal"><span class="pre">CompatCookie</span></code><a class="headerlink" href="#compatcookie" title="Permalink to this headline">¶</a></h3>
<p>Previously, <code class="docutils literal"><span class="pre">django.http</span></code> exposed an undocumented <code class="docutils literal"><span class="pre">CompatCookie</span></code> class,
which was a bugfix wrapper around the standard library <code class="docutils literal"><span class="pre">SimpleCookie</span></code>. As the
fixes are moving upstream, this is now deprecated - you should use <code class="docutils literal"><span class="pre">from</span>
<span class="pre">django.http</span> <span class="pre">import</span> <span class="pre">SimpleCookie</span></code> instead.</p>
</div>
<div class="section" id="s-loading-of-project-level-translations">
<span id="s-id2"></span><span id="loading-of-project-level-translations"></span><span id="id2"></span><h3>Loading of <em>project-level</em> translations<a class="headerlink" href="#loading-of-project-level-translations" title="Permalink to this headline">¶</a></h3>
<p>This release of Django starts the deprecation process for inclusion of
translations located under the so-called <em>project path</em> in the translation
building process performed at runtime. The <a class="reference internal" href="../ref/settings.html#std:setting-LOCALE_PATHS"><code class="xref std std-setting docutils literal"><span class="pre">LOCALE_PATHS</span></code></a> setting can
be used for the same task by adding the filesystem path to a <code class="docutils literal"><span class="pre">locale</span></code>
directory containing project-level translations to the value of that setting.</p>
<p>Rationale for this decision:</p>
<ul>
<li><p class="first">The <em>project path</em> has always been a loosely defined concept
(actually, the directory used for locating project-level
translations is the directory containing the settings module) and
there has been a shift in other parts of the framework to stop using
it as a reference for location of assets at runtime.</p>
</li>
<li><p class="first">Detection of the <code class="docutils literal"><span class="pre">locale</span></code> subdirectory tends to fail when the
deployment scenario is more complex than the basic one. e.g. it
fails when the settings module is a directory (ticket #10765).</p>
</li>
<li><p class="first">There are potential strange development- and deployment-time
problems like the fact that the <code class="docutils literal"><span class="pre">project_dir/locale/</span></code> subdir can
generate spurious error messages when the project directory is added
to the Python path (<code class="docutils literal"><span class="pre">manage.py</span> <span class="pre">runserver</span></code> does this) and then it
clashes with the equally named standard library module, this is a
typical warning message:</p>
<div class="highlight-default"><div class="highlight"><pre><span></span><span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">python2</span><span class="o">.</span><span class="mi">6</span><span class="o">/</span><span class="n">gettext</span><span class="o">.</span><span class="n">py</span><span class="p">:</span><span class="mi">49</span><span class="p">:</span> <span class="ne">ImportWarning</span><span class="p">:</span> <span class="n">Not</span> <span class="n">importing</span> <span class="n">directory</span> <span class="s1">'/path/to/project/locale'</span><span class="p">:</span> <span class="n">missing</span> <span class="n">__init__</span><span class="o">.</span><span class="n">py</span><span class="o">.</span>
<span class="kn">import</span> <span class="nn">locale</span><span class="o">,</span> <span class="nn">copy</span><span class="o">,</span> <span class="nn">os</span><span class="o">,</span> <span class="nn">re</span><span class="o">,</span> <span class="nn">struct</span><span class="o">,</span> <span class="nn">sys</span>
</pre></div>
</div>
</li>
<li><p class="first">This location wasn’t included in the translation building process
for JavaScript literals. This deprecation removes such
inconsistency.</p>
</li>
</ul>
</div>
<div class="section" id="s-permwrapper-moved-to-django-contrib-auth-context-processors">
<span id="permwrapper-moved-to-django-contrib-auth-context-processors"></span><h3><code class="docutils literal"><span class="pre">PermWrapper</span></code> moved to <code class="docutils literal"><span class="pre">django.contrib.auth.context_processors</span></code><a class="headerlink" href="#permwrapper-moved-to-django-contrib-auth-context-processors" title="Permalink to this headline">¶</a></h3>
<p>In Django 1.2, we began the process of changing the location of the
<code class="docutils literal"><span class="pre">auth</span></code> context processor from <code class="docutils literal"><span class="pre">django.core.context_processors</span></code> to
<code class="docutils literal"><span class="pre">django.contrib.auth.context_processors</span></code>. However, the
<code class="docutils literal"><span class="pre">PermWrapper</span></code> support class was mistakenly omitted from that
migration. In Django 1.3, the <code class="docutils literal"><span class="pre">PermWrapper</span></code> class has also been
moved to <code class="docutils literal"><span class="pre">django.contrib.auth.context_processors</span></code>, along with the
<code class="docutils literal"><span class="pre">PermLookupDict</span></code> support class. The new classes are functionally
identical to their old versions; only the module location has changed.</p>
</div>
<div class="section" id="s-removal-of-xmlfield">
<span id="removal-of-xmlfield"></span><h3>Removal of <code class="docutils literal"><span class="pre">XMLField</span></code><a class="headerlink" href="#removal-of-xmlfield" title="Permalink to this headline">¶</a></h3>
<p>When Django was first released, Django included an <code class="docutils literal"><span class="pre">XMLField</span></code> that performed
automatic XML validation for any field input. However, this validation function
hasn’t been performed since the introduction of <code class="docutils literal"><span class="pre">newforms</span></code>, prior to the 1.0
release. As a result, <code class="docutils literal"><span class="pre">XMLField</span></code> as currently implemented is functionally
indistinguishable from a simple <a class="reference internal" href="../ref/models/fields.html#django.db.models.TextField" title="django.db.models.TextField"><code class="xref py py-class docutils literal"><span class="pre">TextField</span></code></a>.</p>
<p>For this reason, Django 1.3 has fast-tracked the deprecation of
<code class="docutils literal"><span class="pre">XMLField</span></code> – instead of a two-release deprecation, <code class="docutils literal"><span class="pre">XMLField</span></code>
will be removed entirely in Django 1.4.</p>
<p>It’s easy to update your code to accommodate this change – just
replace all uses of <code class="docutils literal"><span class="pre">XMLField</span></code> with <code class="docutils literal"><span class="pre">TextField</span></code>, and remove the
<code class="docutils literal"><span class="pre">schema_path</span></code> keyword argument (if it is specified).</p>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="yui-b" id="sidebar">
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../contents.html">Table Of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">Django 1.3 release notes</a><ul>
<li><a class="reference internal" href="#overview">Overview</a></li>
<li><a class="reference internal" href="#python-compatibility">Python compatibility</a></li>
<li><a class="reference internal" href="#what-s-new-in-django-1-3">What’s new in Django 1.3</a><ul>
<li><a class="reference internal" href="#class-based-views">Class-based views</a></li>
<li><a class="reference internal" href="#logging">Logging</a></li>
<li><a class="reference internal" href="#extended-static-files-handling">Extended static files handling</a></li>
<li><a class="reference internal" href="#unittest2-support">unittest2 support</a></li>
<li><a class="reference internal" href="#transaction-context-managers">Transaction context managers</a></li>
<li><a class="reference internal" href="#configurable-delete-cascade">Configurable delete-cascade</a></li>
<li><a class="reference internal" href="#contextual-markers-and-comments-for-translatable-strings">Contextual markers and comments for translatable strings</a></li>
<li><a class="reference internal" href="#improvements-to-built-in-template-tags">Improvements to built-in template tags</a></li>
<li><a class="reference internal" href="#templateresponse">TemplateResponse</a></li>
<li><a class="reference internal" href="#caching-changes">Caching changes</a></li>
<li><a class="reference internal" href="#permissions-for-inactive-users">Permissions for inactive users</a></li>
<li><a class="reference internal" href="#geodjango">GeoDjango</a></li>
<li><a class="reference internal" href="#media-url-and-static-url-must-end-in-a-slash"><code class="docutils literal"><span class="pre">MEDIA_URL</span></code> and <code class="docutils literal"><span class="pre">STATIC_URL</span></code> must end in a slash</a></li>
<li><a class="reference internal" href="#everything-else">Everything else</a></li>
</ul>
</li>
<li><a class="reference internal" href="#backwards-incompatible-changes-in-1-3">Backwards-incompatible changes in 1.3</a><ul>
<li><a class="reference internal" href="#csrf-validation-now-applies-to-ajax-requests">CSRF validation now applies to AJAX requests</a></li>
<li><a class="reference internal" href="#restricted-filters-in-admin-interface">Restricted filters in admin interface</a></li>
<li><a class="reference internal" href="#deleting-a-model-doesn-t-delete-associated-files">Deleting a model doesn’t delete associated files</a></li>
<li><a class="reference internal" href="#passwordinput-default-rendering-behavior">PasswordInput default rendering behavior</a></li>
<li><a class="reference internal" href="#clearable-default-widget-for-filefield">Clearable default widget for FileField</a></li>
<li><a class="reference internal" href="#new-index-on-database-session-table">New index on database session table</a></li>
<li><a class="reference internal" href="#no-more-naughty-words">No more naughty words</a></li>
<li><a class="reference internal" href="#localflavor-changes">Localflavor changes</a></li>
<li><a class="reference internal" href="#formset-updates">FormSet updates</a></li>
<li><a class="reference internal" href="#callables-in-templates">Callables in templates</a></li>
<li><a class="reference internal" href="#use-of-custom-sql-to-load-initial-data-in-tests">Use of custom SQL to load initial data in tests</a></li>
<li><a class="reference internal" href="#changed-priority-of-translation-loading">Changed priority of translation loading</a></li>
<li><a class="reference internal" href="#transaction-management">Transaction management</a></li>
<li><a class="reference internal" href="#no-password-reset-for-inactive-users">No password reset for inactive users</a></li>
<li><a class="reference internal" href="#password-reset-view-now-accepts-from-email">Password reset view now accepts <code class="docutils literal"><span class="pre">from_email</span></code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#features-deprecated-in-1-3">Features deprecated in 1.3</a><ul>
<li><a class="reference internal" href="#mod-python-support"><code class="docutils literal"><span class="pre">mod_python</span></code> support</a></li>
<li><a class="reference internal" href="#function-based-generic-views">Function-based generic views</a></li>
<li><a class="reference internal" href="#test-client-response-template-attribute">Test client response <code class="docutils literal"><span class="pre">template</span></code> attribute</a></li>
<li><a class="reference internal" href="#djangotestrunner"><code class="docutils literal"><span class="pre">DjangoTestRunner</span></code></a></li>
<li><a class="reference internal" href="#changes-to-url-and-ssi">Changes to <code class="docutils literal"><span class="pre">url</span></code> and <code class="docutils literal"><span class="pre">ssi</span></code></a></li>
<li><a class="reference internal" href="#changes-to-the-login-methods-of-the-admin">Changes to the login methods of the admin</a></li>
<li><a class="reference internal" href="#reset-and-sqlreset-management-commands"><code class="docutils literal"><span class="pre">reset</span></code> and <code class="docutils literal"><span class="pre">sqlreset</span></code> management commands</a></li>
<li><a class="reference internal" href="#id1">GeoDjango</a></li>
<li><a class="reference internal" href="#czbirthnumberfield-clean"><code class="docutils literal"><span class="pre">CZBirthNumberField.clean</span></code></a></li>
<li><a class="reference internal" href="#compatcookie"><code class="docutils literal"><span class="pre">CompatCookie</span></code></a></li>
<li><a class="reference internal" href="#loading-of-project-level-translations">Loading of <em>project-level</em> translations</a></li>
<li><a class="reference internal" href="#permwrapper-moved-to-django-contrib-auth-context-processors"><code class="docutils literal"><span class="pre">PermWrapper</span></code> moved to <code class="docutils literal"><span class="pre">django.contrib.auth.context_processors</span></code></a></li>
<li><a class="reference internal" href="#removal-of-xmlfield">Removal of <code class="docutils literal"><span class="pre">XMLField</span></code></a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h3>Browse</h3>
<ul>
<li>Prev: <a href="1.3.1.html">Django 1.3.1 release notes</a></li>
<li>Next: <a href="1.2.7.html">Django 1.2.7 release notes</a></li>
</ul>
<h3>You are here:</h3>
<ul>
<li>
<a href="../index.html">Django 1.8.19 documentation</a>
<ul><li><a href="index.html">Release notes</a>
<ul><li>Django 1.3 release notes</li></ul>
</li></ul>
</li>
</ul>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/releases/1.3.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<div><input type="text" name="q" /></div>
<div><input type="submit" value="Go" /></div>
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<h3>Last update:</h3>
<p class="topless">Mar 10, 2018</p>
</div>
</div>
<div id="ft">
<div class="nav">
« <a href="1.3.1.html" title="Django 1.3.1 release notes">previous</a>
|
<a href="index.html" title="Release notes" accesskey="U">up</a>
|
<a href="1.2.7.html" title="Django 1.2.7 release notes">next</a> »</div>
</div>
</div>
<div class="clearer"></div>
</div>
</body>
</html>
distrib
>
Mageia
>
6
>
armv7hl
>
media
>
core-updates
>
by-pkgid
>
65530c6176058f9b54858c3b4f6385e6
>
files
>
826
