Plain Text | 233 lines | 175 code | 58 blank | 0 comment | 0 complexity | b20a88c5d84a1e3abc53ba6296aa0db8 MD5 | raw file
Possible License(s): BSD-3-Clause
- 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`
- 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
- 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>` 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
- * :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`
- .. _r12634: http://code.djangoproject.com/changeset/12634
- Changes to ``USStateField``
- The :mod:`django.contrib.localflavor` application contains collections
- of code relevant to specific countries or cultures. One such is
- :class:`~django.contrib.localflavor.us.models.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,
- :class:`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, :class:`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 :mod:`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
- 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:
- * http://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
- * :doc:`How to contribute to Django </internals/contributing>`
- Contributions on any level -- developing code, writing documentation or simply
- triaging tickets and helping to test proposed bugfixes -- are always welcome and