2012年3月23日
欢迎来到Django 1.4！
这些发行说明涵盖新功能以及一些向后不兼容的更改，您需要知道从Django 1.3或更早版本升级时。我们还删除了一些功能，详情请参阅our deprecation plan，我们已开始针对某些功能的弃用流程。
Django 1.4中最大的新功能是处理日期/时间时支持时区。启用时，此Django将以UTC格式存储日期/时间，在内部使用时区感知对象，并将其转换为用户的本地时区以进行显示。
如果将现有项目升级到Django 1.4，切换到时区感知模式可能需要小心：新模式不允许以前接受的一些相当粗糙的行为。我们鼓励任何正在升级的用户查看timezone migration guide和timezone FAQ，了解有用的指针。
Django 1.4中的其他值得注意的新功能包括：
只要有可能，我们就会根据our API stability policy政策，以向后兼容的方式引入新功能。但是，与以前的版本一样，Django 1.4附带了一些次要的向后不兼容的更改；从以前版本的Django升级的人应该仔细阅读该列表。
Django 1.4已经放弃了对Python 2.4的支持。Python 2.5现在是所需的最低Python版本。Django在Python 2.5,2.6和2.7上经过测试和支持。
此更改应该只影响少数的Django用户，因为目前大多数操作系统供应商都将Python 2.5或更高版本作为默认版本。如果你仍然使用Python 2.4，你需要坚持Django 1.3，直到你可以升级。根据our support policy，Django 1.3将继续接收安全支持，直到发布Django 1.5。
Django目前不支持Python 3.x。在Django 1.4发布之前的某个时刻，我们计划发布一份文档，概述我们完全弃用Python 2.x并移动到Python 3.x的时间表。
在以前的版本中，Django使用“天真”日期/时间（即没有相关联的时区的日期/时间），让每个开发人员解释给定的日期/时间“真正意义”。这可能导致各种微妙的时区相关的错误。
在Django 1.4中，您现在可以将Django切换到更正确的时区感知模式。在此模式下，Django在UTC中存储数据库中的日期和时间信息，在内部使用时区感知datetime对象，并将它们转换为模板和表单中的最终用户的时区。使用此功能的原因包括：
默认情况下，在使用startproject创建的新项目中启用时区支持。如果您要在现有项目中使用此功能，请阅读migration guide。如果遇到问题，您可以使用有用的FAQ。
Django 1.4支持与浏览器测试框架集成，例如Selenium。新的django.test.LiveServerTestCase基本类可让您更全面地测试网站前端和后端之间的互动。有关更多详细信息和具体示例，请参阅documentation。
Django 1.4附带了更新的默认项目布局和manage.py文件，用于startproject管理命令。这些修复了以前的manage.py处理导致双重导入，从开发到部署的麻烦以及其他难以调试的路径问题的Python导入路径的一些问题。
之前的manage.py调用函数现在已被弃用，因此项目升级到Django 1.4应更新其manage.py。（旧样式manage.py将继续像以前一样工作，直到Django 1.6。在1.5它将提高DeprecationWarning）。
新推荐的manage.py文件应如下所示：
#!/usr/bin/env python
import os, sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
from django.core.management import execute_from_command_line
execute_from_command_line(sys.argv)
{{ project_name }}应替换为实际项目的Python包名称。
如果项目中的设置，URLconfs和应用程序使用项目名称前缀（例如，myproject.settings，ROOT_URLCONF = “myproject.urls”新的manage.py需要向上移动一个目录，因此它位于项目包外，而不是靠近settings.py和urls.py
例如，使用以下布局：
manage.py
mysite/
__init__.py
settings.py
urls.py
myapp/
__init__.py
models.py
您可以导入mysite.settings，mysite.urls和mysite.myapp，但不能导入settings，urls或myapp作为顶级模块。
作为顶级模块导入的任何内容都可以放置在新manage.py附近。例如，要将“myapp”从项目模块解耦，并将其导入为myapp，请将其放在mysite/目录外：
manage.py
myapp/
__init__.py
models.py
mysite/
__init__.py
settings.py
urls.py
如果相同的代码导入不一致（有些地方带有项目前缀，有些地方没有），切换到新的manage.py时需要清除导入。
startapp和startproject管理命令现在具有用于指定自定义应用程序或项目模板的路径或URL的--template选项。
例如，当您运行以下命令时，Django将使用/path/to/my_project_template目录：
django-admin.py startproject --template=/path/to/my_project_template myproject
您现在还可以提供目标目录作为startapp和startproject的第二个参数：
django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project
有关详细信息，请参阅startapp和startproject文档。
startproject管理命令现在向初始项目布局添加了一个wsgi.py模块，其中包含一个可用于deploying with WSGI app servers
built-in development server现在支持使用外部定义的WSGI可调用， runserver具有用于部署的相同WSGI配置。新的WSGI_APPLICATION设置允许您配置哪个WSGI可调用runserver使用。
（runfcgi管理命令也在内部封装通过WSGI_APPLICATION配置的WSGI可调用）
Django 1.4包括QuerySet.select_for_update()方法，它会生成SELECT ... FOR UPDATE SQL查询。这将锁定行，直到事务结束，意味着其他事务不能修改或删除由FOR UPDATE查询匹配的行。
有关详细信息，请参阅select_for_update()的文档。
此方法允许您更有效地创建多个对象。如果你有很多对象，它可以导致显着的性能提高。
Django在内部使用它，这意味着一些操作（例如测试套件的数据库设置）已经看到了性能优势。
有关详细信息，请参阅bulk_create()文档。
Django的认证系统（django.contrib.auth）使用单向算法存储密码。Django 1.3使用SHA1算法，但是增加处理器速度和理论攻击表明SHA1没有我们想要的那么安全。因此，Django 1.4引入了新的密码存储系统：默认情况下，Django现在使用PBKDF2算法（如NIST所推荐）。您还可以轻松选择不同的算法（包括流行的bcrypt算法）。有关详细信息，请参阅How Django stores passwords。
我们已将管理员和其他捆绑模板切换为使用HTML5 doctype。尽管Django会小心保持与旧版浏览器的兼容性，但这一变化意味着您可以在管理页面中使用所需的任何HTML5功能，而不必失去HTML有效性或覆盖提供的模板来更改文件类型。
在Django 1.4之前，admin应用程序允许您通过指定字段查找来指定更改列表过滤器，但它不允许创建自定义过滤器。这已经纠正了一个简单的API（以前内部使用，称为“FilterSpec”）。有关更多详细信息，请参阅list_filter的文档。
管理更改列表现在支持对多个列进行排序。它尊重ordering属性的所有元素，并通过单击标题对多个列进行排序旨在模拟桌面GUI的行为。我们还添加了一个get_ordering()方法来动态指定排序（即，取决于请求）。
我们向ModelAdmin添加了save_related()方法，以便于定制相关对象在管理中的保存方式。
另外两个新的ModelAdmin方法get_list_display()和get_list_display_links()启用对管理更改列表中显示的字段和链接的动态自定义。
管理员内联现在只允许用户具有权限的操作。对于与自动创建的中间模型（其没有自己的权限）的ManyToMany关系，相关模型的更改权限确定用户是否具有添加，更改或删除关系的权限。
Django 1.4添加了用于签名值的低级API和用于设置和读取签名cookie的高级API，这是登录Web应用程序最常见的用途之一。
有关详细信息，请参阅cryptographic signing文档。
Django 1.4引入了一个基于cookie的会话后端，它使用cryptographic signing的工具将会话数据存储在客户端的浏览器中。
警告
会话数据由服务器签名和验证，但未加密。这意味着用户可以查看存储在会话中的任何数据，但不能更改它。在使用此后端之前，请阅读文档以进一步澄清。
有关详细信息，请参阅cookie-based session backend文档。
来自django.contrib.formtools的上一个FormWizard已替换为基于Django 1.3中引入的基于类的视图的新实现。它具有可插入的存储API，并且不需要向导绕过每个前面步骤的隐藏字段。
Django 1.4附带了基于会话的存储后端和基于Cookie的存储后端。后者使用也在Django 1.4中引入的cryptographic signing的工具将向导的状态存储在用户的Cookie中。
添加了一个懒惰评估版本的django.core.urlresolvers.reverse()，以允许在项目的URLconf加载之前使用URL反转。
Django现在可以在使用新的i18n_patterns()帮助函数时在URLpattern中查找语言前缀。现在也可以使用ugettext_lazy()定义可翻译的网址格式。有关语言前缀以及如何将网址格式国际化的详细信息，请参见Internationalization: in URL patterns中。
通过pgettext函数在Django 1.3中引入的contextual translation支持已扩展到trans和blocktrans模板标签使用新的context关键字。
已将pk_url_kwarg和slug_url_kwarg两个新属性添加到SingleObjectMixin中，以启用用于单一对象通用视图的URLconf关键字参数的定制。
向template.Library添加了新的assignment_tag帮助函数，以便于创建在指定的上下文变量中存储数据的模板标记。
simple_tag，inclusion_tag和新引入的assignment_tag模板助手函数现在可以接受任意数量的位置或关键字参数。例如：
@register.simple_tag
def my_tag(a, b, *args, **kwargs):
warning = kwargs['warning']
profile = kwargs['profile']
...
return ...
然后，在模板中，任何数量的参数可以传递给模板标签。例如：
{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
在早期版本的Django中，只要TEMPLATE_DEBUG设置为True，模板渲染期间引发的任何异常（即使与模板语法无关的异常）都包含在TemplateSyntaxError这是为了在调试500页面中提供详细的模板源位置信息。
在Django 1.4中，异常不再被包装。相反，原始异常用源信息注释。这意味着，无论TEMPLATE_DEBUG的值如何，从模板呈现捕获异常现在都是一致的，并且不需要捕获和打开TemplateSyntaxError以捕获其他错误。
此新过滤器将字符串截断为不超过指定的字符数。截断的字符串以可翻译的省略号序列（“...”）结尾。有关更多详细信息，请参阅truncatechars的文档。
The staticfiles contrib app has a new static template tag to refer to files saved with the STATICFILES_STORAGE storage backend. 它使用存储后端的url方法，因此支持高级功能，例如serving files from a cloud service。
staticfiles contrib应用程序现在有一个CachedStaticFilesStorage后端，通过附加MD5哈希值来缓存它保存的文件（当运行collectstatic管理命令时）文件的内容到文件名。例如，文件css/styles.css也将另存为css/styles.55e7cbb9ba48.css
有关详细信息，请参阅CachedStaticFilesStorage文档。
我们添加了一个中间件，以使用X-Frame-Options标题轻松防止点击劫持。由于向后兼容性原因，默认情况下未启用它，但您几乎可以肯定希望enable it以帮助为支持标头的浏览器插入该安全漏洞。
我们对CSRF功能进行了各种改进，包括ensure_csrf_cookie()装饰器，它可以帮助AJAX重的网站；保护PUT和DELETE请求；和CSRF_COOKIE_SECURE和CSRF_COOKIE_PATH设置，这可以提高CSRF保护的安全性和实用性。有关详细信息，请参阅CSRF docs。
我们添加了两个函数装饰器sensitive_variables()和sensitive_post_parameters()，以允许指定可能包含敏感信息的局部变量和POST参数， 。
所有POST参数现在系统地过滤掉某些视图的错误报告（login，password_reset_confirm，password_change和add_view在django.contrib.auth.views中，以及管理应用程序中的user_change_password），以防止泄露敏感信息（如用户密码）。
您可以通过写入custom filter来覆盖或自定义默认过滤。有关详细信息，请参阅Filtering error reports上的文档。
Django 1.4现在可以使用新的GenericIPAddressField模型字段，GenericIPAddressField表单字段和验证器validate_ipv46_address和validate_ipv6_address
django.test中的基类现在有一些帮助器来比较HTML而不跳过空格，参数引用/排序和关闭自关闭标签的不相关的差异。You can either compare HTML directly with the new assertHTMLEqual() and assertHTMLNotEqual() assertions, or use the html=True flag with assertContains() and assertNotContains() to test whether the client’s response contains a given HTML fragment. 有关更多信息，请参见assertions documentation。
添加了两个新的date格式，用于模板过滤器，模板标签和Format localization：
如果格式字符串中包含e或o，请务必更新您的custom format files。例如西班牙语本地化格式以前只转义了d格式字符：
DATE_FORMAT = r'j \de F \de Y'
但现在它还需要转义e和o：
DATE_FORMAT = r'j \d\e F \d\e Y'
有关详细信息，请参阅date文档。
Django 1.4还包括几个小的改进值得注意：
trans模板标签现在采用可选的as参数，以便能够检索转换字符串而不显示它，而是设置模板上下文变量。
if模板代码现在支持{％ elif ％}子句。
如果您的Django应用程式位于Proxy之后，您可能会发现新的SECURE_PROXY_SSL_HEADER设定很实用。它解决了您的代理“吃”的事实，通过HTTPS进来的请求的问题。但只有使用此设置，如果你知道你在做什么。
当DEBUG是True时，当Django检测到请求已启动时，服务器会向客户端发送新的纯文本版本的HTTP 500状态代码内部错误页面在JavaScript代码中。（is_ajax()用于此。）
与其HTML对应物一样，它包含有关应用程序状态的不同信息的集合。
这将使调试与客户端JavaScript的交互时更容易阅读。
向makemessages命令添加了--no-location选项。
将locmem缓存后端更改为使用pickle.HIGHEST_PROTOCOL，以便与其他缓存后端更好地兼容。
在ORM中添加了对生成包含DISTINCT ON的SELECT查询的支持。
distinct() QuerySet方法现在接受模型字段名称的可选列表。如果指定，则DISTINCT语句仅限于这些字段。这只在PostgreSQL中支持。
有关更多详细信息，请参阅distinct()的文档。
如果您在urls.py中包含名称为'admin_password_reset'的网址，管理员登录页将添加密码重置链接，因此插入内置密码重置机制并使其可用更容易。有关详细信息，请参阅Adding a password-reset feature。
MySQL数据库后端现在可以使用MySQL版本5.0.3或更高版本与InnoDB存储引擎实现的保存点功能。
现在可以将初始值传递给模型表单，这些模型表单是分别从工厂函数modelformset_factory和inlineformset_factory返回的模型表单和内联模型表单的一部分，与正常表单。然而，初始值只适用于额外的形式，即那些不绑定到现有模型实例。
Sitemaps框架现在可以使用新的Sitemap.protocol类属性处理HTTPS链接。
比django.test.TestCase和公司更轻的unittest.TestCase的新django.test.SimpleTestCase子类。它可以在不需要命中数据库的测试中有用。请参见Hierarchy of Django unit testing classes。
使用空或已知的SECRET_KEY运行Django会禁用许多Django的安全保护，并可能导致远程代码执行漏洞。在没有SECRET_KEY的情况下，不应运行任何Django网站。
在Django 1.4中，使用空的SECRET_KEY启动Django会产生DeprecationWarning。在Django 1.5中，它会引发异常，Django将拒绝启动。This is slightly accelerated from the usual deprecation path due to the severity of the consequences of running Django with no SECRET_KEY.
包含的管理应用程序django.contrib.admin长时间附带一组默认的静态文件，例如JavaScript，图像和样式表。Django 1.3添加了一个新的contrib应用程序django.contrib.staticfiles以通用方式处理这些文件，并为应用程序中包含的静态文件定义约定。
从Django 1.4开始，管理员的静态文件也遵循这个约定，使文件更容易部署。在以前的Django版本中，定义ADMIN_MEDIA_PREFIX设置以指向管理员的静态文件在Web服务器上的URL也是常见的。此设置已弃用，并被更常用的设置STATIC_URL替代。Django现在希望在URL <STATIC_URL>/admin/下找到管理静态文件。
如果您先前使用了ADMIN_MEDIA_PREFIX的网址路径（例如/media/）只需确保STATIC_URL和STATIC_ROOT已配置，并且您的Web服务器正确地提供这些文件。开发服务器继续像以前一样提供管理文件。有关详细信息，请参阅static files howto。
如果您的ADMIN_MEDIA_PREFIX设置为特定域（例如http://media.example.com/admin/），请务必将STATIC_URL设置设置为正确的网址，例如http://media.example.com/。
警告
如果你隐式依赖Django源代码中的管理静态文件的路径，你需要更新该路径。文件已从django/contrib/admin/media/移动到django/contrib/admin/static/admin/。
Django没有明确的策略，管理应用程序支持哪些浏览器。我们的新政策规范了现有做法：YUI的A级浏览器应提供完全功能的管理体验，Internet Explorer 6除外，不再受支持。
发布超过10年前，IE6对现代Web开发施加了很多限制。这个政策的实际意义是，贡献者可以自由地改进管理员，而不考虑这些限制。
很明显，这个新政策对您使用Django开发的网站没有影响。它仅适用于Django管理员。随意开发与任何一系列的浏览器兼容的应用程序。
作为提高管理员的更改列表排序界面和horizontal和vertical“过滤器”小部件的性能和可用性的一部分，删除了一些图标文件，并将其分组两个sprite文件。
Specifically: selector-add.gif, selector-addall.gif, selector-remove.gif, selector-removeall.gif, selector_stacked-add.gif and selector_stacked-remove.gif were combined into selector-icons.gif; and arrow-up.gif and arrow-down.gif were combined into sorting-icons.gif.
如果您使用这些图标自定义管理员，则需要将其替换为您自己的图标或从以前的版本获取文件。
避免与其他常见的CSS类名称冲突。“button”），我们添加了一个前缀（“field-”）到从主要管理表单，堆叠内联表单和表格内联单元格中的表单字段名称自动生成的所有CSS类名称。如果您之前使用纯字段名作为自定义样式或JavaScript转换的选择器，则需要在自定义样式表或JavaScript文件中考虑该前缀。
Django 1.3改变了Django中许多地方使用的加密签名机制。虽然Django 1.3保持回退，接受由以前的方法产生的哈希，这些回退在Django 1.4中删除。
因此，如果您直接从1.2或更早版本升级到Django 1.4，您可能会失去/无效使用旧方法加密签名的某些数据。为了避免这种情况，首先使用Django 1.3一段时间，以允许签名的数据自然过期。受影响的部分详述如下，1）忽略此建议的后果，2）运行Django 1.3以使数据到期或变得不相关所需的时间。
与表单相关的哈希：这些哈希具有更短的生命周期，并且仅与短期窗口相关，用户可以填写由升级前的Django实例生成的表单，并尝试将其提交到升级的Django实例：
从1.4开始，FlatpageFallbackMiddleware只会在结果网址引用现有平面网页时添加尾部斜杠和重定向。例如，在先前版本中请求/notaflatpageoravalidurl会重定向到/notaflatpageoravalidurl/，这将随后引发404。请求/notaflatpageoravalidurl立即提出404。
此外，flatpages返回的重定向现在是永久的（具有301状态代码），以匹配CommonMiddleware的行为。
作为时区支持的结果，根据ECMA-262规范，我们对JSON序列化程序进行了更改：
我们更改了XML序列化器以使用ISO8601格式的数据时间。字母T用于将日期部分与时间部分分开，而不是空格。时区信息包括在[+-]HH:MM格式中。
虽然序列化程序现在在创建fixture时使用这些新格式，但它们仍然可以加载使用旧格式的fixture。
数据库supports_timezone用于SQLite的True。事实上，如果你保存了一个意识datetime对象，SQLite存储了一个字符串，包括一个UTC偏移量。但是，从数据库加载值时会忽略此偏移，这可能会损坏数据。
在时区支持的上下文中，此标志更改为False，并且现在在SQLite中存储不包含时区信息的数据时间。当USE_TZ为False时，如果您尝试保存了一个意识到的datetime对象，Django引发异常。
当查询触发异常时，MySQL后端历史上已提出MySQLdb.OperationalError。我们修复了此错误，现在我们改为django.db.DatabaseError。如果您正在测试MySQLdb.OperationalError，则需要更新except子句。
DatabaseWrapper对象（即由django.db.connection和django.db.connections["some_alias"]引用的连接对象曾经是线程本地的。它们现在是全局对象，以便在多个线程之间潜在地共享。虽然各个连接对象现在是全局的，但是引用这些对象的django.db.connections字典仍然是线程局部的。因此，如果你只是使用ORM或DatabaseWrapper.cursor()，那么行为仍然与以前相同。但请注意，django.db.connection不会直接引用默认的DatabaseWrapper对象，现在是访问该对象属性的代理。如果您需要访问实际的DatabaseWrapper对象，请改用django.db.connections[DEFAULT_DB_ALIAS]。
作为此更改的一部分，所有基础SQLite连接现在都启用了潜在的线程共享（通过将check_same_thread=False属性传递给pysqlite）。DatabaseWrapper通过在默认情况下禁用线程共享来保留之前的行为，因此这不会影响任何纯粹依赖于ORM或DatabaseWrapper.cursor()的现有代码。
最后，虽然现在可以在线程之间传递连接，但Django没有做任何努力来同步底层后端的访问。并发行为由底层后端实现定义。请查看其文档以获取详细信息。
Django的评论历来支持排除特殊用户组的评论，但我们从未正确记录该功能，也没有强制在应用程序的其他部分（如模板标记）中排除。为了解决这个问题，我们从Feed类中删除了代码。
如果您依赖此功能并想要恢复旧的行为，请使用自定义注释模型管理器排除用户组，如下所示：
from django.conf import settings
from django.contrib.comments.managers import CommentManager
class BanningCommentManager(CommentManager):
def get_query_set(self):
qs = super(BanningCommentManager, self).get_query_set()
if getattr(settings, 'COMMENTS_BANNED_USERS_GROUP', None):
where = ['user_id NOT IN (SELECT user_id FROM auth_user_groups WHERE group_id = %s)']
params = [settings.COMMENTS_BANNED_USERS_GROUP]
qs = qs.extra(where=where, params=params)
return qs
将此模型管理器保存在您的自定义评论应用中（例如，在my_comments_app/managers.py中），并将其添加为自定义评论应用模型：
from django.db import models
from django.contrib.comments.models import Comment
from my_comments_app.managers import BanningCommentManager
class CommentWithTitle(Comment):
title = models.CharField(max_length=300)
objects = BanningCommentManager()
在Django 1.3之前，可以通过向IGNORABLE_404_STARTS添加前缀并将后缀添加到IGNORABLE_404_ENDS，从Django的404 error reporting中排除某些网址。
在Django 1.4中，这两个设置被IGNORABLE_404_URLS取代，这是一个编译的正则表达式列表。Django不会针对与其中任何一个匹配的网址发送404错误的电子邮件。
此外，以前的设置有一些相当任意的默认值：
IGNORABLE_404_STARTS = ('/cgi-bin/', '/_vti_bin', '/_vti_inf')
IGNORABLE_404_ENDS = ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi',
'favicon.ico', '.php')
决定您的网站是否有旧版的/cgi-bin/部分或favicon.ico不是Django的角色。因此，IGNORABLE_404_URLS，IGNORABLE_404_STARTS和IGNORABLE_404_ENDS的默认值现在都为空。
如果您已自定义IGNORABLE_404_STARTS或IGNORABLE_404_ENDS，或者要保留旧的默认值，则应在设置文件中添加以下行：
import re
IGNORABLE_404_URLS = (
# for each <prefix> in IGNORABLE_404_STARTS
re.compile(r'^<prefix>'),
# for each <suffix> in IGNORABLE_404_ENDS
re.compile(r'<suffix>$'),
)
不要忘记在正则表达式中转义具有特殊含义的字符，例如句点。
以前，Django的CSRF protection仅针对POST请求提供保护。由于在AJAX应用程序中使用PUT和DELETE方法变得越来越普遍，因此我们现在通过 RFC 2616保护所有未定义为安全的方法 - 即，我们免除GET，HEAD， OPTIONS和TRACE，我们对一切事情实施保护。
如果您在AJAX应用程式中使用PUT或DELETE方法，请参阅instructions about using AJAX and CSRF的说明。
django.contrib.auth中的password_reset视图现在接受subject_template_name参数，该参数作为关键字参数传递到密码保存表单。如果您要使用此自定义密码重置表单，那么您需要确保表单的save()方法接受此关键字参数。
这是自2005年以来的django.template.loader的别名，我们已删除它，而不发出警告，由于deprecation的长度。如果您的代码仍然引用此代码，请改用django.template.loader。
由于难以处理的性能和安全问题，此功能已删除。应删除verify_exists的任何现有用法。
基本存储类的open方法用于采用模糊参数mixin，允许您动态更改返回的文件对象的基类。这已删除。在少数情况下，您依赖于mixin参数，您可以通过覆盖open方法轻松实现，如下所示：
from django.core.files import File
from django.core.files.storage import FileSystemStorage
class Spam(File):
"""
Spam, spam, spam, spam and spam.
"""
def ham(self):
return 'eggs'
class SpamStorage(FileSystemStorage):
"""
A custom file storage backend.
"""
def open(self, name, mode='rb'):
return Spam(open(self.path(name), mode))
yaml.load能够构造任何Python对象，如果处理来自不受信任的源的YAML文档，则可能触发任意代码执行。Django的YAML解串器不需要这个功能，它的主要用途是加载由简单对象组成的fixture。即使fixture是受信任的数据，YAML解串器现在使用yaml.safe_load获得额外的安全性。
会话cookie现在包括httponly属性，以帮助减少潜在的XSS攻击的影响。作为此更改的结果，会话Cookie数据（包括会话ID）在许多浏览器中无法再通过JavaScript访问。对于严格的向后兼容性，请在设置文件中使用SESSION_COOKIE_HTTPONLY = False。
当网址包含%xx序列，其中xx是两个十六进制数字时，urlize现在假定网址已经转义，再次应用URL转义。对于不带引号的表单包含%xx序列的网址，这是错误的，但是这样的网址不太可能发生在野外，因为它们也会混淆浏览器。
现在可以检查在assertTemplateUsed()和assertTemplateNotUsed()的代码块中是否使用了模板。它们可以用作上下文管理器：
with self.assertTemplateUsed('index.html'):
render_to_string('index.html')
with self.assertTemplateNotUsed('base.html'):
render_to_string('index.html')
有关更多信息，请参见assertion documentation。
默认测试运行器不再在测试执行后恢复数据库连接。这可以防止生产数据库暴露给仍然正在运行并尝试创建新连接的潜在线程。
如果您的代码依赖于在测试执行后创建的生产数据库的连接，那么您可以通过对DjangoTestRunner进行子类化并覆盖其teardown_databases()方法来恢复先前的行为。
manage.py help现在按应用程序分组可用命令。如果你依赖于这个命令的输出 - 如果你解析它，例如 - 那么你需要更新你的代码。要获取脚本中所有可用管理命令的列表，请改用manage.py help --commands 。
以前，extends标签使用了一个解析参数的错误方法，这可能导致错误地将参数视为字符串字面值。它现在使用parser.compile_filter，和其他标签一样。
标记的内部不是官方稳定的API的一部分，但是为了完全公开，ExtendsNode.__init__定义已更改，这可能会破坏使用此类的任何自定义标记。
在1.4之前，当为字段设置了auto_now或auto_now_add时，会为缺少特定日期或datetime值的fixture对象插入默认值。这是不应该有效的，在1.4加载这种不完整的灯具将失败。由于fixtures是原始导入，因此它们应显式指定所有字段值，而不考虑模型上的字段选项。
默认情况下，开发服务器现在是多线程的。使用--nothreading选项禁用开发服务器中的线程使用：
django-admin.py runserver --nothreading
在Django 1.4之前，不管过滤器的安全模式设置如何，属性都包括在任何markdown输出中。对于Python-Markdown库的版本> 2.1，添加了一个enable_attributes选项。当安全参数传递给markdown过滤器时，会设置safe_mode=True和enable_attributes=False选项。如果使用小于2.1的Python-Markdown库版本，则会发出警告，表明输出不安全。
在Django 1.3中，django.views.generic.edit.FormMixin类的get_initial方法返回了类initial字典。这已修复为返回此字典的副本，因此表单实例可以修改其初始数据，而不会弄乱类变量。
调用cache_page()的一些旧方法已被弃用。请参阅文档，了解使用此装饰器的正确方法。
Django 1.3不支持早于8.0的PostgreSQL版本，并且我们建议使用更新的版本，因为性能改进，更重要的是，8.0和8.1的上游支持期结束接近（2010年11月）。
Django 1.4进一步采取该政策，并将8.2设置为其官方支持的最小PostgreSQL版本。
When we added logging support in Django in 1.3, the admin error email support was moved into the django.utils.log.AdminEmailHandler, attached to the 'django.request' logger. 为了保持错误电子邮件的已建立的行为，仅当DEBUG为False时才调用'django.request'记录器。
为了增加请求的错误记录的灵活性，现在调用'django.request'记录器，而不管DEBUG的值，以及新项目的默认设置文件包括附加到django.utils.log.AdminEmailHandler的单独过滤器，以防止DEBUG模式下出现管理错误电子邮件：
'filters': {
'require_debug_false': {
'()': 'django.utils.log.RequireDebugFalse'
}
},
'handlers': {
'mail_admins': {
'level': 'ERROR',
'filters': ['require_debug_false'],
'class': 'django.utils.log.AdminEmailHandler'
}
},
如果您的项目是在此更改之前创建的，您的LOGGING设置将不会包含此新过滤器。为了保持向后兼容性，Django会检测到您的'mail_admins'处理程序配置不包含'filters'部分，并会自动为您添加此过滤器， -deprecation警告。这将成为Django 1.5中的弃用警告，在Django 1.6中，向后兼容的填充将被完全删除。
在'mail_admins'处理程序下存在任何'filters'键将禁用此向后兼容的垫片和弃用警告。
直到Django 1.3，函数include()，patterns()和url() plus handler404，handler500位于django.conf.urls.defaults模块中。
在Django 1.4中，他们住在django.conf.urls。
Databrowse有一段时间没有看到积极的发展，这没有显示任何改变的迹象。有人建议将GSOC项目将databrowse的功能集成到管理员中，但没有进行任何进度。虽然Databrowse已被弃用，但提供类似功能集的django.contrib.admin的增强仍然可能。
Databrowse的代码以与Django本身相同的条款授权，因此它可以被个人或组作为第三方项目使用。
此函数临时修改sys.path，以使父项目“project”目录可在旧平面startproject布局下导入。此功能现已弃用，因为新的manage.py和默认项目布局不再需要其路径解决方法。
此函数从未被记录或是公共API的一部分，但它被广泛推荐用于为用户脚本设置“Django环境”。应通过设置DJANGO_SETTINGS_MODULE环境变量或使用django.conf.settings.configure()来替换这些用法。
此函数以前由manage.py用于执行管理命令。它与django.core.management.execute_from_command_line相同，除了它首先调用setup_environ，现在已弃用。因此，execute_manager也被弃用；可以改用execute_from_command_line。这些函数都不作为公共API的一部分进行记录，但由于在现有的manage.py文件中使用，因此需要使用弃用路径。
两个标志，is_safe和needs_autoescape，定义每个模板过滤器如何与Django的自动转义行为交互。它们过去是过滤器功能的属性：
@register.filter
def noop(value):
return value
noop.is_safe = True
然而，这种技术与装饰器，特别是@stringfilter一起引起了一些问题。现在，标志是@register.filter的关键字参数：
@register.filter(is_safe=True)
def noop(value):
return value
有关详细信息，请参阅filters and auto-escaping。
直到Django 1.3，INSTALLED_APPS在应用程序名称中接受通配符，例如django.contrib.*。通过来自 t> ＆lt； package＆gt； import t> *的基于文件系统的实现/ t0>。很遗憾，这不能可靠地完成。
这种行为从来没有记录。因为它是unpythonic和不明显有用，它在Django 1.4中删除。如果您依赖它，您必须编辑您的设置文件以明确列出所有应用程序。
这个属性混淆地命名为HttpRequest.raw_post_data，但它实际上提供了HTTP请求的正文。它已重命名为HttpRequest.body，并且已弃用HttpRequest.raw_post_data。
在之前的版本中，网站地图类中使用的Paginator对象已被缓存，这可能会导致过时的网站地图。我们删除了缓存，因此对网站地图的每个请求都创建了一个新的Paginator对象，并调用了Sitemap子类的items()方法。根据您的items()方法执行的操作，这可能会对性能产生负面影响。要减轻性能影响，请考虑在您的Sitemap子类中使用caching framework。
版本低于2.1的Python-Markdown不支持禁用属性的选项。作为一个安全问题，此库的早期版本将不被加速deprecation时间线下的1.5中的标记应用程序支持。
2015年5月13日