============================================ Django 1.6 release notes - UNDER DEVELOPMENT ============================================ Welcome to Django 1.6! These release notes cover the `new features`_, as well as some `backwards incompatible changes`_ you'll want to be aware of when upgrading from Django 1.5 or older versions. We've also dropped some features, which are detailed in :doc:`our deprecation plan `, and we've `begun the deprecation process for some features`_. .. _`new features`: `What's new in Django 1.6`_ .. _`backwards incompatible changes`: `Backwards incompatible changes in 1.6`_ .. _`begun the deprecation process for some features`: `Features deprecated in 1.6`_ What's new in Django 1.6 ======================== Simplified default project and app templates ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The default templates used by :djadmin:`startproject` and :djadmin:`startapp` have been simplified and modernized. The :doc:`admin ` is now enabled by default in new projects; the :doc:`sites ` framework no longer is. :ref:`Language detection ` and :ref:`clickjacking prevention ` are turned on. If the default templates don't suit your tastes, you can use :ref:`custom project and app templates `. Minor features ~~~~~~~~~~~~~~ * Authentication backends can raise ``PermissionDenied`` to immediately fail the authentication chain. * The ``assertQuerysetEqual()`` now checks for undefined order and raises ``ValueError`` if undefined order is spotted. The order is seen as undefined if the given ``QuerySet`` isn't ordered and there are more than one ordered values to compare against. * Added :meth:`~django.db.models.query.QuerySet.earliest` for symmetry with :meth:`~django.db.models.query.QuerySet.latest`. * The default widgets for :class:`~django.forms.EmailField` and :class:`~django.forms.URLField` use the new type attributes available in HTML5 (type='email', type='url'). * The ``number`` argument for :ref:`lazy plural translations ` can be provided at translation time rather than at definition time. * For custom management commands: Verification of the presence of valid settings in commands that ask for it by using the :attr:`~django.core.management.BaseCommand.can_import_settings` internal option is now performed independently from handling of the locale that should be active during the execution of the command. The latter can now be influenced by the new :attr:`~django.core.management.BaseCommand.leave_locale_alone` internal option. See :ref:`management-commands-and-locales` for more details. Backwards incompatible changes in 1.6 ===================================== * The ``django.db.models.query.EmptyQuerySet`` can't be instantiated any more - it is only usable as a marker class for checking if :meth:`~django.db.models.query.QuerySet.none` has been called: ``isinstance(qs.none(), EmptyQuerySet)`` * If your CSS/Javascript code used to access HTML input widgets by type, you should review it as ``type='text'`` widgets might be now output as ``type='email'`` or ``type='url'`` depending on their corresponding field type. * Extraction of translatable literals from templates with the :djadmin:`makemessages` command now correctly detects i18n constructs when they are located after a ``{#`` / ``#}``-type comment on the same line. E.g.: .. code-block:: html+django {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %} * (Related to the above item.) Validation of the placement of :ref:`translator-comments-in-templates` specified using ``{#`` / ``#}`` is now stricter. All translator comments not located at the end of their respective lines in a template are ignored and a warning is generated by :djadmin:`makemessages` when it finds them. E.g.: .. code-block:: html+django {# Translators: This is ignored #}{% trans "Translate me" %} {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}

{% trans "Welcome" %}

.. warning:: In addition to the changes outlined in this section, be sure to review the :doc:`deprecation plan ` for any features that have been removed. If you haven't updated your code within the deprecation timeline for a given feature, its removal may appear as a backwards incompatible change. Features deprecated in 1.6 ========================== ``SEND_BROKEN_LINK_EMAILS`` setting ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :class:`~django.middleware.common.CommonMiddleware` used to provide basic reporting of broken links by email when ``SEND_BROKEN_LINK_EMAILS`` is set to ``True``. Because of intractable ordering problems between :class:`~django.middleware.common.CommonMiddleware` and :class:`~django.middleware.locale.LocaleMiddleware`, this feature was split out into a new middleware: :class:`~django.middleware.common.BrokenLinkEmailsMiddleware`. If you're relying on this feature, you should add ``'django.middleware.common.BrokenLinkEmailsMiddleware'`` to your :setting:`MIDDLEWARE_CLASSES` setting and remove ``SEND_BROKEN_LINK_EMAILS`` from your settings. ``_has_changed`` method on widgets ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you defined your own form widgets and defined the ``_has_changed`` method on a widget, you should now define this method on the form field itself.