Catatan terbitan Django 1.7

September 2, 2014

Selamat datang ke Django 1.7!

Catatan terbitan ini melingkupi new features, sama halnya beberapa backwards incompatible changes anda ingin sadari dari ketika meningkatkan dari Django 1.6 atau versi terlama. Kami telah begun the deprecation process for some features, dan beberapa fitur telah mencapai akhir dari pengolahan pengusangan mereka dan have been removed.

Kesesuaian Python

Django 1.7 membutuhkan Python 2.7, 3.2, 3.3 atau 3.4. Kami sangat menganjurkan dan hanya secara resmi mendukung terbitan terakhir dari setiap rangkaian.

Rangkaian Django 1.6 adalah dukungan terakhir Python 2.6 Django 1.7 adalah terbitan pertama untuk mendukung Python 3.4.

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

Apa yang baru di Django 1.7

Skema perpindahan

Django sekarang mempunyai dukungan siap-pakai untuk skema perpindahan. Itu mengizinkan untuk diperbaharui, dirubah, dan dihapus dengan membuat berkas-berkas perpindahan yang mewakili model perubahan dan yang dapat berjalan pada pengembangan, pementasan atau basisdata produk apapun.

Perpindahan tercakup di their own documentation, tetapi sedikit dari fitur kunci adalah:

  • syncdb telah diusangkan dan diganti oleh migrate. Jangan khawatir - panggil syncdb akan masih dapat bekerja seperti sebelumnya.

  • Sebuah perintah makemigrations menyediakan sebuah cara mudah untuk menemukan otomatis perubahan ke model anda dan membuat perpindahan untuk mereka

    django.db.models.signals.pre_syncdb dan django.db.models.signals.post_syncdb telah diusangkan, untuk diganti oleh pre_migrate dan post_migrate masing-masing. Sinyal baru ini sedikit berbeda argumen. Periksa dokumentasi untuk rincian.

  • Metode allow_syncdb di perute basisdata sekarang dipanggil allow_migrate, tetapi masih melakukan fungsi sama. Perute dengan metode allow_syncdb akan masih bekerja, tetapi nama metode itu diusangkan dan anda harus merubah itu secepatnya (tidak ada yang lebih dari menamai kembali adalah wajib).

  • Alat bantu initial_data tidak lagi dimuat untuk aplikasi dengan perpindahan; jika anda ingin memuat data inisial untuk sebuah aplikasi, kami menyarankan anda membuat sebuah perpindahan untuk aplikasi anda dan menentukan sebuah tindakan RunPython atau RunSQL di bagian operations dari perpindahan.

  • Perilaku kembali percobaan adalah berbeda untuk aplikasi dengan perpindahan; khususnya, Django akan tidak lagi meniru kembali di basisdata bukan-transaksi atau didalam TransactionTestCase unless specifically requested.

  • Itu tidak disarankan untuk memiliki aplikasi tanpa perpindahan bergantung di (mempunyai sebuah ForeignKey atau ManyToManyField pada) aplikasi dengan perpindahan.

Refaktor memuat-aplikasi

Secara riwayat, aplikasi Django terkait erat ke model. Sebuah singleton dikenal sebagai "app cache" ditangani dengan kedia aplikasi terpasang dan model. Modul model digunakan sebagai sebuah penciri untuk aplikasi di banyak API.

Ketika konsep dari Django applications jatuh tempo, kode ini menunjukkan beberapa kekurangan. Itu telah di refaktor kedalam sebuah "app registry" dimana modul model tidak lagi mempunyai peran utama dan dimana itu memungkinkan melampirkan data konfigurasi ke apliaksi.

Perbaikan sejauh ini termasuk:

  • Aplikasi dapat menjalankan kode saat mulai, sebelum Django melakukan apapun lain, dengan metode ready() dari konfigurasi mereka.
  • Label aplikasi diberikan secara benar pada model bahkan ketika mereka ditentukan diluar dari models.py. Anda tidak harus menyetel app_label dengan jelas lagi.
  • Itu memungkinkan menghilangkan models.py sepenuhnya jika sebuah aplikasi tidak mempunyai model apapun.
  • Aplikasi dapat di label ulang dengan atribut label dari konfigurais aplikasi, untuk memecahkan bentrokan label.
  • Nama dari aplikasi dapat disesuaikan di admin dengan verbose_name dari konfigurasi aplikasi.
  • Admin secara otomatis memanggil autodiscover() ketika Django mulai. Anda dapat oleh karena itu memindahkan baris ini dari URLconf anda.
  • Django impor semua konfigurasi aplikasi dan model segera setelah itu mulai, melalui proses deterministik dan terus terang. Ini harus membuatnya lebih mudah untuk menentukan masalah import seperti perulangan impor.

Metode baru di subkelas Field

Untuk menggerakkan kedua skema perpindahan dan mengadakan penambahan lebih mudah dari kunci gabungan di fitur terbitan dari Django, API Field sekarang mempunyai metode wajib baru: deconstruct().

Metode ini tidak mengambil argumen, dan mengembalikan sebuah tuple dari empat barang:

  • name: Nama atribut bidang di model induknya, atau None jika itu adalah bukan bagian dari sebuah model.
  • path: Sebuah bertitik, jalur Python pada kelas dari bidang ini, termasuk nama kelas.
  • args: Argumen penempatan, seperti sebuah daftar
  • kwargs: Argumen kata kuncu, seperti sebuah kamus

Empat nilai ini mengizinkan bidang apapun untuk di serialisasi kedalam sebuah berkas, sama halnya mengizinkan bidang untuk disalin secara aman, kedua bagian penting dari fitur baru ini.

Perubahan ini tidak harus mempengaruhi anda meskipun anda menulis penyesuaian subkelas Bidang; jika anda melakukan, anda mungkin butuh menerapkan kembali metode deconstruct() jika subkelas anda merubah metode tandatangan dari __init__ di cara apapun. Jika bidang anda hanya warisan dari bidang Django siap-pakai dan tidak menimpa __init__, tidak ada perubahan diperlukan.

Jika anda perlu melakukan untuk menimpa deconstruct(), sebuah tempat bagus untuk memulai adalah bidang Django siap-pakai (django/db/models/fields/__init__.py) sebagai beberapa bidang, termasuk DecimalField dan DateField, kesampingkan itu dan tunjukkan bagaimana memanggil metode pada superkelas dan cukup tambah atau pindahkan argumen tambahan.

Ini juga berarti bahwa semua argumen pada bidang harus mereka sendiri diserialisasikan; untuk melihat apa kami anggap dapat serial, dan untuk menemukan bagaimana membuat kelas anda sendiri dapat serial, baca migration serialization documentation.

Memanggil metode QuerySet penyesuaian dari Manager

Secara riwayat, cara yang dianjurkan untuk membuat permintaan model yang digunakan kembali adalah membuat metode di kelas Manager penyesuaian. Masalah dengan pendekatan ini adalah setelah panggilan metode pertama, anda akan mendapatkan kembali instance QuerySet dan tidak dapat memanggil tambahan metode pengelola penyesuaian.

Meskipun tidak didokumentasikan, itu adalah umum untuk memecahkan masalah ini dengan membuat penyesuaian QuerySet sehingga metode penyesuaian dapat dirantai; tetapi pemecahan mempunyai sebuah angka dari pengembalian:

  • Penyesuaian QuerySet` dan metode penyesuainnya telah hilang setelah panggilan pertama pada values() atau values_list().
  • Menulis sebuah penyesuaian Manager masih dibutuhkan untuk mengembalikan kelas QuerySet penyesuaian dan semua metode yang diinginkan di Manager harus di proxykan ke QuerySet. Pengolahan seluruhnya bertentangan dengan prinsip DRY.

Metode kelas QuerySet.as_manager() sekarang secara langsung create Manager with QuerySet methods:

class FoodQuerySet(models.QuerySet):
    def pizzas(self):
        return self.filter(kind='pizza')

    def vegetarian(self):
        return self.filter(vegetarian=True)

class Food(models.Model):
    kind = models.CharField(max_length=50)
    vegetarian = models.BooleanField(default=False)
    objects = FoodQuerySet.as_manager()

Food.objects.pizzas().vegetarian()

Menggunakan penyesuaian pengelola ketika melintasi hubungan balikan

Itu sekarang memungkinkan untuk specify a custom manager ketika melewati lintas hubungan:

class Blog(models.Model):
    pass

class Entry(models.Model):
    blog = models.ForeignKey(Blog)

    objects = models.Manager()  # Default Manager
    entries = EntryManager()    # Custom Manager

b = Blog.objects.get(id=1)
b.entry_set(manager='entries').all()

Kerangka sistem pemeriksaan baru

Kami telah menambahkan System check framework baru untuk mengenali masalah-masalah umum (seperti model tidak sah) dan menyediakan petunjuk untuk menyelesaikan masalah-masalah tersebut. Kerangka dapat diperpanjang jadi anda dapat menambah pemeriksaan anda sendiri untuk aplikasi dan pustaka anda sendiri.

Untuk melakukan pemeriksaan sistem, anda menggunakan perintah pengelolaan check. Perintah ini menggantikan perintah pengelolaan validate lama.

Jalan pintas admin mendukung zona waktu

Jalan pintas "today" dan "now" dekat dengan widget masukan tanggal dan waktu di admin sekarang beroperasi di current time zone. Sebelumnya, mereka menggunakan zona waktu peramban, yang dapat menghasilkan dalam menyimpan nilai salah ketika itu tidak cocok zona waktu saat ini di peladen.

Sebagai tambahan, widget sekarang menampilkan pesna bantuan ketika peramban dan zona waktu peladen berbeda, untuk menjelaskan bagaimana nilai dimasukkan di bidang akan ditafsirkan.

Menggunakan kursor basisdata sebagai pengelola konteks

Sebelum Python 2.7, kursor basisdata dapat digunakan sebagai pengelola konteks. Kursor backend khusus menentukan perilaku dari pengelola konteks. Perilaku ini dari pencarian metode ajaib telah berubah dengan Python 2.7 dan kursor tidak lagi digunakan sebagai pengelola konteks.

Django 1.7 mengizinkan sebuah kursor digunakan sebagai pengelola konteks. Yaitu, berikut dapat digunakan:

with connection.cursor() as c:
    c.execute(...)

dari pada:

c = connection.cursor()
try:
    c.execute(...)
finally:
    c.close()

Penyesuaian Pencarian

Itu sekarang memungkinkan menulis pencarian penyesuaian dan merubah untuk ORM. Pencarian penyesuaian bekerja seperti pencarian siap-pakai Django (sebagai contoh lte, icontains) selagi perubahan adalah konsep baru.

Kelas django.db.models.Lookup menyediakan sebuah cara untuk menambah penghubung pencarian untuk bidang model. Ketika sebuah contoh itu memungkinkan untuk menambah penghubung day_lte untuk DateFields.

Kelas django.db.models.Transform megnizinkan perubahan dari nilai basisdata sebelum pencarian akhir. Sebagai contoh itu memungkinkan menulis sebuah perubahan year yang mengeluarkan tahun dari nilai bidang. Perubahan mengizinkan untuk mengikat. Setelah perubahan year telah ditambahkan ke DateField itu memungkinkan untuk menyaring di nilai berubah, sebagai contoh qs.filter(author__birthdate__year__lte=1981).

Untuk informasi lebih mengenai kedua penyesuaian pencarian dan perubahan mengacu ke dokumentasi custom lookups.

Perbaikan pada penanganan kesalahan Form

Form.add_error()

Sebelumnya ada dua pola utama untuk menangani kesalahan di formulir:

  • Memunculkan sebuah ValidationError dari dalam fungsi tertentu (sebagai contoh Field.clean()`, Form.clean_<fieldname>(), atau Form.clean() untuk kesalahan-kesalahan bukan-bidang.)
  • Meremehkan dengan Form._errors ketika menyasar sebuah bidang khusus di Form.clean() atau menambahkan kesalahan diluar dari metode "clean" (sebagai contoh langsung dari sebuah tampilan).

Menggunakan pola sebelumnya adalah mudah sejak formulir dapat menebak dari konteks (yaitu metode mana memunculkan pengecualian) dimana kesalahan milik dan secara otomatis mengolah mereka. Ini tetap cara resmi dari menambah kesalahan ketika memungkinkan. Bagaimanapun terakhir adalah tipuan dan cenderung-kesalahan, sejak tanggungan dari penanganan sisi kasus jatuh di pengguna.

Metode add_error() baru mengizinkan menambahkan kesalahan ke bidang formulir khusus dari manapun tanpa khawatir tentang rincian seperti membuat instance dari django.forms.utils.ErrorList atau berurusan dengan Form.cleaned_data. API baru ini mengganti merubah Form._errors yang sekarang menjadi API pribadi.

Lihat Membersihkan dan memeriksa bidang yang tergantung satu sama lain untuk sebuah contoh menggunakan Form.add_error().

Kesalahan metadata

Pembangun ValidationError menerima metadata seperti kesalahan code atau params yang kemudian tersedia untuk menambahkan kedalam pesan kesalahan (lihat Membangkitkan ValidationError untuk lebih rinci); bagaimanapun, sebelum Django 1.7 metadata tersebut dibuang segera setelah kesalahan ditambahkan ke Form.errors.

Form.errors dan django.forms.utils.ErrorList sekarang menyimpan instance ValidationError sehingga metadata ini dapat diambil kapanpun melalui metode Form.errors.as_data baru.

Instance ValidationError yang diambil dapat kemudian dicirikan terima kasih ke code kesalahan mereka yang mengadakan hal-hal seperti menulis kembali pesan kesalahan atau menulis penyesuaian logika di sebuah tampilan ketika kesalahan yang diberikan hadir. Itu dapat juga digunakan untuk menserialkan kesalahan di penyesuaian bentuk seperti XML.

Metode Form.errors.as_json() baru adalah sebuah metode nyaman yang mengembalikan pesan kesalahan bersama dengan kode kesalahan diserialkan sebagai JSON. as_json() menggunakan as_data() dan memberikan sebuah ide dari bagaimana sistem baru dapat diperpanjang.

Wadah kesalahan dan kesesuaian kebelakang

Perubahan berat pada beragam wadah kesalahan dibutuhkan untuk mendukung fitur diatas, khususnya Form.errors, django.forms.utils.ErrorList, dan pengimpanan internal dari ValidationError. Wadah ini yang digunakan untuk menyimpan string kesalahan sekarang menyimpan instance ValidationError dan API umum telah disesuaikan untuk membuat ini sejernih mungkin, tetapi jika anda telah menggunakan API pribadi, beberapa dari perubahan adalah ketidaksesuaian kebelakang; lihat Pembangun ValidationError dan penyimpanan internal untuk lebih rinci.

Fitur kecil

django.contrib.admin

  • Anda sekarang dapat menerapkan atribut site_header, site_title, dan index_title pada AdminSite penyesuaian agar dengan mudah merubah judul halaman situs admin dan teks kepala. Tidak perlu lagi menimpa cetakan!
  • Tombol di django.contrib.admin sekarang menggunakan sifat CSS border-radius untuk sudut melingkar daripada gambar latar belakang GIF.
  • Beberapa cetakan admin sekarang mempunyai kelas-kelas app-<app_name> dan model-<model_name> di etiket <body> mereka untuk mengizinkan menyesuaikan CSS per aplikasi atau per model.
  • Sel-sel daftar rubah admin sekarang mempunyai sebuah kelas field-<field_name> di THML untuk mengadakan gaya penyesuaian.
  • Bidang pencarian admin sekarang dapat disesuaikan per-permintaan terima kasih ke metode django.contrib.admin.ModelAdmin.get_search_fields() baru.
  • Metode ModelAdmin.get_fields() mungkin dikesampingkan untuk menyesuaikan nilai dari ModelAdmin.fields.
  • Sebagai tambahan pada sintaksis admin.site.register yang ada, anda dapat menggunakan penghias register() baru untuk mendaftar sebuah ModelAdmin.
  • Anda dapat menentukan ModelAdmin.list_display_links = None untuk meniadakan tautan pada jaring halaman daftar perubahan.
  • Anda dapat sekarang menentukan ModelAdmin.view_on_site untuk mengendalikan apakah atau tidak untuk menampilkan tautan "Lihat pada situs".
  • Anda dapat menentukan urutan menurun untuk nilai ModelAdmin.list_display dengan mengawali nilai admin_order_field dengan tanda penghubung
  • Metode ModelAdmin.get_changeform_initial_data() mungkin dikesampingkan untuk menentukan penyesuaian perilaku untuk mengatur perubahan awalan data formulir.

django.contrib.auth

django.contrib.formtools

  • Panggilan pada WizardView.done() sekarang menyertakan form_dict untuk mengizinkan pengaksesan lebih mudah pda formulir berdasarkan nama langkah mereka.

django.contrib.gis

  • Versi pustaka OpenLayer awalan disertakan di widget telah diperbaharui dari 2.11 menjadi 2.13.
  • Gemoteri dipersiapkan sekarang juga mendukung sebutan crosses, disjoint, overlaps, touches dan within, jika GEOS 3.3 atau terakhir terpasang.

django.contrib.messages

django.contrib.redirects

django.contrib.sessions

  • Backend sesi "django.contrib.sessions.backends.cached_db" sekarang menghormati SESSION_CACHE_ALIAS. Di versi sebelumnya, itu selalu menggunakan cache default.

django.contrib.sitemaps

django.contrib.sites

django.contrib.staticfiles

  • static files storage classes mungkin di subkelaskan untuk menimpa perizinan yang mengumpulkan berkas-berkas tetap dan direktori menerima dengan mengatur parameter file_permissions_mode dan directory_permissions_mode. Lihat collectstatic untuk contoh penggunaan.

  • Backend CachedStaticFilesStorage mendapatkan kelas saudara kandung dipanggil ManifestStaticFilesStorage yang tidak menggunakan sistem penyembunyian pada semua tetapi malahan berkas JSON dipanggil staticfiles.json untuk menyimpan pemetaan diantara nama berkas asli (sebagai contoh css/styles.css) dan nama berkas dicampur (sebagai contoh css/styles.55e7cbb9ba48.css). Berkas staticfiles.json dibuat ketika menjalankan perintah pengelolaan collectstatic dan harus sedikit alternatif mahal untuk penyimpanan terpencil seperti Amazon S3.

    Lihat dokumentasi ManifestStaticFilesStorage untuk informasi lebih.

  • findstatic sekarang menerima bendera terlalu banyak kata tingkat 2, berarti itu akan menunjukkan jalur relatif dari direktori itu cari. Lihat findstatic untuk contoh keluaran.

django.contrib.syndication

  • Unsur updated``umpan perkongsian :class:`~django.utils.feedgenerator.Atom1Feed` sekarang memanfaatkan ``updateddate daripada pubdate, mengizinkan unsur published untuk disertakan di umpan (yang bergantung pada pubdate).

Tembolok

  • Akses ke cache dikonfigurasikan di CACHES sekarang tersedia melalui django.core.cache.caches. Obyek seperti-kamus ini menyediakan instance berbeda per thread. Itu menggantikan django.core.cache.get_cache() yang sekarang diusangkan.
  • Jika anda menginstasiasi backend cache secara langsung, waspada mereka tidak thread-safe lagi, ketika django.core.cache.caches sekarang menghasilkan instance berbeda per thread.
  • Menentukan argumen TIMEOUT dari pengaturan CACHES sebagai None akan menyetel kunci cache sebagai "non-expiring" secara awalan. Sebelumnya, itu hanya memungkinkan melewatkan timeout=None ke metode set() backend cache.

Cross Site Request Forgery

  • Pengaturan CSRF_COOKIE_AGE mempermudah penggunaan kue CSRF berbasis sesi.

Surel

  • send_mail() sekarang menerima sebuah parameter html_message untuk mengirim banyak bagian text/plain dan text/html surel.
  • EmailBackend SMTP sekarang menerima parameter timeout.

Penyimpanan Berkas

  • Penguncian berkas di Windows sebelumnya terbantung di paket PyWin32; jika itu tidak dipasang, penguncian berkas gagal secara diam. Ketergantungan itu telah dipindahkan, dan penguncian berkas sekarang diterapkan asli di kedua Windows dan Unix.

Unggah Berkas

  • Atribut UploadedFile.content_type_extra baru mengandung parameter tambahan dilewatkan ke kepala content-type di sebuah unggah berkas.
  • Pengaturan FILE_UPLOAD_DIRECTORY_PERMISSIONS baru mengendalikan perizinan sistem berkas dari direktori dibuat selama unggah berkas, seperti FILE_UPLOAD_PERMISSIONS lakukan untuk berkas-berkas mereka sendiri.
  • Atribut FileField.upload_to sekarang pilihan. Jika itu dihilangkan atau diberikan None atau sebuah string kosong, sebuah subdirektori tidak akan digunakan untuk menyimpan berkas terunggah.
  • Berkas-berkas terunggah sekarang secara eksplisit tertutup sebelum tanggapan dikirimkan ke klien. Sebagian berkas terunggah juga ditutup selama mereka bernama file di penangan unggahan.
  • Storage.get_available_name() sekarang menambah sebuah garis bawah ditambah 7 karakter alphanumerik string acak (sebagai contoh "_x3a1gho"`), daripada mengulang melalui sebuah garis bawah diikuti oleh sebuah angka (sebagai contoh "_1", "_2", dll) untuk mencegah serangan denial-of-service. Perubahan ini juga dibuat di terbitan keamanan 1.6.6, 1.5.9, dan 1.4.14.

Formulir

  • Etiket <label> dan <input> dibangun oleh RadioSelect dan CheckboxSelectMultiple ketika mengulang tombol radio atau kontak centang sekarang menyertakan atribut for dan id, masing-masing. Setiap tombol radio atau kotak centang menyertakan sebuah atribut id_for_label untuk mengeluarkan unsur ID.
  • Etiket <textarea> dibangun oleh Textarea sekarang menyertakan sebuah atribut maxlength jika bidang model TextField mempunyai max_length.
  • Field.choices sekarang mengizinkan anda untuk menyesuaikan label "empty choice" dengan menyertakan sebuah tuple dengan string kosong atau None untuk kunci dan penyesuaian label sebagai nilai. Pilihan kosong awalan "----------" akan dihilangkan di kasus ini.
  • MultiValueField mengizinkan pilihan subbidang dengan mengatur argumen require_all_fields menjadi False. Atribut required untuk setiap bidang tersendiri akan dihormati, dan pengesahan kesalahan incomplete baru akan dimunculkan ketika setiap bidang yang diwajibkan adalah kosong.
  • Metode clean() di sebuah formulir tidak lagi butuh mengembalikan self.cleaned_data. Jika itu mengembalikan sebuah kamus dirubah meudian itu akan masih digunakan.
  • Setelah pemulihan sementara di Django 1.6, itu sekarang memungkinkan kembali untuk membuat metode coerce TypedChoiceField mengembalikan sebuah nilai yang berubah-ubah.
  • SelectDateWidget.months dapat digunakan untuk menyesuaikan rumus dari bulan ditampilkan di pilihan widget.
  • Parameter min_num dan validate_min telah ditambahkan pada formset_factory() untuk mengizinkan pengecekan angka minimal dari formulir yang diajukan.
  • Meta kelas digunakan oleh Form dan ModelForm telah dikerjakan kembali untuk mendukung skenario warisan lebih. Batasan sebelumnya yang mencegah pewarisan dari kedua Form dan ModelForm terus menerus telah dipindahkan asalkan ModelForm muncul pertama di MRO.
  • Sekarang memungkinkan memindahkan sebuah bidang dari Form ketika mensubkelaskan dengan mengatur nama ke None.
  • Itu sekarang memungkinkan untuk menyesuaikan pesan kesalahan untuk ModelForm unique, unique_for_date, dan batasan unique_together. Untuk mendukung unique_together atau setiap NON_FIELD_ERROR lain, ModelForm sekarang mencari kunci NON_FIELD_ERROR di kamus error_messages dari ModelForm sebelah dalam kelas Meta. Lihat considerations regarding model's error_messages untuk lebih rincian.

Internasionalisasi

  • Atribut django.middleware.locale.LocaleMiddleware.response_redirect_class mengizinkan anda menyesuaian masalah pengalihan oleh middleware.
  • LocaleMiddleware sekarang menyimpan bahasa terpilih pengguna dengan kunci sesi _language. Ini harus hanya bisa diakses menggunakan konstanta LANGUAGE_SESSION_KEY. Sebelumnya itu disimpan dengan kunci konstanta django_language dan LANGUAGE_SESSION_KEY``tidak ada, tetapi kunci disimpan untuk Django harus mulai dengan sebuah garis bawah. Untuk kesesuaian kebelakang ``django_language masih membaca dari di 1.7. Sesi akan dipindahkan ke kunci baru ketika mereka ditulis.
  • Etiket blocktrans sekarang mendukung sebuah pilihan trimmed. Pilihan ini akan memindahkan karakter baris baru dari awal dan akhir dari isi dari etiket {% blocktrans %}, ganti setiap ruang kosong pada awal dan akhir dari sebuah baris dan menggabungkan semua baris kedalam satu menggunakan karakter ruang kosong untuk memisahkan mereka. Ini sangat berguna untuk melekukkan isi dari etiket {% blocktrans %} tanpa memiliki karakter lekukan terakhir di masukan yang sesuai di berkas PO, yang membuat pengolahan terjemahan lebih mudah.
  • Ketika anda menjalankan makemessages dari direktori akar dari proyek anda, setiap string yang diambil akan sekarang otomatis disebarkan ke aplikasi sesuai atau berkas pesan proyek. Lihat Lokalisasi: bagaimana membuat berkas-berkas bahasa untuk rincian.
  • Perintah makemessages sekarang selalu menambah bendera baris perintah --previous ke perintah msgmerge, menjaga string terjemahan sebelumnya di berkas po untuk string tidak jelas.
  • Pengaturan berikut untuk menyesuaikan pilihan kue bahasa diperkenalkan LANGUAGE_COOKIE_AGE, LANGUAGE_COOKIE_DOMAIN dan LANGUAGE_COOKIE_PATH.
  • Ditambahkan Format localization untuk Esperanto

Pengelolaan perintah

  • Pilihan --no-color baru untuk django-admin meniadakan pewarnaan dari keluaran perintah pengelolaan.

  • Pilihan option:dumpdata --natural-foreign dan dumpdata --natural-primary baru, dan argumen use_natural_foreign_keys dan use_natural_primary_keys baru untuk serializers.serialize(), mengizinkan penggunaan primary key alami ketika serialisasi.

  • Itu tidak butuh lagi menyediakan nama tabel cache atau pilihan --database untuk perintah createcachetable. Django mengambil informasi ini dari berkas pengaturan anda. Jika anda telah mengkonfigurasikan banyak cache atau banyak basisdata, semua tabel cache dibuat.

  • Perintah runserver menerima beberapa perbaikan:

    • Di sistem Linux, jika pyinotify terpasang, peladen pengembangan akan memuat ulang segera ketika sebuah berkas berubah. Sebelumnya, itu menanyai sistem berkas untuk perubahan setiap detik. Itu menyebabkan penundaan kecil sebelum memuat kembali dan mengurangi hidup baterai di laptop.
    • Sebagai tambahan, peladen pengembangan secara otomatis memuat kembali kketika berkas terjemahan diperbaharui, yaitu setelah menjalankan compilemessages.
    • Semua permintaan HTTP masuk ke konsol, termasuk permintaan untuk berkas-berkas tetap atau favicon.ico yang biasa disaring.

  • Perintah pengelolaan sekarang dapat menghasilkan sintaksis keluaran bewarna dibawah Windows jika alat pihak-ketiga ANSICON terpasang dan aktif.

  • Perintah collectstatic dengan pilihan symlink sekarang didukung di Windows NT 6 (Windows Vista dan terbaru).

  • Inisial data SQL sekarang bekerja lebih baik jika pustaka Python sqlparse terpasang

    Catat bahwa itu diusangkan dalam mendukung dari operasi RunSQL dari perpindahan, yang manfaat dari perilaku yang ditingkatkan.

Model

  • Metode QuerySet.update_or_create() telah ditambahkan.
  • Model default_permissions baru pilihan Meta mengizinkan anda menyesuaikan (atau meniadakan) pembuatan dari awalan perizinan tambah, berubah, dan hapus.
  • OneToOneField eksplisit untuk Warisan banyak-tabel sekarang ditemukan di kelas-kelas abstrak.
  • Itu sekarang memungkinkan menghindari membuat hubungan kebelakang untuk OneToOneField dengan mengatur related_name nya menjadi '+' atau akhiri itu dengan '+'.
  • F expressions mendukung kekuatan penghubung (**).
  • Metode remove() dan clear() dari pengelola terkait dibuat oleh ForeignKey dan GenericForeignKey sekarang menerima argumen kata kunci bulk untuk mengendalikan apakah atau tidak melakukan tindakan dalam jumlah besar (yaitu menggunakan QuerySet.update()). Awalan menjadi True.
  • Seakrang dimungkinkan menggunakan None sebagai sebuah nilai permintaan untuk pencarian iexact.
  • Itu sekarang memungkinkan melewatkan callable sebagai nilai untuk atribut limit_choices_to ketika menentukan ForeignKey atau ManyToManyField.
  • Memanggil only() dan defer() di hasil dari QuerySet.values() sekarang memunculkan sebuah kesalahan (sebelum itu, itu juga antara hasil di kesalahan basisdata atau data tidak benar).
  • Anda dapat menggunakan daftar tunggal untuk index_together (daripada sebuah daftar dari daftar) ketika menentukan setelan tunggal dari bidang.
  • Penyesuaian model menengah memiliki lebih dari satu foreign key pada setiap dari model yang mengikuti di hubungan many-to-many adalah sekarang diizinkan, disediakan anda secara eksplisit menentukan foreign key mana harus digunakan dengan mengatur argumen ManyToManyField.through_fields baru.
  • Menetapkan sebuah instance model pada bidang bukan-hubungan akan sekarang melempar sebuah kesalahan. Sebelumnya ini digunakan untuk bekerja jika bidang menerima integer sebagai masukan ketika itu mengambil primary key.
  • Bidang integer sekarang disahkan terhadap backend basisdata khusus nilai min dan maks berdasarkan pada internal_type mereka. Sebelumnya pengesahan bidang model tidak mencegah nilai dari jangkauan jenis data kolom terkait mereka dari menjadi disimpan menghasilkan di sebuah kesalahan keutuhan.
  • Sekarang dimungkinkan secara eksplisit order_by() sebuah hubungan bidang _id dengan menggunakan nama atributnya.

Sinyal

  • Argumen enter telah ditambahkan ke sinyal setting_changed.
  • Sinyal model dapat sekarang dihubungkan untuk menggunakan str dari formulir 'app_label.ModelName' - seperti bidang-bidang terkait - untuk bermalas-malasan mengacukan pengirim mereka.

Templat

  • Metode Context.push() sekarang mengembalikan pengelola konteks yang secara otomatis memanggil pop() diatas mengeluarkan pernyataan with. Sebagai tambahan, push() sekarang menerima parameter yang dilewatkan ke pembangun dict digunakan untuk membangun tingkatak konteks baru.
  • Metode Context.flatten() baru mengembalikan sebuah tumpukan Context sebagai satu kamus datar.
  • Obyek Context sekarang dapat dibandingkan untuk kesetaraan (secara internal, ini menggunakan Context.flatten() jadi struktur internal dari setiap tumpukan Context tidak masalah selama versi diluruskan mereka mirip).
  • Etiket cetakan widthratio sekarang menerima sebuah parameter "as" untuk mengambil hasil di sebuah variabel.
  • Etiket cetakan include akan sekarang juga menerima apapun dengan metode render() (seperti Template) sebagai sebuah argumen. Argumen deretan karakter akan dicari menggunakan get_template() seperti biasanya.
  • Sekarang memungkinkan untuk include cetakan secara berulang.
  • Obyek cetakan sekarang mempunyai atribut asli disetel ketika TEMPLATE_DEBUG adalah True. Ini mengizinkan cetakan asli untuk diperiksa dan masuk diluar dari infrastruktur django.template.
  • Pengecualian TypeError tidak lagi didiamkan ketika dimunculkan selama membangun sebuah cetakan.
  • Fungsi berikut sekarang menerima sebuah parameter dirs yaitu sebuah daftar atau tuple untuk menimpa TEMPLATE_DIRS:
  • Penyaring time sekarang menerima terkait-zona waktu ref:format specifiers <date-and-time-formatting-specifiers> 'e', 'O' , 'T' dan 'Z' dan dapat mencerna instance time-zone-aware datetime melakukan pembangunan yang diharapkan.
  • Etiket cache sekarang akan mencoba menggunakan cache dipanggil "template_fragments" jika itu ada dan sebaliknya jatuh kembali menggunakan cache awalan. Itu juga sekarang menerima sebuah pilihan argumen kata kunci using untuk mengendalikan cache mana yang itu gunakan.
  • Penyaring truncatechars_html baru memotong sebuah deretan karakter untuk jadi tidak panjang dari angka yang ditentukan dari karakter, mengambil HTML kedalam akun.

Permintaan dan Tanggapan

Pengujian

  • DiscoverRunner mempunyai dua atribut baru, test_suite dan test_runner, yang memfasilitasi menimpa cara percobaan dikumpulkan dan berjalan.
  • Argumen fetch_redirect_response telah ditambahkan ke assertRedirects(). Sejak percobaan klien tidak dapat mengambil URL luar, ini mengizinkan anda menggunakan assertRedirects dengan mengalihkan dimana bukan bagian dari aplikasi Django anda.
  • Perbaiki penanganan dari skema ketika membuat perbandingan di assertRedirects().
  • Argumen secure telah ditambahkan ke semua metode permintaan dari Client. Jika True, permintaan akan dibuat melalui HTTPS.
  • assertNumQueries() sekarang mencetak daftar dari permintaan dijalankan jika tuntutan gagal.
  • Instance WSGIRequest dibangkitkan oleh penangan percobaan sekarang dilampirkan ke atribut django.test.Response.wsgi_request.
  • Pengaturan basisdata untuk percobaan telah dikumpulkan kedalam kamus dinamai TEST.

Keperluan

  • Ditingkatkan keakuratan strip_tags() (tetapi itu masih tidak dapat menjamin sebuah hasil aman-HTML, seperti dinyatakan di dokumentasi).

Pengesah

  • RegexValidator sekarang menerima pilihan argumen flags dan Boolean inverse_match. Atribut inverse_match menentukan jika ValidationError harus dimunculkan ketika pola regular expression cocok (True) atau tidak cocok (False, secara awalan) value disediakan. Atribut flags menyetel bendera digunakan ketika menyusun deretan karakter regular expression.
  • URLValidator sekarang menerima sebuah pilhan argumen schemes yang mengizinkan penyesuaian dari skema URL diterima (sebagai gantinya http(s) dan ftp(s)).
  • validate_email() sekarang menerima pengalamatan dengan harfiah IPv6, seperti example@[2001:db8::1], seperti ditentukan di RFC 5321.

Perubahan bertentangan kebelakang di 1.7

Peringatan

Sebagai tambahan pada perubahan diuraikan di bagian ini, pastikan untuk meninjau kembali deprecation plan untuk setiap fitur yang telah dipindahkan. Jika anda belum memperbaharui kode anda dalam linimasa pengusangan untuk fitur yang diberikan, perpindahannya mugkin muncul sebagai perubahan ketidaksesuaian kebelakang.

allow_syncdb / allow_migrate

Selagi Django akan amsih mencari metode allow_syncdb meskipun mereka harus dinamai kembali ke allow_migrate, ada sebuah perbedaan halus di model mana diloloskan ke metode ini.

Untuk aplikasi dengan perpindahan, allow_migrate akan sekarang melewatkan historical models, yang model versi khusus tanpa atribut penyesuaian, metode atau pengelola. Pastikan metode allow_migrate anda hanya mengacu ke bidang-bidang atau barang-barang lainnya di model._meta.

initial_data

Aplikasi-aplikasi dengan perpindahan tidak akan memuat perlengkapan initial_data ketika mereka telah menyelesaikan perpindahan. Aplikasi-aplikasi tanpa perpindahan akan melanjutkan memuat perlengkapan ini selama fase dari migrate yang meniru perilaku syncdb lama, tetapi setiap apliaksi baru tidak mempunyai dukungan ini.

Malahan, anda didorong memuat data inisial di perpindahan jika anda butuh itu (menggunakan tindakan RunPython dan kelas-kelas model anda); ini mempunyai tambahan keuntungan yang data inisial anda tidak akan butuh diperbaharui setiap kali anda merubah skema.

Tambahannya, seperti kode syncdb lama Django lainnya, initial_data telah dimulai jalur pengusangan dan akan dipindahkan di Django 1.9.

deconstruct() dan serializability

Django sekarang membutuhkan semua kelas-kelas Field dan semua dari argumen pembangun mereka untuk diserialisasikan. Jika anda merubah tanda tangan pembangun di penyesuaian Field dengan cara apapun, anda akan butuh menerapkan sebuah metode deconstruct(); kami telah memperpanjang penyesuaian dokumentasi bidang dengan instructions on implementing this method.

Persyaratan untuk semua bidang argumen untuk menjadi serializable berarti bahwa setiap penyesuaian instance kelas sedang dilewatkan kedalam pembangun Field - hal-hal seperti penyesuaian subkelas Storage, sebagai contoh - butuh memiliki deconstruct method defined on them as well, meskipun Django menyediakan sebuah penghias kelas mudah yang akan bekerja untuk kebanyakan aplikasi.

Perubahan memuat-aplikasi

Urutan memulai

Django 1.7 memuat konfigurasi aplikasi dan model ketika itu mulai. Selagi perilaku ini lebih terang-terangan dan dipercaya untuk menjadi lebih kuat, pemulihan tidak dapat dikesampingkan. Lihat Menyelesaikan masalah untuk pemecahan pada beberapa masalah anda mungkin hadapi.

Tulisan berdiri sendiri

Jika anda sedang menggunakan Django dalam tulisan Python polos - daripada perintah pengelolaan - dan anda menggantungkan pada variabel lingkungan DJANGO_SETTINGS_MODULE, anda harus sekarang secara eksplisit menginisialisasi Django pada permulaan dari tulisan anda dengan:

>>> import django
>>> django.setup()

Jika tidak, anda akan membentur sebuah pengecualian AppRegistryNotReady.

Tulisan WSGI

Sampai Django 1.3, cara dianjurkan untuk membuat aplikasi WSGI adalah:

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Di Django 1.4, dukungan untk WSGI telah ditingkarkan dan API berubah menjadi:

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Jika anda masih menggunakan gaya bekas di tulisan WSGI anda, anda butuh meningkatkan ke terakhir, atau anda akan mengenai sebuah pengecualian AppRegistryNotReady.

Kemantapan registrar aplikasi

Itu tidak lagi memungkinkan memiliki banyak aplikasi terpasang dengan label sama. Dalam versi sebelum dari Django, ini tidak selalu bekerja dengan benar, tetapi tidak gagal sekaligus juga.

Jika anda mempunyai dua aplikasi dengan label sama, anad harus membuat sebuah AppConfig untuk satu dari mereka dan menimpa label nya disana. Anda harus kemudian menyesuaikan kode anda dimanapun itu mengacu aplikasi ini atau modelnya dengan label lama.

Itu tidak mungkin mengimpor model yang sama dua kali melalui jalur berbeda lagi. Ketika Django 1.6, ini mungkin terjadi hanya jika anda sedang secara manual menaruh sebuah direktori dan sebuah subdirektori pada PYTHONPATH. Mengacu pada bagian di tata letak proyek baru di 1.4 release notes untuk pentunjuk perpindahan.

Anda harus pastikan itu:

  • Semua model ditentukan di aplikasi yang didaftarkan di INSTALLED_APPS atau mempunyai sebuah app_label yang jelas.
  • Model tidak diimpor sebagai pengaruh-samping dari memuat aplikasi mereka. Khususnya, anda tidak harus mengimpor model di modul akar dari sebuah aplikasi maupun di modul yang menentukan kelas konfigurasinya.

Django akan memaksa persyaratan ini sebagai versi 1.9, setelah masa pengusangan.

Mensubkelaskan AppCommand

Subkelas-subkelas dari AppCommand harus sekarang menerapkan sebuah metode handle_app_config() daripada handle_app(). Metode ini menerima sebuah instance AppConfig daripada modul model.

Menginterospeksi aplikasi

Sejak INSTALLED_APPS sekarang mendukung kelas-kelas konfigurasi aplikasi sebagai tambahan pada modul aplikasi, anda harus meninjau kembali kode yang mengakses pengaturan ini secara langsung dan menggunakan registrar aplikasi (django.apps.apps) sebagai gantinya.

Registrar aplikasi telah melindungi beberapa fitur dari cache aplikasi lama. Meskipun cache aplikasi adalah API pribadi, metode dan argumen usang akan dipindahkan melalui sebuah jalur pengusangan standar, dengan pengecualian dari perubahan berikut yang mengambil pengaruh segera:

  • get_model memunculkan LookupError daripada mengembalikan None ketika tidak ada model ditemukan.
  • Argumen only_installed dari get_model dan get_models tidak lagi ada, maupun argumen seed_cache dari get_model.

Perintah pengelolaan dan urutan dari INSTALLED_APPS

Ketika beberapa aplikasi menyediakan perintah pengelolaan dengan nama sama, Django memuat perintah dari aplikasi yang datang pertama di INSTALLED_APPS. Versi sebelumnya memuat perintah dari aplikasi yang datang terakhir.

Ini membawa penemuan dari perintah pengelolaan di baris dengan bagian lain dari Django yang bergantung di urutan dari INSTALLED_APPS, seperti berkas-berkas tetap, cetakan, dan terjemahan.

Pembangun ValidationError dan penyimpanan internal

Perilaku dari pembangun ValidationError telah berubah ketika itu menerima sebuah wadah kesalahan sebagai sebuah argumen (sebagai contoh sebuah list atau sebuah ErrorList):

  • Itu merubah string apapun pada instance dari ValidationError sebelum menambahkan mereka ke penyimpanan internal nya.
  • Itu tidak menyimpan wadah yang diberikan tetapi lebih baik menyalin isinya ke penyimpanan interal sendiri; sebelumnya wadah itu sendiri telah ditambahkan ke instance ValidationError dan digunakan sebagai penyimpanan internal.

Ini berarti bahwa jika anda mengakses penyimpan internal ValidationError, seperti error_list; error_dict; atau mengembalikan nilai dari update_error_dict() anda mungkin menemukan instance dari ValidationError dimana anda akan sebelumnya menemukan string.

Juga jika anda secara langsung memberikan nilai kembali dari update_error_dict() pada Form._errors anda mungkin secar tidak sengaja menambah instance list` dimana instance ErrorList yang diharapkan. Ini adalah sebuah masalah karena tidak seperti sebuah list sederhana, sebuah ErrorList tahu bagaimana menangani instance dari ValidationError.

Kebanyakan kasus-digunakan yang menjamin menggunakan API pribadi ini sekarang dicakupi oleh metode Form.add_error() yang baru diperkenalkan:

# Old pattern:
try:
    # ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# New pattern:
try:
    # ...
except ValidationError as e:
    self.add_error(None, e)

Jika anda butuh kesesuaian kedua Django <= 1.6 dan 1.7 anda tidak dapat menggunakan Form.add_error() sejak itu tidak tersedia sebelum Django 1.7, tetapi anda dapat menggunakan pemecahan berikut untuk merubah setiap list menjadi ErrorList:

try:
    # ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# Additional code to ensure ``ErrorDict`` is exclusively
# composed of ``ErrorList`` instances.
for field, error_list in self._errors.items():
    if not isinstance(error_list, self.error_class):
        self._errors[field] = self.error_class(error_list)

Perilaku `` LocMemCache`` mengenai kesalahan pickle

Sebuah ketidakkonsistentan ada di versi sebelumnya dari Django perihal bagaimana kesulitan kesalahan ditangani oleh backend penyimpanan sementara yang berbeda. django.core.cache.backends.locmem.LocMemCache digunakan untuk gagal secara diam ketika kesalahan seperti itu muncul, yaitu ketidakkonsistenan dengan backend lain dan membawa pada kesalahan penyimpanan sementara-tertentu. Ini telah diperbaiki di Django 1.7, lihat #21200 untuk lebih rinci.

Kunci cache sekarang dibangkitkan dari permintaan URL mutlak

Versi sebelumnya dari Django membangkitkan kunci tembolok menggunakan jalur permintaan dan permintaan deretan karakter tetapi bukan skema atau penyimpanan. Jika sebuah aplikasi Django telah melayani banyak subranah atau ranah, kunci tembolok dapat bertabrakan. Di Django 1.7, kunci tembolok beragam berdasarkan URL mutlak dari permintaan termasuk skema, penyimpanan, jalur, dan permintaan deretan karakter. Sebagai contoh, bagian URL dari kunci tembolok sekarang dibangkitkan dari https://www.example.com/path/to/?key=val daripada /path/to/?key=val.Kunci tembolok dibangkitkan oleh Django 1.7 akan menjadi berbeda dari kunci dibangkitkan oleh versi terlama dari Django. Setelah meningkatkan ke Django 1.7, permintaan pertama pada setiap URL disembunyikan sebelumnya akan lolos menyimpan.

Melewati None ke Manager.db_manager()

Di versi sebelumnya dari Django, itu memungkinkan menggunakan db_manager(using=None) di sebuah instance pengelola model untuk mengambil sebuah instance pengelola menggunakan perilaku rute awalan, menimpa setiap secara manual ditentukan rute basisdata. Di Djang0 1.7, sebuah nilai dari None dilewatkan ke db_manager akan menghasilkan sebuah perute yang mempertahankan setiap secara manual diberikan rute basisdata -- pengelola tidak akan disetel kembali. Ini diperlukan untuk menyelesaikan ketidakmantapan dalam cara merute aliran informasi terhadap join. Lihat #13724 untuk lebih rinci.

pytz mungkin dibutuhkan

Jika proyek anda menangani datetime sebelum 1970 dan setelah 2037 dan Django memunculkan sebuah ValueError ketika menghadapi mereka, anda harus memasang pytz. Anda mungkin terpengaruh oleh masalah ini jika anda menggunakan bentuk terkait-zona waktu Django atau django.contrib.syndication.

Siasat pengalihan masuk admin

Secara riwayat, situs admin Django melewatkan permintaan dari sebuah pengguna tidak terotorisasi dan tidak terautentifikasi secara langsun gke tampilan masuk, tanpa pengalihan HTTP. Di Django 1.7, perilaku ini berukan untuk memenuhi lebih alur kerja tradisional dimana permintaan tidak terotorisasi pada halaman admin akan diarahkan (dengan kode keadaan HTTP 302) ke halaman masuk, dengan parameter next disetel ke jalur yang diacukan. Pengguna akan dialihkan disana setelah berhasil masuk.

Catat juga bahwa formulir masuk admin telah diperbaharui untuk tidak mengandung bidang this_is_the_login_form (sekarang tidak berguna) dan kode ValidationError telah dikirim ke lebih biasa kunci invalid_login

select_for_update() membutuhkan sebuah transaksi

Secara riwayat, permintaan yang menggunakan select_for_update() dapat dijalankan dalam suasana pembetulan otomatis, diluar sebuah transaksi. Sebelum DJango 1.6, suasana transaksi otomatis Django mengizinkan ini digunakan untuk mengunci rekaman sampai tindakan menulis selanjutnya. Django 1.6 memperkenalkan pembetulan otomatis tingkat-basisdata; sejak itu, pengerjaan seperti konteks membatalkan pengaruh dari select_for_update(). Itu adalah, karena itu, menganggap sekarang menjadi sebuah kesalahan dan memunculkan sebuah pengecualian.

Perubahan ini telah dibuat karena kesalahan itu dapat disebabkan oleh menyertakan sebuah aplikasi yang mengharapkan transaksi global (sebagai contoh ATOMIC_REQUESTS disetel menjadi True), atau perilaku perbaikan otomatis lama Django, di sebuah proyek yang berjalan tanpa mereka; dan lebih lanjut, kesalahan itu mungkin wujud sebagai kesalahan kerusakan-data. Itu juga telah dibuat di Django 1.6.3.

Perubahan ini mungkin menyebabkan kegagalan percobaan jika anda menggunakan select_for_update() di kelas percobaan yaitu subkelas dari TransactionTestCase daripada TestCase.

Sumbangan middleware dipindahkan dari MIDDLEWARE_CLASSES awalan

app-loading refactor ` diusangkan menggunakan model dari aplikasi yang bukan bagian dari pengaturan :setting:`INSTALLED_APPS. Ini menunjukkan sebuah ketidaksesuaian diantara INSTALLED_APPS awalan dan MIDDLEWARE_CLASSES awalan keseluruhan (django.conf.global_settings). Untuk membawa pengaturan ini dalam sinkronisasi dan mencegah peringatan pengusangan ketika melakukan hal-hal seperti menguji aplikasi digunakan kembali dengan pengaturan minimal, SessionMiddleware, AuthenticationMiddleware, dan MessageMiddleware dipindahkan dari awalan. Kelas-kelas ini masih disertakan dalam pengaturan awalan dibangkitkan oleh startproject. Kebanyakan proyek tidak akan terpegnaruh oleh perubahan ini tetapi jika anda tidak sebelumnya mnyatakan MIDDLEWARE_CLASSES dalam pengaturan proyek anda dan bergantung pada awalan keseluruhan anda harus memastikan bawah awalan baru sejalan dengan kebutuhan proyek anda. Anda harus juga memeriksa untuk setiap kode yang mengakses django.conf.global_settings.MIDDLEWARE_CLASSES langsung.

Bermacam-macam

  • Metode django.core.files.uploadhandler.FileUploadHandler.new_file() sekarang melewatkan sebuah parameter content_type_extra tambahan. Jika anda mempunyai penyesuaian FileUploadHandler yang menerapkan new_file(), pastikan itu menerima parameter baru ini.

  • ModelFormSet tidak lagi menghapus instance ketika save(commit=False) dipanggil. Lihat can_delete untuk petunjuk pada bagaimana secara manual menghapus obyek dari formulir dihapus.

  • Memuat alat bantu kosong memancarkan RuntimeWarning dari pada memunculkan CommandError.

  • django.contrib.staticfiles.views.serve() akan sekarang memunculkan sebuah pengecualian Http404 daripada ImproperlyConfigured ketika DEBUG adalah False. Perubahan ini memindahkan kebutuhkan untuk kondisional menambah tampilan ke akar URLconf anda, yang pada gilirannya membuat itu aman untuk membalikkan berdasarkan nama. Itu juga memindahkan kemampuan pengunjung untuk membangkitkan kesalahan HTTP 500 palsu dengan meminta berkas tetap yang tidak ada atau belum dikumpulkan.

  • Metode django.db.models.Model.__eq__() sekarang ditentukan dengan cara dimana instance dari model proxy dan model dasarnya dianggap setara ketika primary key cocok. Sebelumnya hanya instance dari kelas sama yang tepat dianggap setara di primary key cocok.

  • Metode django.db.models.Model.__eq__() telah berubah seperti instance Model dua itu tanpa nilai primar key tidak akan dianggap setara (meskipun mereka adalah instance sama).

  • Metode django.db.models.Model.__hash__() sekarang akan menampilkan TypeError ketika dipanggil pada sebuah instance tanpa nilai primary key. Ini dilakukan untuk menghindari nilai __hash__ mungkin berubah dalam penampungan.

  • Kolom AutoField di basisdata SQLite akan sekarang dibuat selama pilihan AUTOINCREMENT, yang menjamin penaikan monoton. Ini akan menyebabkan perilaku penomoran primary key berubah di SQLite, menjadi mantap selaras dengan kebanykan basisdata SQL lain. Ini akan hanya berlaku pada tabel yang dibuat baru. Jika anda mempunyai sebuah basisdata dibuat dengan versi terlama dari Django, anda akan butuh memindahkann itu untuk mengambil keuntungan dari fitur ini. Sebagai contoh, anda dapat melakukan berikut:

    1. Gunakan dumpdata untuk menyimpan data anda.
    2. Namai kembali berkas basisdata yang ada (biarkan sebagai sokongan).
    3. Jalankan migrate untuk membuat skema terperbaharui.
    4. Gunakan loaddata untuk mengimpor perlengkapan anda ekspor dalam (1).

  • django.contrib.auth.models.AbstractUser tidak lagi menentukan sebuah metode get_absolute_url(). Definisi lama mengembalikan "/users/%s/" % urlquote(self.username) yang sebelumnya berubah-rubah sejak aplikasi mungkin atau mungkin tidak ditentukan seperti url di urlpatterns. Tentukan sebuah metode get_absolute_url() pada obyek pengguna penyesuaian anda sendiri atau menggunakan ABSOLUTE_URL_OVERRIDES jika anda ingin URL untuk pengguna anda.

  • Kegunaan melayani-aset tetap dari kelas django.test.LiveServerTestCase telah disederhanakan: Sekarang itu hanya dapat melayani isi sudah hadir di STATIC_ROOT ketika percobaan berjalan. Kemampuan untuk secara transparan melayani semua aset tetap (mirip pada apa satu dapatkan dengan DEBUG = True pada waktu-pengembangan) telah dipindahkan ke kelas baru yang tinggal di aplikasi staticfiles (satu yang sebenarnya bertanggung jawab dari fitur seperti itu): django.contrib.staticfiles.testing.StaticLiveServerTestCase. Dengan kata lain, LiveServerTestCase itu sendiri kurang kuat tetapi pada saat bersamaan mempunyai sedikit keajaiban.

    Alasan dibelakang perpindahan ini adalah ketergantungan dari kdoe bukan-bantuan di aplikasi bantuan.

  • Sintaksis URL cache lama (sebagai contoh "locmem://") tidak lagi didukung. Itu masih bekerja, meskipun itu tidak didokumentasikan atau secara resmi didukung. Jika anda masih menggunakan itu, harap memperbaharui sintaksis CACHES saat ini.

  • Urutan awalan dari bidang Form dalam kasus dari warisan telah berubah untuk mengikuti MRO Python biasa. Bidang-bidang sekarang ditemukan dengan memutar melalui MRO di balikan dengan kelas paling atas datang terakhir. Ini hanya berpengaruh jika anda bergantung pada urutan bidang awalan selagi mempunyai bidang-bidang ditentukan pada kedua keadaan kelas 8dan* pada induk Form.

  • Argumen required dari SelectDateWidget telah dipindahkan. Widget ini sekarang menhormati atribut is_required bidang formulir seperti widget-widget lain.

  • Widget.is_hidden sekarang adalah sifat hanya-baca, mendapatkan nilainya dengan menginterospeksi kehadiran dari input_type == 'hidden'.

  • select_related() sekarang menambat di cara sama seperti panggilan mirip lainnya seperti prefetch_related. Yaitu, select_related('foo', 'bar') setara pada select_related('foo').select_related('bar'). Sebelumnya yang terakhir akan setara pada select_related('bar').

  • GeoDjango membuang dukungan untuk GEOS < 3.1.

  • Metode init_connection_state dari backend basisdata sekarang berjalan dalam suasana pembetulan otomatis (meskipun anda menyetel AUTOCOMMIT menjadi False). Jika anda merawat penyesuaian backend backend basisdata, anda harus memeriksa metode itu.

  • Atribut django.db.backends.BaseDatabaseFeatures.allows_primary_key_0 telah dinamai menjadi allows_auto_pk_0``untuk menggambarkan itu lebih baik. Itu adalah ``True untuk semua backend basisdata termasuk dengan Django kecuali MySQL yang mengizinkan primary key dengan nilai 0. Itu hanya melarang primary key autoincrement dengan nilai 0.

  • Pembayangan bidang-bidang model ditentukan di model induk telah dilarang ketika ini membuat kebingungan dalam perilaku model yang diharapkan. Sebagai tambahan, bidang-bidang yang bertabrakan di hasil susunan model warisan dalam sistem pemeriksaan kesalahan. Sebagai contoh, jika butuh anda menggunakan banyak-warisan, anda butuh menentukan penyesuaian bidang-bidang primary key pada model induk, jika tidak bidang id awalan akan bertabrakan. Lihat Banyak warisan untuk rincian.

  • django.utils.translation.parse_accept_lang_header() sekarang mengembalikan lokal huruf kecil, sebagai ganti dari kasus ketika itu disediakan. Sebagai lokal harus di perlakukan tidak sensitif-kasus ini mengizinkan kamu mempercepat penemuan lokal.

  • django.utils.translation.get_language_from_path() dan django.utils.translation.trans_real.get_supported_language_variant() sekarang tidak lagi mempunyai argumen supported.

  • Tampilan shortcut dalam django.contrib.contenttypes.views sekarang mendukung protocol-relative URL (sebagai contoh //example.com).

  • GenericRelation sekarang mendukung sebuah pilihan argumen related_query_name. Pengaturan related_query_name menambahkan sebuah hubungan dari obyek terkait kebelakang pada jenis isi untuk penyaringan, pengurutan dan tindakan permintaan lain.

  • Ketika menjalankan percobaan pada PostgreSQL, USER akan butuh membaca akses pada basisdata postgres siap-pakai. Ini adalah daripada perilaku sebelumnya dari menghubungkan ke basisdata bukan-percobaan sebenarnya.

  • Sebagai bagian dari System check framework, fields, models, and model managers semua menerapkan sebuah metode check() yang terdaftar dengan pemeriksaan kerangka. Jika anda mempunyai sebuah metode yang ada memanggil check() pada satu dari obyek ini, anda akan butuh menamai kembalinya.

  • Seperti dicatat diatas di bagian "Cache" dari "Minor Features", menentukan argumen TIMEOUT dari pengaturan CACHES sebagai None akan menyetel kunci cache sebagai "non-expiring". Sebelumnya, dengan backend memcache, sebuah TIMEOUT dari 0 akan menyetel kunci tidak-kadaluarsa, tetapi ini tidak tetap dengan setel-dan-kadaluarsa (yaitu tidak ada penyimpanan sementara) perilaku dari set("key", "value", timeout=0). Jika anda ingin kuncu tidak-kadaluarsa, harap memperbaharui pengaturan anda untuk menggunakan None daripada 0 sebagai yang terakhir sekarang menunjuk setel-dan-kadaluarsa di pengaturan juga.

  • Perintah pengelolaan sql* sekarang menghormati metode allow_migrate() dari DATABASE_ROUTERS. Jika anda mempunyai model disamakan pada basisdata bukan-awalan, gunakan bendera --database untuk mendapatkan SQL untuk model tersebut (sebelumnya mereka akan selalu disertakan dalam keluaran).

  • Membaca permintaan string dari URL sekarang jatuh kembali ke penyandian ISO-8859-1 ketika masukan bukan YTF-8 yang sah.

  • Dengan tambahan dari django.contrib.auth.middleware.SessionAuthenticationMiddleware ke cetakan proyek awalan (hanya pra-1.7.2), sebuah basisdata harus dibuat sebelum mengakses sebuah halaman menggunakan runserver.

  • Tambahan dari argumen schemes pada URLValidator` akan muncul sebagai ketidaksesuaian-kebelakang berubah jika anda sebelumnya menggunakan penyesuaian regular expression untuk mensahkan skema. Setiap skema tidak terdaftar di schemes akan gagal disahkan, bahkan jika regular expression cocok di URL yang diberikan.

Fitur usang di 1.7

django.core.cache.get_cache

django.core.cache.get_cache telah digantikan oleh django.core.cache.caches.

django.utils.dictconfig/django.utils.importlib

django.utils.dictconfig dan django.utils.importlib telah disalin masing-masing logging.config dan importlib disediakan untuk Python versi sebelum 2.7. Mereka telah diusangkan.

django.utils.module_loading.import_by_path

Fungsi django.utils.module_loading.import_by_path saat ini menangkap pengecualian AttributeError, ImportError, dan ValueError, dan memunculkan kembali ImproperlyConfigured. Penutupan pengecualian tersebut membuat itu sia-sia keras untuk mengenal lingkaran masalah import, karena itu membuat itu seperti masalah datang dari dalam Django. Itu telah diusangkan dalam mendukung import_string().

django.utils.tzinfo

django.utils.tzinfo menyediakan dua tzinfo subclasses, LocalTimezone dan FixedOffset. Mereka telah diusangkan dalam mendukung lebih jalan lain yang benar disediakan oleh django.utils.timezone, django.utils.timezone.get_default_timezone() dan django.utils.timezone.get_fixed_timezone().

django.utils.unittest

django.utils.unittest menyediakan akses seragam akses ke pustaka unittest2 di semua versi Python. Sejak unittest2 menjadi modul unittest pustaka standar di Python 2.7, dan Django 1.7 menjatuhkan dukungan untuk versi Python terlama, modul ini tidak berguna lagi. itu telah diusangkan. Gunakan unittest sebagai gantinya.

django.utils.datastructures.SortedDict

Ketika OrderedDict telah ditambahkan ke pustaka standar di Python 2.7, SortedDict tidak lagi dibutuhkan dan telah diusangkan.

Dua tambahan, metode diusangkan disediakan oleh SortedDict (insert() dan value_for_index()) telah dipindahkan. Jika anda bergantung pada metode ini untuk merubah struktur bidang formulir seperti, anda harus sekarang memperlakukan OrderedDict sebagai obyek kekal dan menimpa mereka untuk merubah isi mereka.

Sebagai contoh, anda mungkin ingin menimpa MyFormClass.base_fields (meskipun atribut ini tidak dianggap API umum) untuk merubah urutan dari bidang untuk semua instance MyFormClass; atau sama halnya, anda dapat mengesampingkan self.fields dari dalam MyFormClass.__init__(), untuk merubah bidang-bidang untuk instance formulir tertentu. Sebagai contoh (dari Django itu sendiri):

PasswordChangeForm.base_fields = OrderedDict(
    (k, PasswordChangeForm.base_fields[k])
    for k in ['old_password', 'new_password1', 'new_password2']
)

Penyesuaian tempat SQL untuk paket model

Sebelumnya, jika model diatur dalam paket (myapp/models/) daripada hanya myapp/models.py, Django akan mencari inisial data SQL di myapp/models/sql/. Kesalahan ini telah diperbaiki sehingga Django akan mencari myapp/sql/ seperti yang didokumentasikan. Setelah masalah ini telah diperbaiki, perpindahan ditambahkan dimana pengusangan inisial data SQL. Demikian, selagi perubahan ini masih ada, pengusangan tidak bersangkut paut sebagai fitur keseluruhan akan dipindahkan di Django 1.9.

Reorganisasi dari django.contrib.sites

django.contrib.sites menyediakan pengurangan kegunaan ketika itu tidak di INSTALLED_APPS. Refaktor memuat-aplikasi menambahkan beberapa batasan di keadaan tersebut. Sebagai akibatnya, dua obyek dipindah, dan tempat lama diusangkan:

Atribut declared_fieldsets pada ModelAdmin

ModelAdmin.declared_fieldsets telah diusangkan. Meskipun menjadi sebuah API pribadi, itu akan melalui jalur pengusangan biasa. Atribut ini kebanyakan digunakan oleh metode yang meloloskan ModelAdmin.get_fieldsets() tetapi ini telah dianggap sebuah kesalahan dan telah dialamatkan.

Reorganisasi dari django.contrib.contenttypes

Sejak django.contrib.contenttypes.generic menentukan kedua admin dan obyek terkait model, sebuah impor dari modul ini dapat memicu efek samping yang tidak diharapkan. Sebagai sebuah konsekuensi, isinya dipisah menjadi submodul contenttypes dan modul django.contrib.contenttypes.generic diusangkan.

syncdb

Perintah syncdb telah diusangkan dalam mendukung dari perintah migrate baru. migrate mengambil argumen sama sebagai syncdb digunakan untuk menambah sedikit lagi, jadi itu aman untuk hanya merubah nama anda sedang panggil dan tidak ada lagi.

Modul util dinamai kembali menjadi utils

Instance berikut dari util.py di kode dasar Django telah dinamai kembali menjadi utils.py di sebuah usaha untuk menyatukan semua acuan util dan utils:

  • django.contrib.admin.util
  • django.contrib.gis.db.backends.util
  • django.db.backends.util
  • django.forms.util

Metode get_formsets pada ModelAdmin

ModelAdmin.get_formsets telah diusangkan mendukung dari get_formsets_with_inlines() baru, agar menjadi lebih baik menangani kasus dari memilih menampilkan berderet pada ModelAdmin.

IPAddressField

Bidang django.db.models.IPAddressField dan django.forms.IPAddressField telah diusangkan dalam mendukung django.db.models.GenericIPAddressField dan django.forms.GenericIPAddressField.

Metode BaseMemcachedCache._get_memcache_timeout

Metode BaseMemcachedCache._get_memcache_timeout() telah dinamai kembali menjadi get_backend_timeout(). Meskipun menjadi sebuah API pribadi, itu akan melalui pengusangan biasa.

Pilihan serialisasi kunci alami

Pilihan --natural dan -n untuk dumpdata telah diusangkan. Gunakan dumpdata --natural-foreign sebagai gantinya.

Demikian pula, argumen use_natural_keys untuk serializers.serialize() telah diusangkan. Gunakan use_natural_foreign_keys sebagai gantinya.

Menggabungkan argumen POST dan GET kedalam WSGIRequest.REQUEST

Itu sudah sangat dianjurkan bahwa anda menggunakan GET dan POST daripada REQUEST, karena yang terlebih dahulu lebih eksplisit. Sifat REQUEST diusangkan dan akan dipindahkan di Django 1.9.

Kelas django.utils.datastructures.MergeDict

MergeDict ada utamanya untuk mendukung penggabungan argumen POST dan GET kedalam sebuah sifat REQUEST pada WSGIRequest. Untuk menggabungkan kamus, gunakan dict.update() sebagai gantinya. Kelas MergeDict diusangkan dan akan dipindahkan di Django 1.9.

Kode bahasa zh-cn, zh-tw dan fy-nl

Kode bahasa digunakan saat ini untuk China Disederhanakan zh-cn, China Tradisional zh-tw dan (Barat) Frysian fy-nl diusangkan dan harus diganti dengan kode bahasa zh-hans, zh-hant and fy masing-masing. Jika anda menggunakan kode bahasa ini, anda harus menamai kembali direktori lokal dan memperbaharui pengaturan anda untuk mencerminkan perubahan ini. Kode bahasa pengusangan akan diindahkan di Django 1.9.

Fungsi django.utils.functional.memoize

Fungsi memoize diusangkan dan harus diganti oleh penghias functools.lru_cache (tersedia dari Python 3.2 ke depan).

Django membekali sebuah backport dari penghias ini untuk versi Python lebih lama dan itu tersedia di django.utils.lru_cache.lru_cache. Fungsi diusangkan akan dipindahkan di Django 1.9.

Peta situs Geo

Google telah berhenti mendukung untuk bentuk Geo Sitemap. Oleh karena itu Django mendukung untuk Geo Sitemap diusangkan dan akan dipindahkan di Django 1.8.

Melewatkan argumen dapat dipanggul pada metode queryset

Argumen dapat dipanggil untuk queryset adalah sebuah fitur yang tidak didokumentasikan yang telah tidak handal. Itu telah diusangkan dan akan dipindahkan di Django 1.9.

Argumen dapat dipanggil telah dinilai ketika queryset telah dibangun daripada ketika itu telah dinilai, dengan demikian fitur ini tidak menawarkan keuntungan apapun dibandingkan pada menilai argumen sebelum melewatkan mereka ke queryset dan membuat kebingungan bahwa argumen mungkin telah dinilai pada waktu permintaan.

Pengaturan ADMIN_FOR

Fitur ADMIN_FOR, bagian dari admindoc, telah dipindahkan. Anda dapat memindahkan pengaturan untuk konfigurasi anda pada kenyamanan anda.

SplitDateTimeWidget dengan DateTimeField

Dukungan SplitDateTimeWidget di DateTimeField diusangkan, gunakan SplitDateTimeWidget dengan SplitDateTimeField sebagai gantinya.

validate

Perintah pengelolaan validate diusangkan dalam mendukung dari perintah check.

django.core.management.BaseCommand

requires_model_validation diusangkan dalam mendukung dari bendera requires_system_checks baru. Jika bendera terakhir hilang, kemudian nilai dari bendera awal digunakan. Menentukan kedua hasil requires_system_checks dan``requires_model_validation`` di kesalahan.

Cara check() telah mengganti cara validate()`.

Pengesah ModelAdmin

Atribut ModelAdmin.validator_class dan default_validator_class diusangkan dalam mendukung atribut checks_class baru.

Cara ModelAdmin.validate() diusangkan mendukung ModelAdmin.check().

Modul django.contrib.admin.validation diusangkan.

django.db.backends.DatabaseValidation.validate_field

Metode ini diusangkan dalam mendukung dari cara check_field baru. Kegunaan dibutuhkan oleh check_field() adalah sama seperti yang disediakan oleh validate_field(), tetapi bentuk keluaran adalah berbeda. Backend basisdata pihak-ketiga membutuhkan kegunaan ini harus menyediakan sebuah penerapan dari check_field().

Memuat etiket cetakan ssi dan url dari pustaka future

Django 1.3 memperkenalkan sintaksis {% load ssi from future %} and {% load url from future %} untuk kesesuaian kedepan dari etiket cetakan ssi dan url. Sintaksis ini sekarang diusangkan dan akan dipindahkan di Django 1.9. Anda dapat dengan mudah memindahkan etiket {% load ... from future %}.

django.utils.text.javascript_quote

javascript_quote() adalah fungsi tidak didokumentasikan hadir di django.utils.text. Itu digunakan secara internal di javascript_catalog() yang penerapannya telah berubah untuk memastikan penggunaan dari json.dumps() sebagai gantinya. Jika anda sedang bergantung pada fungsi ini untuk menyediakan keluaran aman dari deretan karakter tidak dipercaya, anda harus menggunakan penyaring cetakan django.utils.html.escapejs atau the escapejs. Jika semua anda butuhkan adalah untuk membangkitkan deretan karakter JavaScript sah, anda dapat dengan mudah menggunakan json.dumps().

Metode kegunaan fix_ampersands dan penyaring cetakan

Metode django.utils.html.fix_ampersands dan penyaring cetakan fix_ampersands diusangkan, pelolosan dan sudah ditangani oleh fitur pelolosan HTML standar. Memadukan ini dengan fix_ampersands akan menghasilkan di pelolosan ganda, atau jika keluaran dianggap aman, sebuah resiko dari memperkenalkan kerentanan XSS. Bersama dengan fix_ampersands, django.utils.html.clean_html diusangkan, sebuah fungsi tidak terdokumentasikan yang memanggil fix_ampersands. Karena ini adalah pengusangan dipercepat, fix_ampersands dan clean_html akan dipindahkan di Django 1.8.

Reorganisasi dari pengaturan percobaan basisdata

Semua pengaturan basisdata dengan awalan TEST_ telah diusangkan dalam mendukung masukan di kamus TEST di pengaturan basisdata. Pengaturan lama akan didukung sampai Django 1.9. Untuk kesesuaian kebelakang dengan versi terlama dari Django, anda dapat menentukan kedua versi dari pengaturan selama mereka cocok.

Dukungan FastCGI

Dukungan FastCGI melalui perintah pengelolaan runfcgi akan dipindahkan di Django 1.9. Silahkan sebarkan proyek anda menggunakan WSGI.

Memindahkan obyek di contrib.sites

Refaktor memuat-aplikasi berikut, dua obyek di django.contrib.sites.models butuh dipindahkan karena mereka harus tersedia tanpa mengimpor django.contrib.sites.models ketika django.contrib.sites tidak terpasang. Impor RequestSite dari django.contrib.sites.requests dan get_current_site() dari django.contrib.sites.shortcuts. Tempat impor lama akan bekerja sampai Django 1.9.

django.forms.forms.get_declared_fields()

Django tidak lagi menggunakan fungsi ini secara internal. Meskipun itu adalah API pribadi, itu akan pergi melalui siklus pengusangan biasa.

API Pencarian Permintaan Pribadi

API pribadi django.db.models.sql.where.WhereNode.make_atom() dan django.db.models.sql.where.Constraint diusangkan dalam mendukung dari custom lookups API baru.

Fitur-fitur dipindahkan dalam 1.7

Fitur-fitur ini telah mencapai akhir siklus pengusangan mereka dan dipindahkan di Django 1.7. Lihat Fitur usang di 1.5 untuk rincian, termasuk bagaimana memindahkan penggunaan fitur ini.

  • django.utils.simplejson dipindahkan.
  • django.utils.itercompat.product dipindahkan.
  • INSTALLED_APPS dan TEMPLATE_DIRS tidak lagi diperbaiki dari deretan karakter polos kedalam sebuah tuple.
  • HttpResponse, SimpleTemplateResponse, TemplateResponse, render_to_response(), index(), dan sitemap() tidak lagi mengambil sebuah argumen mimetype
  • HttpResponse segera memakan isinya jika itu adalah sebuah perulangan.
  • Pengaturan AUTH_PROFILE_MODULE, dan metode get_profile() pada model User dipindahkan.
  • Perintah pengelolaan cleanup dipindahkan.
  • Tulisan daily_cleanup.py dipindahkan.
  • select_related() tidak lagi mempunyai argumen kata kunci depth.
  • Fungsi get_warnings_state()/restore_warnings_state() dari django.test.utils dan the save_warnings_state()/ restore_warnings_state() django.test.*TestCase dipindahkan.
  • Metode check_for_test_cookie di AuthenticationForm dipindahkan.
  • The version of django.contrib.auth.views.password_reset_confirm() that supports base36 encoded user IDs (django.contrib.auth.views.password_reset_confirm_uidb36) is removed.
  • Mix-in django.utils.encoding.StrAndUnicode dipindahkan.
Back to Top