1.8.txt 43 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049
  1. ============================================
  2. Django 1.8 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.8!
  5. These release notes cover the `new features`_, as well as some `backwards
  6. incompatible changes`_ you'll want to be aware of when upgrading from Django
  7. 1.6 or older versions. We've also `begun the deprecation process for some
  8. features`_, and some features have reached the end of their deprecation process
  9. and `have been removed`_.
  10. .. _`new features`: `What's new in Django 1.8`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.8`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.8`_
  13. .. _`have been removed`: `Features removed in 1.8`_
  14. Python compatibility
  15. ====================
  16. Like Django 1.7, Django 1.8 requires Python 2.7 or above, though we
  17. **highly recommend** the latest minor release.
  18. What's new in Django 1.8
  19. ========================
  20. Security enhancements
  21. ~~~~~~~~~~~~~~~~~~~~~
  22. Several features of the django-secure_ third-party library have been
  23. integrated into Django. :class:`django.middleware.security.SecurityMiddleware`
  24. provides several security enhancements to the request/response cycle. The new
  25. :djadminopt:`--deploy` option of the :djadmin:`check` command allows you to
  26. check your production settings file for ways to increase the security of your
  27. site.
  28. .. _django-secure: https://pypi.python.org/pypi/django-secure
  29. New PostgreSQL specific functionality
  30. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  31. Django now has a module with extensions for PostgreSQL specific features, such
  32. as :class:`~django.contrib.postgres.fields.ArrayField` and
  33. :class:`~django.contrib.postgres.fields.HStoreField`. A full breakdown of the
  34. features is available :doc:`in the documentation</ref/contrib/postgres/index>`.
  35. New data types
  36. ~~~~~~~~~~~~~~
  37. * Django now has a :class:`~django.db.models.UUIDField` for storing
  38. universally unique identifiers. There is a corresponding :class:`form field
  39. <django.forms.UUIDField>`. It is stored as the native ``uuid`` data type on
  40. PostgreSQL and as a fixed length character field on other backends.
  41. Minor features
  42. ~~~~~~~~~~~~~~
  43. :mod:`django.contrib.admin`
  44. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  45. * :class:`~django.contrib.admin.ModelAdmin` now has a
  46. :meth:`~django.contrib.admin.ModelAdmin.has_module_permission`
  47. method to allow limiting access to the module on the admin index page.
  48. * :class:`~django.contrib.admin.InlineModelAdmin` now has an attribute
  49. :attr:`~django.contrib.admin.InlineModelAdmin.show_change_link` that
  50. supports showing a link to an inline object's change form.
  51. * Use the new ``django.contrib.admin.RelatedOnlyFieldListFilter`` in
  52. :attr:`ModelAdmin.list_filter <django.contrib.admin.ModelAdmin.list_filter>`
  53. to limit the ``list_filter`` choices to foreign objects which are attached to
  54. those from the ``ModelAdmin``.
  55. * The :meth:`ModelAdmin.delete_view()
  56. <django.contrib.admin.ModelAdmin.delete_view>` displays a summary of objects
  57. to be deleted on the deletion confirmation page.
  58. * The jQuery library embedded in the admin has been upgraded to version 1.11.1.
  59. * You can now specify :attr:`AdminSite.site_url
  60. <django.contrib.admin.AdminSite.site_url>` in order to display a link to the
  61. front-end site.
  62. * You can now specify :attr:`ModelAdmin.show_full_result_count
  63. <django.contrib.admin.ModelAdmin.show_full_result_count>` to control whether
  64. or not the full count of objects should be displayed on a filtered admin page.
  65. :mod:`django.contrib.admindocs`
  66. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  67. * reStructuredText is now parsed in model docstrings.
  68. :mod:`django.contrib.auth`
  69. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  70. * Authorization backends can now raise
  71. :class:`~django.core.exceptions.PermissionDenied` in
  72. :meth:`~django.contrib.auth.models.User.has_perm`
  73. and :meth:`~django.contrib.auth.models.User.has_module_perms`
  74. to short-circuit permission checking.
  75. * :class:`~django.contrib.auth.forms.PasswordResetForm` now
  76. has a method :meth:`~django.contrib.auth.forms.PasswordResetForm.send_email`
  77. that can be overridden to customize the mail to be sent.
  78. * The ``max_length`` of :attr:`Permission.name
  79. <django.contrib.auth.models.Permission.name>` has been increased from 50 to
  80. 255 characters. Please run the database migration.
  81. * :attr:`~django.contrib.auth.models.CustomUser.USERNAME_FIELD` and
  82. :attr:`~django.contrib.auth.models.CustomUser.REQUIRED_FIELDS` now supports
  83. :class:`~django.db.models.ForeignKey`\s.
  84. :mod:`django.contrib.formtools`
  85. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  86. * A :doc:`form wizard </ref/contrib/formtools/form-wizard>` using the
  87. :class:`~django.contrib.formtools.wizard.views.CookieWizardView` will now ignore
  88. an invalid cookie, and the wizard will restart from the first step. An invalid
  89. cookie can occur in cases of intentional manipulation, but also after a secret
  90. key change. Previously, this would raise ``WizardViewCookieModified``, a
  91. ``SuspiciousOperation``, causing an exception for any user with an invalid cookie
  92. upon every request to the wizard, until the cookie is removed.
  93. :mod:`django.contrib.gis`
  94. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  95. * Compatibility shims for ``SpatialRefSys`` and ``GeometryColumns`` changed in
  96. Django 1.2 have been removed.
  97. * The Spatialite backend now supports ``Collect`` and ``Extent`` aggregates
  98. when the database version is 3.0 or later.
  99. :mod:`django.contrib.messages`
  100. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  101. * ...
  102. :mod:`django.contrib.redirects`
  103. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  104. * ...
  105. :mod:`django.contrib.sessions`
  106. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  107. * Session cookie is now deleted after
  108. :meth:`~django.contrib.sessions.backends.base.SessionBase.flush()` is called.
  109. :mod:`django.contrib.sitemaps`
  110. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  111. * The new :attr:`Sitemap.i18n <django.contrib.sitemaps.Sitemap.i18n>` attribute
  112. allows you to generate a sitemap based on the :setting:`LANGUAGES` setting.
  113. :mod:`django.contrib.sites`
  114. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  115. * :func:`~django.contrib.sites.shortcuts.get_current_site` will now lookup
  116. the current site based on :meth:`request.get_host()
  117. <django.http.HttpRequest.get_host>` if the :setting:`SITE_ID` setting is not
  118. defined.
  119. :mod:`django.contrib.staticfiles`
  120. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  121. * ...
  122. :mod:`django.contrib.syndication`
  123. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  124. * ...
  125. Cache
  126. ^^^^^
  127. * The ``incr()`` method of the
  128. ``django.core.cache.backends.locmem.LocMemCache`` backend is now thread-safe.
  129. Database backends
  130. ^^^^^^^^^^^^^^^^^
  131. * The MySQL backend no longer strips microseconds from ``datetime`` values as
  132. MySQL 5.6.4 and up supports fractional seconds depending on the declaration
  133. of the datetime field (when ``DATETIME`` includes fractional precision greater
  134. than 0). New datetime database columns created with Django 1.8 and MySQL 5.6.4
  135. and up will support microseconds. See the :ref:`MySQL database notes
  136. <mysql-fractional-seconds>` for more details.
  137. Email
  138. ^^^^^
  139. * :ref:`Email backends <topic-email-backends>` now support the context manager
  140. protocol for opening and closing connections.
  141. * The SMTP email backend now supports ``keyfile`` and ``certfile``
  142. authentication with the :setting:`EMAIL_SSL_CERTFILE` and
  143. :setting:`EMAIL_SSL_KEYFILE` settings.
  144. * The SMTP :class:`~django.core.mail.backends.smtp.EmailBackend` now supports
  145. setting the ``timeout`` parameter with the :setting:`EMAIL_TIMEOUT` setting.
  146. File Storage
  147. ^^^^^^^^^^^^
  148. * ...
  149. File Uploads
  150. ^^^^^^^^^^^^
  151. * ...
  152. Forms
  153. ^^^^^
  154. * Form widgets now render attributes with a value of ``True`` or ``False``
  155. as HTML5 boolean attributes.
  156. * The new :meth:`~django.forms.Form.has_error()` method allows checking
  157. if a specific error has happened.
  158. * If :attr:`~django.forms.Form.required_css_class` is defined on a form, then
  159. the ``<label>`` tags for required fields will have this class present in its
  160. attributes.
  161. * The rendering of non-field errors in unordered lists (``<ul>``) now includes
  162. ``nonfield`` in its list of classes to distinguish them from field-specific
  163. errors.
  164. * :class:`~django.forms.Field` now accepts a
  165. :attr:`~django.forms.Field.label_suffix` argument, which will override the
  166. form's :attr:`~django.forms.Form.label_suffix`. This enables customizing the
  167. suffix on a per-field basis — previously it wasn't possible to override
  168. a form's :attr:`~django.forms.Form.label_suffix` while using shortcuts such
  169. as ``{{ form.as_p }}`` in templates.
  170. * :class:`~django.forms.extras.widgets.SelectDateWidget` now accepts an
  171. :attr:`~django.forms.extras.widgets.SelectDateWidget.empty_label` argument, which will
  172. override the top list choice label when :class:`~django.forms.DateField` is not required.
  173. * After an :class:`~django.forms.ImageField` has been cleaned and validated, the
  174. ``UploadedFile`` object will have an additional ``image`` attribute containing
  175. the Pillow ``Image`` instance used to check if the file was a valid image. It
  176. will also update ``UploadedFile.content_type`` with the image's content type
  177. as determined by Pillow.
  178. * You can now pass a callable that returns an iterable of choices when
  179. instantiating a :class:`~django.forms.ChoiceField`.
  180. Generic Views
  181. ^^^^^^^^^^^^^
  182. * Generic views that use :class:`~django.views.generic.list.MultipleObjectMixin`
  183. may now specify the ordering applied to the
  184. :attr:`~django.views.generic.list.MultipleObjectMixin.queryset` by setting
  185. :attr:`~django.views.generic.list.MultipleObjectMixin.ordering` or overriding
  186. :meth:`~django.views.generic.list.MultipleObjectMixin.get_ordering()`.
  187. * The new :attr:`SingleObjectMixin.query_pk_and_slug
  188. <django.views.generic.detail.SingleObjectMixin.query_pk_and_slug>`
  189. attribute allows changing the behavior of
  190. :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
  191. so that it'll perform its lookup using both the primary key and the slug.
  192. * The :meth:`~django.views.generic.edit.FormMixin.get_form()` method doesn't
  193. require a ``form_class`` to be provided anymore. If not provided ``form_class``
  194. defaults to :meth:`~django.views.generic.edit.FormMixin.get_form_class()`.
  195. Internationalization
  196. ^^^^^^^^^^^^^^^^^^^^
  197. * :setting:`FORMAT_MODULE_PATH` can now be a list of strings representing
  198. module paths. This allows importing several format modules from different
  199. reusable apps. It also allows overriding those custom formats in your main
  200. Django project.
  201. Management Commands
  202. ^^^^^^^^^^^^^^^^^^^
  203. * :djadmin:`dumpdata` now has the option :djadminopt:`--output` which allows
  204. specifying the file to which the serialized data is written.
  205. * :djadmin:`makemessages` and :djadmin:`compilemessages` now have the option
  206. :djadminopt:`--exclude` which allows exclusion of specific locales from
  207. processing.
  208. * The :djadminopt:`--ignorenonexistent` option of the :djadmin:`loaddata`
  209. management command now ignores data for models that no longer exist.
  210. * :djadmin:`runserver` now uses daemon threads for faster reloading.
  211. * :djadmin:`inspectdb` now outputs ``Meta.unique_together``.
  212. * When calling management commands from code through :ref:`call_command
  213. <call-command>` and passing options, the option name can match the command
  214. line option name (without the initial dashes) or the final option destination
  215. variable name, but in either case, the resulting option received by the
  216. command is now always the ``dest`` name specified in the command option
  217. definition (as long as the command uses the new :py:mod:`argparse` module).
  218. * The :djadmin:`dbshell` command now supports MySQL's optional SSL certificate
  219. authority setting (``--ssl-ca``).
  220. * The :djadminopt:`--name` option for :djadmin:`makemigrations` allows you to
  221. to give the migration(s) a custom name instead of a generated one.
  222. * The :djadmin:`loaddata` command now prevents repeated fixture loading. If
  223. :setting:`FIXTURE_DIRS` contains duplicates or a default fixture directory
  224. path (``app_name/fixtures``), an exception is raised.
  225. Middleware
  226. ^^^^^^^^^^
  227. * The :attr:`CommonMiddleware.response_redirect_class
  228. <django.middleware.common.CommonMiddleware.response_redirect_class>`
  229. attribute allows you to customize the redirects issued by the middleware.
  230. Migrations
  231. ^^^^^^^^^^
  232. * The :class:`~django.db.migrations.operations.RunSQL` operation can now handle
  233. parameters passed to the SQL statements.
  234. * It is now possible to have migrations (most probably :ref:`data migrations
  235. <data-migrations>`) for applications without models.
  236. Models
  237. ^^^^^^
  238. * Django now logs at most 9000 queries in ``connections.queries``, in order
  239. to prevent excessive memory usage in long-running processes in debug mode.
  240. * There is now a model ``Meta`` option to define a
  241. :attr:`default related name <django.db.models.Options.default_related_name>`
  242. for all relational fields of a model.
  243. * Pickling models and querysets across different versions of Django isn't
  244. officially supported (it may work, but there's no guarantee). An extra
  245. variable that specifies the current Django version is now added to the
  246. pickled state of models and querysets, and Django raises a ``RuntimeWarning``
  247. when these objects are unpickled in a different version than the one in
  248. which they were pickled.
  249. * Added :meth:`Model.from_db() <django.db.models.Model.from_db()>` which
  250. Django uses whenever objects are loaded using the ORM. The method allows
  251. customizing model loading behavior.
  252. * ``extra(select={...})`` now allows you to escape a literal ``%s`` sequence
  253. using ``%%s``.
  254. * :doc:`Custom Lookups</howto/custom-lookups>` can now be registered using
  255. a decorator pattern.
  256. * The new :attr:`Transform.bilateral <django.db.models.Transform.bilateral>`
  257. attribute allows creating bilateral transformations. These transformations
  258. are applied to both ``lhs`` and ``rhs`` when used in a lookup expression,
  259. providing opportunities for more sophisticated lookups.
  260. Signals
  261. ^^^^^^^
  262. * Exceptions from the ``(receiver, exception)`` tuples returned by
  263. :meth:`Signal.send_robust() <django.dispatch.Signal.send_robust>` now have
  264. their traceback attached as a ``__traceback__`` attribute.
  265. * The ``environ`` argument, which contains the WSGI environment structure from
  266. the request, was added to the :data:`~django.core.signals.request_started`
  267. signal.
  268. System Check Framework
  269. ^^^^^^^^^^^^^^^^^^^^^^
  270. * :attr:`~django.core.checks.register` can now be used as a function.
  271. Templates
  272. ^^^^^^^^^
  273. * :tfilter:`urlize` now supports domain-only links that include characters after
  274. the top-level domain (e.g. ``djangoproject.com/`` and
  275. ``djangoproject.com/download/``).
  276. * :tfilter:`urlize` doesn't treat exclamation marks at the end of a domain or
  277. its query string as part of the URL (the URL in e.g. ``'djangoproject.com!``
  278. is ``djangoproject.com``)
  279. Requests and Responses
  280. ^^^^^^^^^^^^^^^^^^^^^^
  281. * ``WSGIRequest`` now respects paths starting with ``//``.
  282. * The :meth:`HttpRequest.build_absolute_uri()
  283. <django.http.HttpRequest.build_absolute_uri>` method now handles paths
  284. starting with ``//`` correctly.
  285. * If :setting:`DEBUG` is ``True`` and a request raises a
  286. :exc:`~django.core.exceptions.SuspiciousOperation`, the response will be
  287. rendered with a detailed error page.
  288. * The ``query_string`` argument of :class:`~django.http.QueryDict` is now
  289. optional, defaulting to ``None``, so a blank ``QueryDict`` can now be
  290. instantiated with ``QueryDict()`` instead of ``QueryDict(None)`` or
  291. ``QueryDict('')``.
  292. * The ``GET`` and ``POST`` attributes of an :class:`~django.http.HttpRequest`
  293. object are now :class:`~django.http.QueryDict`\s rather than dictionaries,
  294. and the ``FILES`` attribute is now a ``MultiValueDict``.
  295. This brings this class into line with the documentation and with
  296. ``WSGIRequest``.
  297. * The :attr:`HttpResponse.charset <django.http.HttpResponse.charset>` attribute
  298. was added.
  299. * ``WSGIRequestHandler`` now follows RFC in converting URI to IRI, using
  300. ``uri_to_iri()``.
  301. * The :meth:`HttpRequest.get_full_path()
  302. <django.http.HttpRequest.get_full_path>` method now escapes unsafe characters
  303. from the path portion of a Uniform Resource Identifier (URI) properly.
  304. * :class:`~django.http.HttpResponse` now implements a few additional methods
  305. like :meth:`~django.http.HttpResponse.getvalue` so that instances can be used
  306. as stream objects.
  307. Tests
  308. ^^^^^
  309. * The :class:`RequestFactory.trace() <django.test.RequestFactory>`
  310. and :class:`Client.trace() <django.test.Client.trace>` methods were
  311. implemented, allowing you to create ``TRACE`` requests in your tests.
  312. * The ``count`` argument was added to
  313. :meth:`~django.test.SimpleTestCase.assertTemplateUsed`. This allows you to
  314. assert that a template was rendered a specific number of times.
  315. * The new :meth:`~django.test.SimpleTestCase.assertJSONNotEqual` assertion
  316. allows you to test that two JSON fragments are not equal.
  317. * Added the ability to preserve the test database by adding the
  318. :djadminopt:`--keepdb` flag.
  319. * Added the :attr:`~django.test.Response.resolver_match` attribute to test
  320. client responses.
  321. * Added several settings that allow customization of test tablespace parameters
  322. for Oracle: :setting:`DATAFILE`, :setting:`DATAFILE_TMP`,
  323. :setting:`DATAFILE_MAXSIZE` and :setting:`DATAFILE_TMP_MAXSIZE`.
  324. Validators
  325. ^^^^^^^^^^
  326. * ...
  327. Backwards incompatible changes in 1.8
  328. =====================================
  329. .. warning::
  330. In addition to the changes outlined in this section, be sure to review the
  331. :ref:`deprecation plan <deprecation-removed-in-1.8>` for any features that
  332. have been removed. If you haven't updated your code within the
  333. deprecation timeline for a given feature, its removal may appear as a
  334. backwards incompatible change.
  335. Related object operations are run in a transaction
  336. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  337. Some operations on related objects such as
  338. :meth:`~django.db.models.fields.related.RelatedManager.add()` or
  339. :ref:`direct assignment<direct-assignment>` ran multiple data modifying
  340. queries without wrapping them in transactions. To reduce the risk of data
  341. corruption, all data modifying methods that affect multiple related objects
  342. (i.e. ``add()``, ``remove()``, ``clear()``, and :ref:`direct assignment
  343. <direct-assignment>`) now perform their data modifying queries from within a
  344. transaction, provided your database supports transactions.
  345. This has one backwards incompatible side effect, signal handlers triggered from
  346. these methods are now executed within the method's transaction and any
  347. exception in a signal handler will prevent the whole operation.
  348. Assigning unsaved objects to relations raises an error
  349. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  350. Assigning unsaved objects to a :class:`~django.db.models.ForeignKey`,
  351. :class:`~django.contrib.contenttypes.fields.GenericForeignKey`, and
  352. :class:`~django.db.models.OneToOneField` now raises a :exc:`ValueError`.
  353. Previously, the assignment of an unsaved object would be silently ignored.
  354. For example::
  355. >>> book = Book.objects.create(name="Django")
  356. >>> book.author = Author(name="John")
  357. >>> book.author.save()
  358. >>> book.save()
  359. >>> Book.objects.get(name="Django")
  360. >>> book.author
  361. >>>
  362. Now, an error will be raised to prevent data loss::
  363. >>> book.author = Author(name="john")
  364. Traceback (most recent call last):
  365. ...
  366. ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.
  367. Management commands that only accept positional arguments
  368. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  369. If you have written a custom management command that only accepts positional
  370. arguments and you didn't specify the
  371. :attr:`~django.core.management.BaseCommand.args` command variable, you might
  372. get an error like ``Error: unrecognized arguments: ...``, as variable parsing
  373. is now based on :py:mod:`argparse` which doesn't implicitly accept positional
  374. arguments. You can make your command backwards compatible by simply setting the
  375. :attr:`~django.core.management.BaseCommand.args` class variable. However, if
  376. you don't have to keep compatibility with older Django versions, it's better to
  377. implement the new :meth:`~django.core.management.BaseCommand.add_arguments`
  378. method as described in :doc:`/howto/custom-management-commands`.
  379. Custom test management command arguments through test runner
  380. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  381. The method to add custom arguments to the `test` management command through the
  382. test runner has changed. Previously, you could provide an `option_list` class
  383. variable on the test runner to add more arguments (à la :py:mod:`optparse`).
  384. Now to implement the same behavior, you have to create an
  385. ``add_arguments(cls, parser)`` class method on the test runner and call
  386. ``parser.add_argument`` to add any custom arguments, as parser is now an
  387. :py:class:`argparse.ArgumentParser` instance.
  388. Model check ensures auto-generated column names are within limits specified by database
  389. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  390. A field name that's longer than the column name length supported by a database
  391. can create problems. For example, with MySQL you'll get an exception trying to
  392. create the column, and with PostgreSQL the column name is truncated by the
  393. database (you may see a warning in the PostgreSQL logs).
  394. A model check has been introduced to better alert users to this scenario before
  395. the actual creation of database tables.
  396. If you have an existing model where this check seems to be a false positive,
  397. for example on PostgreSQL where the name was already being truncated, simply
  398. use :attr:`~django.db.models.Field.db_column` to specify the name that's being
  399. used.
  400. The check also applies to the columns generated in an implicit
  401. ``ManyToManyField.through`` model. If you run into an issue there, use
  402. :attr:`~django.db.models.ManyToManyField.through` to create an explicit model
  403. and then specify :attr:`~django.db.models.Field.db_column` on its column(s)
  404. as needed.
  405. Query relation lookups now check object types
  406. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  407. Querying for model lookups now checks if the object passed is of correct type
  408. and raises a :exc:`ValueError` if not. Previously, Django didn't care if the
  409. object was of correct type; it just used the object's related field attribute
  410. (e.g. ``id``) for the lookup. Now, an error is raised to prevent incorrect
  411. lookups::
  412. >>> book = Book.objects.create(name="Django")
  413. >>> book = Book.objects.filter(author=book)
  414. Traceback (most recent call last):
  415. ...
  416. ValueError: Cannot query "<Book: Django>": Must be "Author" instance.
  417. Default ``EmailField.max_length`` increased to 254
  418. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  419. The old default 75 character ``max_length`` was not capable of storing all
  420. possible RFC3696/5321-compliant email addresses. In order to store all
  421. possible valid email addresses, the ``max_length`` has been increased to 254
  422. characters. You will need to generate and apply database migrations for your
  423. affected models (or add ``max_length=75`` if you wish to keep the length on
  424. your current fields). A migration for
  425. :attr:`django.contrib.auth.models.User.email` is included.
  426. Support for PostgreSQL versions older than 9.0
  427. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  428. The end of upstream support periods was reached in July 2014 for PostgreSQL 8.4.
  429. As a consequence, Django 1.8 sets 9.0 as the minimum PostgreSQL version it
  430. officially supports.
  431. This also includes dropping support for PostGIS 1.3 and 1.4 as these versions
  432. are not supported on versions of PostgreSQL later than 8.4.
  433. Django also now requires the use of Psycopg2 version 2.0.9 or higher.
  434. Support for MySQL versions older than 5.5
  435. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  436. The end of upstream support periods was reached in January 2012 for MySQL 5.0
  437. and December 2013 for MySQL 5.1. As a consequence, Django 1.8 sets 5.5 as the
  438. minimum MySQL version it officially supports.
  439. Support for Oracle versions older than 11.1
  440. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  441. The end of upstream support periods was reached in July 2010 for Oracle 9.2,
  442. January 2012 for Oracle 10.1, and July 2013 for Oracle 10.2. As a consequence,
  443. Django 1.8 sets 11.1 as the minimum Oracle version it officially supports.
  444. Specific privileges used instead of roles for tests on Oracle
  445. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  446. Earlier versions of Django granted the CONNECT and RESOURCE roles to the test
  447. user on Oracle. These roles have been deprecated, so Django 1.8 uses the
  448. specific underlying privileges instead. This changes the privileges required
  449. of the main user for running tests (unless the project is configured to avoid
  450. creating a test user). The exact privileges required now are detailed in
  451. :ref:`Oracle notes <oracle-notes>`.
  452. ``AbstractUser.last_login`` allows null values
  453. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  454. The :attr:`AbstractUser.last_login <django.contrib.auth.models.User.last_login>`
  455. field now allows null values. Previously, it defaulted to the time when the user
  456. was created which was misleading if the user never logged in. Please run the
  457. database migration. If your custom user inherits from ``AbstractUser`` and you
  458. wish to set ``last_login`` to ``NULL`` for users who haven't logged in, you can
  459. run this query::
  460. from django.db import models
  461. from django.contrib.auth import get_user_model
  462. from django.contrib.auth.models import AbstractBaseUser
  463. UserModel = get_user_model()
  464. if issubclass(UserModel, AbstractBaseUser):
  465. UserModel._default_manager.filter(
  466. last_login=models.F('date_joined')
  467. ).update(last_login=None)
  468. :mod:`django.contrib.gis`
  469. ~~~~~~~~~~~~~~~~~~~~~~~~~
  470. * Support for GEOS 3.1 and GDAL 1.6 has been dropped.
  471. * Support for SpatiaLite < 2.4 has been dropped.
  472. * GIS-specific lookups have been refactored to use the
  473. :class:`django.db.models.Lookup` API.
  474. * The default ``str`` representation of
  475. :class:`~django.contrib.gis.geos.GEOSGeometry` objects has been changed from
  476. WKT to EWKT format (including the SRID). As this representation is used in
  477. the serialization framework, that means that ``dumpdata`` output will now
  478. contain the SRID value of geometry objects.
  479. Priority of context processors for ``TemplateResponse`` brought in line with ``render``
  480. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  481. The :class:`~django.template.response.TemplateResponse` constructor is designed to be a
  482. drop-in replacement for the :func:`~django.shortcuts.render` function. However,
  483. it had a slight incompatibility, in that for ``TemplateResponse``, context data
  484. from the passed in context dictionary could be shadowed by context data returned
  485. from context processors, whereas for ``render`` it was the other way
  486. around. This was a bug, and the behaviour of ``render`` is more appropriate,
  487. since it allows the globally defined context processors to be overridden locally
  488. in the view. If you were relying on the fact context data in a
  489. ``TemplateResponse`` could be overridden using a context processor, you will
  490. need to change your code.
  491. Miscellaneous
  492. ~~~~~~~~~~~~~
  493. * ``connections.queries`` is now a read-only attribute.
  494. * Database connections are considered equal only if they're the same object.
  495. They aren't hashable any more.
  496. * :class:`~django.middleware.gzip.GZipMiddleware` used to disable compression
  497. for some content types when the request is from Internet Explorer, in order
  498. to work around a bug in IE6 and earlier. This behavior could affect
  499. performance on IE7 and later. It was removed.
  500. * ``URLField.to_python`` no longer adds a trailing slash to pathless URLs.
  501. * The :tfilter:`length` template filter now returns ``0`` for an undefined
  502. variable, rather than an empty string.
  503. * ``ForeignKey.default_error_message['invalid']`` has been changed from
  504. ``'%(model)s instance with pk %(pk)r does not exist.'`` to
  505. ``'%(model)s instance with %(field)s %(value)r does not exist.'`` If you are
  506. using this message in your own code, please update the list of interpolated
  507. parameters. Internally, Django will continue to provide the
  508. ``pk`` parameter in ``params`` for backwards compatibility.
  509. * ``UserCreationForm.errors_messages['duplicate_username']`` is no longer used.
  510. If you wish to customize that error message, :ref:`override it on the form
  511. <modelforms-overriding-default-fields>` using the ``'unique'`` key in
  512. ``Meta.errors_messages['username']`` or, if you have a custom form field for
  513. ``'username'``, using the the ``'unique'`` key in its
  514. :attr:`~django.forms.Field.error_messages` argument.
  515. * ``AdminSite`` no longer takes an ``app_name`` argument and its ``app_name``
  516. attribute has been removed. The application name is always ``admin`` (as
  517. opposed to the instance name which you can still customize using
  518. ``AdminSite(name="...")``.
  519. * Internal changes were made to the :class:`~django.forms.ClearableFileInput`
  520. widget to allow more customization. The undocumented ``url_markup_template``
  521. attribute was removed in favor of ``template_with_initial``.
  522. * For consistency with other major vendors, the ``en_GB`` locale now has Monday
  523. as the first day of the week.
  524. * Seconds have been removed from any locales that had them in ``TIME_FORMAT``,
  525. ``DATETIME_FORMAT``, or ``SHORT_DATETIME_FORMAT``.
  526. * The default max size of the Oracle test tablespace has increased from 200M
  527. to 500M.
  528. * :func:`~django.core.urlresolvers.reverse` and
  529. :func:`~django.core.urlresolvers.reverse_lazy` now return Unicode strings
  530. instead of byte strings.
  531. * The ``CacheClass`` shim has been removed from all cache backends.
  532. These aliases were provided for backwards compatibility with Django 1.3.
  533. If you are still using them, please update your project to use the real
  534. class name found in the :setting:`BACKEND <CACHES-BACKEND>` key of the
  535. :setting:`CACHES` setting.
  536. * By default, :ref:`call_command <call-command>` now always skips the check
  537. framework (unless you pass it ``skip_checks=False``).
  538. * When iterating over lines, :class:`~django.core.files.File` now uses
  539. `universal newlines`_. The following are recognized as ending a line: the
  540. Unix end-of-line convention ``'\n'``, the Windows convention ``'\r\n'``, and
  541. the old Macintosh convention ``'\r'``.
  542. .. _universal newlines: http://www.python.org/dev/peps/pep-0278
  543. .. _deprecated-features-1.8:
  544. Features deprecated in 1.8
  545. ==========================
  546. Loading ``cycle`` and ``firstof`` template tags from ``future`` library
  547. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  548. Django 1.6 introduced ``{% load cycle from future %}`` and
  549. ``{% load firstof from future %}`` syntax for forward compatibility of the
  550. :ttag:`cycle` and :ttag:`firstof` template tags. This syntax is now deprecated
  551. and will be removed in Django 2.0. You can simply remove the
  552. ``{% load ... from future %}`` tags.
  553. ``django.conf.urls.patterns()``
  554. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  555. In the olden days of Django, it was encouraged to reference views as strings
  556. in ``urlpatterns``::
  557. urlpatterns = patterns('',
  558. url('^$', 'myapp.views.myview'),
  559. )
  560. and Django would magically import ``myapp.views.myview`` internally and turn
  561. the string into a real function reference. In order to reduce repetition when
  562. referencing many views from the same module, the ``patterns()`` function takes
  563. a required initial ``prefix`` argument which is prepended to all
  564. views-as-strings in that set of ``urlpatterns``::
  565. urlpatterns = patterns('myapp.views',
  566. url('^$', 'myview'),
  567. url('^other/$', 'otherview'),
  568. )
  569. In the modern era, we have updated the tutorial to instead recommend importing
  570. your views module and referencing your view functions (or classes) directly.
  571. This has a number of advantages, all deriving from the fact that we are using
  572. normal Python in place of "Django String Magic": the errors when you mistype a
  573. view name are less obscure, IDEs can help with autocompletion of view names,
  574. etc.
  575. So these days, the above use of the ``prefix`` arg is much more likely to be
  576. written (and is better written) as::
  577. from myapp import views
  578. urlpatterns = patterns('',
  579. url('^$', views.myview),
  580. url('^other/$', views.otherview),
  581. )
  582. Thus ``patterns()`` serves little purpose and is a burden when teaching new users
  583. (answering the newbie's question "why do I need this empty string as the first
  584. argument to ``patterns()``?"). For these reasons, we are deprecating it.
  585. Updating your code is as simple as ensuring that ``urlpatterns`` is a list of
  586. :func:`django.conf.urls.url` instances. For example::
  587. from django.conf.urls import url
  588. from myapp import views
  589. urlpatterns = [
  590. url('^$', views.myview),
  591. url('^other/$', views.otherview),
  592. ]
  593. Passing a string as ``view`` to :func:`~django.conf.urls.url`
  594. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  595. Related to the previous item, referencing views as strings in the ``url()``
  596. function is deprecated. Pass the callable view as described in the previous
  597. section instead.
  598. ``django.test.SimpleTestCase.urls``
  599. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  600. The attribute :attr:`SimpleTestCase.urls <django.test.SimpleTestCase.urls>`
  601. for specifying URLconf configuration in tests has been deprecated and will be
  602. removed in Django 2.0. Use :func:`@override_settings(ROOT_URLCONF=...)
  603. <django.test.override_settings>` instead.
  604. ``prefix`` argument to :func:`~django.conf.urls.i18n.i18n_patterns`
  605. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  606. Related to the previous item, the ``prefix`` argument to
  607. :func:`django.conf.urls.i18n.i18n_patterns` has been deprecated. Simply pass a
  608. list of :func:`django.conf.urls.url` instances instead.
  609. Using an incorrect count of unpacked values in the :ttag:`for` template tag
  610. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  611. Using an incorrect count of unpacked values in :ttag:`for` tag will raise an
  612. exception rather than fail silently in Django 2.0.
  613. Passing a dotted path to :func:`~django.core.urlresolvers.reverse()` and :ttag:`url`
  614. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  615. Reversing URLs by Python path is an expensive operation as it causes the
  616. path being reversed to be imported. This behavior has also resulted in a
  617. `security issue`_. Use :ref:`named URL patterns <naming-url-patterns>`
  618. for reversing instead.
  619. If you are using :mod:`django.contrib.sitemaps`, add the ``name`` argument to
  620. the ``url`` that references :func:`django.contrib.sitemaps.views.sitemap`::
  621. from django.contrib.sitemaps.views import sitemap
  622. url(r'^sitemap\.xml$', sitemap, {'sitemaps': sitemaps},
  623. name='django.contrib.sitemaps.views.sitemap')
  624. to ensure compatibility when reversing by Python path is removed in Django 2.0.
  625. Similarly for GIS sitemaps, add ``name='django.contrib.gis.sitemaps.views.kml'``
  626. or ``name='django.contrib.gis.sitemaps.views.kmz'``.
  627. .. _security issue: https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse
  628. Extending management command arguments through ``Command.option_list``
  629. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  630. Management commands now use :py:mod:`argparse` instead of :py:mod:`optparse` to
  631. parse command-line arguments passed to commands. This also means that the way
  632. to add custom arguments to commands has changed: instead of extending the
  633. ``option_list`` class list, you should now override the
  634. :meth:`~django.core.management.BaseCommand.add_arguments` method and add
  635. arguments through ``argparse.add_argument()``. See
  636. :ref:`this example <custom-commands-options>` for more details.
  637. ``django.core.management.NoArgsCommand``
  638. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  639. The class :class:`~django.core.management.NoArgsCommand` is now deprecated and
  640. will be removed in Django 2.0. Use :class:`~django.core.management.BaseCommand`
  641. instead, which takes no arguments by default.
  642. ``cache_choices`` option of ``ModelChoiceField`` and ``ModelMultipleChoiceField``
  643. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  644. :class:`~django.forms.ModelChoiceField` and
  645. :class:`~django.forms.ModelMultipleChoiceField` took an undocumented, untested
  646. option ``cache_choices``. This cached querysets between multiple renderings of
  647. the same ``Form`` object. This option is subject to an accelerated deprecation
  648. and will be removed in Django 1.9.
  649. ``django.template.resolve_variable()``
  650. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  651. The function has been informally marked as "Deprecated" for some time. Replace
  652. ``resolve_variable(path, context)`` with
  653. ``django.template.Variable(path).resolve(context)``.
  654. ``django.contrib.webdesign``
  655. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  656. It provided the :ttag:`lorem` template tag which is now included in the
  657. built-in tags. Simply remove ``'django.contrib.webdesign'`` from
  658. :setting:`INSTALLED_APPS` and ``{% load webdesign %}`` from your templates.
  659. ``error_message`` argument to ``django.forms.RegexField``
  660. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  661. It provided backwards compatibility for pre-1.0 code, but its functionality is
  662. redundant. Use ``Field.error_messages['invalid']`` instead.
  663. Old :tfilter:`unordered_list` syntax
  664. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  665. An older (pre-1.0), more restrictive and verbose input format for the
  666. :tfilter:`unordered_list` template filter has been deprecated::
  667. ``['States', [['Kansas', [['Lawrence', []], ['Topeka', []]]], ['Illinois', []]]]``
  668. Using the new syntax, this becomes::
  669. ``['States', ['Kansas', ['Lawrence', 'Topeka'], 'Illinois']]``
  670. ``django.forms.Field._has_changed()``
  671. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  672. Rename this method to :meth:`~django.forms.Field.has_changed` by removing the
  673. leading underscore. The old name will still work until Django 2.0.
  674. ``django.utils.html.remove_tags()`` and ``removetags`` template filter
  675. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  676. ``django.utils.html.remove_tags()`` as well as the template filter
  677. ``removetags`` have been deprecated as they cannot guarantee safe output. Their
  678. existence is likely to lead to their use in security-sensitive contexts where
  679. they are not actually safe.
  680. The unused and undocumented ``django.utils.html.strip_entities()`` function has
  681. also been deprecated.
  682. ``is_admin_site`` argument to ``django.contrib.auth.views.password_reset()``
  683. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  684. It's a legacy option that should no longer be necessary.
  685. ``SubfieldBase``
  686. ~~~~~~~~~~~~~~~~
  687. ``django.db.models.fields.subclassing.SubfieldBase`` has been deprecated and
  688. will be removed in Django 2.0. Historically, it was used to handle fields where
  689. type conversion was needed when loading from the database, but it was not used
  690. in ``.values()`` calls or in aggregates. It has been replaced with
  691. :meth:`~django.db.models.Field.from_db_value`. Note that the new approach does
  692. not call the :meth:`~django.db.models.Field.to_python` method on assignment
  693. as was the case with ``SubfieldBase``.
  694. ``django.utils.checksums``
  695. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  696. The ``django.utils.checksums`` module has been deprecated and will be removed
  697. in Django 2.0. The functionality it provided (validating checksum using the
  698. Luhn algorithm) was undocumented and not used in Django. The module has been
  699. moved to the `django-localflavor`_ package (version 1.1+).
  700. .. _django-localflavor: https://pypi.python.org/pypi/django-localflavor
  701. ``django.contrib.admin.helpers.InlineAdminForm.original_content_type_id``
  702. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  703. The ``original_content_type_id`` attribute on ``InlineAdminForm`` has been
  704. deprecated and will be removed in Django 2.0. Historically, it was used
  705. to construct the "view on site" URL. This URL is now accessible using the
  706. ``absolute_url`` attribute of the form.
  707. ``django.views.generic.edit.FormMixin.get_form()``’s ``form_class`` argument
  708. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  709. ``FormMixin`` subclasses that override the ``get_form()`` method should make
  710. sure to provide a default value for the ``form_class`` argument since it's
  711. now optional.
  712. Overriding ``setUpClass`` / ``tearDownClass`` in test cases
  713. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  714. The decorators :func:`~django.test.override_settings` and
  715. :func:`~django.test.modify_settings` now act at the class level when used as
  716. class decorators. As a consequence, when overriding ``setUpClass()`` or
  717. ``tearDownClass()``, the ``super`` implementation should always be called.
  718. .. removed-features-1.8:
  719. Features removed in 1.8
  720. =======================
  721. These features have reached the end of their deprecation cycle and so have been
  722. removed in Django 1.8 (please see the :ref:`deprecation timeline
  723. <deprecation-removed-in-1.8>` for more details):
  724. * ``django.contrib.comments`` is removed.
  725. * The following transaction management APIs are removed:
  726. - ``TransactionMiddleware``
  727. - the decorators and context managers ``autocommit``, ``commit_on_success``,
  728. and ``commit_manually``, defined in ``django.db.transaction``
  729. - the functions ``commit_unless_managed`` and ``rollback_unless_managed``,
  730. also defined in ``django.db.transaction``
  731. - the ``TRANSACTIONS_MANAGED`` setting
  732. * The :ttag:`cycle` and :ttag:`firstof` template tags auto-escape their
  733. arguments.
  734. * The ``SEND_BROKEN_LINK_EMAILS`` setting is removed.
  735. * ``django.middleware.doc.XViewMiddleware`` is removed.
  736. * The ``Model._meta.module_name`` alias is removed.
  737. * The backward compatible shims introduced to rename ``get_query_set``
  738. and similar queryset methods are removed. This affects the following classes:
  739. ``BaseModelAdmin``, ``ChangeList``, ``BaseCommentNode``,
  740. ``GenericForeignKey``, ``Manager``, ``SingleRelatedObjectDescriptor`` and
  741. ``ReverseSingleRelatedObjectDescriptor``.
  742. * The backward compatible shims introduced to rename the attributes
  743. ``ChangeList.root_query_set`` and ``ChangeList.query_set`` are removed.
  744. * ``django.views.defaults.shortcut`` and ``django.conf.urls.shortcut`` are
  745. removed.
  746. * Support for the Python Imaging Library (PIL) module is removed.
  747. * The following private APIs are removed:
  748. - ``django.db.backend``
  749. - ``django.db.close_connection()``
  750. - ``django.db.backends.creation.BaseDatabaseCreation.set_autocommit()``
  751. - ``django.db.transaction.is_managed()``
  752. - ``django.db.transaction.managed()``
  753. * ``django.forms.widgets.RadioInput`` is removed.
  754. * The module ``django.test.simple`` and the class
  755. ``django.test.simple.DjangoTestSuiteRunner`` are removed.
  756. * The module ``django.test._doctest`` is removed.
  757. * The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is removed.
  758. * Usage of the hard-coded *Hold down "Control", or "Command" on a Mac, to select
  759. more than one.* string to override or append to user-provided ``help_text`` in
  760. forms for ``ManyToMany`` model fields is not be performed by Django anymore
  761. either at the model or forms layer.
  762. * The ``Model._meta.get_(add|change|delete)_permission`` methods are removed.
  763. * The session key ``django_language`` is no longer read for backwards
  764. compatibility.
  765. * Geographic Sitemaps are removed
  766. (``django.contrib.gis.sitemaps.views.index`` and
  767. ``django.contrib.gis.sitemaps.views.sitemap``).
  768. * ``django.utils.html.fix_ampersands``, the ``fix_ampersands`` template filter,
  769. and ``django.utils.html.clean_html`` are removed.