732 lines
31 KiB
Plaintext
732 lines
31 KiB
Plaintext
============================================
|
|
Django 1.4 release notes - UNDER DEVELOPMENT
|
|
============================================
|
|
|
|
This page documents release notes for the as-yet-unreleased Django
|
|
1.4. As such, it's tentative and subject to change. It provides
|
|
up-to-date information for those who are following trunk.
|
|
|
|
Django 1.4 includes various `new features`_ and some minor `backwards
|
|
incompatible changes`_. There are also some features that have been dropped,
|
|
which are detailed in :doc:`our deprecation plan </internals/deprecation>`, and
|
|
we've `begun the deprecation process for some features`_.
|
|
|
|
|
|
|
|
.. _new features: `What's new in Django 1.4`_
|
|
.. _backwards incompatible changes: backwards-incompatible-changes-1.4_
|
|
.. _begun the deprecation process for some features: deprecated-features-1.4_
|
|
|
|
Python compatibility
|
|
====================
|
|
|
|
While not a new feature, it's important to note that Django 1.4 introduces the
|
|
second shift in our Python compatibility policy since Django's initial public
|
|
debut. Django 1.2 dropped support for Python 2.3; now Django 1.4 drops support
|
|
for Python 2.4. As such, the minimum Python version required for Django is now
|
|
2.5, and Django is tested and supported on Python 2.5, 2.6 and 2.7.
|
|
|
|
This change should affect only a small number of Django users, as most
|
|
operating-system vendors today are shipping Python 2.5 or newer as their default
|
|
version. If you're still using Python 2.4, however, you'll need to stick to
|
|
Django 1.3 until you can upgrade; per :doc:`our support policy
|
|
</internals/release-process>`, Django 1.3 will continue to receive security
|
|
support until the release of Django 1.5.
|
|
|
|
Django does not support Python 3.x at this time. A document outlining our full
|
|
timeline for deprecating Python 2.x and moving to Python 3.x will be published
|
|
before the release of Django 1.4.
|
|
|
|
What's new in Django 1.4
|
|
========================
|
|
|
|
``SELECT FOR UPDATE`` support
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.4 now includes a :meth:`QuerySet.select_for_update()
|
|
<django.db.models.query.QuerySet.select_for_update>` method which generates a
|
|
``SELECT ... FOR UPDATE`` SQL query. This will lock rows until the end of the
|
|
transaction, meaning that other transactions cannot modify or delete rows
|
|
matched by a ``FOR UPDATE`` query.
|
|
|
|
For more details, see the documentation for
|
|
:meth:`~django.db.models.query.QuerySet.select_for_update`.
|
|
|
|
``Model.objects.bulk_create`` in the ORM
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This method allows for more efficient creation of multiple objects in the ORM.
|
|
It can provide significant performance increases if you have many objects,
|
|
Django makes use of this internally, meaning some operations (such as database
|
|
setup for test suites) has seen a performance benefit as a result.
|
|
|
|
See the :meth:`~django.db.models.query.QuerySet.bulk_create` docs for more
|
|
information.
|
|
|
|
``QuerySet.prefetch_related``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Similar to :meth:`~django.db.models.query.QuerySet.select_related` but with a
|
|
different strategy and broader scope,
|
|
:meth:`~django.db.models.query.QuerySet.prefetch_related` has been added to
|
|
:class:`~django.db.models.query.QuerySet`. This method returns a new
|
|
``QuerySet`` that will prefetch in a single batch each of the specified related
|
|
lookups as soon as it begins to be evaluated. Unlike ``select_related``, it does
|
|
the joins in Python, not in the database, and supports many-to-many
|
|
relationships, :class:`~django.contrib.contenttypes.generic.GenericForeignKey`
|
|
and more. This enables you to fix many instances of a very common performance
|
|
problem, in which your code ends up doing O(n) database queries (or worse) if
|
|
objects on your primary ``QuerySet`` each have many related objects that you
|
|
also need.
|
|
|
|
HTML5
|
|
~~~~~
|
|
|
|
We've switched the admin and other bundled templates to use the HTML5
|
|
doctype. While Django will be careful in its use of HTML5 features, to maintain
|
|
compatibility with older browsers, this change means that you can use any HTML5
|
|
features you need in admin pages without having to lose HTML validity or
|
|
override the provided templates to change the doctype.
|
|
|
|
Supported browsers for the admin
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django hasn't had a clear policy on which browsers are supported for using the
|
|
admin app. Django's new policy formalizes existing practices: `YUI's A-grade`_
|
|
browsers should provide a fully-functional admin experience, with the notable
|
|
exception of IE6, which is no longer supported.
|
|
|
|
Released over ten years ago, IE6 imposes many limitations on modern web
|
|
development. The practical implications of this policy are that contributors
|
|
are free to improve the admin without consideration for these limitations.
|
|
|
|
This new policy **has no impact** on development outside of the admin. Users of
|
|
Django are free to develop webapps compatible with any range of browsers.
|
|
|
|
.. _YUI's A-grade: http://yuilibrary.com/yui/docs/tutorials/gbs/
|
|
|
|
List filters in admin interface
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Prior to Django 1.4, the Django admin app allowed specifying change list
|
|
filters by specifying a field lookup (including spanning relations), and
|
|
not custom filters. This has been rectified with a simple API previously
|
|
known as "FilterSpec" which was used internally. For more details, see the
|
|
documentation for :attr:`~django.contrib.admin.ModelAdmin.list_filter`.
|
|
|
|
Multiple sort in admin interface
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The admin change list now supports sorting on multiple columns. It respects
|
|
all elements of the :attr:`~django.contrib.admin.ModelAdmin.ordering`
|
|
attribute, and sorting on multiple columns by clicking on headers is designed
|
|
to work similarly to how desktop GUIs do it. The new hook
|
|
:meth:`~django.contrib.admin.ModelAdmin.get_ordering` for specifying the
|
|
ordering dynamically (e.g. depending on the request) has also been added.
|
|
|
|
``ModelAdmin.save_related()``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
A new :meth:`~django.contrib.admin.ModelAdmin.save_related` hook was added to
|
|
:mod:`~django.contrib.admin.ModelAdmin` to ease the customization of how
|
|
related objects are saved in the admin.
|
|
|
|
Admin inlines respect user permissions
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Admin inlines will now only allow those actions for which the user has
|
|
permission. For ``ManyToMany`` relationships with an auto-created intermediate
|
|
model (which does not have its own permissions), the change permission for the
|
|
related model determines if the user has the permission to add, change or
|
|
delete relationships.
|
|
|
|
Tools for cryptographic signing
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.4 adds both a low-level API for signing values and a high-level API
|
|
for setting and reading signed cookies, one of the most common uses of
|
|
signing in Web applications.
|
|
|
|
See :doc:`cryptographic signing </topics/signing>` docs for more information.
|
|
|
|
Cookie-based session backend
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.4 introduces a new cookie based backend for the session framework
|
|
which uses the tools for :doc:`cryptographic signing </topics/signing>` to
|
|
store the session data in the client's browser.
|
|
|
|
See the :ref:`cookie-based backend <cookie-session-backend>` docs for
|
|
more information.
|
|
|
|
New form wizard
|
|
~~~~~~~~~~~~~~~
|
|
|
|
The previously shipped ``FormWizard`` of the formtools contrib app has been
|
|
replaced with a new implementation that is based on the class based views
|
|
introduced in Django 1.3. It features a pluggable storage API and doesn't
|
|
require the wizard to pass around hidden fields for every previous step.
|
|
|
|
Django 1.4 ships with a session based storage backend and a cookie based
|
|
storage backend. The latter uses the tools for
|
|
:doc:`cryptographic signing </topics/signing>` also introduced in
|
|
Django 1.4 to store the wizard state in the user's cookies.
|
|
|
|
See the :doc:`form wizard </ref/contrib/formtools/form-wizard>` docs for
|
|
more information.
|
|
|
|
``reverse_lazy``
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
A lazily evaluated version of :func:`django.core.urlresolvers.reverse` was
|
|
added to allow using URL reversals before the project's URLConf gets loaded.
|
|
|
|
Translating URL patterns
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.4 gained the ability to look for a language prefix in the URL pattern
|
|
when using the new :func:`django.conf.urls.i18n.i18n_patterns` helper function.
|
|
Additionally, it's now possible to define translatable URL patterns using
|
|
:func:`~django.utils.translation.ugettext_lazy`. See
|
|
:ref:`url-internationalization` for more information about the language prefix
|
|
and how to internationalize URL patterns.
|
|
|
|
Customizable ``SingleObjectMixin`` URLConf kwargs
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Two new attributes,
|
|
:attr:`pk_url_kwarg<django.views.generic.detail.SingleObjectMixin.pk_url_kwarg>` and
|
|
:attr:`slug_url_kwarg<django.views.generic.detail.SingleObjectMixin.slug_url_kwarg>`,
|
|
have been added to :class:`django.views.generic.detail.SingleObjectMixin` to
|
|
enable the customization of URLConf keyword arguments used for single
|
|
object generic views.
|
|
|
|
Assignment template tags
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
A new helper function,
|
|
:ref:`assignment_tag<howto-custom-template-tags-assignment-tags>`, was added to
|
|
``template.Library`` to ease the creation of template tags that store some
|
|
data in a specified context variable.
|
|
|
|
``*args`` and ``**kwargs`` support for template tag helper functions
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
:ref:`simple_tag<howto-custom-template-tags-simple-tags>`, :ref:`inclusion_tag
|
|
<howto-custom-template-tags-inclusion-tags>` and the newly introduced
|
|
:ref:`assignment_tag<howto-custom-template-tags-assignment-tags>` template
|
|
helper functions may now accept any number of positional or keyword arguments.
|
|
For example:
|
|
|
|
.. code-block:: python
|
|
|
|
@register.simple_tag
|
|
def my_tag(a, b, *args, **kwargs):
|
|
warning = kwargs['warning']
|
|
profile = kwargs['profile']
|
|
...
|
|
return ...
|
|
|
|
Then in the template any number of arguments may be passed to the template tag.
|
|
For example:
|
|
|
|
.. code-block:: html+django
|
|
|
|
{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}
|
|
|
|
No wrapping of exceptions in ``TEMPLATE_DEBUG`` mode
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
In previous versions of Django, whenever the :setting:`TEMPLATE_DEBUG` setting
|
|
was ``True``, any exception raised during template rendering (even exceptions
|
|
unrelated to template syntax) were wrapped in ``TemplateSyntaxError`` and
|
|
re-raised. This was done in order to provide detailed template source location
|
|
information in the debug 500 page.
|
|
|
|
In Django 1.4, exceptions are no longer wrapped. Instead, the original
|
|
exception is annotated with the source information. This means that catching
|
|
exceptions from template rendering is now consistent regardless of the value of
|
|
:setting:`TEMPLATE_DEBUG`, and there's no need to catch and unwrap
|
|
``TemplateSyntaxError`` in order to catch other errors.
|
|
|
|
``truncatechars`` template filter
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Added a filter which truncates a string to be no longer than the specified
|
|
number of characters. Truncated strings end with a translatable ellipsis
|
|
sequence ("..."). See the :tfilter:`truncatechars docs <truncatechars>` for
|
|
more details.
|
|
|
|
``static`` template tag
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The :mod:`staticfiles<django.contrib.staticfiles>` contrib app has now a new
|
|
:ttag:`static template tag<staticfiles-static>` to refer to files saved with
|
|
the :setting:`STATICFILES_STORAGE` storage backend. It'll use the storage
|
|
``url`` method and therefore supports advanced features such as
|
|
:ref:`serving files from a cloud service<staticfiles-from-cdn>`.
|
|
|
|
``CachedStaticFilesStorage`` storage backend
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Additional to the `static template tag`_ the
|
|
:mod:`staticfiles<django.contrib.staticfiles>` contrib app now has a
|
|
:class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage` which
|
|
caches the files it saves (when running the :djadmin:`collectstatic`
|
|
management command) by appending the MD5 hash of the file's content to the
|
|
filename. For example, the file ``css/styles.css`` would also be saved as
|
|
``css/styles.55e7cbb9ba48.css``
|
|
|
|
See the :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
|
|
docs for more information.
|
|
|
|
Simple clickjacking protection
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
We've added a middleware to provide easy protection against `clickjacking
|
|
<http://en.wikipedia.org/wiki/Clickjacking>`_ using the X-Frame-Options
|
|
header. It's not enabled by default for backwards compatibility reasons, but
|
|
you'll almost certainly want to :doc:`enable it </ref/clickjacking/>` to help
|
|
plug that security hole for browsers that support the header.
|
|
|
|
CSRF improvements
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
We've made various improvements to our CSRF features, including the
|
|
:func:`~django.views.decorators.csrf.ensure_csrf_cookie` decorator which can
|
|
help with AJAX heavy sites, protection for PUT and DELETE, and settings
|
|
:setting:`CSRF_COOKIE_SECURE` and :setting:`CSRF_COOKIE_PATH` which can improve
|
|
the security and usefulness of the CSRF protection. See the :doc:`CSRF docs
|
|
</ref/contrib/csrf>` for more information.
|
|
|
|
Error report filtering
|
|
~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Two new function decorators, :func:`sensitive_variables` and
|
|
:func:`sensitive_post_parameters`, were added to allow designating the
|
|
traceback frames' local variables and request's POST parameters susceptible
|
|
to contain sensitive information and that should be filtered out of error
|
|
reports.
|
|
|
|
All POST parameters are now systematically filtered out of error reports for
|
|
certain :mod:`contrib.views.auth` views (``login``, ``password_reset_confirm``,
|
|
``password_change``, and ``add_view`` and ``user_change_password`` in the
|
|
``auth`` admin) to prevent the leaking of sensitive information such as user
|
|
passwords.
|
|
|
|
You may override or customize the default filtering by writing a
|
|
:ref:`custom filter<custom-error-reports>`. Learn more on
|
|
:ref:`Filtering error reports<filtering-error-reports>`.
|
|
|
|
Extended IPv6 support
|
|
~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The previously added support for IPv6 addresses when using the runserver
|
|
management command in Django 1.3 has now been further extended by adding
|
|
a :class:`~django.db.models.fields.GenericIPAddressField` model field,
|
|
a :class:`~django.forms.fields.GenericIPAddressField` form field and
|
|
the validators :data:`~django.core.validators.validate_ipv46_address` and
|
|
:data:`~django.core.validators.validate_ipv6_address`
|
|
|
|
Minor features
|
|
~~~~~~~~~~~~~~
|
|
|
|
Django 1.4 also includes several smaller improvements worth noting:
|
|
|
|
* A more usable stacktrace in the technical 500 page: frames in the stack
|
|
trace which reference Django's code are dimmed out, while frames in user
|
|
code are slightly emphasized. This change makes it easier to scan a stacktrace
|
|
for issues in user code.
|
|
|
|
* Customizable names for :meth:`~django.template.Library.simple_tag`.
|
|
|
|
* In the documentation, a helpful :doc:`security overview </topics/security>`
|
|
page.
|
|
|
|
* Function :func:`django.contrib.auth.models.check_password` has been moved
|
|
to the :mod:`django.contrib.auth.utils` module. Importing it from the old
|
|
location will still work, but you should update your imports.
|
|
|
|
* The :djadmin:`collectstatic` management command gained a ``--clear`` option
|
|
to delete all files at the destination before copying or linking the static
|
|
files.
|
|
|
|
* It is now possible to load fixtures containing forward references when using
|
|
MySQL with the InnoDB database engine.
|
|
|
|
* A new 403 response handler has been added as
|
|
``'django.views.defaults.permission_denied'``. You can set your own handler by
|
|
setting the value of :data:`django.conf.urls.handler403`. See the
|
|
documentation about :ref:`the 403 (HTTP Forbidden) view<http_forbidden_view>`
|
|
for more information.
|
|
|
|
* The :ttag:`trans` template tag now takes an optional ``as`` argument to
|
|
be able to retrieve a translation string without displaying it but setting
|
|
a template context variable instead.
|
|
|
|
* A new plain text version of the HTTP 500 status code internal error page
|
|
served when :setting:`DEBUG` is ``True`` is now sent to the client when
|
|
Django detects that the request has originated in JavaScript code
|
|
(:meth:`~django.http.HttpRequest.is_ajax` is used for this).
|
|
|
|
Similarly to its HTML counterpart, it contains a collection of different
|
|
pieces of information about the state of the web application.
|
|
|
|
This should make it easier to read when debugging interaction with
|
|
client-side Javascript code.
|
|
|
|
.. _backwards-incompatible-changes-1.4:
|
|
|
|
Backwards incompatible changes in 1.4
|
|
=====================================
|
|
|
|
django.contrib.admin
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The included administration app ``django.contrib.admin`` has for a long time
|
|
shipped with a default set of static files such as JavaScript, images and
|
|
stylesheets. Django 1.3 added a new contrib app ``django.contrib.staticfiles``
|
|
to handle such files in a generic way and defined conventions for static
|
|
files included in apps.
|
|
|
|
Starting in Django 1.4 the admin's static files are now also following this
|
|
convention to make it easier to deploy the included files. In previous
|
|
versions of Django, it was also common to define a ``ADMIN_MEDIA_PREFIX``
|
|
setting to point to the URL where the admin's static files are served by a
|
|
web server. This setting has now been deprecated and replaced by the more
|
|
general setting :setting:`STATIC_URL`. Django will now expect to find the
|
|
admin static files under the URL ``<STATIC_URL>/admin/``.
|
|
|
|
If you've previously used a URL path for ``ADMIN_MEDIA_PREFIX`` (e.g.
|
|
``/media/``) simply make sure :setting:`STATIC_URL` and :setting:`STATIC_ROOT`
|
|
are configured and your web server serves the files correctly. The development
|
|
server continues to serve the admin files just like before. Don't hesitate to
|
|
consult the :doc:`static files howto </howto/static-files>` for further
|
|
details.
|
|
|
|
In case your ``ADMIN_MEDIA_PREFIX`` is set to an own domain (e.g.
|
|
``http://media.example.com/admin/``) make sure to also set your
|
|
:setting:`STATIC_URL` setting to the correct URL, for example
|
|
``http://media.example.com/``.
|
|
|
|
.. warning::
|
|
|
|
If you're implicitely relying on the path of the admin static files on
|
|
your server's file system when you deploy your site, you have to update
|
|
that path. The files were moved from :file:`django/contrib/admin/media/`
|
|
to :file:`django/contrib/admin/static/admin/`.
|
|
|
|
Removed admin icons
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
As part of an effort to improve the performance and usability of the admin's
|
|
changelist sorting interface and of the admin's :attr:`horizontal
|
|
<django.contrib.admin.ModelAdmin.filter_horizontal>` and :attr:`vertical
|
|
<django.contrib.admin.ModelAdmin.filter_vertical>` "filter" widgets, some icon
|
|
files were removed and grouped into two sprite files, respectively:
|
|
``selector-add.gif``, ``selector-addall.gif``, ``selector-remove.gif``,
|
|
``selector-removeall.gif``, ``selector_stacked-add.gif`` and
|
|
``selector_stacked-remove.gif`` into ``selector-icons.gif``; and
|
|
``arrow-up.gif`` and ``arrow-down.gif`` into ``sorting-icons.gif``. If you used
|
|
those icons to customize the admin then you will want to replace them with your
|
|
own icons or retrieve them from a previous release.
|
|
|
|
CSS class names in admin forms
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
To avoid conflicts with other common CSS class names (e.g. "button"), a prefix
|
|
"field-" has been added to all CSS class names automatically generated from the
|
|
form field names in the main admin forms, stacked inline forms and tabular
|
|
inline cells. You will need to take that prefix into account in your custom
|
|
style sheets or javascript files if you previously used plain field names as
|
|
selectors for custom styles or javascript transformations.
|
|
|
|
Compatibility with old signed data
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.3 changed the cryptographic signing mechanisms used in a number of
|
|
places in Django. While Django 1.3 kept fallbacks that would accept hashes
|
|
produced by the previous methods, these fallbacks are removed in Django 1.4.
|
|
|
|
So, if you upgrade to Django 1.4 directly from 1.2 or earlier, you may
|
|
lose/invalidate certain pieces of data that have been cryptographically signed
|
|
using an old method. To avoid this, use Django 1.3 first, for a period of time,
|
|
to allow the signed data to expire naturally. The affected parts are detailed
|
|
below, with 1) the consequences of ignoring this advice and 2) the amount of
|
|
time you need to run Django 1.3 for the data to expire or become irrelevant.
|
|
|
|
* contrib.sessions data integrity check
|
|
|
|
* consequences: the user will be logged out, and session data will be lost.
|
|
|
|
* time period: defined by SESSION_COOKIE_AGE.
|
|
|
|
* contrib.auth password reset hash
|
|
|
|
* consequences: password reset links from before the upgrade will not work.
|
|
|
|
* time period: defined by PASSWORD_RESET_TIMEOUT_DAYS.
|
|
|
|
Form related hashes — these are much shorter lifetime, and are relevant only for
|
|
the short window where a user might fill in a form generated by the pre-upgrade
|
|
Django instance, and try to submit it to the upgraded Django instance:
|
|
|
|
* contrib.comments form security hash
|
|
|
|
* consequences: the user will see a validation error "Security hash failed".
|
|
|
|
* time period: the amount of time you expect users to take filling out comment
|
|
forms.
|
|
|
|
* FormWizard security hash
|
|
|
|
* consequences: the user will see an error about the form having expired,
|
|
and will be sent back to the first page of the wizard, losing the data
|
|
they have inputted so far.
|
|
|
|
* time period: the amount of time you expect users to take filling out the
|
|
affected forms.
|
|
|
|
* CSRF check
|
|
|
|
* Note: This is actually a Django 1.1 fallback, not Django 1.2,
|
|
and applies only if you are upgrading from 1.1.
|
|
|
|
* consequences: the user will see a 403 error with any CSRF protected POST
|
|
form.
|
|
|
|
* time period: the amount of time you expect user to take filling out
|
|
such forms.
|
|
|
|
django.contrib.flatpages
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Starting in the 1.4 release the
|
|
:class:`~django.contrib.flatpages.middleware.FlatpageFallbackMiddleware` only
|
|
adds a trailing slash and redirects if the resulting URL refers to an existing
|
|
flatpage. For example, requesting ``/notaflatpageoravalidurl`` in a previous
|
|
version would redirect to ``/notaflatpageoravalidurl/``, which would
|
|
subsequently raise a 404. Requesting ``/notaflatpageoravalidurl`` now will
|
|
immediately raise a 404. Additionally redirects returned by flatpages are now
|
|
permanent (301 status code) to match the behavior of the
|
|
:class:`~django.middleware.common.CommonMiddleware`.
|
|
|
|
`COMMENTS_BANNED_USERS_GROUP` setting
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django's :doc:`comments app </ref/contrib/comments/index>` has historically
|
|
supported excluding the comments of a special user group, but we've never
|
|
documented the feature properly and didn't enforce the exclusion in other parts
|
|
of the app, e.g., the template tags. To fix this problem, we removed the code
|
|
from the feed class.
|
|
|
|
If you rely on the feature and want to restore the old behavior, simply use
|
|
a custom comment model manager to exclude the user group, like this::
|
|
|
|
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
|
|
|
|
Save this model manager in your custom comment app (e.g. in
|
|
``my_comments_app/managers.py``) and add it your
|
|
:ref:`custom comment app model <custom-comment-app-api>`::
|
|
|
|
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()
|
|
|
|
For more details, see the documentation about
|
|
:doc:`customizing the comments framework </ref/contrib/comments/custom>`.
|
|
|
|
`IGNORABLE_404_STARTS` and `IGNORABLE_404_ENDS` settings
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django can report 404 errors: see :doc:`/howto/error-reporting`.
|
|
Until Django 1.3, it was possible to exclude some URLs from the reporting
|
|
by adding prefixes to :setting:`IGNORABLE_404_STARTS` and suffixes to
|
|
:setting:`IGNORABLE_404_ENDS`.
|
|
|
|
In Django 1.4, these two settings are superseded by
|
|
:setting:`IGNORABLE_404_URLS`, which is a list of compiled regular expressions.
|
|
Django won't send an email for 404 errors on URLs that match any of them.
|
|
|
|
Furthermore, the previous settings had some rather arbitrary default values::
|
|
|
|
IGNORABLE_404_STARTS = ('/cgi-bin/', '/_vti_bin', '/_vti_inf')
|
|
IGNORABLE_404_ENDS = ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi',
|
|
'favicon.ico', '.php')
|
|
|
|
It's not Django's role to decide if your website has a legacy ``/cgi-bin/``
|
|
section or a ``favicon.ico``. As a consequence, the default values of
|
|
:setting:`IGNORABLE_404_URLS`, :setting:`IGNORABLE_404_STARTS` and
|
|
:setting:`IGNORABLE_404_ENDS` are all now empty.
|
|
|
|
If you have customized :setting:`IGNORABLE_404_STARTS` or
|
|
:setting:`IGNORABLE_404_ENDS`, or if you want to keep the old default value,
|
|
you should add the following lines in your settings file::
|
|
|
|
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>$'),
|
|
)
|
|
|
|
Don't forget to escape characters that have a special meaning in a regular
|
|
expression.
|
|
|
|
CSRF protection extended to PUT and DELETE
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Previously, Django's :doc:`CSRF protection </ref/contrib/csrf/>` provided
|
|
protection against only POST requests. Since use of PUT and DELETE methods in
|
|
AJAX applications is becoming more common, we now protect all methods not
|
|
defined as safe by :rfc:`2616` i.e. we exempt GET, HEAD, OPTIONS and TRACE, and
|
|
enforce protection on everything else.
|
|
|
|
If you using PUT or DELETE methods in AJAX applications, please see the
|
|
:ref:`instructions about using AJAX and CSRF <csrf-ajax>`.
|
|
|
|
``django.core.template_loaders``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This was an alias to ``django.template.loader`` since 2005, it has been removed
|
|
without emitting a warning due to the length of the deprecation. If your code
|
|
still referenced this please use ``django.template.loader`` instead.
|
|
|
|
``django.db.models.fields.URLField.verify_exists``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
This functionality has been removed due to intractable performance and
|
|
security issues. Any existing usage of ``verify_exists`` should be
|
|
removed.
|
|
|
|
``django.core.files.storage.Storage.open``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The ``open`` method of the base Storage class took an obscure parameter
|
|
``mixin`` which allowed to dynamically change the base classes of the
|
|
returned file object. In the rare case you relied on the `mixin` parameter,
|
|
you can easily achieve the same by overriding the `open` method, e.g.::
|
|
|
|
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))
|
|
|
|
.. _deprecated-features-1.4:
|
|
|
|
Features deprecated in 1.4
|
|
==========================
|
|
|
|
Old styles of calling ``cache_page`` decorator
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Some legacy ways of calling :func:`~django.views.decorators.cache.cache_page`
|
|
have been deprecated, please see the docs for the correct way to use this
|
|
decorator.
|
|
|
|
Support for PostgreSQL versions older than 8.2
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.3 dropped support for PostgreSQL versions older than 8.0 and the
|
|
relevant documents suggested to use a recent version because of performance
|
|
reasons but more importantly because end of the upstream support periods for
|
|
releases 8.0 and 8.1 was near (November 2010.)
|
|
|
|
Django 1.4 takes that policy further and sets 8.2 as the minimum PostgreSQL
|
|
version it officially supports.
|
|
|
|
Request exceptions are now always logged
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
When :doc:`logging support </topics/logging/>` was added to Django in 1.3, the
|
|
admin error email support was moved into the
|
|
:class:`django.utils.log.AdminEmailHandler`, attached to the
|
|
``'django.request'`` logger. In order to maintain the established behavior of
|
|
error emails, the ``'django.request'`` logger was called only when
|
|
:setting:`DEBUG` was `False`.
|
|
|
|
To increase the flexibility of request-error logging, the ``'django.request'``
|
|
logger is now called regardless of the value of :setting:`DEBUG`, and the
|
|
default settings file for new projects now includes a separate filter attached
|
|
to :class:`django.utils.log.AdminEmailHandler` to prevent admin error emails in
|
|
`DEBUG` mode::
|
|
|
|
'filters': {
|
|
'require_debug_false': {
|
|
'()': 'django.utils.log.RequireDebugFalse'
|
|
}
|
|
},
|
|
'handlers': {
|
|
'mail_admins': {
|
|
'level': 'ERROR',
|
|
'filters': ['require_debug_false'],
|
|
'class': 'django.utils.log.AdminEmailHandler'
|
|
}
|
|
},
|
|
|
|
If your project was created prior to this change, your :setting:`LOGGING`
|
|
setting will not include this new filter. In order to maintain
|
|
backwards-compatibility, Django will detect that your ``'mail_admins'`` handler
|
|
configuration includes no ``'filters'`` section, and will automatically add
|
|
this filter for you and issue a pending-deprecation warning. This will become a
|
|
deprecation warning in Django 1.5, and in Django 1.6 the
|
|
backwards-compatibility shim will be removed entirely.
|
|
|
|
The existence of any ``'filters'`` key under the ``'mail_admins'`` handler will
|
|
disable this backward-compatibility shim and deprecation warning.
|
|
|
|
``django.conf.urls.defaults``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Until Django 1.3 the functions :func:`~django.conf.urls.include`,
|
|
:func:`~django.conf.urls.patterns` and :func:`~django.conf.urls.url` plus
|
|
:data:`~django.conf.urls.handler404`, :data:`~django.conf.urls.handler500`
|
|
were located in a ``django.conf.urls.defaults`` module.
|
|
|
|
Starting with Django 1.4 they are now available in :mod:`django.conf.urls`.
|
|
|
|
``django.contrib.databrowse``
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Databrowse has not seen active development for some time, and this does not
|
|
show any sign of changing. There had been a suggestion for a GSOC project to
|
|
integrate the functionality of databrowse into the admin, but no progress was
|
|
made. While Databrowse has been deprecated, an enhancement of
|
|
django.contrib.admin providing a similar feature set is still possible.
|
|
|
|
.. _GSOC Proposal: https://code.djangoproject.com/wiki/SummerOfCode2011#Integratedatabrowseintotheadmin
|
|
|
|
The code that powers Databrowse is licensed under the same terms as Django
|
|
itself, and so is available to be adopted by an individual or group as
|
|
a third-party project.
|
|
|