Changes between Version 265 and Version 266 of BackwardsIncompatibleChanges
- Timestamp:
- Sep 24, 2008, 6:48:57 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
BackwardsIncompatibleChanges
v265 v266 96 96 }}} 97 97 should be modified to read: 98 99 98 100 99 101 … … 369 371 == Auto-escaping in templates == 370 372 371 In [6671] a long-awaited feature was committed to make default HTML template usage a bit safe from some forms of cross-site scripting attacks. For full details, read the [http:// www.djangoproject.com/documentation/templates/#automatic-html-escaping template author documentation] and the [http://www.djangoproject.com/documentation/templates_python/#filters-and-auto-escaping template filter documentation].373 In [6671] a long-awaited feature was committed to make default HTML template usage a bit safe from some forms of cross-site scripting attacks. For full details, read the [http://docs.djangoproject.com/en/dev/topics/templates/#automatic-html-escaping template author documentation] and the [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#filters-and-auto-escaping template filter documentation]. 372 374 373 375 Automatic HTML escaping (henceforth ''auto-escaping'') affects any variables in templates. It is only applied to variables and not to template tags. … … 409 411 }}} 410 412 411 The second and probably more robust way is to use {{{mark_safe()}}} where appropriate (see [http:// www.djangoproject.com/documentation/templates_python/#filters-and-auto-escaping the documentation] for details) and go through each of your custom filters attaching {{{is_safe}}} and {{{needs_autoescape}}} attributes where necessary (again, the details are in the above documentation).413 The second and probably more robust way is to use {{{mark_safe()}}} where appropriate (see [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#filters-and-auto-escaping the documentation] for details) and go through each of your custom filters attaching {{{is_safe}}} and {{{needs_autoescape}}} attributes where necessary (again, the details are in the above documentation). 412 414 413 Have a look at Django's default filters (in {{{django/template/defaultfilters.py}}}) for examples of how mixed filters (those which behave differently depending upon whether auto-escaping is in effect o r not) can be written.415 Have a look at Django's default filters (in {{{django/template/defaultfilters.py}}}) for examples of how mixed filters (those which behave differently depending upon whether auto-escaping is in effect o/r not) can be written. 414 416 415 417 The attributes on filter functions and the new {{{escape}}} behaviour mean that you can write templates and filters that will operate correctly in both auto-escaping and non-auto-escaping environments, so you're not forcing your decision onto users of your filters, if you distribute the code. … … 501 503 == Raise errors if extends is not the first tag of a template == 502 504 503 In [7082] we removed the possibility of putting extends below other tags (in [7089]). You may still put it below comment tags or whitespace. Otherwise it will raise a !TemplateSyntaxError. This is not technically a backward incompatible change because documentation has always specified that [http:// www.djangoproject.com/documentation/templates/#template-inheritance extends tags should be placed first in your templates], but it may break your code if you haven't followed those instructions.505 In [7082] we removed the possibility of putting extends below other tags (in [7089]). You may still put it below comment tags or whitespace. Otherwise it will raise a !TemplateSyntaxError. This is not technically a backward incompatible change because documentation has always specified that [http://docs.djangoproject.com/en/dev/topics/templates/#template-inheritance extends tags should be placed first in your templates], but it may break your code if you haven't followed those instructions. 504 506 505 507 == Change es_AR to es-ar in LANGUAGES == … … 564 566 [7814] introduced changes to the way Django handles uploaded files. Most of the changes are in the form of added flexibility and performance (for details, see the [http://www.djangoproject.com/documentation/upload_handing/ upload handling documentation]). 565 567 566 However, as part of the change, the representation of uploaded files has changed. Previous, uploaded files -- that is, entries in {{{request.FILES}}} -- were represented by simple dictionaries with a few well-known keys. Uploaded files are now represented by an [http:// www.djangoproject.com/documentation/upload_handling/#uploaded-file-objects UploadedFile object], and thus the file's information is accessible through object attributes. Thus, given {{{f = request.FILES['some_field_name']}}}:568 However, as part of the change, the representation of uploaded files has changed. Previous, uploaded files -- that is, entries in {{{request.FILES}}} -- were represented by simple dictionaries with a few well-known keys. Uploaded files are now represented by an [http://docs.djangoproject.com/en/dev/topics/http/file-uploads/#uploadedfile-objects UploadedFile object], and thus the file's information is accessible through object attributes. Thus, given {{{f = request.FILES['some_field_name']}}}: 567 569 568 570 || '''Deprecated''' || '''Replacement''' || … … 832 834 }}} 833 835 834 Before you would define an {{{edit_inline}}} database field option and give it the value of the type of inline you wanted, either {{{models.TABULAR}}} or {{{models.STACKED}}}. This is now done with classes and gives you much more flexibility over the options of a specific inline. See [http:// www.djangoproject.com/documentation/admin/#inlinemodeladmin-objects the inlines documentation] to learn more.836 Before you would define an {{{edit_inline}}} database field option and give it the value of the type of inline you wanted, either {{{models.TABULAR}}} or {{{models.STACKED}}}. This is now done with classes and gives you much more flexibility over the options of a specific inline. See [http://docs.djangoproject.com/en/dev/ref/contrib/admin/#inlinemodeladmin-objects the inlines documentation] to learn more. 835 837 836 838 === Refactored inner Admin ```js``` option to media definitions === … … 883 885 class Media: 884 886 js = ( 887 885 888 settings.ADMIN_MEDIA_PREFIX + "some_file.js", 886 889 ) … … 1169 1172 For MySQL users only: Due to a number of unintended side-effects and after carefully considering the alternatives, the changes from [7798] were reverted in [8319]. Thus, `__exact` filters in MySQL now use the database table's native collation setting to determine whether the match is case-sensitive or case-insensitive. 1170 1173 1171 [http:// www.djangoproject.com/documentation/db-api/#exact The documentation] for `exact` has been updated to indicate how to control this behaviour.1174 [http://docs.djangoproject.com/en/dev/ref/models/querysets/#exact The documentation] for `exact` has been updated to indicate how to control this behaviour. 1172 1175 1173 1176 == Added parameter to session backend save() method ==