2014年9月2日
欢迎来到Django 1.7！
这些发行说明涵盖新功能以及一些向后不兼容更改，您需要知道从Django 1.6或更早版本升级时。我们已开始对某些功能的弃用过程，某些功能已达到其弃用过程的结束，并且已删除。
Django 1.7需要Python 2.7或更高版本，但我们强烈推荐最新的小版本。支持Python 2.6已被删除，并且添加了对Python 3.4的支持。
此更改应仅影响少量的Django用户，因为目前大多数操作系统供应商都提供Python 2.7或更低版本作为其默认版本。如果你仍然使用Python 2.6，你需要坚持Django 1.6，直到你可以升级你的Python版本。根据our support policy，Django 1.6将继续接收安全支持，直到发布Django 1.8。
Django现在已经内置了对模式迁移的支持。它允许通过创建表示模型更改的迁移文件来更新，更改和删除模型，并且可以在任何开发，分阶段或生产数据库上运行。
迁移在their own documentation中介绍，但其中一些主要功能如下：
syncdb已弃用，并替换为migrate。别担心，对syncdb的呼叫仍会像以前一样工作。
新的makemigrations命令提供了一种自动检测模型更改并为其进行迁移的简单方法。
pre_syncdb和post_syncdb已弃用，分别替换为pre_migrate和post_migrate。这些新信号具有稍微不同的参数。有关详细信息，请查看文档。
数据库路由器上的allow_syncdb方法现在称为allow_migrate，但仍执行相同的功能。具有allow_syncdb方法的路由器仍然可以工作，但是该方法名称已过时，您应该尽快更改它（不需要重命名）。
initial_data fixtures are no longer loaded for apps with migrations; if you want to load initial data for an app, we suggest you create a migration for your application and define a RunPython or RunSQL operation in the operations section of the migration.
具有迁移的应用程序的测试回滚行为不同；特别是，除非特别要求，否则Django将不再模拟非事务性数据库或TransactionTestCase unless specifically requested
不建议在没有迁移的应用程序依赖（具有迁移的ForeignKey或ManyToManyField）应用程序。有关更多信息，请参阅dependencies documentation。
如果您要从South升级，请参阅我们的Upgrading from South文档，第三方应用程序作者应阅读South 1.0发行说明，了解有关如何支持South和Django的详细信息迁移。
历史上，Django应用程序与模型紧密相连。一个称为“应用程序缓存”的单例处理已安装的应用程序和模型。模型模块用作许多API中的应用程序的标识符。
作为Django applications的概念，此代码显示了一些缺点。它已被重构到一个“应用程序注册表”，其中模型模块不再具有中心角色，并且可以将配置数据附加到应用程序。
到目前为止的改进包括：
为帮助同时实现模式迁移以及在将来的Django版本中更轻松地添加复合键，Field API现在有一个新的必需方法：deconstruct()。
此方法不带参数，并返回四个项目的元组：
这四个值允许将任何字段序列化为文件，以及允许字段被安全地复制，这两个新特征的必要部分。
此更改不应影响您，除非您编写自定义字段子类；如果您这样做，如果您的子类以任何方式更改__init__的方法签名，则可能需要重新实现deconstruct()方法。如果您的字段仅继承自内置的Django字段，并且不覆盖__init__，则无需进行任何更改。
如果你需要重写deconstruct()，一个好的开始的地方是内置的Django字段（django/db/models/fields/__init__.py）as几个字段，包括DecimalField和DateField，覆盖它并显示如何在超类上调用该方法，只需添加或删除额外的参数。
这也意味着字段的所有参数本身必须是可序列化的；看看我们认为可序列化，并了解如何使自己的类可序列化，阅读migration serialization documentation。
历史上，建议的可重用模型查询的方法是在自定义Manager类上创建方法。此方法的问题是，在第一个方法调用之后，您将返回一个QuerySet实例，并且无法调用其他自定义管理器方法。
虽然没有记录，但通常通过创建自定义QuerySet来解决这个问题，以便可以链接自定义方法；但解决方案有一些缺点：
QuerySet.as_manager()类方法现在可以直接使用QuerySet方法create Manager with QuerySet methods：
class FoodQuerySet(models.QuerySet):
def pizzas(self):
return self.filter(kind='pizza')
def vegetarian(self):
return self.filter(vegetarian=True)
class Food(models.Model):
kind = models.CharField(max_length=50)
vegetarian = models.BooleanField(default=False)
objects = FoodQuerySet.as_manager()
Food.objects.pizzas().vegetarian()
现在可以在遍历反向关系时specify a custom manager：
class Blog(models.Model):
pass
class Entry(models.Model):
blog = models.ForeignKey(Blog)
objects = models.Manager() # Default Manager
entries = EntryManager() # Custom Manager
b = Blog.objects.get(id=1)
b.entry_set(manager='entries').all()
我们添加了一个新的System check framework，用于检测常见问题（如无效模型）并提供解决这些问题的提示。框架是可扩展的，因此您可以为自己的应用和库添加自己的检查。
管理员中日期和时间输入小工具旁边的“今天”和“现在”快捷方式现在在current time zone中运行。以前，他们使用浏览器时区，这可能导致在不匹配服务器上的当前时区时保存错误的值。
此外，当浏览器和服务器时区不同时，窗口小部件现在显示帮助消息，以说明如何解释在字段中插入的值。
在Python 2.7之前，数据库游标可以用作上下文管理器。特定后端的游标定义了上下文管理器的行为。魔法方法查找的行为已经改变了Python 2.7和游标不再可用作上下文管理器。
Django 1.7允许将游标用作上下文管理器。也就是说，可以使用以下：
with connection.cursor() as c:
c.execute(...)
代替：
c = connection.cursor()
try:
c.execute(...)
finally:
c.close()
现在可以为ORM编写自定义查找和转换。自定义查找的工作方式与Django的内置查找（例如lte，icontains），而转换是一个新概念。
django.db.models.Lookup类提供了一种为模型字段添加查找运算符的方法。作为示例，可以为DateFields添加day_lte运算符。
django.db.models.Transform类允许在最终查找之前转换数据库值。例如，可以写一个year变换，从字段的值提取年份。变换允许链接。在将year变换添加到DateField之后，可以对变换的值进行过滤，例如qs.filter(author__birthdate__year__lte=1981) 。
有关自定义查找和转换的详细信息，请参阅custom lookups文档。
以前有两种主要模式用于处理表单中的错误：
使用前一种模式是直接的，因为形式可以从上下文猜测。哪个方法引发异常），错误属于哪里，并自动处理它们。这仍然是在可能的情况下添加错误的规范方式。然而，后者是轻率和容易出错的，因为处理边缘情况的负担落在用户身上。
新的add_error()方法允许从任何地方向特定表单字段添加错误，而无需担心细节，例如创建django.forms.utils.ErrorList的实例或处理与Form.cleaned_data。这个新的API取代了操作Form._errors，现在成为一个私有API。
有关使用Form.add_error()的示例，请参见Cleaning and validating fields that depend on each other。
The ValidationError constructor accepts metadata such as error code or params which are then available for interpolating into the error message (see Raising ValidationError for more details); however, before Django 1.7 those metadata were discarded as soon as the errors were added to Form.errors.
Form.errors and django.forms.utils.ErrorList now store the ValidationError instances so these metadata can be retrieved at any time through the new Form.errors.as_data method.
然后，可以通过它们的错误code来识别检索到的ValidationError实例，这使得当给定错误存在时，可以重写错误的消息或在视图中写入自定义逻辑。它也可以用于以自定义格式（例如XML）序列化错误。
新的Form.errors.as_json()方法是一个方便的方法，它返回错误消息以及序列化为JSON的错误代码。as_json()使用as_data()，并给出如何扩展新系统的想法。
Heavy changes to the various error containers were necessary in order to support the features above, specifically Form.errors, django.forms.utils.ErrorList, and the internal storages of ValidationError. 用于存储错误字符串的这些容器现在存储ValidationError实例和公共API，已尽可能使其尽可能透明，但如果您已使用私有API，某些更改是向后不兼容；有关详细信息，请参阅ValidationError constructor and internal storage。
通过设置file_permissions_mode和directory_permissions_mode参数，static files storage classes可以被子类化以覆盖收集的静态文件和目录接收的权限。有关使用示例，请参见collectstatic。
CachedStaticFilesStorage后端获取一个称为ManifestStaticFilesStorage的兄弟类，它根本不使用缓存系统，而是一个名为staticfiles.json的JSON文件存储原始文件名（例如，css/styles.css）和散列文件名（例如。css/styles.55e7cbb9ba48.css）。staticfiles.json文件是在运行collectstatic管理命令时创建的，对于远程存储（如Amazon S3）应该是一个较便宜的备选方案。
有关详细信息，请参阅ManifestStaticFilesStorage文档。
findstatic现在接受详细标志级别2，这意味着它将显示它搜索的目录的相对路径。请参见findstatic例如输出。
django-admin的--no-color选项允许禁用管理命令输出的着色。
dumpdata的新--natural-foreign和--natural-primary选项，以及新的use_natural_foreign_keys用于serializers.serialize()的use_natural_primary_keys参数，允许在序列化时使用自然主键。
不再需要为createcachetable命令提供高速缓存表名称或--database选项。Django从您的设置文件中获取此信息。如果已配置多个高速缓存或多个数据库，则将创建所有高速缓存表。
runserver命令有几个改进：
如果安装并激活了ANSICON第三方工具，管理命令现在可以在Windows下生成语法颜色输出。
现在在Windows NT 6（Windows Vista和更高版本）上支持带有符号链接选项的collectstatic命令。
Providing initial SQL data现在可以更好地运行sqlparse Python库安装。
请注意，为了支持RunSQL迁移操作，它已被弃用，这有助于改进的行为。
警告
除了本节中概述的更改外，请务必查看已删除的任何功能的deprecation plan。如果您没有在指定功能的弃用时间轴内更新代码，则其移除可能会显示为向后不兼容的更改。
尽管Django仍然会查看allow_syncdb方法，即使它们应该重命名为allow_migrate，但是在将模型传递给这些方法时存在微妙的差别。
对于包含迁移的应用，allow_migrate现在将通过historical models，这是没有自定义属性，方法或管理器的特殊版本模型。请确保您的allow_migrate方法仅指向model._meta中的字段或其他项目。
具有迁移功能的应用在完成迁移后将无法加载initial_data灯具。不进行迁移的应用会在migrate阶段（将模拟旧的syncdb行为）中继续加载这些工具，但任何新应用都不会有此支持。
相反，如果需要，您可以在迁移中加载初始数据（使用RunPython操作和模型类）；这具有附加的优点，即您的初始数据不需要在每次更改模式时更新。
此外，与Django的其他旧的syncdb代码一样，initial_data已从弃用路径开始，并将在Django 1.9中删除。
Django现在要求所有Field类和它们的所有构造函数参数都是可序列化的。如果您以任何方式修改自定义字段中的构造函数签名，则需要实现deconstruct()方法；我们已通过instructions on implementing this method扩展了自定义字段文档。
要求所有字段参数为serializable意味着任何传递到Field构造函数（如自定义存储子类）的自定义类实例需要有一个deconstruct method defined on them as well，虽然Django提供了一个方便的类装饰器，将适用于大多数应用程序。
Django 1.7一旦启动就加载应用程序配置和模型。虽然这种行为更直接，被认为是更强大，回归不能排除。有关您可能遇到的一些问题的解决方案，请参见Troubleshooting。
如果您在纯Python脚本（而不是管理命令）中使用Django，而且您依赖于 DJANGO_SETTINGS_MODULE环境变量，则必须在开始时显式初始化Django的脚本与：
>>> import django
>>> django.setup()
否则，您将遇到AppRegistryNotReady异常。
直到Django 1.3，创建WSGI应用程序的推荐方法是：
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()
在Django 1.4中，对WSGI的支持得到改进，API更改为：
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
如果您仍然在WSGI脚本中使用以前的样式，则需要升级到后者，否则您将遇到AppRegistryNotReady异常。
不再可能有多个已安装的应用程序具有相同的标签。在以前的Django版本中，这并不总是正确工作，但也没有崩溃。
如果您有两个具有相同标签的应用，则应为其中一个应用创建AppConfig，并覆盖其label。然后，您应该调整您的代码，无论它引用此应用程序或其模型与旧标签。
不可能通过不同的路径两次导入相同的模型。从Django 1.6开始，只有当您手动将目录和子目录放在 PYTHONPATH上时，才会发生这种情况。有关迁移说明，请参阅1.4 release notes中有关新项目布局的部分。
你应该确保：
在弃用期之后，Django将执行版本1.9的这些要求。
AppCommand的子类现在必须实现handle_app_config()方法，而不是handle_app()。此方法接收AppConfig实例，而不是模型模块。
由于INSTALLED_APPS现在还支持应用程序模块之外的应用程序配置类，因此您应该查看直接访问此设置的代码，并改为使用应用程序注册表（django.apps.apps）。
应用注册表保留了旧应用缓存的一些功能。即使应用缓存是专用API，过时的方法和参数也会通过标准弃用路径删除，但以下会立即生效的更改除外：
当多个应用程序提供具有相同名称的管理命令时，Django从INSTALLED_APPS中首先应用程序加载命令。以前的版本从最后运行的应用程序加载命令。
这使得管理命令的发现符合依赖于INSTALLED_APPS顺序的Django的其他部分，例如静态文件，模板和翻译。
ValidationError构造函数的行为在接收到错误的容器作为参数时已更改。a list或ErrorList）：
这意味着如果您访问ValidationError内部存储器，例如error_list； error_dict；或update_error_dict()的返回值，您可能会在之前找到的字符串中找到ValidationError的实例。
Also if you directly assigned the return value of update_error_dict() to Form._errors you may inadvertently add list instances where ErrorList instances are expected. 这是一个问题，因为与简单的列表不同，ErrorList知道如何处理ValidationError的实例。
使用这些私有API保证的大多数使用情况现在由新引入的Form.add_error()方法覆盖：
# Old pattern:
try:
# ...
except ValidationError as e:
self._errors = e.update_error_dict(self._errors)
# New pattern:
try:
# ...
except ValidationError as e:
self.add_error(None, e)
If you need both Django <= 1.6 and 1.7 compatibility you can’t use Form.add_error() since it wasn’t available before Django 1.7, but you can use the following workaround to convert any list into ErrorList:
try:
# ...
except ValidationError as e:
self._errors = e.update_error_dict(self._errors)
# Additional code to ensure ``ErrorDict`` is exclusively
# composed of ``ErrorList`` instances.
for field, error_list in self._errors.items():
if not isinstance(error_list, self.error_class):
self._errors[field] = self.error_class(error_list)
Django的以前版本中存在不一致，涉及不同的缓存后端如何处理pickle错误。django.core.cache.backends.locmem.LocMemCache用于在发生此类错误时失败，这与其他后端不一致，并导致特定于缓存的错误。这已在Django 1.7中修复，有关详细信息，请参阅＃21200。
先前版本的Django使用请求的路径和查询字符串生成缓存密钥，但不生成方案或主机。如果Django应用程序服务多个子域或域，缓存键可能会冲突。在Django 1.7中，缓存键因请求的绝对URL而异，包括scheme，host，path和query字符串。例如，缓存键的网址部分现在是从http://www.example.com/path/to/?key=val而不是/path/to/?key=val。由Django 1.7生成的缓存键将与由旧版本的Django生成的键不同。升级到Django 1.7后，对任何先前缓存的URL的第一个请求将是缓存未命中。
在以前的Django版本中，可以在模型管理器实例上使用db_manager(using=None)来获取使用默认路由行为的管理器实例，覆盖任何手动指定的数据库路由。在Django 1.7中，传递给db_manager的None的值将生成保留任何手动分配的数据库路由的路由器 - 管理器将不重置。这是解决路由信息在连接上级联的方式不一致所必需的。有关详细信息，请参阅＃13724。
如果您的项目在1970年之前或2037年之后处理数据时间，并且Django遇到ValueError时，您将不得不安装pytz。如果您使用Django的时区相关日期格式或django.contrib.syndication，您可能会受此问题的影响。
历史上，Django管理网站将未经授权或未经身份验证的用户的请求直接传递到登录视图，而没有HTTP重定向。In Django 1.7, this behavior changed to conform to a more traditional workflow where any unauthorized request to an admin page will be redirected (by HTTP status code 302) to the login page, with the next parameter set to the referring path. 成功登录后，用户将被重定向到那里。
还请注意，管理员登录表单已更新为不包含this_is_the_login_form字段（现在未使用），并且ValidationError代码已设置为更常规的invalid_login
历史上，使用select_for_update()的查询可以在事务之外的自动提交模式下执行。在Django 1.6之前，Django的自动事务模式允许使用它来锁定记录，直到下一个写操作。Django 1.6引入了数据库级自动提交；从那时起，在这种上下文中的执行会影响select_for_update()的效果。因此，现在假定它是一个错误并引发一个异常。
进行此更改是因为此类错误可能是由于包含预期全局事务的应用程序（例如，ATOMIC_REQUESTS设置为True）或Django的旧自动提交行为，在没有它们的项目中运行；并且此外，这样的错误可以表现为数据腐败错误。它也是在Django 1.6.3。
如果在作为TransactionTestCase而不是TestCase的子类的测试类中使用select_for_update()，则此更改可能会导致测试失败。
使用不属于INSTALLED_APPS设置的应用中的模型，已弃用app-loading refactor。这暴露了全局默认值（django.conf.global_settings）中默认的INSTALLED_APPS和MIDDLEWARE_CLASSES之间的不兼容性。要使这些设置保持同步并防止在以最少设置测试可重复使用的应用时发生弃用警告，请移除SessionMiddleware，AuthenticationMiddleware和MessageMiddleware从默认值。这些类仍将包含在由startproject生成的默认设置中。大多数项目不会受到此更改的影响，但如果您之前未在项目设置中声明MIDDLEWARE_CLASSES并依赖于全局默认值，则应确保新默认值与项目的需求一致。您还应该检查直接访问django.conf.global_settings.MIDDLEWARE_CLASSES的任何代码。
django.core.files.uploadhandler.FileUploadHandler.new_file()方法现在传递了另一个content_type_extra参数。如果您有实现new_file()的自定义FileUploadHandler，请确保接受此新参数。
ModelFormSets no longer delete instances when save(commit=False) is called. 有关如何手动删除已删除表单中的对象的说明，请参阅can_delete。
加载空夹具会发出RuntimeWarning，而不是提高CommandError。
django.contrib.staticfiles.views.serve() will now raise an Http404 exception instead of ImproperlyConfigured when DEBUG is False. 此更改不需要有条件地将视图添加到根URLconf，这反过来使得可以安全地按名称进行反转。它还消除了访问者通过请求不存在或尚未收集的静态文件来生成假的HTTP 500错误的能力。
django.db.models.Model.__eq__()方法现在定义为，当主键匹配时，代理模型的实例及其基本模型被认为是相等的。以前只有完全相同的类的实例被认为在主键匹配上是相等的。
django.db.models.Model.__eq__()方法已更改，使得两个不带主键值的Model实例不会被视为相等（除非它们相同实例）。
当在没有主键值的实例上调用时，django.db.models.Model.__hash__()方法现在将调用TypeError。这是为了避免容器中的可变的__hash__值。
现在将使用AUTOINCREMENT选项创建SQLite数据库中的AutoField列，这将确保单调递增。这将导致主键编号行为在SQLite上更改，与大多数其他SQL数据库一致。这将只适用于新创建的表。如果您有使用旧版本的Django创建的数据库，您将需要迁移它以利用此功能。例如，您可以执行以下操作：
django.contrib.auth.models.AbstractUser不再定义get_absolute_url()方法。旧定义会传回“/ users /％s /” ％ urlquote（self.username）因为应用程序可能或可能不会在urlpatterns中定义此类网址。在您自己的自定义用户对象上定义get_absolute_url()方法，或者如果您希望为用户提供网址，请使用ABSOLUTE_URL_OVERRIDES。
django.test.LiveServerTestCase类的静态资产提供功能已经过简化：现在，只有在运行测试时，它才能提供已存在于STATIC_ROOT中的内容。The ability to transparently serve all the static assets (similarly to what one gets with DEBUG = True at development-time) has been moved to a new class that lives in the staticfiles application (the one actually in charge of such feature): django.contrib.staticfiles.testing.StaticLiveServerTestCase. 换句话说，LiveServerTestCase本身不太强大，但同时具有较少的魔法。
这背后的理由是去除非contrib代码对contrib应用程序的依赖。
旧的高速缓存URI语法（例如，"locmem://"）不再受支持。它仍然工作，即使它没有记录或正式支持。如果您仍在使用它，请更新为当前的CACHES语法。
在继承的情况下，Form字段的默认顺序已更改为遵循正常的Python MRO。现在通过反向迭代MRO来发现字段，最后一个类是最后一个。如果您在父类Form上在当前类和上定义字段时依赖于默认字段顺序，则此操作仅影响您。
SelectDateWidget的required参数已删除。此小部件现在与其他小部件一样遵守表单字段的is_required属性。
Widget.is_hidden现在是只读属性，通过查看是否存在input_type == 隐藏“。
select_related()现在链接的方式与其他类似调用（例如prefetch_related）相同。也就是说，select_related（'foo'， 'bar'）等效于select_related('foo').select_related('bar')。以前，后者等效于select_related('bar')。
GeoDjango放弃了对GEOS的支持
数据库后端的init_connection_state方法现在以自动提交模式执行（除非将AUTOCOMMIT设置为False）。
django.db.backends.BaseDatabaseFeatures.allows_primary_key_0属性已重命名为allows_auto_pk_0，以更好地描述它。对于Django中包含的所有数据库后端，它True，除了MySQL允许主键值为0。它仅禁止值为0的自动增量主键。
父模型中定义的阴影模型字段已被禁止，因为这会在预期的模型行为中产生歧义。此外，模型继承层次结构中的冲突字段会导致系统检查错误。例如，如果使用多继承，则需要在父模型上定义自定义主键字段，否则默认的id字段会冲突。有关详细信息，请参阅Multiple inheritance。
django.utils.translation.parse_accept_lang_header()现在返回小写语言环境，而不是提供的情况。由于区域设置应该处理不区分大小写，这允许我们加快区域设置检测。
django.utils.translation.get_language_from_path()和django.utils.translation.trans_real.get_supported_language_variant()现在不再有supported参数。
django.contrib.contenttypes.views中的shortcut视图现在支持协议相对URL。//example.com）。
GenericRelation现在支持可选的related_query_name参数。设置related_query_name将相关对象的关系添加回过滤，排序和其他查询操作的内容类型。
当在PostgreSQL上运行测试时，USER将需要读取访问内置的postgres数据库。这是为了代替以前连接到实际的非测试数据库的行为。
作为System check framework，fields, models, and model managers的一部分，都实现了向检查框架注册的check()方法。如果您在其中一个对象上有一个名为check()的现有方法，则需要重命名它。
如上所述，在“次要特性”的“缓存”部分中，将CACHES设置的TIMEOUT参数定义为None键为“未到期”。以前，使用内存缓存后端，0的TIMEOUT将设置非过期密钥，但这与设置和过期（即，没有缓存）设置（“键”， “值”， timeout = 0）的行为。如果您想要未过期的键，请更新您的设置，使用None而不是0，因为后者现在还在设置中指定设置和到期。
sql*管理命令现在遵守DATABASE_ROUTERS的allow_migrate()方法。如果模型已同步到非默认数据库，请使用--database标志为这些模型获取SQL（以前它们将始终包含在输出中）。
当输入无效的UTF-8时，解码来自URL的查询字符串现在将返回到ISO-8859-1编码。
通过向默认项目模板（仅限于1.7.2版）添加SessionAuthenticationMiddleware，必须在使用runserver访问页面之前创建数据库。
django.utils.dictconfig和django.utils.importlib分别是logging.config和importlib的副本Python之前的2.7版本。它们已被弃用。
当前import_by_path()函数捕获AttributeError，ImportError和ValueError异常，并重新提出ImproperlyConfigured。这种异常掩蔽使得它不必要地很难诊断循环导入问题，因为它使它看起来像问题来自Django内部。它已被弃用，赞成import_string()。
django.utils.tzinfo提供了两个tzinfo子类，LocalTimezone和FixedOffset。对于由django.utils.timezone，django.utils.timezone.get_default_timezone()和django.utils.timezone.get_fixed_timezone()。
django.utils.unittest提供对所有Python版本的unittest2库的统一访问。由于在Python 2.7中unittest2成为标准库的unittest模块，而Django 1.7不再支持旧的Python版本，因此此模块不再有用。它已被弃用。请改用unittest。
由于在Python 2.7中将OrderedDict添加到标准库中，因此不再需要使用SortedDict，因此已被弃用。
由SortedDict（insert()和value_for_index()）提供的另外两个已弃用的方法已删除。如果您依赖这些方法来更改表单字段等结构，则应将这些OrderedDict视为不可变对象，并覆盖它们以更改其内容。
例如，您可能想要覆盖MyFormClass.base_fields（虽然此属性不被视为公共API）以更改所有MyFormClass实例的字段顺序；或者类似地，您可以覆盖MyFormClass.__init__()内的self.fields，以更改特定表单实例的字段。例如（从Django本身）：
PasswordChangeForm.base_fields = OrderedDict(
(k, PasswordChangeForm.base_fields[k])
for k in ['old_password', 'new_password1', 'new_password2']
)
Previously, if models were organized in a package (myapp/models/) rather than simply myapp/models.py, Django would look for initial SQL data in myapp/models/sql/. 这个bug已经修复，Django将搜索myapp/sql/。修复此问题后，添加了迁移，其中弃用初始SQL数据。因此，虽然此更改仍然存在，但不推荐使用，因为整个功能部件将在Django 1.9中删除。
django.contrib.sites在不在INSTALLED_APPS中时提供缩减的功能。应用程序加载重构在这种情况下添加了一些约束。因此，两个对象已移动，旧位置已弃用：
ModelAdmin.declared_fieldsets已被弃用。尽管是一个私有API，它将通过一个常规的弃用路径。此属性主要由绕过ModelAdmin.get_fieldsets()的方法使用，但这被视为一个错误并已解决。
由于django.contrib.contenttypes.generic定义了管理和模型相关对象，导入此模块可能会触发意外的副作用。因此，其内容分为contenttypes子模块和django.contrib.contenttypes.generic模块已弃用：
以下Django代码库中的util.py实例已重命名为utils.py，以统一所有util和utils引用：
为了更好地处理在ModelAdmin上选择性显示内联的情况，ModelAdmin.get_formsets已被弃用支持新的get_formsets_with_inlines()
django.db.models.IPAddressField和django.forms.IPAddressField字段已弃用，支持django.db.models.GenericIPAddressField和django.forms.GenericIPAddressField。
BaseMemcachedCache._get_memcache_timeout()方法已重命名为get_backend_timeout()。尽管是一个私有API，它将经历正常的弃用。
dumpdata的--natural和-n选项已被弃用。请改用--natural-foreign。
类似地，serializers.serialize()的use_natural_keys参数已被弃用。请改用use_natural_foreign_keys。
已经强烈建议您使用GET和POST而不是REQUEST，因为前者更加明确。属性REQUEST已弃用，将在Django 1.9中移除。
MergeDict exists primarily to support merging POST and GET arguments into a REQUEST property on WSGIRequest. 要合并字典，请改用dict.update()。类MergeDict已弃用，将在Django 1.9中删除。
目前使用的简体中文zh-cn，繁体中文zh-tw和（西部）Frysian fy-nl的语言代码已弃用，分别替换为语言代码zh-hans，zh-hant和fy。如果您使用这些语言代码，则应重命名区域设置目录并更新您的设置以反映这些更改。已弃用的语言代码将在Django 1.9中删除。
函数memoize已废弃，应由functools.lru_cache装饰器（可从Python 3.2开始）替换。
Django ships a backport of this decorator for older Python versions and it’s available at django.utils.lru_cache.lru_cache. 已弃用的函数将在Django 1.9中删除。
Google已停止支援「地理Sitemap」格式。因此，Django对Geo Sitemap的支持已弃用，将在Django 1.8中删除。
作为admindocs的一部分的ADMIN_FOR功能已删除。您可以在方便时从配置中删除该设置。
DateTimeField中的SplitDateTimeWidget支持已弃用，请改用SplitDateTimeWidget与SplitDateTimeField
requires_model_validation is deprecated in favor of a new requires_system_checks flag. 如果后一个标志丢失，则使用前一个标志的值。定义requires_system_checks和requires_model_validation会导致错误。
check()方法替换了旧的validate()方法。
不推荐使用ModelAdmin.validator_class和default_validator_class属性，而使用新的checks_class属性。
ModelAdmin.validate()方法已弃用，支持ModelAdmin.check()。
不推荐使用django.contrib.admin.validation模块。
此方法已弃用，支持新的check_field方法。check_field()所需的功能与validate_field()提供的功能相同，但输出格式不同。需要此功能的第三方数据库后端应提供check_field()的实现。
Django 1.3 introduced {% load ssi from future %} and {% load url from future %} syntax for forward compatibility of the ssi and url template tags. 此语法现已弃用，将在Django 1.9中删除。You can simply remove the {% load ... from future %} tags.
javascript_quote()是django.utils.text中存在的未记录的函数。它在内部在javascript_catalog view中使用，其实现已更改为使用json.dumps()。如果您依靠此函数从不受信任的字符串提供安全输出，则应使用django.utils.html.escapejs或escapejs模板过滤器。如果您需要的是生成有效的JavaScript字符串，则可以使用json.dumps()。
django.utils.html.fix_ampersands方法和fix_ampersands模板过滤器已弃用，因为＆符号的转义已由Django的标准HTML转义功能处理。将此与fix_ampersands结合将导致双重转义，或者，如果输出被假定为安全的，则存在引入XSS漏洞的风险。除了fix_ampersands，django.utils.html.clean_html已被弃用，这是一个未记录的函数，调用fix_ampersands。由于这是加速淘汰，因此在Django 1.8中将删除fix_ampersands和clean_html。
具有TEST_前缀的所有数据库设置已被弃用，以利用数据库设置中TEST字典中的条目。旧的设置将被支持，直到Django 1.9。为了向后兼容旧版本的Django，您可以定义两个版本的设置，只要它们匹配。
通过runfcgi管理命令的FastCGI支持将在Django 1.9中删除。请使用WSGI部署您的项目。
在应用程序加载重构器之后，需要移动django.contrib.sites.models中的两个对象，因为它们必须可用，而不导入django.contrib.sites.models django.contrib.sites未安装。从django.contrib.sites.shortcuts导入django.contrib.sites.requests和get_current_site()的RequestSite 。旧的导入位置将工作，直到Django 1.9。
Django不再在内部使用这个功能。即使它是一个私有API，它会经历正常的淘汰循环。
专用API django.db.models.sql.where.WhereNode.make_atom()和django.db.models.sql.where.Constraint已弃用，支持新的custom lookups API。
这些功能已到达其deprecation cycle的末尾，因此已在Django 1.7中移除（有关详情，请参阅deprecation timeline）：
2015年5月13日