1.7.txt 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235
  1. ============================================
  2. Django 1.7 release notes - UNDER DEVELOPMENT
  3. ============================================
  4. Welcome to Django 1.7!
  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 dropped some features, which are detailed in
  8. :doc:`our deprecation plan </internals/deprecation>`, and we've `begun the
  9. deprecation process for some features`_.
  10. .. _`new features`: `What's new in Django 1.7`_
  11. .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.7`_
  12. .. _`begun the deprecation process for some features`: `Features deprecated in 1.7`_
  13. Python compatibility
  14. ====================
  15. Django 1.7 requires Python 2.7 or above, though we **highly recommend**
  16. the latest minor release. Support for Python 2.6 has been dropped.
  17. This change should affect only a small number of Django users, as most
  18. operating-system vendors today are shipping Python 2.7 or newer as their default
  19. version. If you're still using Python 2.6, however, you'll need to stick to
  20. Django 1.6 until you can upgrade your Python version. Per :doc:`our support
  21. policy </internals/release-process>`, Django 1.6 will continue to receive
  22. security support until the release of Django 1.8.
  23. What's new in Django 1.7
  24. ========================
  25. Calling custom ``QuerySet`` methods from the ``Manager``
  26. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  27. The :meth:`QuerySet.as_manager() <django.db.models.query.QuerySet.as_manager>`
  28. class method has been added to :ref:`create Manager with QuerySet methods
  29. <create-manager-with-queryset-methods>`.
  30. Admin shortcuts support time zones
  31. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  32. The "today" and "now" shortcuts next to date and time input widgets in the
  33. admin are now operating in the :ref:`current time zone
  34. <default-current-time-zone>`. Previously, they used the browser time zone,
  35. which could result in saving the wrong value when it didn't match the current
  36. time zone on the server.
  37. In addition, the widgets now display a help message when the browser and
  38. server time zone are different, to clarify how the value inserted in the field
  39. will be interpreted.
  40. Minor features
  41. ~~~~~~~~~~~~~~
  42. * The new :attr:`UploadedFile.content_type_extra
  43. <django.core.files.uploadedfile.UploadedFile.content_type_extra>` attribute
  44. contains extra parameters passed to the ``content-type`` header on a file
  45. upload.
  46. * The ``enter`` argument was added to the
  47. :data:`~django.test.signals.setting_changed` signal.
  48. * The :meth:`QuerySet.update_or_create()
  49. <django.db.models.query.QuerySet.update_or_create>` method was added.
  50. * :attr:`~django.db.models.Options.app_label` is no longer required for models
  51. that are defined in a ``models`` package within an app.
  52. * The :meth:`Context.push() <django.template.Context.push>` method now returns
  53. a context manager which automatically calls :meth:`pop()
  54. <django.template.Context.pop>` upon exiting the ``with`` statement.
  55. Additionally, :meth:`push() <django.template.Context.push>` now accepts
  56. parameters that are passed to the ``dict`` constructor used to build the new
  57. context level.
  58. * The :class:`~django.utils.feedgenerator.Atom1Feed` syndication feed's
  59. ``updated`` element now utilizes `updateddate` instead of ``pubdate``,
  60. allowing the ``published`` element to be included in the feed (which
  61. relies on ``pubdate``).
  62. * Buttons in :mod:`django.contrib.admin` now use the ``border-radius`` CSS
  63. property for rounded corners rather than GIF background images.
  64. * Some admin templates now have ``app-<app_name>`` and ``model-<model_name>``
  65. classes in their ``<body>`` tag to allow customizing the CSS per app or per
  66. model.
  67. * The admin changelist cells now have a ``field-<field_name>`` class in the
  68. HTML to enable style customizations.
  69. * :func:`~django.core.mail.send_mail` now accepts an ``html_message``
  70. parameter for sending a multipart ``text/plain`` and ``text/html`` email.
  71. * The :djadminopt:`--no-color` option for ``django-admin.py`` allows you to
  72. disable the colorization of management command output.
  73. * The :mod:`sitemap framework<django.contrib.sitemaps>` now makes use of
  74. :attr:`~django.contrib.sitemaps.Sitemap.lastmod` to set a ``Last-Modified``
  75. header in the response. This makes it possible for the
  76. :class:`~django.middleware.http.ConditionalGetMiddleware` to handle
  77. conditional ``GET`` requests for sitemaps which set ``lastmod``.
  78. * You can override the new :meth:`AuthenticationForm.confirm_login_allowed()
  79. <django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed>` method
  80. to more easily customize the login policy.
  81. * :attr:`Field.choices<django.db.models.Field.choices>` now allows you to
  82. customize the "empty choice" label by including a tuple with an empty string
  83. or ``None`` for the key and the custom label as the value. The default blank
  84. option ``"----------"`` will be omitted in this case.
  85. * The admin's search fields can now be customized per-request thanks to the new
  86. :meth:`django.contrib.admin.ModelAdmin.get_search_fields` method.
  87. * The :meth:`ModelAdmin.get_fields()
  88. <django.contrib.admin.ModelAdmin.get_fields>` method may be overridden to
  89. customize the value of :attr:`ModelAdmin.fields
  90. <django.contrib.admin.ModelAdmin.fields>`.
  91. * :func:`django.contrib.auth.views.password_reset` takes an optional
  92. ``html_email_template_name`` parameter used to send a multipart HTML email
  93. for password resets.
  94. * :class:`~django.forms.MultiValueField` allows optional subfields by setting
  95. the ``require_all_fields`` argument to ``False``. The ``required`` attribute
  96. for each individual field will be respected, and a new ``incomplete``
  97. validation error will be raised when any required fields are empty.
  98. * The :meth:`~django.forms.Form.clean` method on a form no longer needs to
  99. return ``self.cleaned_data``. If it does return a changed dictionary then
  100. that will still be used.
  101. * The new :attr:`~django.db.models.Options.default_permissions` model
  102. ``Meta`` option allows you to customize (or disable) creation of the default
  103. add, change, and delete permissions.
  104. * The :func:`~django.contrib.auth.decorators.permission_required` decorator can
  105. take a list of permissions as well as a single permission.
  106. * The new :setting:`FILE_UPLOAD_DIRECTORY_PERMISSIONS` setting controls
  107. the file system permissions of directories created during file upload, like
  108. :setting:`FILE_UPLOAD_PERMISSIONS` does for the files themselves.
  109. * Explicit :class:`~django.db.models.OneToOneField` for
  110. :ref:`multi-table-inheritance` are now discovered in abstract classes.
  111. * The ``<label>`` and ``<input>`` tags rendered by
  112. :class:`~django.forms.RadioSelect` and
  113. :class:`~django.forms.CheckboxSelectMultiple` when looping over the radio
  114. buttons or checkboxes now include ``for`` and ``id`` attributes, respectively.
  115. Each radio button or checkbox includes an ``id_for_label`` attribute to
  116. output the element's ID.
  117. * Any ``**kwargs`` passed to
  118. :meth:`~django.contrib.auth.models.User.email_user()` are passed to the
  119. underlying :meth:`~django.core.mail.send_mail()` call.
  120. Backwards incompatible changes in 1.7
  121. =====================================
  122. .. warning::
  123. In addition to the changes outlined in this section, be sure to review the
  124. :doc:`deprecation plan </internals/deprecation>` for any features that
  125. have been removed. If you haven't updated your code within the
  126. deprecation timeline for a given feature, its removal may appear as a
  127. backwards incompatible change.
  128. Miscellaneous
  129. ~~~~~~~~~~~~~
  130. * The :meth:`django.core.files.uploadhandler.FileUploadHandler.new_file()`
  131. method is now passed an additional ``content_type_extra`` parameter. If you
  132. have a custom :class:`~django.core.files.uploadhandler.FileUploadHandler`
  133. that implements ``new_file()``, be sure it accepts this new parameter.
  134. * :class:`ModelFormSet<django.forms.models.BaseModelFormSet>`’s no longer
  135. delete instances when ``save(commit=False)`` is called. See
  136. :attr:`~django.forms.formsets.BaseFormSet.can_delete` for instructions on how
  137. to manually delete objects from deleted forms.
  138. * Loading empty fixtures emits a ``RuntimeWarning`` rather than raising
  139. :class:`~django.core.management.CommandError`.
  140. * :func:`django.contrib.staticfiles.views.serve` will now raise an
  141. :exc:`~django.http.Http404` exception instead of
  142. :exc:`~django.core.exceptions.ImproperlyConfigured` when :setting:`DEBUG`
  143. is ``False``. This change removes the need to conditionally add the view to
  144. your root URLconf, which in turn makes it safe to reverse by name. It also
  145. removes the ability for visitors to generate spurious HTTP 500 errors by
  146. requesting static files that don't exist or haven't been collected yet.
  147. Features deprecated in 1.7
  148. ==========================
  149. ``django.utils.dictconfig``/``django.utils.importlib``
  150. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  151. ``django.utils.dictconfig`` and ``django.utils.importlib`` were copies of
  152. respectively :mod:`logging.config` and :mod:`importlib` provided for Python
  153. versions prior to 2.7. They have been deprecated.
  154. ``django.utils.unittest``
  155. ~~~~~~~~~~~~~~~~~~~~~~~~~
  156. ``django.utils.unittest`` provided uniform access to the ``unittest2`` library
  157. on all Python versions. Since ``unittest2`` became the standard library's
  158. :mod:`unittest` module in Python 2.7, and Django 1.7 drops support for older
  159. Python versions, this module isn't useful anymore. It has been deprecated. Use
  160. :mod:`unittest` instead.
  161. ``django.utils.datastructures.SortedDict``
  162. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  163. As :class:`~collections.OrderedDict` was added to the standard library in
  164. Python 2.7, :class:`~django.utils.datastructures.SortedDict` is no longer
  165. needed and has been deprecated.
  166. Custom SQL location for models package
  167. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  168. Previously, if models were organized in a package (``myapp/models/``) rather
  169. than simply ``myapp/models.py``, Django would look for :ref:`initial SQL data
  170. <initial-sql>` in ``myapp/models/sql/``. This bug has been fixed so that Django
  171. will search ``myapp/sql/`` as documented. The old location will continue to
  172. work until Django 1.9.
  173. ``declared_fieldsets`` attribute on ``ModelAdmin.``
  174. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  175. ``ModelAdmin.declared_fieldsets`` was deprecated. Despite being a private API,
  176. it will go through a regular deprecation path. This attribute was mostly used
  177. by methods that bypassed ``ModelAdmin.get_fieldsets()`` but this was considered
  178. a bug and has been addressed.