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:

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.

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.

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.

Back to Top