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.

For instance, with the following layout:

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.

Anything imported as a top-level module can be placed adjacent to the new manage.py. For instance, to decouple myapp from the project module and import it as just myapp, place it outside the mysite/ directory:

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.

For example, Django will use the /path/to/my_project_template directory when you run the following command:

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

You can also now provide a destination directory as the second argument to both 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.

The built-in development server now supports using an externally-defined WSGI callable, which makes it possible to run runserver with the same WSGI configuration that is used for deployment. The new WSGI_APPLICATION setting lets you configure which WSGI callable runserver uses.

(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 adds both a low-level API for signing values and a high-level API for setting and reading signed cookies, one of the most common uses of signing in web applications.

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 can now look for a language prefix in the URLpattern when using the new i18n_patterns() helper function. It's also now possible to define translatable URL patterns using django.utils.translation.ugettext_lazy(). See Internasionalisasi: dalam pola URL for more information about the language prefix and how to internationalize URL patterns.

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

The staticfiles contrib app has a new static template tag to refer to files saved with the STATICFILES_STORAGE storage backend. It uses the storage backend's url method and therefore supports advanced features such as serving files from a cloud service.

Backend penyimpanan CachedStaticFilesStorage

The staticfiles contrib app now has a django.contrib.staticfiles.storage.CachedStaticFilesStorage backend that caches the files it saves (when running the collectstatic management command) by appending the MD5 hash of the file's content to the filename. For example, the file css/styles.css would also be saved as css/styles.55e7cbb9ba48.css

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 Bentuk lokalisasi:

• 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 untuk 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.

• The makemessages command uses a new and more accurate lexer, JsLex, for extracting translatable strings from JavaScript files.

• 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.

• A new, plain-text, version of the HTTP 500 status code internal error page served when DEBUG is True is now sent to the client when Django detects that the request has originated in JavaScript code. (is_ajax() is used for this.)

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

• The admin login page will add a password reset link if you include a URL with the name 'admin_password_reset' in your urls.py, so plugging in the built-in password reset mechanism and making it available is now much easier. For details, see 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.

In Django 1.4, starting Django with an empty SECRET_KEY will raise a DeprecationWarning. In Django 1.5, it will raise an exception and Django will refuse to start. This is slightly accelerated from the usual deprecation path due to the severity of the consequences of running Django with no 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.

Starting in Django 1.4, the admin's static files also follow this convention, to make the files easier to deploy. In previous versions of Django, it was also common to define an ADMIN_MEDIA_PREFIX setting to point to the URL where the admin's static files live on a web server. This setting has now been deprecated and replaced by the more general setting STATIC_URL. Django will now expect to find the admin static files under the URL <STATIC_URL>/admin/.

If you've previously used a URL path for ADMIN_MEDIA_PREFIX (e.g. /media/) simply make sure STATIC_URL and STATIC_ROOT are configured and your web server serves those files correctly. The development server continues to serve the admin files just like before. Read the static files howto for more details.

If your ADMIN_MEDIA_PREFIX is set to a specific domain (e.g. http://media.example.com/admin/), make sure to also set your STATIC_URL setting to the correct URL -- for example, 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.

Released over 10 years ago, IE6 imposes many limitations on modern web development. The practical implications of this policy are that contributors are free to improve the admin without consideration for these limitations.

This new policy has no impact on sites you develop using Django. It only applies to the Django admin. Feel free to develop apps compatible with any range of browsers.

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.

  • Time period: Defined by PASSWORD_RESET_TIMEOUT_DAYS.

Form-related hashes: these have a much shorter lifetime and are relevant only for the short window where a user might fill in a form generated by the pre-upgrade Django instance and try to submit it to the upgraded Django instance:

• 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.

As part of this change, all underlying SQLite connections are now enabled for potential thread-sharing (by passing the check_same_thread=False attribute to pysqlite). DatabaseWrapper however preserves the previous behavior by disabling thread-sharing by default, so this does not affect any existing code that purely relies on the ORM or on 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.

COMMENTS_BANNED_USERS_GROUP setting

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

IGNORABLE_404_STARTS and IGNORABLE_404_ENDS settings

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

Session cookies now include the httponly attribute by default to help reduce the impact of potential XSS attacks. As a consequence of this change, session cookie data, including sessionid, is no longer accessible from JavaScript in many browsers. For strict backwards compatibility, use SESSION_COOKIE_HTTPONLY = False in your settings file.

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

The development server is now is multithreaded by default. Use the runserver --nothreading option to disable the use of threading in the development server:

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:

LOGGING = {
    # ...
    "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.

This function was never documented or part of the public API, but it was widely recommended for use in setting up a "Django environment" for a user script. These uses should be replaced by setting the DJANGO_SETTINGS_MODULE environment variable or using 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.

Wildcard expansion of application names in 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.

This behavior was never documented. Since it is unpythonic, it was removed in Django 1.4. If you relied on it, you must edit your settings file to list all your applications explicitly.

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.