mirror of
https://github.com/django/django.git
synced 2024-11-18 23:44:22 +00:00
233 lines
9.8 KiB
Plaintext
233 lines
9.8 KiB
Plaintext
================================
|
|
Django 1.3 beta 1 release notes
|
|
================================
|
|
|
|
Welcome to Django 1.3 beta 1!
|
|
|
|
This is the second in a series of preview/development releases leading
|
|
up to the eventual release of Django 1.3. This release is primarily
|
|
targeted at developers who are interested in trying out new features
|
|
and testing the Django codebase to help identify and resolve bugs
|
|
prior to the final 1.3 release.
|
|
|
|
As such, this release is *not* intended for production use, and any such use
|
|
is discouraged.
|
|
|
|
What's new in Django 1.3 beta 1
|
|
===============================
|
|
|
|
Further tweaks to the staticfiles app
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
Django 1.3 ships with a new contrib app :mod:`django.contrib.staticfiles`
|
|
to help developers handle the static media files (images, CSS, JavaScript,
|
|
etc.) that are needed to render a complete web page.
|
|
|
|
The :mod:`~django.contrib.staticfiles` app ships with the ability to
|
|
automatically serve static files during development (if the :setting:`DEBUG`
|
|
setting is ``True``) when using the :djadmin:`runserver` management command.
|
|
Based on feedback from the community this release adds two new options to the
|
|
:djadmin:`runserver` command to modify this behavior:
|
|
|
|
* ``--nostatic``: prevents the :djadmin:`runserver` command from serving
|
|
files completely.
|
|
|
|
* ``--insecure``: enables serving of static files even if running with
|
|
:setting:`DEBUG` set to False. (This is **not** recommended!)
|
|
|
|
See the :doc:`staticfiles reference documentation </ref/contrib/staticfiles>`
|
|
for more details, or learn :doc:`how to manage static files
|
|
</howto/static-files/index>`.
|
|
|
|
Translation comments
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If you would like to give translators hints about a translatable string, you
|
|
can add a comment prefixed with the ``Translators`` keyword on the line
|
|
preceding the string, e.g.::
|
|
|
|
def my_view(request):
|
|
# Translators: This message appears on the home page only
|
|
output = ugettext("Welcome to my site.")
|
|
|
|
The comment will appear in the resulting .po file and should also be
|
|
displayed by most translation tools.
|
|
|
|
For more information, see :ref:`translator-comments`.
|
|
|
|
Permissions for inactive users
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
If you provide a custom auth backend with ``supports_inactive_user`` set to
|
|
``True``, an inactive user model will check the backend for permissions.
|
|
This is useful for further centralizing the permission handling. See the
|
|
:doc:`authentication docs </topics/auth/index>` for more details.
|
|
|
|
Backwards-incompatible changes in 1.3 alpha 2
|
|
=============================================
|
|
|
|
Change to admin lookup filters
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The Django admin has long had an undocumented "feature" allowing savvy
|
|
users to manipulate the query string of changelist pages to filter the
|
|
list of objects displayed. However, this also creates a security
|
|
issue, as a staff user with sufficient knowledge of model structure
|
|
could use this "feature" to gain access to information he or she would
|
|
not normally have.
|
|
|
|
As a result, changelist filtering now explicitly validates all lookup
|
|
arguments in the query string, and permits only fields which are
|
|
directly on the model, or relations explicitly permitted by the
|
|
``ModelAdmin`` definition. If you were relying on this undocumented
|
|
feature, you will need to update your ``ModelAdmin`` definitions to
|
|
whitelist the relations you choose to expose for filtering.
|
|
|
|
Introduction of STATIC_URL and STATIC_ROOT settings
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The newly introduced :mod:`~django.contrib.staticfiles` app -- which extends
|
|
Django's abilities to handle static files for apps and projects -- required the
|
|
additon of two new settings to refer to those files in templates and code,
|
|
especially in contrast to the :setting:`MEDIA_URL` and :setting:`MEDIA_ROOT`
|
|
settings that refer to user-uploaded files.
|
|
|
|
Prior to 1.3 alpha 2 these settings were called ``STATICFILES_URL`` and
|
|
``STATICFILES_ROOT`` to follow the naming scheme for app-centric settings.
|
|
Based on feedback from the community it became apparent that those settings
|
|
created confusion, especially given the fact that handling static files is also
|
|
desired outside the use of the optional :mod:`~django.contrib.staticfiles` app.
|
|
|
|
As a result, we took the following steps to rectify the issue:
|
|
|
|
* Two new global settings were added that will be used by, **but are not
|
|
limited to**, the :doc:`staticfiles</ref/contrib/staticfiles>` app:
|
|
|
|
* :setting:`STATIC_ROOT` (formally ``STATICFILES_ROOT``)
|
|
|
|
* :setting:`STATIC_URL` (formally ``STATICFILES_URL``)
|
|
|
|
* The ``django.contrib.staticfiles.templatetags.staticfiles.get_staticfiles_prefix``
|
|
template tag was moved to Django's core (``django.templatetags.static``) and
|
|
renamed to :ttag:`get_static_prefix`.
|
|
|
|
* The ``django.contrib.staticfiles.context_processors.staticfiles``
|
|
context processor was moved to Django's core
|
|
(``django.core.context_processors.static``) and renamed to
|
|
:func:`~django.core.context_processors.static`.
|
|
|
|
* :ref:`form-media-paths` now uses :setting:`STATIC_URL` as the prefix
|
|
**if the value is not None**, and falls back to the previously used
|
|
:setting:`MEDIA_URL` setting otherwise.
|
|
|
|
Changes to the login methods of the admin
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
In previous version the admin app defined login methods in multiple locations
|
|
and ignored the almost identical implementation in the already used auth app.
|
|
A side effect of this duplication was the missing adoption of the changes made
|
|
in r12634_ to support a broader set of characters for usernames.
|
|
|
|
This release refactors the admin's login mechanism to use a subclass of the
|
|
:class:`~django.contrib.auth.forms.AuthenticationForm` instead of a manual
|
|
form validation. The previously undocumented method
|
|
``'django.contrib.admin.sites.AdminSite.display_login_form'`` has been removed
|
|
in favor of a new :attr:`~django.contrib.admin.AdminSite.login_form`
|
|
attribute.
|
|
|
|
.. _r12634: https://code.djangoproject.com/changeset/12634
|
|
|
|
Changes to ``USStateField``
|
|
===========================
|
|
|
|
The ``django.contrib.localflavor`` application contains collections
|
|
of code relevant to specific countries or cultures. One such is
|
|
``USStateField``, which provides a field for storing the two-letter postal
|
|
abbreviation of a U.S. state. This field has consistently caused problems,
|
|
however, because it is often used to store the state portion of a U.S postal
|
|
address, but not all "states" recognized by the U.S Postal Service are
|
|
actually states of the U.S. or even U.S. territory. Several
|
|
compromises over the list of choices resulted in some users feeling
|
|
the field supported too many locations, while others felt it supported
|
|
too few.
|
|
|
|
In Django 1.3 we're taking a new approach to this problem, implemented
|
|
as a pair of changes:
|
|
|
|
* The choice list for ``USStateField`` has changed. Previously, it
|
|
consisted of the 50 U.S. states, the District of Columbia and
|
|
U.S. overseas territories. As of Django 1.3 it includes all previous
|
|
choices, plus the U.S. Armed Forces postal codes.
|
|
|
|
* A new model field,
|
|
``django.contrib.localflavor.us.models.USPostalCodeField``, has
|
|
been added which draws its choices from a list of all postal
|
|
abbreviations recognized by the U.S Postal Service. This includes
|
|
all abbreviations recognized by ``USStateField``, plus three
|
|
independent nations -- the Federated States of Micronesia, the
|
|
Republic of the Marshall Islands and the Republic of Palau -- which
|
|
are serviced under treaty by the U.S. postal system. A new form
|
|
widget, ``django.contrib.localflavor.us.forms.USPSSelect``, is
|
|
also available and provides the same set of choices.
|
|
|
|
Additionally, several finer-grained choice tuples are provided which
|
|
allow mixing and matching of subsets of the U.S. states and
|
|
territories, and other locations serviced by the U.S. postal
|
|
system. Consult the ``django.contrib.localflavor`` documentation
|
|
for more details.
|
|
|
|
The change to ``USStateField`` is technically backwards-incompatible for
|
|
users who expect this field to exclude Armed Forces locations. If you
|
|
need to support U.S. mailing addresses without Armed Forces locations,
|
|
see the list of choice tuples available in the localflavor
|
|
documentation.
|
|
|
|
The Django 1.3 roadmap
|
|
======================
|
|
|
|
Before the final Django 1.3 release, several other preview/development
|
|
releases will be made available. The current schedule consists of at
|
|
least the following:
|
|
|
|
* Week of **January 24, 2011**: First Django 1.3 release
|
|
candidate. String freeze for translations.
|
|
|
|
* Week of **January 31, 2011**: Django 1.3 final release.
|
|
|
|
If necessary, additional beta or release-candidate packages
|
|
will be issued prior to the final 1.3 release. Django 1.3 will be
|
|
released approximately one week after the final release candidate.
|
|
|
|
|
|
What you can do to help
|
|
=======================
|
|
|
|
In order to provide a high-quality 1.3 release, we need your help. Although this
|
|
beta release is, again, *not* intended for production use, you can help the
|
|
Django team by trying out the beta codebase in a safe test environment and
|
|
reporting any bugs or issues you encounter. The Django ticket tracker is the
|
|
central place to search for open issues:
|
|
|
|
* https://code.djangoproject.com/timeline
|
|
|
|
Please open new tickets if no existing ticket corresponds to a problem you're
|
|
running into.
|
|
|
|
Additionally, discussion of Django development, including progress toward the
|
|
1.3 release, takes place daily on the django-developers mailing list:
|
|
|
|
* http://groups.google.com/group/django-developers
|
|
|
|
... and in the ``#django-dev`` IRC channel on ``irc.freenode.net``. If you're
|
|
interested in helping out with Django's development, feel free to join the
|
|
discussions there.
|
|
|
|
Django's online documentation also includes pointers on how to contribute to
|
|
Django:
|
|
|
|
* :doc:`How to contribute to Django </internals/contributing/index>`
|
|
|
|
Contributions on any level -- developing code, writing documentation or simply
|
|
triaging tickets and helping to test proposed bugfixes -- are always welcome and
|
|
appreciated.
|