# dokumentasi Django 2.0.8

# Catatan terbitan Django 1.4

23 Maret 2012

Selamat datang di Django 1.4!

Catatan terbitan ini mencangkup new features, dan juga beberapa backwards incompatible changes anda akan ingin disadari ketika meningkatkan dari Django 1.3 atau versi terlama. Kami telah juga membuang beberapa fitur, yang rinciannya di our deprecation plan, dan kami telah begun the deprecation process for some features.

## Ikhtisar

Fitur baru terbesar di Django 1.4 adalah support for time zones ketika menangani tanggal/waktu. Ketika mengadakan, Django ini akan menyimpan tanggal/waktu dalam UTC, gunakan obyek sadar-zona waktu secara internal, dan rubah mereka menjadi zona waktu lokal pengguna untuk ditampilkan.

Jika anda sedang meningkatkan sebuah proyek pada Django 1.4, mengganti ke suasana sadar zona waktu mungkin mengambil beberapa perawatan: suasana baru tidak mengizinkan beberapa daripada perilaku ceroboh yang biasanya diterima. Kami mendorong siapapun yang meningkatkan untuk memeriksa timezone migration guide dan timezone FAQ untuk petunjuk berguna.

Fitur baru penting lainnya di Django 1.4 termasuk:

- Sejumlah perbaikan ORM, termasuk SELECT FOR UPDATE support, kemampuan untuk bulk insert dataset besar untuk memperbaiki penampilan, dan QuerySet.prefetch_related, sebuah metode untuk memuat-kumpulan terkait obyek di kawasan dimana `select_related()` tidak bekerja.
- Beberapa tambahan keamanan baik, termasuk improved password hashing (dukungan sifat PBKDF2 dan bcrypt), 'tools for cryptographic signing`_ baru, beberapa CSRF improvements, dan simple clickjacking protection.
- Sebuah updated default project layout and manage.py yang memindahkan "magic" dari versi sebelumnya. Dan untuk siapa yang tidak suka tata letak baru, anda dapat menggunakan custom project and app templates sebagai gantinya!
- Support for in-browser testing frameworks (seperti Selenium).
- ... dan banyak lagi; see below!

Dimanapun memungkinkan kami mencoba memperkenalkan fitur baru di sikap bertentangan kebelakang per kebijakan our API stability policy. Bagaimanapun, seperti dengan terbitan sebelumnya, Django 1.4 dibekali dengan beberapa backwards incompatible changes kecil; orang meningkatkan dari versi sebelumnya dari Django harus membaca daftar itu hati-hati.

## Kesesuaian Python

Django 1.4 telah membuang dukungan untuk Python 2.4. Python 2.5 sekarang vesi Python minimal yang diwajibkan. Django dicobakan dan didukung pada Python 2.5, 2.6 and 2.7.

Perubahan ini seharusnya berakibat hanya angka kecil dari pengguna Django, seperti kebanyakan penjaja sistem operasi hari ini yang membekali Phyton 2.5 atau memperbaharui versi awal mereka. Jika anda masih menggunakan Python 2.4, bagaimanapun, anda akan butuh melekat ke Django 1.3 sampai anda dapat meningkatkan; per kebijakan dukungan kami, Django 1.3 akan lanjut menerima dukungan keamanan sampai terbitan dari Django 1.5.

Django tidak mendukung Python 3.x pada saat ini. Pada beberapa titik sebelum terbitan Django 1.4, kami berencana menerbitkan sebuah uraian dokumen linimasa penuh kami untuk pengusangan Python 2.x dan pindah ke Python 3.x.

## Apa yang baru di Django 1.4

### Mendukung untuk zona waktu

Di versi sebelumnya, Django menggunakan tanggal/waktu "tidak dibuat-buat" (yaitu, tanggal/waktu tanpa zona waktu terkait), meninggalkannya ke setiap pengembang untuk mengartikan apa tanggal/waktu yang diberikan "benar-benar berarti". Ini dapat menyebabkan semua urutan halus dari kesalahan terkait-zona waktu.

Di Django 1.4, anda sekarang dapat mengganti Django menjadi lebih tepat, suasana sadar zona-waktu. Di suasana ini, Django menyimpan informasi tanggal dan waktu di UTC di basisdata, menggunakan obyek datetime waspada-zona-waktu secara internal dan menterjemahkan mereka ke zona waktu pengguna akhir di cetakan dan formulir. Alasan untuk menggunakan fitur ini termasuk:

- Menyesuaikan tampilan tanggal dan waktu untuk pengguna disekeliling dunia.
- Menyimpan datetime di UTC untuk basisdata mudah dibawa dan dapat dioperasikan. (Argumen ini tidak berlaku pada PostgreSQL, karena itu sudah menyimpan timestamp dengan informasi zona waktu di Django 1.3.)
- Menghindari masalah kerusakan data sekitar perpindahan DST.

Dukungan zona waktu diadakan secara awalan di proyek baru dibuat dengan `startproject`. Jika anda ingin menggunakan fitur ini di proyek yang sudah ada, baca migration guide. Jika anda mengalami masalah, ada bantuan FAQ.

### Mendukung untuk kerangka percobaan di-peramban

Django 1.4 mendukung perpaduan dengan kerangka percobaan di-peramban seperti Selenium. Kelas dasar `django.test.LiveServerTestCase` baru membiarkan anda mencoba interaksi diantara depan dan belakang situs anda lebih komprehensif. Lihat `documentation` untuk lebih contoh rinci dan nyata.

### Perbaharui tata letak proyek awal dan `manage.py`

Django 1.4 dibekali dengan tata letak proyek awalan terperbaharui dan berkas `manage.py` untuk perintah pengelolaan `startproject`. Ini memperbaiki beberapa masalah dengan `manage.py` sebelumnya menangani dari jalur Python impor yang menyebabkan impor ganda, masalah memindahkan dari pengembangan ke penyebaran, dan masalah jalur sulit-dicari-kesalahan lainnya.

`manage.py` sebelumnya memanggil fungsi yang sekarang diusangkan, dan dengan demikian peningkatan proyek ke Django 1.4 harus memperbaharui `manage.py` mereka. (Gaya lama `manage.py` akan berlanjut kerja sebagai sebelum sampai Django 1.6. Di 1.5 itu akan memunculkan `DeprecationWarning`).

Berkas `manage.py` yang baru dianjurkan harus seperti ini:

    #!/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 }}` harus diganti dengan nama paket Python dari proyek sebenarnya.

Jika pengaturan, URLconfs dan aplikasi dalam proyek diimpor atau diacukan menggunakan awalan nama proyek (sebagai contoh `myproject.settings`, `ROOT_URLCONF = "myproject.urls"`, dll.), `manage.py` baru akan butuh dipindahkan satu direktori keatas, jadi itu diluar paket proyek daripada berdekatan pada `settings.py` dan `urls.py`.

Untuk contoh, dengan tata letak berikut:

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

Anda dapat mengimpor `mysite.settings`, `mysite.urls`, dan `mysite.myapp`, tetapi tidak `settings`, `urls`, atau `myapp` sebagai modul tingkat-atas.

Apapun diimpor sebagai modul tingkat-atas dapat ditempatkan berdekatan ke `manage.py` baru. Sebagai contoh, untuk memisahkan "myapp" dari modul proyek dan impor itu sebagai hanya `myapp`, tempatkan itu diluar direktori `mysite/`:

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

Jika kode sama diimpor tidak tetap (beberapa tempat dengan awalan proyek, beberapa tempat tanpanya). impor akan butuh dibersihkan ketika mengganti ke `manage.py` baru.

### Proyek penyesuaian dan cetakan aplikasi

Perintah pengelolaan `startapp` dan `startproject` sekarang mempunyai sebuah pilihan `--template` untuk menentukan sebuah jalur atau URL ke aplikasi penyesuaian atau cetakan proyek.

Sebagai contoh, Django akan menggunakan direktori `/path/to/my_project_template` ketika anda menjalankan perintah berikut:

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

Anda dapat juga sekarang menyediakan tujuan direktori sebagai argumen kedua pada kedua `startapp` and `startproject`:

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

Untuk informasi lebih, lihat dokumentasi `startapp` dan `startproject`.

### Ditingkatkan dukungan WSGI

Perintah pengelolaan `startproject` sekarang menambahkan sebuah modul `wsgi.py` pada inisial tata letak proyek, mengandung aplikasi WSGI sederhana yang dapat digunakan untuk deploying with WSGI app servers.

`built-in development server` sekarang didukung menggunakan callable WSGI yang ditentukan-eksternal, yang membuatnya memungkinkan untuk menjalankan runserver dengan konfigurasi WSGI sama yang digunakan untuk penyebaran. Pengaturan `WSGI_APPLICATION` baru membiarkan anda mengkonfigurasi dapat dipanggil WSGI yang mana `runserver` gunakan.

(Perintah pengelolaan `runfcgi` juga secara internal membungkus dapat dipanggil WSGI dikonfigurasikan melalui `WSGI_APPLICATION`.)

### Mendukung `SELECT FOR UPDATE`

Django 1.4 menyertakan metode `QuerySet.select_for_update()`, yang membangkitkan sebuah permintaan SQL `SELECT ... FOR UPDATE`. Ini akan mengunci baris sampai akhir dari transaksi, yang berarti transaksi lain tidak dapat merubah atau menghapus baris yang cocok oleh sebuah permintaan `FOR UPDATE`.

Untuk lebih rinci, lihat dokumentasi untuk `select_for_update()`.

### `Model.objects.bulk_create` di ORM

Metode ini membiarkan anda membuat banyak obyek lebih efisien. Itu dapat menghasilkan penampilan yang signifikan meningkat jika anda mempunyai banyak obyek.

Django membuat penggunaan dari internal ini, berarti beberapa tindakan (seperti pengaturan basisdata untuk deretan percobaan) telah melihat keuntungan penampilan sebagai sebuah hasil.

Lihat dokumentasi `bulk_create()` untuk informasi lebih.

### `QuerySet.prefetch_related`

Serupa pada `select_related()` tetapi dengan strategi yang berbeda dan cakupan lebih luas, `prefetch_related()` telah ditambahkan ke `QuerySet`. Metode ini mengembalikan sebuah `QuerySet` baru yang akan mengambil setiap dari pencarian terkait yang ditentukan di kumpulan tunggal sefera ketika permintaan mulai dinilai. Tidak seperti `select_related`, itu melakukan penggabungan di Python, bukan di basisdata, dan mendukung hubungan many-to-many, `GenericForeignKey` dan lainnya. Ini mengizinkan anda memperbaiki masalah penampilan yang paling umum dimana kode anda berakhir melakukan O(n) permintaan basisdata (atau lebih buruk) jika obyek pada `QuerySet` utama setiap mempunyai banyak obyek terkait yang anda juga butuh ambil.

### Diperbaiki mengacak sandi

Sistem otentifikasi Django (`django.contrib.auth`) menyimpan sandi menggunakan algoritma satu-jalan. Django 1.3 menggunakan algoritma SHA1, tetapi meningkarkan kecepatan pengolah dan serangan teoritis telah terungkap bahwa SHA1 tidak seman kita kira. Demikian, Django 1.4 memperkenalkan sebuah sistem penyimpanan sandi baru: secara awalan Django sekarang menggunakan algoritma PBKDF2 (seperti yang dianjurkan oleh NIST). Anda dapat juga dengan mudah memilih algoritma berbeda (termasuk algoritma bcrypt terkenal). Untuk rincian lebih, lihat Bagaimana Django menyimpan sandi.

### Jenis dokumen HTML5

Kami telah mengganti cetakan admin dan gabungan lainnya untuk menggunakan doctype HTML5. Selagi Django akan lebih hati-hati merawat kesesuaian dengan peramban lama, perubahan ini berarti bahwa anda dapat menggunakan fitur HTML5 anda butuhkan di halaman admin tanpa harus kehilangan keabsahan HTML atau menimpa cetakan disediakan untuk merubah doctype.

### Daftar penyaring di antarmuka admin

Sebelum Django 1.4, aplikasi `admin` membiarkan anda menentukan daftar perubahan penyaring dengan menentukan bidang pencarian, tetapi itu tidak mengizinkan anda membuat penyesuaian penyaring. Ini telah diperbaiki dengan API sederhana (sebelumnya digunakan secara internal dan dikenal sebagai "FilterSpec"). Untuk rincian lebih, lihat dokumentasi untuk `list_filter`.

### Urutan banyak di antarmuka admin

Daftar perubahan admin sekarang mendukung pengurutan pada banyak kolom. Itu menghargai semua unsur dari atribut `ordering`, dan mengurutkan pada banyak kolom dengan mengklik pada kepala dirancang pada tiruan perilaku dari GUI desktop. Kami juga menambahkan metode `get_ordering()` untuk menentukan pengurutan secara dinamis (yaitu, tergantung pada permintaan).

### Metode `ModelAdmin` baru

Kami menambahkan metode `save_related()` pada `ModelAdmin` untuk penyesuaian mudah dari bagaimana obyek terkait disimpan di admin.

Dua metode `ModelAdmin` baru lain, `get_list_display()` dan `get_list_display_links()` mengadakan penyesuaian dinamis dari bidang dan tautan ditampilkan pada daftar perubahan admin.

### Deretan admin menghormati perizinan pengguna

Deretan admin sekarang hanya mengizinkan tindakan tersebut untuk dimana pengguna mempunyai perizinan. Untuk hubungan ManyToMany` dengan model menengah dibuat otomatis (yang tidak mempunyai perizinan itu sendiri), perubahan perizinan untuk model terkait menentukan jika pengguna mempunyai perizinan untuk menambahkan, merubah atau menghapus hubungan.

### Alat untuk penandatangan kriptografi

Django 1.4 menambahkan kedua API tingkat-rendah untuk menandatangani nilai-nilai dan API tingkat-tinggi untuk mengatur dan membaca kue ditandatangani, satu dari penggunaan paling umum dari penandatanganan di apliaksi Jaringan.

Lihat dokumen cryptographic signing untuk informasi lebih.

### Backend sesi berdasarkan-kue

Django 1.4 memperkenalkan backend sesi berdasarkan-kue yang menggunakan alat-alat untuk cryptographic signing untuk menyimpan data sesi di peramban klien.

Peringatan

Data sesi ditandatangani dan disahkan oleh peladen, tetapi itu tidak dienkripsi. Ini berarti pengguna dapat menampilkan data apapun disimpan di sesi tetapi tidak dapat merubahnya. Harap baca dokumentasi untuk penjelasan lebih jauh sebelum menggunakan backend ini.

Likat dok cookie-based session backend untuk informasi lebih.

### Wizard formulir baru

`FormWizard` sebelumnya dari `django.contrib.formtools` telah diganti dengan penerapan baru berdasarkan pada tampilan berdasarkan-kelas diperkenalkan di Django 1.3. Fitur itu API penyimpanan dapat tertanam dan tidak membutuhkan wizard untuk melewati sekeliling bidang tersembunyi untuk setiap langkah sebelumnya.

Django 1.4 dibekali dengan backend penyimpanan berdasarkan-sesi dan backend penyimpanan berdasarkan-kue. Terakhir menggunakan alat-alat untuk cryptographic signing juga diperkenalkan di Django 1.4 untuk menyimpan keadaan wizard di kue pengguna.

### `reverse_lazy`

Versi lazy dinilai dari `reverse()` telah ditambahkan untuk mengizinkan pembalikan URL sebelum URLconf proyek akan dimuat.

### Menterjemahkan pola URL

Django sekarang mencari untuk awalan bahasa di URLpattern ketika menggunakan fungsi pembantu `i18n_patterns()` baru. Itu juga sekarang memungkinkan menentukan pola URL dapat diartikan menggunakan `ugettext_lazy()`. Lihat Internasionalisasi: dalam pola URL untuk informasi lebih mengenai awalan bahasa dan bagaimana untuk menginternasionalisasi pola URL.

### Terjemahan kontekstual mengukung untuk `{% trans %}` dan `{% blocktrans %}`

Dukungan contextual translation diperkenalkan di Django 1.3 melalui fungsi `pgettext` telah diperpanjang ke etiket cetakan `trans` dan `blocktrans` menggunakan katakunci `context` baru.

### Disesuaikan `SingleObjectMixin` kwargs URLConf

Dua atribut baru `pk_url_kwarg` dan `slug_url_kwarg`, telah ditambahkan ke `SingleObjectMixin` untuk mengadakan penyesuaian dari argumen kata kunci URLConf digunakan untuk tampilan umum obyek tunggal.

### Menyerahkan etiket cetakan

Fungsi pembantu `assignment_tag` baru telah ditambahkan ke `template.Library` untuk memudahkan pembuatan etiket cetakan yang menyimpan data di variabel konteks yang ditentukan.

### Dukungan `*args` dan `**kwargs` untuk fungsi pembantu etiket cetakan

simple_tag, inclusion_tag dan baru-baru diperkenalkan fungsi pembantu cetakan `assignment_tag` sekarang menerima angka apapun dari penempatan atau argumen kata kunci. Sebagai contoh:

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

Kemudian, di cetakan, angka apapun dari argumen mungkin dilewatkan ke etiket cetakan. Sebagai contoh:

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

### Tidak ada pembungkusan dari pengecualian di suasana `TEMPLATE_DEBUG`

Di vesi sebelumnya dari Django, kapanpun pengaturan `TEMPLATE_DEBUG` adalah `True`, tiap pengecualian dimunculkan selama membangun cetakan (bahkan pengecualian tidak terkait ke sintaksis cetakan) dibungkus di `TemplateSyntaxError` dan dimunculkan kembali. Ini diselesaikan untuk menyediakan informasi rincian tempat sumber cetakan di mencari kesalahan halaman 500.

Di Django 1.4, pengecualian tidak lagi dibungkus. Sebagai gantinya pengecualian diberikan keterangan dengan informasi sumber. Ini berarti bahwa menangkap pengecualian dari membangun cetakan sekarang tetap tanpa memperhatikan nilai dari `TEMPLATE_DEBUG`, dan tidak perlu menangkap dan membuka `TemplateSyntaxError` untuk menangkap kesalahan lain.

### Penyaring cetakan `truncatechars`

Penyaring baru ini memotong deretan karakter untuk tidak lebih panjang dari angka yang ditentukan dari karakter. Deretan karakter diporong berakhir dengan urutan tanda pengganti dapat diartikan ("..."). Lihat dokumentasi untuk `truncatechars` untuk rincian lebih.

### Etiket cetakan `static`

Bantuan aplikasi `staticfiles` mempunyai etiket cetakan `static` baru untuk mengacu ke berkas-berkas disimpan dengan penyimpanan backend `STATICFILES_STORAGE`. Dia menggunakan metode `url` penyimpanan backend dan karena itu mendukung fitur lebih tinggi seperti serving files from a cloud service.

### Backend penyimpanan `CachedStaticFilesStorage`

Aplikasi bantuan `staticfiles` sekarang mempunyai backend `CachedStaticFilesStorage` yang menyembunyikan berkas dia simpan (ketika menjalankan perintah pengelolaan `collectstatic`) dengan menambahkan acakan MD5 dari isi berkas ke nama berkas. Sebagai contoh, berkas `css/styles.css` akan juga disimpan sebagai `css/styles.55e7cbb9ba48.css`

Lihat dokumen `CachedStaticFilesStorage` untuk informasi lebih.

### Perlindungan clickjacking sederhana

Kami telah menambahkan middleware untuk menyediakan perlindungan mudah terhadap clickjacking menggunakan kepala ``X-Frame-Options`. Itu tidak diadakan secara awal untuk alasan kesesuaian kebelakang, tetapi anda akan hampir pasti ingin enable it untuk membantu menanam lubang security untuk peramban yang mendukung kepala.

### Perbaikan CSRF

Kami telah membuat beragam perbaikan untuk fitur CSRF kami, termasuk penghias `ensure_csrf_cookie()`, yang dapat membantu dengan situs berat-AJAX; perlindungan untuk permintaan PUT dan DELETE; dan pengaturan `CSRF_COOKIE_SECURE` dan `CSRF_COOKIE_PATH`, yang dapat meningkatkan keamanan dan kegunaan dari perlindungan CSRF. Lihat CSRF docs untuk informasi lebih.

### Menyaring laporan kesalahan

Kami menambahkan dua fungsi penghias, `sensitive_variables()` dan `sensitive_post_parameters()`, untuk mengizinkan yang menunjuk variabel lokal dan parameter POST yang mungkin mengandung informasi sensitif dan harus disaring dari laporan kesalahan.

Semua parameter POST adalah sekarang sistematis disaring keluar dari laporan kesalahan untuk tampilan (`login`, `password_reset_confirm`, `password_change` dan `add_view` di `django.contrib.auth.views`, dan juga `user_change_password` di aplikasi admin) untuk mencegah kebocoran dari informasi sensitif seperti sandi pengguna.

Anda dapat menimpa atau menyesuaikan penyaringan awalan dengan menulis sebuah custom filter. Untuk informasi lebih lihat dokumen pada Filtering error reports.

### Diperpanjang dukungan IPv6

Django 1.4 sekarang dapat lebih baik menangani alamat IPv6 dengan bidang model `GenericIPAddressField` baru, bidang formuilir `GenericIPAddressField` dan pengesah `validate_ipv46_address` dan `validate_ipv6_address`.

### Perbandingan HTML di percobaan

Kelas-kelas dasar di `django.test` sekarang mempunyai beberapa pembantu untuk membandingkan HTML tanpa bersalah terhadap perbedaan tidak bersangkut paut di ruang kosong, pengutipan/pengurutan argumen dan penutupan dari etiket menutup-sendiri. Anda dapat baik membandingkan HTML secara langsung dengan meth:~django.test.SimpleTestCase.assertHTMLEqual baru dan pernyataan `assertHTMLNotEqual()`, atau gunakan bendera `html=True` dengan `assertContains()` dan `assertNotContains()` untuk mencoba apakah tanggapan klien mengandung potongan HTML yang diberikan. Lihat assertions documentation untuk lebih.

### Dua deretan karakter bentuk tanggal baru

Dua bentuk `date` baru telah ditambahkan untuk digunakan di penyaring cetakan, etiket cetakan dan Format localization:

- `e` -- nama dari zonawaktu dari obyek datetime yang diberikan
- `o` -- Angka tahun ISO 8601

Harap pastikan untuk memperbaharui custom format files anda jika mereka mengandung baik `e` atau `o` di bentuk deretan karakter. Sebagai contoh bentuk lokalisasi Spanyol sebelumnya hanya diloloskan karakter bentuk `d`:

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

Tetapi sekarang itu membutuhkan juga meloloskan `e` dan `o`:

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

Untuk informasi lebih, lihat dokumentasi `date`.

### Fitur kecil

Django 1.4 juga menyertakan beberapa perbaikan kecil yang tidak berharga:

- Stackrace lebih berguna dalam halaman 500 teknis. Kerangka-kerangka dalam tumpukan jejak yang mengacu kode kerangka kode Django dikaburkan, selagi kerangka-kerangka dalam kode aplikasi sedikit ditekankan. Perubahan ini membuat itu lebih mudah utnuk memindai stacktrace untuk diterbitkan dalam kode aplikasi.
- Tablespace support di PostgreSQL.
- Disesuaikan nama-nama untuk `simple_tag()`.
- Di dokumentasi, halaman security overview yang membantu.
- Fungsi `django.contrib.auth.models.check_password` telah dipindahkan ke modul `django.contrib.auth.hashers`. Mengimpornya dari tempat lama akan masih bekerja, tetapi anda harus memperbaharui impor anda.
- Perintah pengelolaan `collectstatic` sekarang mempunyai sebuah pilihan `--clear` untuk menghapus semua berkas pada tujuan sebelum menyalin atau menautkan berkas-berkas tetap.
- Sekarang memungkinkan memuat alat bantu mengandung terusan acuan ketika menggunakan MySQL dengan mesin basisdata InnoDB.
- Penanganan tanggapan 403 baru telah ditambahkan sebagai `'django.views.defaults.permission_denied'`. Anda dapat menyetel penangan anda sendiri dengan mengatur nilai dari `django.conf.urls.handler403`. Lihat dokumentasi tentang the 403 (HTTP Forbidden) view untuk informasi lebih.
- Perintah `makemessages` menggunakan lexer baru dan lebih akurat, JsLex, untuk mengeluarkan deretan karakter dapat diartikan dari berkas-berkas JavaScript.

- Etiket cetakan `trans` sekarang mengambil sebuah pilihan argumen `as` untuk dapat mengambil deretan karakter terjemahan tanpa menampilkannya tetapi mengatur konteks cetakan sebagai gantinya.

- Etiket cetakan `if` sekarang mendukung klausa `{% elif %}`.

- Jika aplikasi Django anda dibelakang proxy, anda mungkin menemukan pengaturan berguna baru `SECURE_PROXY_SSL_HEADER`. Itu menyelesaikan masalah dari "eating" proxy fakta bahwa sebuah permintaan datang dalam melalui HTTPS. Tetapi hanya menggunakan pengaturan ini jika anda mengetahui apa yang anda lakukan.

- Sebuah baru, teks-polos, versi dari halaman kesalahan internal kode keadaan 500 HTTP dilayani ketika `DEBUG` adalah `True` sekarang dikirim ke klien ketika Django mengenali bahwa permintaan berasal di kode JavaScript. (`is_ajax()` digunakan untuk ini.)

  Seperti pasangan HTML nya, itu mengandung kumpulan dari potongan berbeda dari informasi tentang keadaan dari aplikasi.

  Ini seharusnya membuatnya lebih muda untuk membaca ketika mencari kesalahan interaksi dengan JavaScript sisi-klien.

- Ditambahkan pilihan `makemessages --no-location`.

- Dirubah backend tembolok `locmem` untuk menggunakan `pickle.HIGHEST_PROTOCOL` untuk kesesuaian lebih baik dengan backend tembolok lain.

- Ditambahkan dukungan di ORM untuk membangkitkan permintaan `SELECT` mengandung `DISTINCT ON`.

  Metode `distinct()` `QuerySet` sekarang menerima sebuah daftar pilihan dari nama bidang model. Jika ditentukan, kemudian pernyataan `DISTINCT` dibatasi pada bidang ini. Ini hanya didukung di PostgreSQL.

  Untuk lebih rinci, lihat dokumentasi untuk `distinct()`.

- Halaman amsuk admin akan menambahkan tautan setel kembali sandi jika anda menyertakan sebuah URL dengan 'admin_password_reset' di urls.py anda, jadi menanam mekanisme penyetelan kembali sandi siap-pakai dan membuatnya tersedia sekarang lebih mudah. Untuk rincian, lihat Menambahkan fitur penyetelan kembali sandi.

- Backend basisdata MySQL dapat sekarang menggunakan fitur savapoint diterapkan oleh versi MySQL 5.0.3 atau lebih baru dengan mesin penyimpanan InnoDB.

- Sekarang memungkinkan melewati nilai awal ke formulir model yang bagian dari kedua model formset dan formset model berderet sebagai dikembalikan dari fungsi pabrik `modelformset_factory` dan `inlineformset_factory` masing-masing cukup seperti formset biasa. Bagaimanapun, nilai awal hanya berlaku pada formulir tambahan, yaitu yang tidak mengikat ke contoh model yang ada.

- Kerangka kerja peta situs sekarang dapat menangani tautan HTPS menggunakan atribut kelas `Sitemap.protocol` baru.

- Sebuah subkelas `django.test.SimpleTestCase` baru dari `unittest.TestCase` yaitu lebih ringan dari `django.test.TestCase` dan perusahaan. Itu dapat berguna di percobaan yang tidak butuh mengenai basisdata. Lihat Susunan dari satuan kelas-kelas percobaan Django.

## Perubahan bertentangan kebelakang di 1.4

### Pengaturan SECRET_KEY dibutuhkan

Menjalankan Django dengan sebuah `SECRET_KEY` kosong atau diketahui meniadakan banyak dari perlindungan keamanan Django dan dapat membawa ke kerentanan pengerjaan-kode-terpencil. Tidak ada situs Django harus berjalan tanpa `SECRET_KEY`.

Di Django 1.4, memulai Django dengan sebuah `SECRET_KEY` kosong akan memunculkan sebuah DeprecationWarning. Di Django 1.5, itu akan memunculkan sebuah pengecualian dan Django akan menolak mulai. Ini sedikit dipercepat dari jalur pengusangan biasa karena kerasnya akibat dari menjalankan Django dengan tidak ada `SECRET_KEY`.

### `django.contrib.admin`

Aplikasi administrasi disertakan `django.contrib.admin` telah untuk waktu lama dibekali dengan awalan sekumpulan dari berkas-berkas tetap seperti JavaScript, gambar dan stylesheet. Django 1.3 ditambahkan sebuah bantuan aplikasi baru `django.contrib.staticfiles` untuk menangani berkas seperti itu di cara umum dan menentukan persetujuan untuk berkas-berkas tetap disertakan di aplikasi.

Memulai di Django 1.4, berkas tetap admin juga mengikuti persetujuan ini, untuk membuat berkas ini lebih mudah di sebarkan. Dalam versi sebelumnya dari Django, itu juga umum untuk menentukan sebuah pengaturan `ADMIN_MEDIA_PREFIX` untuk menunjuk ke URL dimana berkas tetap admin tinggal di peladen Jaringan. Pengaturan ini sekarang telah diusangkan dan diganti oleh pengaturan `STATIC_URL`. Django sekarang akan berharap menemukan berkas tetap admin dibawah URL `<STATIC_URL>/admin/`.

Jika anda sebelumnya menggunakan jalur URL untuk `ADMIN_MEDIA_PREFIX` (sebagai contoh `/media/`) cukup pastikan `STATIC_URL` dan `STATIC_ROOT` dikonfigurasi dan peladen Jaringan anda melayani berkas-berkas tersebut dengan benar. Pengembangan peladen berlanjut melayani berkas admin sama seperti sebelumnya. Baca static files howto untuk lebih rinci.

Jika `ADMIN_MEDIA_PREFIX` anda disetel ke sebuah ranah khusus (sebagai contoh `http://media.example.com/admin/`), pastikan untuk juga menyetel pengaturan `STATIC_URL` anda ke URL benar -- sebagai contoh, `http://media.example.com/`.

Peringatan

Jika anda sedang tidak langsung bergantung pada jalur dari berkas tetap admin dalam kode sumber Django, anda akan butuh memperbaharui jalur itu. Berkas-berkas dipindahkan dari `django/contrib/admin/media/` ke `django/contrib/admin/static/admin/`.

### Perambah didukung untuk admin

Django belum mempunyai kebijakan jelas pada perambah mana yang didukung oleh aplikasi admin. Kebijakan baru kami meresmikan praktik yang ada: perambah YUI's A-grade harus menyediakan pengalaman admin berfungsi-penuh, dengan keterangan pengecualian dari Internet Explorer 6, yang tidak lagi didukung.

Diterbitkan lebih 10 tahun lalu, IE6 menyebabkan banyak batasan pada pengembangan Jaringan modern. Dampak praktik dari kebijakan ini adalah bahwa pembantu bebas meningkatkan admin tanpa pertimbangan dari batasan-batasan ini.

Dengan jelas, kebijakan baru ini tidak mempunyai dampak pada situs anda kembangkan menggunakan Django. Itu hanya berlaku ke admin Django. Jangan ragu untuk mengembangkan aplikasi sesuai dengan jangkauan apapun dari perambah.

### Pindahkan ikon admin

Sebagai bagian dari sebuah usaha untuk meningkatkan penampilan dan kegunaan dari antarmuka pengurutan daftar-rubah admin dan widget `horizontal` dan `vertical` "filter", beberapa berkas ikon telah dipindahkan dan dikelompokkan kedalam dua berkas sprite.

Khususnya: `selector-add.gif`, `selector-addall.gif`, `selector-remove.gif`, `selector-removeall.gif`, `selector_stacked-add.gif` dan `selector_stacked-remove.gif` telah digabungkan kedalam `selector-icons.gif`; dan `arrow-up.gif` dan `arrow-down.gif` telah digabungkan kedalam `sorting-icons.gif`.

Jika anda menggunakan ikon-ikon tersebut untuk menyesuaikan admin, kemudian anda akan butuh mengganti mereka dengan ikon-ikon anda sendiri atau mendapatkan berkas-berkas dari terbitan sebelumnya.

### Nama kelas CSS di formulir admin

Untuk menghindari pertentangan dengan nama kelas CSS umum lainnya (sebagai contoh "button"), kami menambahkan awalan (field-") ke semua nama kelas yang otomatis dibangkitkan dari nama bidang di formulir admin utama, formulir ditumpuk berderet dan sel-sel datar berderet. Anda akan butuh mengambil awalan itu kedalam akun di lembaran gaya penyesuaian anda atau berkas JavaScript jika anda sebelumnya menggunakan nama bidang polos sebagai pemilih untuk gaya penyesuaian atau perubahan JavaScript.

### Kesesuaian dengan data lama ditandatangani

Django 1.3 merubah mekanisme penandatanganan kriptografi digunakan dalam sejumlah tempat di Django. Selagi Django 1.3 terus menggunakan yang akan menerima acakan dihasilkan oleh metode sebelumnya, penggunaan ini akan dipindahkan di Django 1.4.

Jadi, jika anda meningkatkan ke Django 1.4 secara langsung dari 1.2 atau lebih awal, anda mungkin kehilangan/membatalkan potongan tertentu dari data yang telah dikriptografi ditandatangani menggunakan metode lama. Untuk menghindari ini, gunakan Django 1.3 dahulu untuk masa dari waktu untuk mengizinkan data ditandatangani untuk secara alamai kadaluarsa. Bagian terpengaruh dirinci dibawah ini, dengan 1) akibat dari mengabaikan saran ini dan 2) sejumlah waktu anda butuhkan untuk menjalankan Django 1.3 untuk data menjadi kadaluarsa atau menjadi tidak bersangkut paut.

- Pemeriksaan kesatuan data `contrib.sessions`
  - Konsekuensi: Pengguna akan keluar, dan data sesi akan hilang.
  - Periode waktu: Ditentukan oleh `SESSION_COOKIE_AGE`.
- Aakan penyetelan kembali sandi `contrib.auth`
  - Konsekuensi: Tautan setel kembai sandi dari sebelum peningkatan tidak akan bekerja.
  - Periode waktu: Ditentukan oleh `PASSWORD_RESET_TIMEOUT_DAYS`.

Campuran hubungan-formulir: kepunyaan ini lebih pendek masa hidupnya dan hanya bersangkut paut untuk jendela pendek dimana pengguna mungkin mengisi sebuah formulir dibangkitkan oleh pra-peningkatan contoh Django dan mencoba mengajukan nya ke contoh Django ditingkatkan:

- Campuran keamanan formulir `contrib.comments`
  - Konsekuensi: penggunakan akan melihat kesalahan pengesahan "Security hash failed."
  - Periode waktu: Sejumlah waktu anda harapkan pengguna mengisi formulir komentar.
- Campuran keamanan `FormWizard`
  - Konsekuensi: Pengguna akan melihat sebuah kesalahan tentang formulir memiliki kadaluarsa dan akan dikirim kembali ke halaman pertama dari wizard, kehilangan data dimasukkan sejauh ini.
  - Periode waktu: Sejumlah waktu anda harapkan pengguna mengisi formulir terpengaruh.
- Pemeriksaan CSRF
  - Catat: Ini adalah sebenarnya sebuah fallback Django 1.1, bukan Django 1.2, dan itu berlaku hanya jika anda sedang meningkatkan dari 1.1.
  - Konsekuensi: Pengguna akan melihat kesalahan 403 dengan formulir POST dilindungi-CSRF.
  - Periode waktu: Sejumlah waktu anda harapkan pengguna mengisi formulir seperti itu.
- Urutan peningkatan-campuran sandi pengguna `contrib.auth`
  - Konsekuensi: Setiap sandi pengguna akan diperbaharui ke acakan sandi terkuat ketika itu ditulis ke basisdata di 1.4. Ini berarti bahwa jika anda meningkatkan ke 1.4 dan kemudian butuh untuk menurunkan ke 1.3, versi 1.3 tidak akan dapat membaca sandi terperbaharui.
  - Memperbaiki: Setel `PASSWORD_HASHERS` untuk menggunakan mengacak sandi asli ketika anda awalnya meningkatkan ke 1.4. Setelah anda menegaskan aplikasi anda bekerja baik dengan Django 1.4 dan anda tidak harus mengembalikan ke 1.3, adakan acakan sandi baru.

### `django.contrib.flatpages`

Memulai di 1.4, `FlatpageFallbackMiddleware` hanya menambah buntutan garis miring dan pengalihan jika URL dihaslikan mengacu pada sebuah flatpage yang ada. Sebagai contoh, meminta `/notaflatpageoravalidurl` di versi sebelumnya akan mengalihkan ke `/notaflatpageoravalidurl/`, yang akan kemudian memunculkan sebuah 404. Meminta `/notaflatpageoravalidurl` sekarang akan segera memunculkan sebuah 404.

Juga, pengalihan dikembalikan oleh flatpage sekarang tetap (dengan kode keadaan 301), untuk mencocokkan perilaku dari `CommonMiddleware`.

### Serialisasi dari `datetime` dan `time`

Sebagai konsekuensi dari dukungan zona-waktu, dan menurut pada spesifikasi ECMA-262, kami membuat perubahan pada penserial JSON:

- Itu termasuk zona waktu untuk obyek datetime sadar. Itu memunculkan sebuah pengecualian untuk obyek waktu sadar.
- Itu menyertakan milidetik untuk obyek datetime dan time. Masih ada beberapa kehilangan ketelitian, karena Python menyimpan mikrodetik (6 angka) dan JSON hanya mendukung milidetik (3 angka). Bagaimanapun, itu lebih baik daripada mengabaikan mikrodetik seluruhnya.

Kami merubah penserial XML untuk menggunakan bentuk ISO8601 untuk datetime. Huruf `T` digunakan untuk memisahkan bagian tanggal dari bagian waktu, bukannya spasi. Informasi zona waktu disertakan di bentuk `[+-]HH:MM`.

Meskipun penserial sekarang menggunakan bentuk baru ini ketika membuat alat bantu, mereka masih dapat memuat alat bantu yang menggunakan bentuk lama.

### `supports_timezone` dirubah ke `False` untuk SQLite

Fitur basisdata `supports_timezone` biasanya `True` untuk SQLite. Memang, jika anda menyimpan sebuah obyek datetime sadar, SQLite menyimpan sebuah deretan karakter yang disertakan sebuah perimbangan UTC. Bagaimanapun, perimbangan ini telah diabaikan ketika memuat nilai kembali dari basisdata, yang dapat merusak data.

Dalam konteks dari dukungan zona-waktu, bendera ini telah berubah menjadi `False`, dan datetime sekarang disimpan tanpa informasi zona-waktu di SQLite. Ketika `USE_TZ` adalah `False`, jika anda berusaha menyimpan sebuah obyek zona waktu disadari, Django memunculkan sebuah pengecualian.

### Pengecualian `MySQLdb`-khusus

Riwayat backend MySQL telah memunculkan `MySQLdb.OperationalError` ketika permintaan memicu sebuah pengecualian. Kami telah memperbaiki kesalahan ini, dan kami sekarang memunculkan `django.db.DatabaseError` sebagai gantinya. Jika anda sedang mencoba untuk `MySQLdb.OperationalError`, anda akan butuh memperbaharui klausa `except` anda.

### Thread-locality hubungan basisdata

Obyek `DatabaseWrapper` (yaitu hubungan obyek diacukan oleh `django.db.connection` dan `django.db.connections["some_alias"]`) biasanya thread-local. Mereka sekarang obyek global untuk berpeluang berbagi diantara banyak thread. Selagi hubungan obyek individu sekarang global, kamus `django.db.connections` mengacu obyek tersebut adalah masih thread-local. Karena itu jika anda hanya menggunakan ORM atau `DatabaseWrapper.cursor()` kemudian kebiasan masih sama seperti sebelumnya. Catat, bagaimanapun, bahwa `django.db.connection` tidak secara langsung mengacu awalan obyek `DatabaseWrapper` lagi dan sekarang sebuah proxy untuk mengakses atribut obyek itu. Jika anda butuh mengakses obyek `DatabaseWrapper` sesungguhnya, gunakan `django.db.connections[DEFAULT_DB_ALIAS]` sebagai gantinya.

Sebagai bagian dari perubahan ini, semua hubungan SQLite pokok sekarang diadakan untuk peluang thread-sharing (dengan melewatkan atribut `check_same_thread=False` ke pysqlite). `DatabaseWrapper` bagaimanapun menjaga perilaku sebelumnya dengan meniadakan thread-sharing secara awalan, jadi ini tidak semua mempengaruhi kode yang ada yang murni bergantung pada ORM atau pada `DatabaseWrapper.cursor()`.

Akhirnya, selagi itu sekarang mungkin untuk melewatkan hubungan diantara thread, Django tidak membuat usaha apapun untuk menyelaraskan akses ke backend pokok. Perilaku berulang ditentukan oleh penerapan backend pokok. Periksa dokumentasi mereka untuk rincian.

### Pengaturan COMMENTS_BANNED_USERS_GROUP

Komentar Django mempunyai riwayat didukung mengeluarkan komentar dari kelompok pengguna khusus, tetapi kami tidak pernah mendokumentasikan fitur dengan benar dan tidak memaksa pengecualian di bagian lain dari aplikasi seperti etiket cetakan. Untuk memperbaiki masalah ini, kami telah menganjurkan kode dari kelas umpan.

Jika anda bergantung pada fitur dan ingin menyimpan kembali perilaku lama, gunakan penyesuaian pengelola model komentar untuk mengeluarkan kelompok pengguna, seperti ini:

    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

Simpan pengelola model ini di aplikasi komentar penyesuaian anda (sebagai contoh, di `my_comments_app/managers.py`) dan tambah itu ke model aplikasi komentar penyesuaian anda:

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

### Pengaturan IGNORABLE_404_STARTS dan IGNORABLE_404_ENDS

Sampai Django 1.3, itu memungkinkan mengeluarkan beberapa URL dari 404 error reporting Django dengan menambahkan awalan pada `IGNORABLE_404_STARTS` dan akhiran pada `IGNORABLE_404_ENDS`.

Di Django 1.4, kedua pengaturan ini adalah digantikan oleh `IGNORABLE_404_URLS`, yang sebuah daftar dari regular expression yang disusun. Django tidak akan mengirim sebuah surel untuk kesalahan 404 pada URL yang cocok dari tiap mereka.

Lebih lanjut, pengaturan sebelumnya mempunyai beberapa nilai awalan agak berubah-ubah:

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

Itu bukan peran Django untuk memutuskan jika situs jaringan anda mempunyai warisan bagian `/cgi-bin/` atau `favicon.ico`. Sebagai konsekuensi, nilai awalan dari `IGNORABLE_404_URLS`, `IGNORABLE_404_STARTS`, dan `IGNORABLE_404_ENDS` semua sekarang kosong.

Jika anda telah menyesuaikan `IGNORABLE_404_STARTS` atau `IGNORABLE_404_ENDS`, atau jika anda ingin menjaga nilai awalan lama, anda harus menambahkan baris-baris berikut ke berkas pengaturan anda:

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

Jangan lupa untuk meloloskan karakter yang mempunyai arti khusus di regular expression, seperti masa.

### Perlindungan CSRF diperpanjang pada PUT dan DELETE

Sebelumnya, CSRF protection Django menyediakan perlindungan hanya terhadap permintaan POST. Sejak penggunaan metode PUT dan DELETE di aplikasi AJAX menjadi lebih umum, kami sekarang melindungi semua metode tidak ditentukan sebagai aman oleh RFC 2616 -- yaitu, kami membebaskan GET, HEAD, OPTIONS dan TRACE, dan kami memaksa perlindungan yang lainnya.

Jika anda sedang menggunakan metode PUT atau DELETE di aplikasi AJAX, harap melihat instructions about using AJAX and CSRF.

### Tampilan penyetelan ulang sandi sekarang menerima `subject_template_name`

Tampilan `password_reset` di `django.contrib.auth` sekarang menerima sebuah parameter `subject_template_name`, yang dilewati ke formulir simpan sandi sebagai argumen kata kunci. Jika anda sedang menggunakan tampilan ini dengan penyesuaian formulir setel kembali sandi, kemudian anda akan butuh memastikan metode `save()` formulir anda menerima argumen kata kunci ini.

### `django.core.template_loaders`

Ini adalah nama lain pada `django.template.loader` sejak 2005, dan kami telah memindahkannya tanpa mengilangkan sebuah peringatan karena panjang dari pengusangan. Jika kode anda masih mengacu ini, harap gunakan `django.template.loader` sebagai gantinya.

### `django.db.models.fields.URLField.verify_exists`

Kegunaan ini telah dipindahkan karena masalah penampilan dan keamanan. Tiap penggunaan yang ada dari `verify_exists` harus dipindahkan.

### `django.core.files.storage.Storage.open`

Metode `open` dari kelas Penyimpanan dasar digunakan untuk mengambil sebuah parameter kabur `mixin` yang mengizinkan anda secara dinamis merubah perubahan kelas-kelas dasar dari obyek berkas yang dikembalikan. Ini telah dipindahkan. Di kasus yang jarang anda bergantung pada parameter `mixin`, anda dapat dengan mudah mencapai kesamaan dengan menimpa metode `open`, seperti ini:

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

### Deserializer YAML sekarang menggunakan `yaml.safe_load`

`yaml.load` dapat membangun obyek Python aapun, yang mungkin memicu pengerjaan kode berubah-ubah jika anda mengolah dokumen YAML yang datang dari sumber yang tidak dipercaya. Fitur ini tidak diperlukan untuk deserialisasi YAML Django, yang penggunaan utama adalah memuat perlengkapan terdiri dari obyek sederhana. Bahkan meskipun perlengkapan adalah data dipercaya, pendeserialisasi YAML sekarang menggunakan `yaml.safe_load` untuk keamanan tambahan.

### Kue sesi sekarang mempunyai bendera `httponly` secara awalan

Kue sesi sekarang menyertakan atribut `httponly` secara awalan untuk membantu mengurangi dampak dari peluang serangan XSS. Sebagai konsekuensi dari perubahan ini, data kue sesi, termasuk sessionid, tidak lagi dapat diakses dari JavaScript di banyak peramban. Untuk kesesuaian kebelakang yang ketat, gunakan `SESSION_COOKIE_HTTPONLY = False` di berkas pengaturan anda.

### Penyaring `urlize` tidak lagi meloloskan setiap URL

Ketika URL mengandung urutan `%xx`, dimana `xx` adalah dua angka heksadesimal. `urlize` sekarang menganggap bahwa URL sudah lolos dan tidak memberlakukan pelolosan URL kembali. Ini adalah salah untuk URL yang formulir tidak dikutipnya mengandung urutan `%xx`, tetapi URL tersebut sangat tidak mungkin terjadi di tidak teratur, karena mereka akan membingunkan peramban juga.

### `assertTemplateUsed` dan `assertTemplateNotUsed` sebagai pengelola konteks

Sekarang memungkinkan memeriksa apakah cetakan telah digunakan dalam blok kode dengan `assertTemplateUsed()` dan `assertTemplateNotUsed()`. Dan mereka dapat digunakan sebagai pengelola konteks:

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

Lihat assertion documentation untuk lebih.

### Sambungan absisdata setelah menjalankan rangkaian percobaan

Penjalan percobaan awalan tidak lagi menyimpan kembali hubungan basisdata setelah pengerjaan percobaan. Ini mencegah basisdata produksi dari menjadi terbuka pada kemungkinan ancaman yang akan masih berjalan dan berusaha untuk membuat hubungan baru.

Jika kode anda bergantung pada hubungan ke basisdata produksi sedang dibuat setelah pengerjaan percobaan, kemudian anda dapat menyimpan kembali perilaku sebelumnya dengan mensubkelaskan `DjangoTestRunner` dan menimpa metode `teardown_databases()` nya.

### Keluaran dari `manage.py help`

`manage.py help` sekarang mengelompokkan perintah tersedia oleh aplikasi. Jika anda bergantung pada keluaran dari perintah ini -- jika anda mengurainya -- kemudian anda akan butuh memperbaharui kode anda. Untuk mendapatkan daftar dari semua perintah pengelolaan yang tersedia di tulisan, gunakan `manage.py help --commands` sebagai gantinya.

### Etiket cetakan `extends`

Sebelumnya, etiket `extends` menggunakan metode penuh kesalahan dalam mengurai argumen, yang dapat membawa ke keliruan itu mengingat sebuah argumen sebagai harfiah deretan karakter ketika itu bukan. Itu sekarang menggunakan `parser.compile_filter`, seperti etiket lainnya.

Internal dari etiket bukan bagian dari API stabil resmi, tetapi dalam kepentingan dari penyingkapan penuh, pengertian `ExtendsNode.__init__` telah berubah, yang mungkin merusak tiap etiket penyesuaian yang menggungkan kelas ini.

### Memuat beberapa alat bantu yang tidak lengkap yang tidak lagi bekerja

Sebelum 1.4, nilai awalan telah dimasukkan untuk obyek alat bantu yang telah kehilangan tanggal khusus atau nilai datetime ketika auto_now_add telah disetel untuk bidang. Ini adalah sesuatu yang harus tidak dikerjakan, dan di 1.4 memuat alat bantu seperti itu akan gagal. Karena alat bantu adalah impor mentah, mereka harus secara eksplisit menentukan semua nilai bidang, tanpa memperhatikan pilihan bidang pada model.

### Development Server Multithreading

Peladen pengembangan sekarang multithread secara awalan. Gunakan pilihan `runserver --nothreading` untuk meniadakan penggunaan dari thread di peladen pengembangan:

    django-admin.py runserver --nothreading

### Peniadaan atribut diturunkan ketika mode aman disetel

Sebelum Django 1.4, atribut disertakan di tiap keluaran penurunan tanpa memperhatikan dari pengaturan suasana aman dari penyaring. Dengan versi > 2.1 dari pustaka Python-Markdown, sebuah pilihan enable_attributes telah ditambahkan. Ketika argumen aman dilewatkan ke penyaring penurunan, kedua pilihan `safe_mode=True` dan `enable_attributes=False` disetel. Jika menggunakan versi dari pustaka Python-Markdown kurang dari 2.1, sebuah peringatan diterbitkan yang keluarannya tidak aman.

### get_initial FormMixin mengembalikan sebuah kamus khusus-instance

Di Django 1.3, metode `get_initial` dari kelas `django.views.generic.edit.FormMixin` telah mengembalikan kelas initial` kamus. Ini telah diperbaiki untuk mengembalikan salinan dari kamus ini, jadi formulir instance dapat merubah data inisial mereka tanpa mengacaukan dengan variabel kelas.

## Fitur usang di 1.4

### Gaya lama dari memanggil penghias `cache_page`

Beberapa cara warisan dari memanggil `cache_page()` telah diusangkan. Harap lihat dokumentasi untuk cara benar untuk menggunakan penghias ini.

### Mendukung untuk PostgreSQL versi lebih lama dari 8.2

Django 1.3 membuang dukungan untuk versi PostgreSQL lebih lama dari 8.0, dan kami menyarankan menggunakan versi paling akhir karena dari penampilan perbaikan dan, lebih penting, akhir dari masa dukungan hulu untuk 8.0 dan 8.1 telah dekat (November 2010).

Django 1.4 mengambil kebijakan itu lebih jauh dan menyetel 8.2 sebagai versi PostgreSQL minimal itu secara resmi dukung.

### Permintaan pengecualian sekarang selalu dicatat

Ketika kami menambahkan logging support di Django di 1.3, dukungan surel kesalahan admin telah dipindahkan kedalam `django.utils.log.AdminEmailHandler`, dilampirkan ke pencatat `'django.request'`. Untuk merawat kebiasan yang terbangun dari surel kesalahan, pencatat `'django.request'` dipanggil hanya ketika `DEBUG` adalah `False`.

Untuk meningkatkan fleksibilitas dari pencatatan kesalahan untuk permintaan, pencatat `'django.request'` sekarang dipanggil tanpa memperhatikan nilai dari `DEBUG`, dan berkas pengaturan awalan untuk proyek baru sekarang menyertakan penyaring terpisah terlampir pada `django.utils.log.AdminEmailHandler` untuk mencegah surel kesalahan admin di suasana `DEBUG`:

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

Jika proyek anda telah dibuat sebelum perubahan ini, pengaturan `LOGGING` anda tidak akan menyertakan penyaring baru ini. Untuk merawat kesesuaian-kebelakang, Django akan mengetahui bahwa konfigurasi penangan `'mail_admins'` anda tidak menyertakan bagian `'filters'` dan akan secara otomatis menambah penyaring ini untuk anda dan masalah peringatan pengusangan-tertunda. Ini akan menjadi peringatan pengusangan di Django 1.5, dan di Django 1.6 shim kesesuaian-kebelakang akan dipindahkan sepenuhnya.

Kehadiran dari kunci `'filters'` apapun dibawah penangan `'mail_admins'` akan meniadakan shim kesesuaian-kebelakang ini dan peringatan pengusangan.

### `django.conf.urls.defaults`

Sampai Django 1.3, fungsi-fungsi `include()`, `patterns()`, dan `url()` ditambah `handler404` dan `handler500` ditempatkan dalam modul `django.conf.urls.defaults`.

Di Django 1.4, mereka berada di `django.conf.urls`.

### `django.contrib.databrowse`

Databrowse belum kelihatan pengembangan aktif untuk beberapa waktu, dan ini tidak menampilkan tanda apapun dari perubahan. Ada sebuah saran untuk GSOC project untuk memadukan kegunaan dari databrowse kedalam admin, tetapi tidak ada kemajuan yang dibuat. Selagi Databrowse telah diusangkan, sebuah peningkatan dari `django.contrib.admin` menyediakan sekumpulan fitur yang mirip masih memungkinkan.

Kode yang memberikan daya Databrowse berlisensi dibawah ketentuan sama seperti Django itu sendiri, jadi itu tersedia untuk di pungut oleh perorangan atau kelompok sebagai proyek pihak-ketiga.

### `django.core.management.setup_environ`

Fungsi ini sementara merubah `sys.path` untuk membuat direktori "proyek" induk dapat diimpor dibawah tata letak datar `startproject` yang lama. Fungsi ini sekarang diusangkan, ketika pemecahan jalurnya tidak lagi dibutuhkan dengan `manage.py` baru dan tata letak proyek awalan.

Fungsi ini tidak pernah didokumentasikan atau bagian dari API umum, tetapi itu sangat luas dianjurkan untuk digunakan di pengaturan "Django environment" untuk tulisan pengguna. Penggunaan ini harus diganti dengan mengatur variabel lingkungan `DJANGO_SETTINGS_MODULE` atau menggunakan `django.conf.settings.configure()`.

### `django.core.management.execute_manager`

Fungsi ini sebelumnya digunakan oleh `manage.py` untuk menjalankan perintah pengelolaan. Itu mirip pada `django.core.management.execute_from_command_line`, kecuali bahwa itu pertama memanggil `setup_environ`, yang sekarang diusangkan. Dengan demikian, `execute_manager` juga diusangkan; `execute_from_command_line` dapat digunakan sebagai gantinya. Tidak ada dari fungsi ini didokumentasikan sebagai bagian dari API umum, tetapi jalur pengusangan dibutuhkan karena untuk digunakan di berkas `manage.py` yang ada.

### Atribut is_safe` dan `needs_autoescape` dari cetakan penyaring

Dua bendera, `is_safe` dan``needs_autoescape``, menentukan bagaimana setiap penyaring cetakan berinteraksi dengan perilaku pelolosan-otomatis Django. Mereka digunakan untuk menjadi atribut dari fungsi penyaring:

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

Bagaimanapun, teknik ini menyebabkan beberapa masalah di perpaduan dengan penghias, khususnya `@stringfilter`. Sekarang, bendera adalah argumen kata kunci dari `@register.filter`:

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

Lihat filters and auto-escaping untuk informasi lebih.

### Perluasan wildcard dari nama aplikasi di INSTALLED_APPS

Sampai DJango 1.3, `INSTALLED_APPS` menerima wildcard di nama aplikasi, seperti `django.contrib.*`. Perluasan telah dilakukan dengan penerapan berdasarkan-sistem berkas dari `from <package> import *`. Sayangnya, ini tidak dapat dilakukan secara handal.

Perilaku ini tidak pernah didokumentasikan. Sejak itu adalah bukan python dan tidak jelas berguna, itu telah dipindahkan di Django 1.4. Jika anda bergantung pada itu, anda harus menyunting berkas pengaturan anda ke daftar semua aplikasi anda secara eksplisit.

### `HttpRequest.raw_post_data` dinamai kembali menjadi `HttpRequest.body`

Atribut ini membingungkan bernama `HttpRequest.raw_post_data`, tetapi itu sebenarnya disediakan badan dari permintaan HTTP. Itu telah dinamai menjadi `HttpRequest.body`, dan `HttpRequest.raw_post_data` telah diusangkan.

### Perbaikan kesalahan `django.contrib.sitemaps` dengan peluang keterlibatan penampilan

Di versi sebelumnya, obyek `Paginator` digunakan di kelas-kelas peta situs telah disembunyikan, yang dapat menghasilkan di peta situs basi. Kami telah memindahkan penyembunyian, jadi setiap permintaan pada sebuah peta situs sekarang membuat obyek Paginator baru dan memanggil metode `items()` dari subkelas `Sitemap`. Tergantung pada apa metode `items()``anda lakukan, ini mungkin mempunyai dampak penampilan negatif, pertimbangkan menggunakan :doc:`caching framework </topics/cache>` dalam subkelas ``Sitemap` anda.

### Versi dari Python-Markdown lebih awal daripada 2.1

Versi dari Python-Markdown paling awal dari 2.1 tidak mendukung pilihan untuk meniadakan atribut. Seperti masalah keamanan, versi paling awal dari pustaka ini tidak akan didukung oleh aplikasi bantuan markah di 1.5 dibawah linimasa pengusangan dipercepat.