Django 1.4リリースノート—Djangoドキュメント

Django1.4リリースノート

2012年3月23日

Django 1.4へようこそ！

これらのリリースノートには、の新機能と、Django1.3以前のバージョンからアップグレードするときに注意が必要な後方互換性のない変更が含まれています。 また、非推奨プランで詳しく説明されているいくつかの機能を削除し、いくつかの機能の非推奨プロセスを開始しました。

概要

Django 1.4の最大の新機能は、日付/時刻を処理する際のタイムゾーンのサポートです。 有効にすると、このDjangoは日付/時刻をUTCで保存し、タイムゾーン対応オブジェクトを内部で使用し、それらをユーザーのローカルタイムゾーンに変換して表示します。

既存のプロジェクトをDjango1.4にアップグレードする場合は、タイムゾーン対応モードに切り替えると注意が必要になる場合があります。新しいモードでは、以前は受け入れられていたかなりずさんな動作が許可されません。 アップグレードする場合は、タイムゾーン移行ガイドおよびタイムゾーンFAQ で役立つヒントを確認することをお勧めします。

Django1.4のその他の注目すべき新機能は次のとおりです。

• SELECT FOR UPDATEサポート、パフォーマンスを向上させるための一括挿入大規模データセットの機能、 QuerySet.prefetch_related 、バッチ処理方法など、多くのORMの改善- select_related（）が機能しない領域に関連オブジェクトをロードします。
• 改善されたパスワードハッシュ（ PBKDF2 および bcrypt サポートを備えています）、暗号署名用の新しいツール、いくつかの[X186X ] CSRFの改善、および単純なクリックジャッキング保護。
• 更新されたデフォルトのプロジェクトレイアウトとmanage.py は、以前のバージョンから「魔法」を削除します。 また、新しいレイアウトが気に入らない場合は、代わりにカスタムプロジェクトとアプリテンプレートを使用できます。
• ブラウザー内テストフレームワークのサポート（ Selenium など）。
• …そしてもっとたくさん。 以下を参照！

可能な限り、 API安定性ポリシーポリシーに従って下位互換性のある方法で新機能を導入しようとしています。 ただし、以前のリリースと同様に、Django1.4にはいくつかのマイナーな後方互換性のない変更が付属しています。 以前のバージョンのDjangoからアップグレードする人は、そのリストを注意深く読む必要があります。

Pythonの互換性

Django1.4はPython2.4のサポートを終了しました。 Python 2.5は、最低限必要なPythonバージョンになりました。 Djangoは、Python 2.5、2.6、2.7でテストおよびサポートされています。

今日のほとんどのオペレーティングシステムベンダーはデフォルトバージョンとしてPython2.5以降を出荷しているため、この変更は少数のDjangoユーザーにのみ影響するはずです。 ただし、Python 2.4をまだ使用している場合は、アップグレードできるようになるまでDjango1.3に固執する必要があります。 サポートポリシーに従い、Django1.3はDjango1.5がリリースされるまでセキュリティサポートを受け続けます。

現時点では、DjangoはPython3.xをサポートしていません。 Django 1.4のリリース前のある時点で、Python2.xの非推奨とPython3.xへの移行の完全なタイムラインを概説したドキュメントを公開する予定です。

Django1.4の新機能

タイムゾーンのサポート

以前のバージョンでは、Djangoは「ナイーブ」な日付/時刻（つまり、関連付けられたタイムゾーンのない日付/時刻）を使用し、特定の日付/時刻が「実際に意味する」ことを解釈するのは各開発者に任されていました。 これにより、あらゆる種類の微妙なタイムゾーン関連のバグが発生する可能性があります。

Django 1.4では、Djangoをより正確なタイムゾーン対応モードに切り替えることができるようになりました。 このモードでは、Djangoは日付と時刻の情報をUTCでデータベースに保存し、タイムゾーン対応の日時オブジェクトを内部で使用して、テンプレートとフォームでエンドユーザーのタイムゾーンに変換します。 この機能を使用する理由は次のとおりです。

• 世界中のユーザー向けに日付と時刻の表示をカスタマイズします。
• データベースの移植性と相互運用性のためにUTCで日時を保存します。 （この引数はPostgreSQLには適用されません。これは、タイムゾーン情報を含むタイムスタンプがDjango 1.3にすでに格納されているためです。）
• DST移行に関するデータ破損の問題を回避します。

：djadmin： `startproject` で作成された新しいプロジェクトでは、タイムゾーンのサポートがデフォルトで有効になっています。 この機能を既存のプロジェクトで使用する場合は、移行ガイドをお読みください。 問題が発生した場合は、役立つ FAQ があります。

ブラウザ内テストフレームワークのサポート

Django 1.4は、 Selenium などのブラウザー内テストフレームワークとの統合をサポートしています。 新しい django.test.LiveServerTestCase 基本クラスを使用すると、サイトのフロントエンドとバックエンド間の相互作用をより包括的にテストできます。 詳細と具体例については、ドキュメントを参照してください。

デフォルトのプロジェクトレイアウトとmanage.pyを更新しました

Django 1.4には、：djadmin： `startproject` 管理コマンド用に更新されたデフォルトのプロジェクトレイアウトとmanage.pyファイルが付属しています。 これらは、二重インポートの原因となったPythonインポートパスの以前のmanage.py処理に関するいくつかの問題、開発からデプロイメントへの移行の問題、およびその他のデバッグが難しいパスの問題を修正します。

以前のmanage.pyは現在非推奨の関数を呼び出していたため、Django 1.4にアップグレードするプロジェクトでは、manage.pyを更新する必要があります。 （古いスタイルのmanage.pyは、Django1.6まで以前と同じように機能し続けます。 1.5では、DeprecationWarning）が発生します。

新しく推奨されるmanage.pyファイルは次のようになります。

#!/usr/bin/env python
import os, sys

if __name__ == "__main__":
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")

    from django.core.management import execute_from_command_line

    execute_from_command_line(sys.argv)

テンプレート:Project nameは、実際のプロジェクトのPythonパッケージ名に置き換える必要があります。

プロジェクト内の設定、URLconf、およびアプリがインポートされるか、プロジェクト名のプレフィックスを使用して参照される場合（例： myproject.settings、ROOT_URLCONF = "myproject.urls"など）、新しいmanage.pyは1つ上のディレクトリに移動する必要があるため、 [に隣接するのではなく、プロジェクトパッケージの外部にあります。 X152X]およびurls.py。

たとえば、次のレイアウトでは次のようになります。

manage.py
mysite/
    __init__.py
    settings.py
    urls.py
    myapp/
        __init__.py
        models.py

mysite.settings、mysite.urls、およびmysite.myappはインポートできますが、settings、urls、またはmyappをトップとしてインポートすることはできません。 -レベルのモジュール。

トップレベルモジュールとしてインポートされたものはすべて、新しいmanage.pyに隣接して配置できます。 たとえば、「myapp」をプロジェクトモジュールから切り離して、myappとしてインポートするには、mysite/ディレクトリの外に配置します。

manage.py
myapp/
    __init__.py
    models.py
mysite/
    __init__.py
    settings.py
    urls.py

同じコードのインポートに一貫性がない場合（プロジェクトプレフィックスのある場所とない場所）、新しいmanage.pyに切り替えるときにインポートをクリーンアップする必要があります。

カスタムプロジェクトとアプリのテンプレート

：djadmin： `startapp` および：djadmin：` startproject` 管理コマンドに、カスタムアプリまたはプロジェクトへのパスまたはURLを指定するための--templateオプションが追加されました。レンプレート。

たとえば、次のコマンドを実行すると、Djangoは/path/to/my_project_templateディレクトリを使用します。

django-admin.py startproject --template=/path/to/my_project_template myproject

：djadmin： `startapp` と：djadmin：` startproject` の両方の2番目の引数として宛先ディレクトリを指定できるようになりました：

django-admin.py startapp myapp /path/to/new/app
django-admin.py startproject myproject /path/to/new/project

詳細については、：djadmin： `startapp` および：djadmin：` startproject` のドキュメントを参照してください。

改善されたWSGIサポート

：djadmin： `startproject` 管理コマンドは、wsgi.pyモジュールを初期プロジェクトレイアウトに追加します。このモジュールには WSGIアプリサーバーでのデプロイに使用できる単純なWSGIアプリケーションが含まれています[ X208X]。

NS ：djadmin： `組み込みの開発サーバー ` 外部で定義されたWSGI呼び出し可能オブジェクトの使用をサポートするようになりました。これにより、実行が可能になります。runserver 展開に使用されるのと同じWSGI構成を使用します。 新しい：setting： `WSGI_APPLICATION` 設定では、どのWSGI呼び出し可能：djadmin：` runserver` が使用するかを構成できます。

（runfcgi管理コマンドは、：setting： `WSGI_APPLICATION` を介して構成されたWSGI呼び出し可能オブジェクトも内部的にラップします。）

SELECT FOR UPDATEのサポート

Django 1.4には、SELECT ... FOR UPDATE SQLクエリを生成する QuerySet.select_for_update（）メソッドが含まれています。 これにより、トランザクションが終了するまで行がロックされます。つまり、他のトランザクションは、FOR UPDATEクエリに一致する行を変更または削除できません。

詳細については、 select_for_update（）のドキュメントを参照してください。

ORMのModel.objects.bulk_create

このメソッドを使用すると、複数のオブジェクトをより効率的に作成できます。 多くのオブジェクトがある場合、パフォーマンスが大幅に向上する可能性があります。

Djangoはこれを内部的に利用します。つまり、一部の操作（テストスイートのデータベースセットアップなど）では、結果としてパフォーマンスが向上します。

詳細については、 bullk_create（）のドキュメントを参照してください。

QuerySet.prefetch_related

select_related（）と似ていますが、戦略が異なり、スコープが広いため、 prefetch_related（）が QuerySet に追加されました。 このメソッドは、クエリの評価が開始されるとすぐに、指定された関連ルックアップのそれぞれを単一のバッチでプリフェッチする新しいQuerySetを返します。 select_relatedとは異なり、データベースではなくPythonで結合を行い、多対多の関係、GenericForeignKeyなどをサポートします。 これにより、プライマリQuerySetのオブジェクトにそれぞれフェッチする必要のある関連オブジェクトが多数ある場合に、コードがO（n）データベースクエリを実行する（またはさらに悪い）という非常に一般的なパフォーマンスの問題を修正できます。

パスワードハッシュの改善

Djangoの認証システム（django.contrib.auth）は、一方向のアルゴリズムを使用してパスワードを保存します。 Django1.3は SHA1 アルゴリズムを使用しますが、プロセッサ速度の向上と理論上の攻撃により、SHA1は私たちが望むほど安全ではないことが明らかになりました。 したがって、Django 1.4では新しいパスワードストレージシステムが導入されています。デフォルトでは、Djangoは PBKDF2 アルゴリズムを使用するようになりました（ NIST で推奨）。 別のアルゴリズム（一般的な bcrypt アルゴリズムを含む）を簡単に選択することもできます。 詳細については、 Djangoがパスワードを保存する方法を参照してください。

HTML5 doctype

管理者とその他のバンドルされたテンプレートを、HTML5Doctypeを使用するように切り替えました。 Djangoは古いブラウザとの互換性を維持するように注意しますが、この変更により、HTMLの有効性を失ったり、提供されたテンプレートをオーバーライドしてDoctypeを変更したりすることなく、管理ページで必要なHTML5機能を使用できるようになります。

管理インターフェースにフィルターをリストする

Django 1.4より前のバージョンでは、 admin アプリでは、フィールドルックアップを指定して変更リストフィルターを指定できましたが、カスタムフィルターを作成することはできませんでした。 これは、単純なAPI（以前は内部で使用され、「FilterSpec」と呼ばれていました）で修正されました。 詳細については、 list_filter のドキュメントを参照してください。

管理インターフェースでの複数の並べ替え

管理者変更リストは、複数の列での並べ替えをサポートするようになりました。 ordering 属性のすべての要素を尊重し、ヘッダーをクリックして複数の列を並べ替えるのは、デスクトップGUIの動作を模倣するように設計されています。 また、順序を動的に（つまり、要求に応じて）指定するための get_ordering（）メソッドを追加しました。

新しいModelAdminメソッド

save_related（）メソッドを ModelAdmin に追加して、関連オブジェクトを管理者に保存する方法を簡単にカスタマイズできるようにしました。

他の2つの新しい ModelAdmin メソッド、 get_list_display（）および get_list_display_links（）は、管理者変更リストに表示されるフィールドとリンクの動的なカスタマイズを可能にします。

管理者インラインはユーザー権限を尊重します

管理インラインは、ユーザーが権限を持っているアクションのみを許可するようになりました。 自動作成された中間モデル（独自の権限を持たない）とのManyToMany関係の場合、関連モデルの変更権限は、ユーザーが関係を追加、変更、または削除する権限を持っているかどうかを決定します。

暗号署名用のツール

Django 1.4は、値に署名するための低レベルAPIと、署名されたCookieを設定および読み取るための高レベルAPIの両方を追加します。これは、Webアプリケーションでの署名の最も一般的な使用法の1つです。

詳細については、暗号署名のドキュメントを参照してください。

Cookieベースのセッションバックエンド

Django 1.4では、暗号署名のツールを使用してセッションデータをクライアントのブラウザに保存するCookieベースのセッションバックエンドが導入されています。

警告

セッションデータはサーバーによって署名および検証されますが、暗号化されていません。 つまり、ユーザーはセッションに保存されているすべてのデータを表示できますが、変更することはできません。 このバックエンドを使用する前に、詳細についてドキュメントをお読みください。

詳細については、 Cookieベースのセッションバックエンドのドキュメントを参照してください。

新しいフォームウィザード

django.contrib.formtoolsの以前のFormWizardは、Django1.3で導入されたクラスベースのビューに基づく新しい実装に置き換えられました。 プラグ可能なストレージAPIを備えており、ウィザードが前のすべてのステップで非表示フィールドを渡す必要はありません。

Django 1.4には、セッションベースのストレージバックエンドとCookieベースのストレージバックエンドが付属しています。 後者は、Django1.4でも導入された暗号署名のツールを使用して、ウィザードの状態をユーザーのCookieに保存します。

reverse_lazy

プロジェクトのURLconfがロードされる前にURL反転を使用できるように、遅延評価バージョンのreverse()が追加されました。

URLパターンの翻訳

Djangoは、新しい i18n_patterns（）ヘルパー関数を使用するときに、URLpatternで言語プレフィックスを検索できるようになりました。 django.utils.translation.ugettext_lazy()を使用して翻訳可能なURLパターンを定義することも可能になりました。 言語プレフィックスとURLパターンを国際化する方法の詳細については、国際化：URLパターンを参照してください。

{% trans %}および{% blocktrans %}のコンテキスト翻訳のサポート

pgettext関数を介してDjango1.3で導入されたコンテキスト変換のサポートは、：ttag： `trans` および：ttag：` blocktrans`に拡張されました。新しいcontextキーワードを使用したテンプレートタグ。

カスタマイズ可能なSingleObjectMixin URLConf kwargs

pk_url_kwarg と slug_url_kwarg の2つの新しい属性が、 SingleObjectMixin に追加され、単一オブジェクトの汎用ビューに使用されるURLconfキーワード引数をカスタマイズできるようになりました。

割り当てテンプレートタグ

新しいassignment_tagヘルパー関数がtemplate.Libraryに追加され、指定されたコンテキスト変数にデータを格納するテンプレートタグの作成が容易になりました。

テンプレートタグヘルパー関数の*argsおよび**kwargsサポート

simple_tag 、 include_tag 、および新しく導入されたassignment_tagテンプレートヘルパー関数は、任意の数の位置引数またはキーワード引数を受け入れることができるようになりました。 例えば：

@register.simple_tag
def my_tag(a, b, *args, **kwargs):
    warning = kwargs['warning']
    profile = kwargs['profile']
    ...
    return ...

次に、テンプレートで、任意の数の引数をテンプレートタグに渡すことができます。 例えば：

{% my_tag 123 "abcd" book.title warning=message|lower profile=user.profile %}

TEMPLATE_DEBUGモードでは例外のラッピングはありません

以前のバージョンのDjangoでは、TEMPLATE_DEBUG設定がTrueの場合は常に、テンプレートのレンダリング中に発生した例外（テンプレート構文に関係のない例外も含む）がTemplateSyntaxErrorでラップされ、再発生しました。 。 これは、デバッグ500ページで詳細なテンプレートソースの場所情報を提供するために行われました。

Django 1.4では、例外はラップされなくなりました。 代わりに、元の例外にソース情報の注釈が付けられます。 つまり、テンプレートレンダリングからの例外のキャッチは、TEMPLATE_DEBUGの値に関係なく一貫しており、他のエラーをキャッチするためにTemplateSyntaxErrorをキャッチしてアンラップする必要はありません。

truncatecharsテンプレートフィルター

この新しいフィルターは、指定された文字数を超えないように文字列を切り捨てます。 切り捨てられた文字列は、翻訳可能な省略記号シーケンス（ "…"）で終わります。 詳細については、：tfilter： `truncatechars` のドキュメントを参照してください。

staticテンプレートタグ

staticfiles contribアプリには、：setting： `STATICFILES_STORAGE` ストレージバックエンドで保存されたファイルを参照するための新しいstaticテンプレートタグがあります。 ストレージバックエンドのurlメソッドを使用するため、クラウドサービスからのファイルの提供などの高度な機能をサポートします。

CachedStaticFilesStorageストレージバックエンド

staticfiles contribアプリには、MD5ハッシュを追加することで、保存したファイルをキャッシュするdjango.contrib.staticfiles.storage.CachedStaticFilesStorageバックエンドが追加されました（：djadmin： `collectstatic` 管理コマンドを実行する場合）。ファイルの内容をファイル名に変換します。 たとえば、ファイルcss/styles.cssもcss/styles.55e7cbb9ba48.cssとして保存されます。

シンプルなクリックジャッキング保護

X-Frame-Optionsヘッダーを使用して、クリックジャッキングから簡単に保護するミドルウェアを追加しました。 下位互換性の理由からデフォルトでは有効になっていませんが、ヘッダーをサポートするブラウザーのセキュリティホールを埋めるために、ほぼ確実に有効にする必要があります。

CSRFの改善

CSRF機能にさまざまな改善を加えました。 ensure_csrf_cookie（）デコレータは、AJAXを多用するサイトに役立ちます。 PUTおよびDELETE要求の保護。 ：setting： `CSRF_COOKIE_SECURE` および：setting：` CSRF_COOKIE_PATH` 設定。これにより、CSRF保護のセキュリティと有用性を向上させることができます。 詳細については、 CSRFドキュメントを参照してください。

エラーレポートのフィルタリング

2つの関数デコレータ sensitive_variables（）と sensitive_post_parameters（）を追加して、機密情報を含む可能性があり、エラーレポートから除外する必要があるローカル変数とPOSTパラメータを指定できるようにしました。

すべてのPOSTパラメーターは、 django.contribの特定のビュー（login、password_reset_confirm、password_change、add_view）のエラーレポートから体系的に除外されるようになりました。 auth.views 、および管理アプリのuser_change_password）は、ユーザーパスワードなどの機密情報の漏洩を防ぎます。

カスタムフィルターを作成することにより、デフォルトのフィルタリングをオーバーライドまたはカスタマイズできます。 詳細については、エラーレポートのフィルタリングに関するドキュメントを参照してください。

拡張IPv6サポート

Django 1.4は、新しい GenericIPAddressField モデルフィールド、 GenericIPAddressField フォームフィールド、およびバリデーター validate_ipv46_address と validate_ipv6_address を使用してIPv6アドレスをより適切に処理できるようになりました。

テストでのHTML比較

django.test の基本クラスには、空白、引数の引用/順序付け、および自己終了タグの終了の無関係な違いにつまずくことなくHTMLを比較するためのヘルパーがいくつか含まれるようになりました。 HTMLを新しい assertHTMLEqual（）および assertHTMLNotEqual（）アサーションと直接比較するか、html=Trueフラグを assertContains（）で使用できます。 assertNotContains（）を使用して、クライアントの応答に特定のHTMLフラグメントが含まれているかどうかをテストします。 詳細については、アサーションドキュメントを参照してください。

2つの新しい日付形式の文字列

2つの新しい：tfilter： `date` 形式が、テンプレートフィルター、テンプレートタグ、および形式のローカリゼーションで使用するために追加されました。

• e –指定された日時オブジェクトのタイムゾーンの名前
• o –ISO8601年番号

フォーマット文字列にeまたはoが含まれている場合は、必ずカスタムフォーマットファイルを更新してください。 たとえば、スペイン語のローカリゼーション形式は、以前はd形式の文字のみをエスケープしていました。

DATE_FORMAT = r'j \de F \de Y'

ただし、eとoもエスケープする必要があります。

DATE_FORMAT = r'j \d\e F \d\e Y'

詳細については、：tfilter： `date` のドキュメントを参照してください。

マイナーな機能

Django 1.4には、注目に値するいくつかの小さな改善点も含まれています。

• テクニカル500ページでより使いやすいスタックトレース。 Djangoのフレームワークコードを参照するスタックトレースのフレームは淡色表示になり、アプリケーションコードのフレームはわずかに強調されます。 この変更により、アプリケーションコードの問題についてスタックトレースをスキャンしやすくなります。
• PostgreSQLでのテーブルスペースのサポート。
• simple_tag（）のカスタマイズ可能な名前。
• ドキュメントには、役立つセキュリティの概要ページがあります。
• django.contrib.auth.models.check_password関数は django.contrib.auth.hashers モジュールに移動されました。 古い場所からのインポートは引き続き機能しますが、インポートを更新する必要があります。
• ：djadmin： `collectstatic` 管理コマンドに、静的ファイルをコピーまたはリンクする前に、宛先にあるすべてのファイルを削除する--clearオプションが追加されました。
• InnoDBデータベースエンジンでMySQLを使用するときに、前方参照を含むフィクスチャをロードできるようになりました。
• 新しい403応答ハンドラーが'django.views.defaults.permission_denied'として追加されました。 django.conf.urls.handler403 の値を設定することで、独自のハンドラーを設定できます。 詳細については、 403（HTTP Forbidden）ビューに関するドキュメントを参照してください。
• ：djadmin： `makemessages` コマンドは、JavaScriptファイルから翻訳可能な文字列を抽出するために、新しくより正確なレクサー JsLex を使用します。

• ：ttag： `trans` テンプレートタグは、オプションのas引数を取り、翻訳文字列を表示せずに、代わりにテンプレートコンテキスト変数を設定して取得できるようになりました。

• ：ttag： `if` テンプレートタグが{% elif %}句をサポートするようになりました。

• Djangoアプリがプロキシの背後にある場合は、新しい：setting： `SECURE_PROXY_SSL_HEADER` 設定が役立つ場合があります。 これは、リクエストがHTTPS経由で着信したという事実をプロキシが「食べる」という問題を解決します。 ただし、この設定は、自分が何をしているかがわかっている場合にのみ使用してください。

• ：setting： `DEBUG` がTrueの場合に提供されるHTTP500ステータスコード内部エラーページの新しいプレーンテキストバージョンが、Djangoがリクエストを検出したときにクライアントに送信されるようになりましたJavaScriptコードに端を発しています。 （これにはis_ajax()が使用されます。）

  HTML版と同様に、アプリケーションの状態に関するさまざまな情報のコレクションが含まれています。

  これにより、クライアント側のJavaScriptとの相互作用をデバッグするときに読みやすくなります。

• makemessages --no-locationオプションを追加しました。

• 他のキャッシュバックエンドとの互換性を高めるために、locmemキャッシュバックエンドをpickle.HIGHEST_PROTOCOLを使用するように変更しました。

• DISTINCT ONを含むSELECTクエリを生成するためのORMのサポートが追加されました。

  distinct() QuerySetメソッドは、モデルフィールド名のオプションのリストを受け入れるようになりました。 指定した場合、DISTINCTステートメントはこれらのフィールドに制限されます。 これはPostgreSQLでのみサポートされています。

  詳細については、 distinct（）のドキュメントを参照してください。

• urls.pyに'admin_password_reset'という名前のURLを含めると、管理者ログインページにパスワードリセットリンクが追加されるため、組み込みのパスワードリセットメカニズムをプラグインして利用できるようになりました。 詳しくは、パスワードリセット機能の追加をご覧ください。

• MySQLデータベースバックエンドは、MySQLバージョン5.0.3以降で実装されたセーブポイント機能をInnoDBストレージエンジンで利用できるようになりました。

• 通常のフォームセットと同様に、ファクトリ関数modelformset_factoryおよびinlineformset_factoryからそれぞれ返されるモデルフォームセットとインラインモデルフォームセットの両方の一部であるモデルフォームに初期値を渡すことができるようになりました。 ただし、初期値は追加のフォームにのみ適用されます。 既存のモデルインスタンスにバインドされていないもの。

• サイトマップフレームワークは、新しい Sitemap.protocol クラス属性を使用してHTTPSリンクを処理できるようになりました。

• django.test.TestCase および会社よりも軽量なunittest.TestCaseの新しい django.test.SimpleTestCase サブクラス。 これは、データベースにアクセスする必要のないテストで役立ちます。 Djangoユニットテストクラスの階層を参照してください。

1.4での後方互換性のない変更

SECRET_KEY設定が必要です

空のまたは既知の：setting： `SECRET_KEY` でDjangoを実行すると、Djangoのセキュリティ保護の多くが無効になり、リモートでコードが実行される脆弱性が発生する可能性があります。 ：setting： `SECRET_KEY` なしでDjangoサイトを実行することはできません。

Django 1.4では、空の：setting： `SECRET_KEY` でDjangoを開始すると、DeprecationWarningが発生します。 Django 1.5では、例外が発生し、Djangoは起動を拒否します。 ：setting： `SECRET_KEY` を指定せずにDjangoを実行すると結果が深刻になるため、これは通常の非推奨パスからわずかに加速されます。

django.contrib.admin

付属の管理アプリdjango.contrib.adminには、JavaScript、画像、スタイルシートなどの静的ファイルのデフォルトセットが長い間付属しています。 Django 1.3は、このようなファイルを一般的な方法で処理するための新しいcontribアプリdjango.contrib.staticfilesを追加し、アプリに含まれる静的ファイルの規則を定義しました。

Django 1.4以降、管理者の静的ファイルもこの規則に従い、ファイルのデプロイを容易にします。 以前のバージョンのDjangoでは、管理者の静的ファイルがWebサーバー上に存在するURLを指すようにADMIN_MEDIA_PREFIX設定を定義することも一般的でした。 この設定は非推奨になり、より一般的な設定：setting： `STATIC_URL` に置き換えられました。 Djangoは、URL <STATIC_URL>/admin/の下に管理静的ファイルを見つけることを期待します。

以前にADMIN_MEDIA_PREFIXのURLパスを使用したことがある場合（例： /media/）：setting： `STATIC_URL` と：setting：` STATIC_ROOT` が構成されており、Webサーバーがこれらのファイルを正しく提供していることを確認してください。 開発サーバーは、以前と同じように管理ファイルを提供し続けます。 詳細については、静的ファイルのハウツーをお読みください。

ADMIN_MEDIA_PREFIXが特定のドメインに設定されている場合（例： http://media.example.com/admin/）、：setting： `STATIC_URL` 設定も正しいURL（たとえば、http://media.example.com/）に設定してください。

警告

Djangoのソースコード内の管理静的ファイルのパスに暗黙的に依存している場合は、そのパスを更新する必要があります。 ファイルはdjango/contrib/admin/media/からdjango/contrib/admin/static/admin/に移動されました。

管理者がサポートするブラウザ

Djangoには、管理アプリでサポートされるブラウザーに関する明確なポリシーがありません。 新しいポリシーは、既存のプラクティスを形式化したものです。 YUIのAグレードブラウザーは、サポートされなくなったInternet Explorer 6を除いて、完全に機能する管理エクスペリエンスを提供する必要があります。

10年以上前にリリースされたIE6は、最新のWeb開発に多くの制限を課しています。 このポリシーの実際的な意味は、寄稿者がこれらの制限を考慮せずに管理者を自由に改善できることです。

この新しいポリシーは、Djangoを使用して開発するサイトに影響を与えません。 Django管理者にのみ適用されます。 あらゆるブラウザと互換性のあるアプリを自由に開発してください。

管理アイコンを削除しました

管理者の変更リストの並べ替えインターフェイスと水平および垂直「フィルター」ウィジェットのパフォーマンスと使いやすさを向上させる取り組みの一環として、一部のアイコンファイルが削除され、2つのスプライトにグループ化されました。ファイル。

具体的には、selector-add.gif、selector-addall.gif、selector-remove.gif、selector-removeall.gif、selector_stacked-add.gif、selector_stacked-remove.gifを組み合わせて [ X105X]; arrow-up.gifとarrow-down.gifを組み合わせてsorting-icons.gifにしました。

これらのアイコンを使用して管理者をカスタマイズした場合は、それらを独自のアイコンに置き換えるか、以前のリリースのファイルを取得する必要があります。

管理フォームのCSSクラス名

他の一般的なCSSクラス名との競合を回避するため（例： 「ボタン」）、メイン管理フォーム、スタックインラインフォーム、および表形式のインラインセルのフォームフィールド名から自動的に生成されるすべてのCSSクラス名にプレフィックス（「フィールド-」）を追加しました。 以前にカスタムスタイルまたはJavaScript変換のセレクターとしてプレーンフィールド名を使用したことがある場合は、カスタムスタイルシートまたはJavaScriptファイルでそのプレフィックスを考慮する必要があります。

古い署名済みデータとの互換性

Django 1.3は、Djangoの多くの場所で使用されている暗号署名メカニズムを変更しました。 Django 1.3は、以前の方法で生成されたハッシュを受け入れるフォールバックを保持していましたが、これらのフォールバックはDjango1.4で削除されています。

そのため、1.2以前から直接Django 1.4にアップグレードすると、古い方法を使用して暗号で署名された特定のデータが失われたり無効になったりする可能性があります。 これを回避するには、最初にDjango 1.3を一定期間使用して、署名されたデータが自然に期限切れになるようにします。 影響を受ける部分の詳細を以下に示します。1）このアドバイスを無視した場合の結果、および2）データの有効期限が切れるか無関係になるまでにDjango1.3を実行するために必要な時間。

• contrib.sessionsデータ整合性チェック
  • 結果：ユーザーはログアウトされ、セッションデータは失われます。
  • 期間：：setting： `SESSION_COOKIE_AGE` で定義されます。
• contrib.authパスワードリセットハッシュ
  • 結果：アップグレード前のパスワードリセットリンクは機能しません。
  • 期間：：setting： `PASSWORD_RESET_TIMEOUT_DAYS` で定義されます。

フォーム関連のハッシュ：これらは寿命がはるかに短く、ユーザーがアップグレード前のDjangoインスタンスによって生成されたフォームに入力し、アップグレードされたDjangoインスタンスに送信しようとする短いウィンドウにのみ関連します。

• contrib.commentsフォームセキュリティハッシュ
  • 結果：ユーザーには、検証エラー「セキュリティハッシュが失敗しました」が表示されます。
  • 期間：ユーザーがコメントフォームに入力するのにかかると予想される時間。
• FormWizardセキュリティハッシュ
  • 結果：ユーザーには、フォームの有効期限が切れているというエラーが表示され、ウィザードの最初のページに送り返され、これまでに入力したデータが失われます。
  • 期間：ユーザーが影響を受けるフォームに入力するのにかかると予想される時間。
• CSRFチェック
  • 注：これは実際にはDjango1.2のフォールバックでありDjango1.2ではなく、1.1からアップグレードする場合にのみ適用されます。
  • 結果：CSRFで保護されたPOSTフォームで403エラーが表示されます。
  • 期間：ユーザーがそのようなフォームに記入するのにかかると予想される時間。
• contrib.authユーザーパスワードハッシュアップグレードシーケンス
  • 結果：1.4でデータベースに書き込まれると、各ユーザーのパスワードはより強力なパスワードハッシュに更新されます。 つまり、1.4にアップグレードしてから1.3にダウングレードする必要がある場合、バージョン1.3は更新されたパスワードを読み取ることができません。
  • 対処法：最初に1.4にアップグレードするときに、元のパスワードハッシュを使用するように：setting： `PASSWORD_HASHERS` を設定します。 アプリがDjango1.4で正常に動作し、1.3にロールバックする必要がないことを確認したら、新しいパスワードハッシュを有効にします。

django.contrib.flatpages

1.4以降、 FlatpageFallbackMiddleware は、結果のURLが既存のフラットページを参照している場合にのみ、末尾にスラッシュを追加してリダイレクトします。 たとえば、以前のバージョンで/notaflatpageoravalidurlを要求すると、/notaflatpageoravalidurl/にリダイレクトされ、その後404が発生します。 /notaflatpageoravalidurlをリクエストすると、すぐに404が発生します。

また、フラットページによって返されるリダイレクトは、 CommonMiddleware の動作と一致するように、永続的（301ステータスコード）になりました。

datetimeおよびtimeのシリアル化

タイムゾーンサポートの結果として、ECMA-262仕様に従って、JSONシリアライザーに変更を加えました。

• これには、認識されている日時オブジェクトのタイムゾーンが含まれます。 認識時間オブジェクトの例外が発生します。
• これには、datetimeオブジェクトとtimeオブジェクトのミリ秒が含まれます。 Pythonはマイクロ秒（6桁）を格納し、JSONはミリ秒（3桁）しかサポートしないため、精度はまだ多少低下します。 ただし、マイクロ秒を完全に破棄するよりはましです。

日時にISO8601形式を使用するようにXMLシリアライザーを変更しました。 文字Tは、スペースではなく、日付部分と時間部分を区切るために使用されます。 タイムゾーン情報は[+-]HH:MM形式で含まれています。

シリアライザーはフィクスチャを作成するときにこれらの新しいフォーマットを使用するようになりましたが、古いフォーマットを使用するフィクスチャをロードすることはできます。

SQLiteのsupports_timezoneがFalseに変更されました

データベース機能supports_timezoneは、SQLiteではTrueでした。 実際、認識された日時オブジェクトを保存した場合、SQLiteはUTCオフセットを含む文字列を保存しました。 ただし、データベースから値をロードするときにこのオフセットは無視され、データが破損する可能性がありました。

タイムゾーンサポートのコンテキストでは、このフラグはFalseに変更され、日時はタイムゾーン情報なしでSQLiteに保存されるようになりました。 ：setting： `USE_TZ` がFalseの場合、認識されている日時オブジェクトを保存しようとすると、Djangoは例外を発生させます。

MySQLdb固有の例外

MySQLバックエンドは、クエリが例外をトリガーしたときにMySQLdb.OperationalErrorを発生させてきました。 このバグを修正し、代わりに django.db.DatabaseError を発生させます。 MySQLdb.OperationalErrorをテストしていた場合は、except句を更新する必要があります。

データベース接続のスレッドローカリティ

DatabaseWrapperオブジェクト（つまり django.db.connectionおよびdjango.db.connections["some_alias"]）によって参照される接続オブジェクトは、以前はスレッドローカルでした。 これらは、複数のスレッド間で共有される可能性があるため、グローバルオブジェクトになりました。 個々の接続オブジェクトはグローバルになりましたが、それらのオブジェクトを参照するdjango.db.connectionsディクショナリはスレッドローカルのままです。 したがって、ORMまたはDatabaseWrapper.cursor()を使用するだけでも、動作は以前と同じです。 ただし、django.db.connectionは、デフォルトのDatabaseWrapperオブジェクトを直接参照しなくなり、そのオブジェクトの属性にアクセスするためのプロキシになりました。 実際のDatabaseWrapperオブジェクトにアクセスする必要がある場合は、代わりにdjango.db.connections[DEFAULT_DB_ALIAS]を使用してください。

この変更の一環として、基礎となるすべてのSQLite接続で潜在的なスレッド共有が有効になりました（check_same_thread=False属性をpysqliteに渡すことにより）。 ただし、DatabaseWrapperは、デフォルトでスレッド共有を無効にすることで以前の動作を維持するため、ORMまたはDatabaseWrapper.cursor()に純粋に依存する既存のコードには影響しません。

最後に、スレッド間で接続を渡すことが可能になりましたが、Djangoは基盤となるバックエンドへのアクセスを同期するための努力をしていません。 並行性の動作は、基盤となるバックエンドの実装によって定義されます。 詳細については、ドキュメントを確認してください。

COMMENTS_BANNED_USERS_GROUP設定

Djangoのコメントは、これまで特別なユーザーグループのコメントの除外をサポートしてきましたが、この機能を適切に文書化したことはなく、テンプレートタグなどのアプリの他の部分で除外を強制しませんでした。 この問題を修正するために、フィードクラスからコードを削除しました。

この機能に依存していて、古い動作を復元する場合は、カスタムコメントモデルマネージャーを使用して、次のようにユーザーグループを除外します。

from django.conf import settings
from django.contrib.comments.managers import CommentManager

class BanningCommentManager(CommentManager):
    def get_query_set(self):
        qs = super().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

このモデルマネージャーをカスタムコメントアプリ（my_comments_app/managers.pyなど）に保存し、カスタムコメントアプリモデルに追加します。

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()

IGNORABLE_404_STARTSおよびIGNORABLE_404_ENDS設定

Django 1.3までは、IGNORABLE_404_STARTSにプレフィックスを追加し、IGNORABLE_404_ENDSにサフィックスを追加することで、Djangoの 404エラーレポートから一部のURLを除外することができました。

Django 1.4では、これら2つの設定は、コンパイルされた正規表現のリストである：setting： `IGNORABLE_404_URLS` に置き換えられています。 Djangoは、それらのいずれかに一致するURLの404エラーについてメールを送信しません。

さらに、以前の設定には、かなり恣意的なデフォルト値がいくつかありました。

IGNORABLE_404_STARTS = ('/cgi-bin/', '/_vti_bin', '/_vti_inf')
IGNORABLE_404_ENDS = ('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi',
                      'favicon.ico', '.php')

Webサイトにレガシー/cgi-bin/セクションがあるかfavicon.icoがあるかを判断するのはDjangoの役割ではありません。 その結果、：setting： `IGNORABLE_404_URLS` 、IGNORABLE_404_STARTS、およびIGNORABLE_404_ENDSのデフォルト値はすべて空になりました。

IGNORABLE_404_STARTSまたはIGNORABLE_404_ENDSをカスタマイズした場合、または古いデフォルト値を保持したい場合は、設定ファイルに次の行を追加する必要があります。

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>$'),
)

ピリオドなど、正規表現で特別な意味を持つ文字をエスケープすることを忘れないでください。

CSRF保護がPUTとDELETEに拡張されました

以前は、Djangoの CSRF保護は、POSTリクエストに対してのみ保護を提供していました。 AJAXアプリケーションでのPUTおよびDELETEメソッドの使用が一般的になっているため、 RFC 2616 で安全と定義されていないすべてのメソッドを保護するようになりました。つまり、GET、HEAD、OPTIONS、およびTRACE、そして私たちは他のすべてに保護を強制します。

AJAXアプリケーションでPUTまたはDELETEメソッドを使用している場合は、 AJAXおよびCSRFの使用に関する説明を参照してください。

パスワードリセットビューがsubject_template_nameを受け入れるようになりました

django.contrib.authのpassword_resetビューは、subject_template_nameパラメーターを受け入れるようになりました。このパラメーターは、キーワード引数としてパスワード保存フォームに渡されます。 カスタムパスワードリセットフォームでこのビューを使用している場合は、フォームのsave()メソッドがこのキーワード引数を受け入れることを確認する必要があります。

django.core.template_loaders

これは2005年からdjango.template.loaderのエイリアスでしたが、廃止予定期間が長かったため、警告を出さずに削除しました。 コードがまだこれを参照している場合は、代わりにdjango.template.loaderを使用してください。

django.db.models.fields.URLField.verify_exists

この機能は、手に負えないパフォーマンスとセキュリティの問題のために削除されました。 verify_existsの既存の使用法はすべて削除する必要があります。

django.core.files.storage.Storage.open

基本ストレージクラスのopenメソッドは、返されたファイルオブジェクトの基本クラスを動的に変更できるようにするあいまいなパラメーターmixinを取得するために使用されていました。 これは削除されました。 mixinパラメータに依存したまれなケースでは、次のようにopenメソッドをオーバーライドすることで、同じことを簡単に実現できます。

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))

YAMLデシリアライザーがyaml.safe_loadを使用するようになりました

yaml.loadは任意のPythonオブジェクトを構築できます。これにより、信頼できないソースからのYAMLドキュメントを処理すると、任意のコードが実行される可能性があります。 この機能は、DjangoのYAMLデシリアライザーには必要ありません。Djangoの主な用途は、単純なオブジェクトで構成されるフィクスチャをロードすることです。 フィクスチャは信頼できるデータですが、YAMLデシリアライザーはセキュリティを強化するためにyaml.safe_loadを使用するようになりました。

セッションCookieにデフォルトでhttponlyフラグが設定されるようになりました

セッションCookieには、潜在的なXSS攻撃の影響を軽減するために、デフォルトでhttponly属性が含まれるようになりました。 この変更の結果、セッションIDを含むセッションCookieデータは、多くのブラウザでJavaScriptからアクセスできなくなりました。 厳密な下位互換性のために、設定ファイルでSESSION_COOKIE_HTTPONLY = Falseを使用してください。

：tfilter： `urlize` フィルターがすべてのURLをエスケープしなくなりました

URLに%xxシーケンスが含まれている場合（xxは16進数の2桁）、：tfilter： `urlize` は、URLが既にエスケープされていると見なし、適用されないようになりました。 URLが再びエスケープされます。 これは、引用符で囲まれていない形式に%xxシーケンスが含まれているURLの場合は誤りですが、ブラウザーも混乱させるため、このようなURLが実際に発生する可能性はほとんどありません。

コンテキストマネージャーとしてのassertTemplateUsedおよびassertTemplateNotUsed

assertTemplateUsed（）および assertTemplateNotUsed（）を使用して、コードのブロック内でテンプレートが使用されたかどうかを確認できるようになりました。 そして、それらはコンテキストマネージャーとして使用できます。

with self.assertTemplateUsed('index.html'):
    render_to_string('index.html')
with self.assertTemplateNotUsed('base.html'):
    render_to_string('index.html')

詳細については、アサーションドキュメントを参照してください。

テストスイートの実行後のデータベース接続

デフォルトのテストランナーは、テストの実行後にデータベース接続を復元しなくなりました。 これにより、本番データベースが、まだ実行されていて新しい接続を作成しようとしている可能性のあるスレッドにさらされるのを防ぎます。

テストの実行後に作成される本番データベースへの接続にコードが依存している場合は、DjangoTestRunnerをサブクラス化し、そのteardown_databases()メソッドをオーバーライドすることで、以前の動作を復元できます。

の出力 ：djadmin： `manage.pyヘルプ `

：djadmin： `manage.pyヘルプ ` 使用可能なコマンドをアプリケーションごとにグループ化するようになりました。 このコマンドの出力に依存している場合（たとえば、コマンドを解析した場合）、コードを更新する必要があります。 スクリプトで使用可能なすべての管理コマンドのリストを取得するには、次を使用します。 ：djadmin： `manage.py help --commands ` 代わりは。

extendsテンプレートタグ

以前は、：ttag： `extends` タグは、引数を解析するバグのある方法を使用していました。これにより、引数が文字列リテラルではないのに、誤って文字列リテラルと見なされる可能性がありました。 他のタグと同様に、parser.compile_filterを使用するようになりました。

タグの内部は公式の安定したAPIの一部ではありませんが、完全に開示するために、ExtendsNode.__init__の定義が変更され、このクラスを使用するカスタムタグが破損する可能性があります。

一部の不完全なフィクスチャのロードが機能しなくなりました

1.4より前では、フィールドにauto_nowまたはauto_now_addが設定されている場合に、特定の日付または日時の値が欠落しているフィクスチャオブジェクトにデフォルト値が挿入されていました。 これは機能するはずのないものであり、1.4ではそのような不完全なフィクスチャのロードは失敗します。 フィクスチャは未加工のインポートであるため、モデルのフィールドオプションに関係なく、すべてのフィールド値を明示的に指定する必要があります。

開発サーバーのマルチスレッド

開発サーバーはデフォルトでマルチスレッド化されています。 runserver --nothreadingオプションを使用して、開発サーバーでのスレッドの使用を無効にします。

django-admin.py runserver --nothreading

セーフモードが設定されている場合、マークダウンで属性が無効になります

Django 1.4より前は、フィルターのセーフモード設定に関係なく、属性はすべてのマークダウン出力に含まれていました。 Python-Markdownライブラリのバージョン> 2.1では、enable_attributesオプションが追加されました。 safe引数がマークダウンフィルターに渡されると、safe_mode=Trueオプションとenable_attributes=Falseオプションの両方が設定されます。 2.1未満のバージョンのPython-Markdownライブラリを使用している場合、出力が安全でないという警告が発行されます。

FormMixin get_initialは、インスタンス固有の辞書を返します

Django 1.3では、 django.views.generic.edit.FormMixin クラスのget_initialメソッドがクラスinitialディクショナリを返していました。 これは、このディクショナリのコピーを返すように修正されたため、フォームインスタンスは、クラス変数をいじることなく初期データを変更できます。

1.4で廃止された機能

cache_pageデコレータを呼び出す古いスタイル

cache_page（）を呼び出すいくつかのレガシーな方法は非推奨になりました。 このデコレータの正しい使用方法については、ドキュメントを参照してください。

8.2より古いバージョンのPostgreSQLのサポート

Django 1.3は8.0より古いバージョンのPostgreSQLのサポートを終了しました。パフォーマンスが向上し、さらに重要なことに、8.0と8.1のアップストリームサポート期間の終了が近づいたため、より新しいバージョンを使用することをお勧めしました（2010年11月）。

Django 1.4はそのポリシーをさらに発展させ、公式にサポートするPostgreSQLの最小バージョンとして8.2を設定します。

リクエストの例外が常にログに記録されるようになりました

1.3のDjangoでロギングサポートを追加したとき、管理エラーメールサポートは'django.request'ロガーに接続された django.utils.log.AdminEmailHandler に移動されました。 エラーメールの確立された動作を維持するために、'django.request'ロガーは、：setting： `DEBUG` がFalseの場合にのみ呼び出されました。

リクエストのエラーログの柔軟性を高めるために、：setting： `DEBUG` の値に関係なく、'django.request'ロガーが呼び出されるようになり、新しいプロジェクトのデフォルト設定ファイルにDEBUGモードでの管理エラーメールを防ぐために、 django.utils.log.AdminEmailHandler に添付された個別のフィルター：

'filters': {
     'require_debug_false': {
         '()': 'django.utils.log.RequireDebugFalse'
     }
 },
 'handlers': {
     'mail_admins': {
         'level': 'ERROR',
         'filters': ['require_debug_false'],
         'class': 'django.utils.log.AdminEmailHandler'
     }
 },

この変更の前にプロジェクトが作成された場合、：setting： `LOGGING` 設定にはこの新しいフィルターは含まれません。 下位互換性を維持するために、Djangoは'mail_admins'ハンドラー構成に'filters'セクションが含まれていないことを検出し、このフィルターを自動的に追加して、非推奨の保留警告を発行します。 これは、Django 1.5では非推奨の警告になり、Django 1.6では、下位互換性のあるシムが完全に削除されます。

'mail_admins'ハンドラーの下に'filters'キーが存在すると、この下位互換性シムと非推奨の警告が無効になります。

django.conf.urls.defaults

Django 1.3までは、include()、patterns()、url()関数に加えて、 handler404 と handler500 がdjango.conf.urls.defaultsモジュール。

Django 1.4では、それらは django.conf.urls にあります。

django.contrib.databrowse

Databrowseはしばらくの間活発な開発を見ていません、そしてこれは変化の兆候を示していません。 GSOCプロジェクトでデータ閲覧の機能を管理者に統合することが提案されていましたが、進展はありませんでした。 Databrowseは非推奨になりましたが、同様の機能セットを提供するdjango.contrib.adminの拡張は引き続き可能です。

Databrowseを強化するコードは、Django自体と同じ条件でライセンスされているため、個人またはグループがサードパーティプロジェクトとして採用することができます。

django.core.management.setup_environ

この関数は、親の「プロジェクト」ディレクトリを古いフラット：djadmin： `startproject` レイアウトでインポートできるようにするために、sys.pathを一時的に変更しました。 新しいmanage.pyおよびデフォルトのプロジェクトレイアウトではパスの回避策が不要になったため、この関数は非推奨になりました。

この関数は文書化されておらず、パブリックAPIの一部でもありませんが、ユーザースクリプトの「Django環境」のセットアップで使用することが広く推奨されていました。 これらの使用法は、 DJANGO_SETTINGS_MODULE 環境変数を設定するか、 django.conf.settings.configure（）を使用して置き換える必要があります。

django.core.management.execute_manager

この機能は、以前はmanage.pyが管理コマンドを実行するために使用していました。 django.core.management.execute_from_command_lineと同じですが、最初にsetup_environを呼び出す点が異なりますが、現在は非推奨です。 そのため、execute_managerも非推奨になりました。 代わりにexecute_from_command_lineを使用できます。 これらの関数はどちらもパブリックAPIの一部として文書化されていませんが、既存のmanage.pyファイルで使用されているため、非推奨パスが必要です。

テンプレートフィルターのis_safeおよびneeds_autoescape属性

is_safeとneeds_autoescapeの2つのフラグは、各テンプレートフィルターがDjangoの自動エスケープ動作とどのように相互作用するかを定義します。 それらは、以前はフィルター関数の属性でした。

@register.filter
def noop(value):
    return value
noop.is_safe = True

ただし、この手法では、デコレータ、特に @stringfilter との組み合わせでいくつかの問題が発生しました。 現在、フラグは @ register.filter のキーワード引数です。

@register.filter(is_safe=True)
def noop(value):
    return value

詳細については、フィルターと自動エスケープを参照してください。

INSTALLED_APPSでのアプリケーション名のワイルドカード拡張

Django 1.3まで、：setting： `INSTALLED_APPS` は、django.contrib.*などのアプリケーション名でワイルドカードを受け入れていました。 拡張は、from <package> import *のファイルシステムベースの実装によって実行されました。 残念ながら、これを確実に行うことはできません。

この動作は文書化されていません。 非Pythonであるため、Django1.4で削除されました。 これに依存している場合は、設定ファイルを編集して、すべてのアプリケーションを明示的に一覧表示する必要があります。

HttpRequest.raw_post_dataはHttpRequest.bodyに名前が変更されました

この属性は紛らわしい名前がHttpRequest.raw_post_dataでしたが、実際にはHTTPリクエストの本文を提供していました。 HttpRequest.bodyに名前が変更され、HttpRequest.raw_post_dataは非推奨になりました。

django.contrib.sitemaps潜在的なパフォーマンスへの影響を伴うバグ修正

以前のバージョンでは、サイトマップクラスで使用されるPaginatorオブジェクトがキャッシュされていたため、サイトマップが古くなる可能性がありました。 キャッシュを削除したため、サイトマップへの各リクエストで新しいPaginatorオブジェクトが作成され、 Sitemap サブクラスの items（）メソッドが呼び出されます。 items()メソッドの実行内容によっては、パフォーマンスに悪影響を与える可能性があります。 パフォーマンスへの影響を軽減するには、Sitemapサブクラス内でキャッシングフレームワークを使用することを検討してください。

Pythonのバージョン-2.1より前のMarkdown

2.1より前のバージョンのPython-Markdownは、属性を無効にするオプションをサポートしていません。 セキュリティの問題として、このライブラリの以前のバージョンは、非推奨のタイムラインが加速されている1.5のマークアップcontribアプリではサポートされません。