---
title: "Catatan terbitan Django 1.7"
version: 3.2
locale: id
source: https://docs.djangoproject.com/id/3.2/releases/1.7/
canonical: https://djangodocs.dev/id/3.2/releases/1.7/
---
# Catatan terbitan Django 1.7

*September 2, 2014*

Selamat datang ke Django 1.7!

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

## 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](/id/3.2/internals/release-process/), 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](/id/3.2/topics/migrations/), 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`](/id/3.2/ref/signals/#django.db.models.signals.pre_migrate) dan [`post_migrate`](/id/3.2/ref/signals/#django.db.models.signals.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`](/id/3.2/ref/migration-operations/#django.db.migrations.operations.RunPython) atau [`RunSQL`](/id/3.2/ref/migration-operations/#django.db.migrations.operations.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](/id/3.2/topics/testing/overview/#test-case-serialized-rollback).
- Itu tidak disarankan untuk memiliki aplikasi tanpa perpindahan bergantung di (mempunyai sebuah [`ForeignKey`](/id/3.2/ref/models/fields/#django.db.models.ForeignKey) atau [`ManyToManyField`](/id/3.2/ref/models/fields/#django.db.models.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](/id/3.2/ref/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()`](/id/3.2/ref/applications/#django.apps.AppConfig.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`](/id/3.2/ref/models/options/#django.db.models.Options.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`](/id/3.2/ref/applications/#django.apps.AppConfig.label) dari konfigurais aplikasi, untuk memecahkan bentrokan label.
- Nama dari aplikasi dapat disesuaikan di admin dengan [`verbose_name`](/id/3.2/ref/applications/#django.apps.AppConfig.verbose_name) dari konfigurasi aplikasi.
- Admin secara otomatis memanggil [`autodiscover()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.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`](/id/3.2/ref/models/fields/#django.db.models.Field)  sekarang mempunyai metode wajib baru: `deconstruct()`.

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

- `name`: The field's attribute name on its parent model, or `None` if it
  is not part of a 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](/id/3.2/topics/migrations/#migration-serializing).

### 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()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.as_manager) sekarang secara langsung [create Manager with QuerySet methods](/id/3.2/topics/db/managers/#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](/id/3.2/topics/db/queries/#using-custom-reverse-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](/id/3.2/ref/checks/) 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`](/id/3.2/ref/django-admin/#django-admin-check). Perintah ini menggantikan perintah pengelolaan `validate` lama.

### Obyek `Prefetch` baru untuk tindakan `prefetch_related` lebih lanjut.

Obyek [`Prefetch`](/id/3.2/ref/models/querysets/#django.db.models.Prefetch) baru mengizinkan penyesuaian tindakan prefetch.

Anda dapat menentukan `QuerySet` digunakan untuk melintasi hubungan yang diberikan atau menyesuaikan tempat penyimpanan dari hasil prefetch.

Ini mengadakan hal-hal seperti menyaring hubungan pengambilan, memanggil [`select_related()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.select_related) dari hubungan pengambilan, atau pengambilan hubungan sama banyak kali dengan queryset berbeda. Lihat [`prefetch_related()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.prefetch_related) untuk lebih rinci.

### 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](/id/3.2/topics/i18n/timezones/#default-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`](/id/3.2/ref/models/lookups/#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`](/id/3.2/ref/models/lookups/#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](/id/3.2/howto/custom-lookups/).

### Perbaikan pada penanganan kesalahan `Form`

#### `Form.add_error()`

Sebelumnya ada dua pola utama untuk menangani kesalahan di formulir:

- Memunculkan sebuah [`ValidationError`](/id/3.2/ref/exceptions/#django.core.exceptions.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()`](/id/3.2/ref/forms/api/#django.forms.Form.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](/id/3.2/ref/forms/validation/#validating-fields-with-clean) untuk sebuah contoh menggunakan `Form.add_error()`.

#### Kesalahan metadata

Pembangun [`ValidationError`](/id/3.2/ref/exceptions/#django.core.exceptions.ValidationError) menerima metadata seperti kesalahan `code` atau `params` yang kemudian tersedia untuk menambahkan kedalam pesan kesalahan (lihat [Membangkitkan ValidationError](/id/3.2/ref/forms/validation/#raising-validation-error) untuk lebih rinci); bagaimanapun, sebelum Django 1.7 metadata tersebut dibuang segera setelah kesalahan ditambahkan ke [`Form.errors`](/id/3.2/ref/forms/api/#django.forms.Form.errors).

[`Form.errors`](/id/3.2/ref/forms/api/#django.forms.Form.errors) dan `django.forms.utils.ErrorList` sekarang menyimpan instance `ValidationError` sehingga metadata ini dapat diambil kapanpun melalui metode [`Form.errors.as_data`](/id/3.2/ref/forms/api/#django.forms.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()`](/id/3.2/ref/forms/api/#django.forms.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`](/id/3.2/ref/forms/api/#django.forms.Form.errors), `django.forms.utils.ErrorList`, dan pengimpanan internal dari [`ValidationError`](/id/3.2/ref/exceptions/#django.core.exceptions.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](#validation-error-constructor-and-internal-storage) untuk lebih rinci.

### Fitur kecil

#### [`django.contrib.admin`](/id/3.2/ref/contrib/admin/#module-django.contrib.admin)

- Anda sekarang dapat menerapkan atribut [`site_header`](/id/3.2/ref/contrib/admin/#django.contrib.admin.AdminSite.site_header), [`site_title`](/id/3.2/ref/contrib/admin/#django.contrib.admin.AdminSite.site_title), dan [`index_title`](/id/3.2/ref/contrib/admin/#django.contrib.admin.AdminSite.index_title) pada [`AdminSite`](/id/3.2/ref/contrib/admin/#django.contrib.admin.AdminSite) penyesuaian agar dengan mudah merubah judul halaman situs admin dan teks kepala. Tidak perlu lagi menimpa cetakan!
- Tombol di [`django.contrib.admin`](/id/3.2/ref/contrib/admin/#module-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()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_search_fields) baru.
- Metode [`ModelAdmin.get_fields()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_fields) mungkin dikesampingkan untuk menyesuaikan nilai dari [`ModelAdmin.fields`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fields).
- Sebagai tambahan pada sintaksis `admin.site.register` yang ada, anda dapat menggunakan penghias [`register()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.register) baru untuk mendaftar sebuah [`ModelAdmin`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin).
- Anda dapat menentukan [`ModelAdmin.list_display_links`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display_links) `= None` untuk meniadakan tautan pada jaring halaman daftar perubahan.
- Anda dapat sekarang menentukan [`ModelAdmin.view_on_site`](/id/3.2/ref/contrib/admin/#django.contrib.admin.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`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display) dengan mengawali nilai `admin_order_field` dengan tanda penghubung
- Metode [`ModelAdmin.get_changeform_initial_data()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_changeform_initial_data) mungkin dikesampingkan untuk menentukan penyesuaian perilaku untuk mengatur perubahan awalan data formulir.

#### [`django.contrib.auth`](/id/3.2/topics/auth/#module-django.contrib.auth)

- Setiap `**kwargs` dilewatkan pada [`email_user()`](/id/3.2/ref/contrib/auth/#django.contrib.auth.models.User.email_user) dilewatkan ke panggilan [`send_mail()`](/id/3.2/topics/email/#django.core.mail.send_mail) pokok.
- Penghias [`permission_required()`](/id/3.2/topics/auth/default/#django.contrib.auth.decorators.permission_required) dapat mengambil sebuah daftar dari perizinan sama halnya perizinan tunggal.
- Anda dapat menimpa metode [`AuthenticationForm.confirm_login_allowed()`](/id/3.2/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed) baru untuk lebih mudah menyesuaikan kebijakan masuk.
- `django.contrib.auth.views.password_reset()` takes an optional
  `html_email_template_name` parameter used to send a multipart HTML email
  for password resets.
- Metode [`AbstractBaseUser.get_session_auth_hash()`](/id/3.2/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) telah ditambahkan dan jika warisan [`AUTH_USER_MODEL`](/id/3.2/ref/settings/#std-setting-AUTH_USER_MODEL) anda dari [`AbstractBaseUser`](/id/3.2/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser), merubah sandi pengguna sekarang membatalkan sesi lama jika `django.contrib.auth.middleware.SessionAuthenticationMiddleware` diadakan. Lihat [Penghapusan sesi pada perubahan sandi](/id/3.2/topics/auth/default/#session-invalidation-on-password-change) untuk lebih rinci.

#### `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`](/id/3.2/ref/contrib/gis/#module-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`](/id/3.2/ref/contrib/messages/#module-django.contrib.messages)

- Backend untuk [`django.contrib.messages`](/id/3.2/ref/contrib/messages/#module-django.contrib.messages) yang menggunakan kue, sekarang akan mengikuti pengaturan [`SESSION_COOKIE_SECURE`](/id/3.2/ref/settings/#std-setting-SESSION_COOKIE_SECURE) dan [`SESSION_COOKIE_HTTPONLY`](/id/3.2/ref/settings/#std-setting-SESSION_COOKIE_HTTPONLY).
- [messages context processor](/id/3.2/ref/contrib/messages/#message-displaying) sekarang menambahkan sebuah kamus dari tingkat awalan dibawah nama `DEFAULT_MESSAGE_LEVELS`.
- Obyek [`Message`](/id/3.2/ref/contrib/messages/#django.contrib.messages.storage.base.Message) sekarang mempunyai sebuah atribut `level_tag` yang mengandung string perwakilan dari tingkatan pesan.

#### [`django.contrib.redirects`](/id/3.2/ref/contrib/redirects/#module-django.contrib.redirects)

- [`RedirectFallbackMiddleware`](/id/3.2/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware) mempunyai dua atribut baru ([`response_gone_class`](/id/3.2/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class) dan [`response_redirect_class`](/id/3.2/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class)) yang menentukan jenis-jenis dari instance [`HttpResponse`](/id/3.2/ref/request-response/#django.http.HttpResponse) kembalian middleware.

#### [`django.contrib.sessions`](/id/3.2/topics/http/sessions/#module-django.contrib.sessions)

- The `"django.contrib.sessions.backends.cached_db"` session backend now
  respects [`SESSION_CACHE_ALIAS`](/id/3.2/ref/settings/#std-setting-SESSION_CACHE_ALIAS). In previous versions, it always used
  the `default` cache.

#### [`django.contrib.sitemaps`](/id/3.2/ref/contrib/sitemaps/#module-django.contrib.sitemaps)

- [`sitemap framework`](/id/3.2/ref/contrib/sitemaps/#module-django.contrib.sitemaps) sekarang memanfaatkan [`lastmod`](/id/3.2/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap.lastmod) untuk menyetel kepala `Last-Modified` di tanggapan. Ini membuatnya memungkinkan untuk [`ConditionalGetMiddleware`](/id/3.2/ref/middleware/#django.middleware.http.ConditionalGetMiddleware) untuk menangani permintaan `GET` bersyarat untuk peta situs yang menyetel `lastmod`.

#### [`django.contrib.sites`](/id/3.2/ref/contrib/sites/#module-django.contrib.sites)

- [`django.contrib.sites.middleware.CurrentSiteMiddleware`](/id/3.2/ref/middleware/#django.contrib.sites.middleware.CurrentSiteMiddleware) baru mengizinkan mengatur situs saat ini di setiap permintaan

#### [`django.contrib.staticfiles`](/id/3.2/ref/contrib/staticfiles/#module-django.contrib.staticfiles)

- [static files storage classes](/id/3.2/ref/contrib/staticfiles/#staticfiles-storages) mungkin di subkelaskan untuk menimpa perizinan yang mengumpulkan berkas-berkas tetap dan direktori menerima dengan mengatur parameter [`file_permissions_mode`](/id/3.2/ref/files/storage/#django.core.files.storage.FileSystemStorage.file_permissions_mode) dan [`directory_permissions_mode`](/id/3.2/ref/files/storage/#django.core.files.storage.FileSystemStorage.directory_permissions_mode). Lihat [`collectstatic`](/id/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) untuk contoh penggunaan.
- The `CachedStaticFilesStorage` backend gets a sibling class called
  [`ManifestStaticFilesStorage`](/id/3.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage)
  that doesn't use the cache system at all but instead a JSON file called
  `staticfiles.json` for storing the mapping between the original file name
  (e.g. `css/styles.css`) and the hashed file name (e.g.
  `css/styles.55e7cbb9ba48.css`). The `staticfiles.json` file is created
  when running the [`collectstatic`](/id/3.2/ref/contrib/staticfiles/#django-admin-collectstatic) management command and should
  be a less expensive alternative for remote storages such as Amazon S3.

  Lihat dokumentasi [`ManifestStaticFilesStorage`](/id/3.2/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage) untuk informasi lebih.
- [`findstatic`](/id/3.2/ref/contrib/staticfiles/#django-admin-findstatic) sekarang menerima bendera terlalu banyak kata tingkat 2, berarti itu akan menunjukkan jalur relatif dari direktori itu cari. Lihat [`findstatic`](/id/3.2/ref/contrib/staticfiles/#django-admin-findstatic) untuk contoh keluaran.

#### [`django.contrib.syndication`](/id/3.2/ref/contrib/syndication/#module-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`](/id/3.2/ref/settings/#std-setting-CACHES) sekarang tersedia melalui [`django.core.cache.caches`](/id/3.2/topics/cache/#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`](/id/3.2/topics/cache/#django.core.cache.caches) sekarang menghasilkan instance berbeda per thread.
- Menentukan argumen [`TIMEOUT`](/id/3.2/ref/settings/#std-setting-CACHES-TIMEOUT) dari pengaturan [`CACHES`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/settings/#std-setting-CSRF_COOKIE_AGE) mempermudah penggunaan kue CSRF berbasis sesi.

#### Surel

- [`send_mail()`](/id/3.2/topics/email/#django.core.mail.send_mail) now accepts an `html_message`
  parameter for sending a multipart `text/plain` and
  `text/html` email.
- [`EmailBackend`](/id/3.2/topics/email/#django.core.mail.backends.smtp.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`](/id/3.2/ref/files/uploads/#django.core.files.uploadedfile.UploadedFile.content_type_extra) baru mengandung parameter tambahan dilewatkan ke kepala `content-type` di sebuah unggah berkas.
- Pengaturan [`FILE_UPLOAD_DIRECTORY_PERMISSIONS`](/id/3.2/ref/settings/#std-setting-FILE_UPLOAD_DIRECTORY_PERMISSIONS) baru mengendalikan perizinan sistem berkas dari direktori dibuat selama unggah berkas, seperti [`FILE_UPLOAD_PERMISSIONS`](/id/3.2/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) lakukan untuk berkas-berkas mereka sendiri.
- Atribut [`FileField.upload_to`](/id/3.2/ref/models/fields/#django.db.models.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()`](/id/3.2/ref/files/storage/#django.core.files.storage.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`](/id/3.2/ref/forms/widgets/#django.forms.RadioSelect) dan [`CheckboxSelectMultiple`](/id/3.2/ref/forms/widgets/#django.forms.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`](/id/3.2/ref/forms/widgets/#django.forms.Textarea) sekarang menyertakan sebuah atribut `maxlength` jika bidang model [`TextField`](/id/3.2/ref/models/fields/#django.db.models.TextField) mempunyai `max_length`.
- [`Field.choices`](/id/3.2/ref/models/fields/#django.db.models.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`](/id/3.2/ref/forms/fields/#django.forms.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()`](/id/3.2/ref/forms/api/#django.forms.Form.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`](/id/3.2/ref/forms/fields/#django.forms.TypedChoiceField) mengembalikan sebuah nilai yang berubah-ubah.
- [`SelectDateWidget.months`](/id/3.2/ref/forms/widgets/#django.forms.SelectDateWidget.months) dapat digunakan untuk menyesuaikan rumus dari bulan ditampilkan di pilihan widget.
- Parameter `min_num` dan `validate_min` telah ditambahkan pada [`formset_factory()`](/id/3.2/ref/forms/formsets/#django.forms.formsets.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](/id/3.2/topics/forms/modelforms/#considerations-regarding-model-errormessages) untuk lebih rincian.

#### Internasionalisasi

- Atribut [`django.middleware.locale.LocaleMiddleware.response_redirect_class`](/id/3.2/ref/middleware/#django.middleware.locale.LocaleMiddleware.response_redirect_class) mengizinkan anda menyesuaian masalah pengalihan oleh middleware.
- [`LocaleMiddleware`](/id/3.2/ref/middleware/#django.middleware.locale.LocaleMiddleware) sekarang menyimpan bahasa terpilih pengguna dengan kunci sesi `_language`. Ini harus hanya bisa diakses menggunakan konstanta [`LANGUAGE_SESSION_KEY`](/id/3.2/ref/utils/#django.utils.translation.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`](/id/3.2/topics/i18n/translation/#std-templatetag-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`](/id/3.2/ref/django-admin/#django-admin-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](/id/3.2/topics/i18n/translation/#how-to-create-language-files) untuk rincian.
- Perintah [`makemessages`](/id/3.2/ref/django-admin/#django-admin-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`](/id/3.2/ref/settings/#std-setting-LANGUAGE_COOKIE_AGE), [`LANGUAGE_COOKIE_DOMAIN`](/id/3.2/ref/settings/#std-setting-LANGUAGE_COOKIE_DOMAIN) dan [`LANGUAGE_COOKIE_PATH`](/id/3.2/ref/settings/#std-setting-LANGUAGE_COOKIE_PATH).
- Ditambahkan [Format localization](/id/3.2/topics/i18n/formatting/) untuk Esperanto

#### Pengelolaan perintah

- Pilihan [`--no-color`](/id/3.2/ref/django-admin/#cmdoption-no-color) baru untuk `django-admin` meniadakan pewarnaan dari keluaran perintah pengelolaan.
- Pilihan option:dumpdata --natural-foreign dan [`dumpdata --natural-primary`](/id/3.2/ref/django-admin/#cmdoption-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`](/id/3.2/ref/django-admin/#django-admin-createcachetable). Django mengambil informasi ini dari berkas pengaturan anda. Jika anda telah mengkonfigurasikan banyak cache atau banyak basisdata, semua tabel cache dibuat.
- Perintah [`runserver`](/id/3.2/ref/django-admin/#django-admin-runserver) menerima beberapa perbaikan:

  - Di sistem Linux, jika [pyinotify](https://pypi.org/project/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`](/id/3.2/ref/django-admin/#django-admin-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`](/id/3.2/ref/contrib/staticfiles/#django-admin-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](https://pypi.org/project/sqlparse/) terpasang

  Catat bahwa itu diusangkan dalam mendukung dari operasi [`RunSQL`](/id/3.2/ref/migration-operations/#django.db.migrations.operations.RunSQL) dari perpindahan, yang manfaat dari perilaku yang ditingkatkan.

#### Model

- Metode [`QuerySet.update_or_create()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.update_or_create) telah ditambahkan.
- Model [`default_permissions`](/id/3.2/ref/models/options/#django.db.models.Options.default_permissions) baru pilihan `Meta` mengizinkan anda menyesuaikan (atau meniadakan) pembuatan dari awalan perizinan tambah, berubah, dan hapus.
- [`OneToOneField`](/id/3.2/ref/models/fields/#django.db.models.OneToOneField) eksplisit untuk [Warisan banyak-tabel](/id/3.2/topics/db/models/#multi-table-inheritance) sekarang ditemukan di kelas-kelas abstrak.
- Itu sekarang memungkinkan menghindari membuat hubungan kebelakang untuk [`OneToOneField`](/id/3.2/ref/models/fields/#django.db.models.OneToOneField) dengan mengatur [`related_name`](/id/3.2/ref/models/fields/#django.db.models.ForeignKey.related_name) nya menjadi `'+'` atau akhiri itu dengan `'+'`.
- [`F expressions`](/id/3.2/ref/models/expressions/#django.db.models.F) 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`](/id/3.2/ref/models/querysets/#std-fieldlookup-iexact).
- Itu sekarang memungkinkan melewatkan callable sebagai nilai untuk atribut [`limit_choices_to`](/id/3.2/ref/models/fields/#django.db.models.ForeignKey.limit_choices_to) ketika menentukan `ForeignKey` atau `ManyToManyField`.
- Memanggil [`only()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.only) dan [`defer()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.defer) di hasil dari [`QuerySet.values()`](/id/3.2/ref/models/querysets/#django.db.models.query.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`](/id/3.2/ref/models/options/#django.db.models.Options.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`](/id/3.2/ref/models/fields/#django.db.models.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`](/id/3.2/ref/models/fields/#django.db.models.Field.get_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()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.order_by) sebuah hubungan bidang `_id` dengan menggunakan nama atributnya.

#### Sinyal

- Argumen `enter` telah ditambahkan ke sinyal [`setting_changed`](/id/3.2/ref/signals/#django.test.signals.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()`](/id/3.2/ref/templates/api/#django.template.Context.push) sekarang mengembalikan pengelola konteks yang secara otomatis memanggil [`pop()`](/id/3.2/ref/templates/api/#django.template.Context.pop) diatas mengeluarkan pernyataan `with`. Sebagai tambahan, [`push()`](/id/3.2/ref/templates/api/#django.template.Context.push) sekarang menerima parameter yang dilewatkan ke pembangun `dict` digunakan untuk membangun tingkatak konteks baru.
- Metode [`Context.flatten()`](/id/3.2/ref/templates/api/#django.template.Context.flatten) baru mengembalikan sebuah tumpukan `Context` sebagai satu kamus datar.
- Obyek `Context` sekarang dapat dibandingkan untuk kesetaraan (secara internal, ini menggunakan [`Context.flatten()`](/id/3.2/ref/templates/api/#django.template.Context.flatten) jadi struktur internal dari setiap tumpukan `Context` tidak masalah selama versi diluruskan mereka mirip).
- Etiket cetakan [`widthratio`](/id/3.2/ref/templates/builtins/#std-templatetag-widthratio) sekarang menerima sebuah parameter `"as"` untuk mengambil hasil di sebuah variabel.
- Etiket cetakan [`include`](/id/3.2/ref/templates/builtins/#std-templatetag-include) akan sekarang juga menerima apapun dengan metode `render()` (seperti `Template`) sebagai sebuah argumen. Argumen deretan karakter akan dicari menggunakan [`get_template()`](/id/3.2/topics/templates/#django.template.loader.get_template) seperti biasanya.
- Sekarang memungkinkan untuk [`include`](/id/3.2/ref/templates/builtins/#std-templatetag-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`:

  - [`django.template.loader.get_template()`](/id/3.2/topics/templates/#django.template.loader.get_template)
  - [`django.template.loader.select_template()`](/id/3.2/topics/templates/#django.template.loader.select_template)
  - [`django.shortcuts.render()`](/id/3.2/topics/http/shortcuts/#django.shortcuts.render)
  - `django.shortcuts.render_to_response()`
- Penyaring [`time`](/id/3.2/ref/templates/builtins/#std-templatefilter-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](/id/3.2/topics/i18n/timezones/#naive-vs-aware-datetimes) `datetime` melakukan pembangunan yang diharapkan.
- Etiket [`cache`](/id/3.2/topics/cache/#std-templatetag-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`](/id/3.2/ref/templates/builtins/#std-templatefilter-truncatechars_html) baru memotong sebuah deretan karakter untuk jadi tidak panjang dari angka yang ditentukan dari karakter, mengambil HTML kedalam akun.

#### Permintaan dan Tanggapan

- Atribut [`HttpRequest.scheme`](/id/3.2/ref/request-response/#django.http.HttpRequest.scheme) baru menentukan skema dari permintaan (`http` atau `https` secara umum).
- Jalan pintas [`redirect()`](/id/3.2/topics/http/shortcuts/#django.shortcuts.redirect) sekarang mendukung URL relatif.
- Subkelas [`JsonResponse`](/id/3.2/ref/request-response/#django.http.JsonResponse) baru dari [`HttpResponse`](/id/3.2/ref/request-response/#django.http.HttpResponse) membantu dengan mudah membuat tanggapan JSON-disandikan.

#### Pengujian

- [`DiscoverRunner`](/id/3.2/topics/testing/advanced/#django.test.runner.DiscoverRunner) mempunyai dua atribut baru, [`test_suite`](/id/3.2/topics/testing/advanced/#django.test.runner.DiscoverRunner.test_suite) dan [`test_runner`](/id/3.2/topics/testing/advanced/#django.test.runner.DiscoverRunner.test_runner), yang memfasilitasi menimpa cara percobaan dikumpulkan dan berjalan.
- Argumen `fetch_redirect_response` telah ditambahkan ke [`assertRedirects()`](/id/3.2/topics/testing/tools/#django.test.SimpleTestCase.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()`](/id/3.2/topics/testing/tools/#django.test.SimpleTestCase.assertRedirects).
- Argumen `secure` telah ditambahkan ke semua metode permintaan dari [`Client`](/id/3.2/topics/testing/tools/#django.test.Client). Jika `True`, permintaan akan dibuat melalui HTTPS.
- [`assertNumQueries()`](/id/3.2/topics/testing/tools/#django.test.TransactionTestCase.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`](/id/3.2/topics/testing/tools/#django.test.Response.wsgi_request).
- Pengaturan basisdata untuk percobaan telah dikumpulkan kedalam kamus dinamai [`TEST`](/id/3.2/ref/settings/#std-setting-DATABASE-TEST).

#### Keperluan

- Ditingkatkan keakuratan [`strip_tags()`](/id/3.2/ref/utils/#django.utils.html.strip_tags) (tetapi itu masih tidak dapat menjamin sebuah hasil aman-HTML, seperti dinyatakan di dokumentasi).

#### Pengesah

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

## Perubahan bertentangan kebelakang di 1.7

> **Warning**
>
> Sebagai tambahan pada perubahan diuraikan di bagian ini, pastikan untuk meninjau kembali [deprecation plan](/id/3.2/internals/deprecation/#deprecation-removed-in-1-7) 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](/id/3.2/topics/migrations/#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](/id/3.2/howto/custom-model-fields/#custom-field-deconstruct-method).

Persyaratan untuk semua bidang argumen untuk menjadi [serializable](/id/3.2/topics/migrations/#migration-serializing) 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](/id/3.2/topics/migrations/#custom-deconstruct-method), 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](/id/3.2/ref/applications/#applications-troubleshooting) 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`](/id/3.2/topics/settings/#envvar-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`](/id/3.2/ref/applications/#django.apps.AppConfig) untuk satu dari mereka dan menimpa [`label`](/id/3.2/ref/applications/#django.apps.AppConfig.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`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH). Mengacu pada bagian di tata letak proyek baru di [1.4 release notes](/id/3.2/releases/1.4/) untuk pentunjuk perpindahan.

Anda harus pastikan itu:

- Semua model ditentukan di aplikasi yang didaftarkan di [`INSTALLED_APPS`](/id/3.2/ref/settings/#std-setting-INSTALLED_APPS) atau mempunyai sebuah [`app_label`](/id/3.2/ref/models/options/#django.db.models.Options.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`](/id/3.2/howto/custom-management-commands/#django.core.management.AppCommand) harus sekarang menerapkan sebuah metode [`handle_app_config()`](/id/3.2/howto/custom-management-commands/#django.core.management.AppCommand.handle_app_config) daripada `handle_app()`. Metode ini menerima sebuah instance [`AppConfig`](/id/3.2/ref/applications/#django.apps.AppConfig) daripada modul model.

#### Menginterospeksi aplikasi

Sejak [`INSTALLED_APPS`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/applications/#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`](https://docs.python.org/3/library/exceptions.html#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`](/id/3.2/ref/settings/#std-setting-INSTALLED_APPS)

Ketika beberapa aplikasi menyediakan perintah pengelolaan dengan nama sama, Django memuat perintah dari aplikasi yang datang pertama di [`INSTALLED_APPS`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/settings/#std-setting-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.

Also if you directly assigned the return value of `update_error_dict()`
to `Form._errors` you may inadvertently add `list` instances where
`ErrorList` instances are expected. This is a problem because unlike a
simple `list`, an `ErrorList` knows how to handle instances of
`ValidationError`.

Kebanyakan kasus-digunakan yang menjamin menggunakan API pribadi ini sekarang dicakupi oleh metode [`Form.add_error()`](/id/3.2/ref/forms/api/#django.forms.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()`](/id/3.2/ref/forms/api/#django.forms.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](https://code.djangoproject.com/ticket/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](https://code.djangoproject.com/ticket/13724) untuk lebih rinci.

### `pytz` may be required

Jika proyek anda menangani datetime sebelum 1970 dan setelah 2037 dan Django memunculkan sebuah [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) ketika menghadapi mereka, anda harus memasang [pytz](https://pypi.org/project/pytz/). Anda mungkin terpengaruh oleh masalah ini jika anda menggunakan bentuk terkait-zona waktu Django atau [`django.contrib.syndication`](/id/3.2/ref/contrib/syndication/#module-django.contrib.syndication).

### Metode `remove()` dan `clear()` dari pengelola terkait

Metode `remove()` dan `clear()` dari pengelola terkait dibuat oleh `ForeignKey`, `GenericForeignKey`, and `ManyToManyField` menderita dari sejumlah masalah. Beberapa tindakan berjalan banyak data merubah permintaan tanpa membungkus mereka di sebuah transaksi, dan beberapa tindakan tidak menanggapi penyaringan awalan ketika itu dicegah (yaitu ketika pengelola awalan di model terkait menerapkan sebuah penyesuaian `get_queryset()`).

Memperbaiki beberapa masalah memperkenalkan beberapa perubahan tidakkesuaian kebelakang:

- Penerapan awalan dari `remove()` untuk pengelola terkait `ForeignKey` berubah dari rangkaian panggilan `Model.save()` ke panggilan `QuerySet.update()` tunggal. Perubahan berarti bahwa sinyal `pre_save` dan `post_save` tidak dikirim lagi. Anda dapat menggunakan argumen kata kunci `bulk=False` untuk kembali ke perilaku sebelumnya.
- Metode `remove()` dan `clear()` untuk pengelola terkait `GenericForeignKey` sekarang melakukan penghapusan dalam jumlah besar. Metode `Model.delete()` tidak dipanggil di setiap instance lagi. Anda dapat menggunakan argumen kata kunci `bulk=False` untuk kembali ke perilaku sebelumnya.
- Metode `remove()` dan `clear()` untuk pengelola terkait `ManyToManyField` melakukan permintaan ketika penyaringan dilibatkan, yang mungkin atau tidak menjadi sebuah masalah tergantung pada basisdata anda dan data anda itu sendiri. Lihat [this note](/id/3.2/ref/models/querysets/#nested-queries-performance) untuk rincian lebih.

### 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()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.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`](/id/3.2/ref/settings/#std-setting-DATABASE-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`](/id/3.2/topics/testing/tools/#django.test.TransactionTestCase) daripada [`TestCase`](/id/3.2/topics/testing/tools/#django.test.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`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/middleware/#django.contrib.sessions.middleware.SessionMiddleware), [`AuthenticationMiddleware`](/id/3.2/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware), dan [`MessageMiddleware`](/id/3.2/ref/middleware/#django.contrib.messages.middleware.MessageMiddleware) dipindahkan dari awalan. Kelas-kelas ini masih disertakan dalam pengaturan awalan dibangkitkan oleh [`startproject`](/id/3.2/ref/django-admin/#django-admin-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()`](/id/3.2/ref/files/uploads/#django.core.files.uploadhandler.FileUploadHandler.new_file) sekarang melewatkan sebuah parameter `content_type_extra` tambahan. Jika anda mempunyai penyesuaian [`FileUploadHandler`](/id/3.2/ref/files/uploads/#django.core.files.uploadhandler.FileUploadHandler) yang menerapkan `new_file()`, pastikan itu menerima parameter baru ini.
- [`ModelFormSet`](/id/3.2/topics/forms/modelforms/#django.forms.models.BaseModelFormSet) tidak lagi menghapus instance ketika `save(commit=False)` dipanggil. Lihat [`can_delete`](/id/3.2/topics/forms/formsets/#django.forms.formsets.BaseFormSet.can_delete) untuk petunjuk pada bagaimana secara manual menghapus obyek dari formulir dihapus.
- Memuat alat bantu kosong memancarkan `RuntimeWarning` dari pada memunculkan [`CommandError`](/id/3.2/howto/custom-management-commands/#django.core.management.CommandError).
- [`django.contrib.staticfiles.views.serve()`](/id/3.2/ref/contrib/staticfiles/#django.contrib.staticfiles.views.serve) akan sekarang memunculkan sebuah pengecualian [`Http404`](/id/3.2/topics/http/views/#django.http.Http404) daripada [`ImproperlyConfigured`](/id/3.2/ref/exceptions/#django.core.exceptions.ImproperlyConfigured) ketika [`DEBUG`](/id/3.2/ref/settings/#std-setting-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__()`](/id/3.2/ref/models/instances/#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__()`](/id/3.2/ref/models/instances/#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__()`](/id/3.2/ref/models/instances/#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`](/id/3.2/ref/models/fields/#django.db.models.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`](/id/3.2/ref/django-admin/#django-admin-dumpdata) untuk menyimpan data anda.
  2. Namai kembali berkas basisdata yang ada (biarkan sebagai sokongan).
  3. Jalankan [`migrate`](/id/3.2/ref/django-admin/#django-admin-migrate) untuk membuat skema terperbaharui.
  4. Gunakan [`loaddata`](/id/3.2/ref/django-admin/#django-admin-loaddata) untuk mengimpor perlengkapan anda ekspor dalam (1).
- `django.contrib.auth.models.AbstractUser` tidak lagi menentukan sebuah metode [`get_absolute_url()`](/id/3.2/ref/models/instances/#django.db.models.Model.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`](/id/3.2/ref/settings/#std-setting-ABSOLUTE_URL_OVERRIDES) jika anda ingin URL untuk pengguna anda.
- Kegunaan melayani-aset tetap dari kelas [`django.test.LiveServerTestCase`](/id/3.2/topics/testing/tools/#django.test.LiveServerTestCase) telah disederhanakan: Sekarang itu hanya dapat melayani isi sudah hadir di [`STATIC_ROOT`](/id/3.2/ref/settings/#std-setting-STATIC_ROOT) ketika percobaan berjalan. Kemampuan untuk secara transparan melayani semua aset tetap (mirip pada apa satu dapatkan dengan [`DEBUG = True`](/id/3.2/ref/settings/#std-setting-DEBUG) 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`](/id/3.2/ref/contrib/staticfiles/#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`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/forms/widgets/#django.forms.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()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.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`](/id/3.2/ref/settings/#std-setting-DATABASE-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](/id/3.2/topics/db/models/#model-multiple-inheritance-topic) 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`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.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`](/id/3.2/ref/settings/#std-setting-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](/id/3.2/ref/checks/), [fields, models, and model managers](/id/3.2/topics/checks/#field-checking) 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`](/id/3.2/ref/settings/#std-setting-CACHES-TIMEOUT) dari pengaturan [`CACHES`](/id/3.2/ref/settings/#std-setting-CACHES) sebagai `None` akan menyetel kunci cache sebagai "non-expiring". Sebelumnya, dengan backend memcache, sebuah [`TIMEOUT`](/id/3.2/ref/settings/#std-setting-CACHES-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`](/id/3.2/ref/settings/#std-setting-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`](/id/3.2/ref/django-admin/#django-admin-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`](/id/3.2/topics/cache/#django.core.cache.caches).

### `django.utils.dictconfig`/`django.utils.importlib`

`django.utils.dictconfig` dan `django.utils.importlib` telah disalin masing-masing [`logging.config`](https://docs.python.org/3/library/logging.config.html#module-logging.config) dan [`importlib`](https://docs.python.org/3/library/importlib.html#module-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`](/id/3.2/ref/exceptions/#django.core.exceptions.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()`](/id/3.2/ref/utils/#django.utils.module_loading.import_string).

### `django.utils.tzinfo`

`django.utils.tzinfo` menyediakan dua [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo) subclasses, `LocalTimezone` dan `FixedOffset`. Mereka telah diusangkan dalam mendukung lebih jalan lain yang benar disediakan oleh [`django.utils.timezone`](/id/3.2/ref/utils/#module-django.utils.timezone), [`django.utils.timezone.get_default_timezone()`](/id/3.2/ref/utils/#django.utils.timezone.get_default_timezone) dan [`django.utils.timezone.get_fixed_timezone()`](/id/3.2/ref/utils/#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`](https://docs.python.org/3/library/unittest.html#module-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`](https://docs.python.org/3/library/unittest.html#module-unittest) sebagai gantinya.

### `django.utils.datastructures.SortedDict`

Ketika [`OrderedDict`](https://docs.python.org/3/library/collections.html#collections.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`](/id/3.2/ref/settings/#std-setting-INSTALLED_APPS). Refaktor memuat-aplikasi menambahkan beberapa batasan di keadaan tersebut. Sebagai akibatnya, dua obyek dipindah, dan tempat lama diusangkan:

- [`RequestSite`](/id/3.2/ref/contrib/sites/#django.contrib.sites.requests.RequestSite) sekarang berada di `django.contrib.sites.requests`.
- [`get_current_site()`](/id/3.2/ref/contrib/sites/#django.contrib.sites.shortcuts.get_current_site) sekarang berada di `django.contrib.sites.shortcuts`.

### 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`](/id/3.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes) dan modul `django.contrib.contenttypes.generic` diusangkan.

- [`GenericForeignKey`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericForeignKey) dan [`GenericRelation`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericRelation) sekarang berada di [`fields`](/id/3.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes.fields).
- [`BaseGenericInlineFormSet`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.BaseGenericInlineFormSet) dan [`generic_inlineformset_factory()`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.generic_inlineformset_factory) sekarang berada di [`forms`](/id/3.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes.forms).
- [`GenericInlineModelAdmin`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericInlineModelAdmin), [`GenericStackedInline`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericStackedInline) dan [`GenericTabularInline`](/id/3.2/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericTabularInline) sekarang berada di [`admin`](/id/3.2/ref/contrib/contenttypes/#module-django.contrib.contenttypes.admin).

### `syncdb`

Perintah `syncdb` telah diusangkan dalam mendukung dari perintah [`migrate`](/id/3.2/ref/django-admin/#django-admin-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()`](/id/3.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.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`](/id/3.2/ref/models/fields/#django.db.models.GenericIPAddressField) dan [`django.forms.GenericIPAddressField`](/id/3.2/ref/forms/fields/#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`](/id/3.2/ref/django-admin/#django-admin-dumpdata) telah diusangkan. Gunakan [`dumpdata --natural-foreign`](/id/3.2/ref/django-admin/#cmdoption-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`](/id/3.2/ref/forms/fields/#django.forms.DateTimeField) diusangkan, gunakan `SplitDateTimeWidget` dengan [`SplitDateTimeField`](/id/3.2/ref/forms/fields/#django.forms.SplitDateTimeField) sebagai gantinya.

### `validate`

Perintah pengelolaan `validate` diusangkan dalam mendukung dari perintah [`check`](/id/3.2/ref/django-admin/#django-admin-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`](/id/3.2/ref/templates/builtins/#std-templatetag-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`](/id/3.2/ref/templates/builtins/#std-templatefilter-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`](/id/3.2/ref/settings/#std-setting-DATABASE-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](/id/3.2/ref/models/lookups/) 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](/id/3.2/releases/1.5/#deprecated-features-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`](/id/3.2/ref/request-response/#django.http.HttpResponse), [`SimpleTemplateResponse`](/id/3.2/ref/template-response/#django.template.response.SimpleTemplateResponse), [`TemplateResponse`](/id/3.2/ref/template-response/#django.template.response.TemplateResponse), `render_to_response()`, [`index()`](/id/3.2/ref/contrib/sitemaps/#django.contrib.sitemaps.views.index), dan [`sitemap()`](/id/3.2/ref/contrib/sitemaps/#django.contrib.sitemaps.views.sitemap) tidak lagi mengambil sebuah argumen `mimetype`
- [`HttpResponse`](/id/3.2/ref/request-response/#django.http.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()`](/id/3.2/ref/models/querysets/#django.db.models.query.QuerySet.select_related) tidak lagi mempunyai argumen kata kunci `depth`.
- Fungsi `get_warnings_state()`/`restore_warnings_state()` dari [`django.test.utils`](/id/3.2/topics/testing/advanced/#module-django.test.utils) dan the `save_warnings_state()`/ `restore_warnings_state()` [django.test.\*TestCase](/id/3.2/topics/testing/tools/#django-testcase-subclasses) dipindahkan.
- Metode `check_for_test_cookie` di [`AuthenticationForm`](/id/3.2/topics/auth/default/#django.contrib.auth.forms.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.