# dokumentasi Django 2.0.8

# Catatan terbitan Django 1.6

Catatan

Dipersembahkan kepada Malcolm Tredinnick

Pada 17 Maret 2013, proyek Django dan komunitas perangkat lunak bebas kehilangan teman dan pengembang.

Malcom adalah pembantu lama pada Django, sebuah model anggota komunitas, pikiran cemerlang, dan seorang teman. Bantuannya pada Django - dan ke banyak proyek sumber terbuka lainnya - hampir tidak mungkin menghitung. Banyak pada tim Django inti mempunyai tambalan pertama mereka ditinjau oleh dia; bimbingannya memperkaya kami. Pertimbangan dia, kesabaran, dan pengabdian akan selalu menjadi inspirasi untuk kami.

Terbitan Django ini untuk Malcolm.

-- Pengembang Django

November 6, 2013

Selamat datang di Django 1.6!

Catatan terbitan ini mencangkupi new features, sama halnya beberapa backwards incompatible changes anda akan ingin menjadi waspada ketika meningkatkan dari Django 1.5 atau versi terlama. Kami telah membuang beberapa fitur, yang rinciannya di our deprecation plan, dan kami telah begun the deprecation process for some features.

## Kesesuaian Python

Django 1.6, seperti Django 1.5, membutuhkan Python 2.6.5 atau diatasnya. Python 3 juga secara resmi didukung. Kami sangat menganjurkan terbitan kecil terakhir untuk setiap rangkaian Python yang didukung (2.6.X, 2.7.X, 3.2.X, and 3.3.X).

Django 1.6 akan menjadi rangkaian terbitan terakhir untuk mendukung Python 2.6; dimulai dengan Django 1.7, minimal dukungan versi Python akan menjadi 2.7.

Python 3.4 tidak didukung, tetapi dukungan akan ditambahkan di Django 1.7.

## Apa yang baru di Django 1.6

### Sederhanakan proyek awal dan cetakan aplikasi

Cetakan awalan digunakan oleh `startproject` dan `startapp` telah disederhanakan dan dimodernisasikan. admin sekarng diadakan secara awalan di proyek baru; kerangka kerja sites tidak lagi. clickjacking prevention sekarang di dan awalan basisdata pada SQLite.

Jika awalan cetakan tidak cocok dengan rasa anda, anda dapat menggunakan custom project and app templates.

### Perbaikan pengelolaan transaksi

Pengelolaan transaksi Django dirombak. Tingkat-basisdata pembenaran otomatis sekarang nyala sebagai awalan. Ini membuat penanganan transaksi lebih jelas dan harus meningkatkan penampilan. API yang ada diusangkan, dan API baru telah diperkenalkan, sebagai digambarkan di transaction management docs.

### Hubungan basisdata gigih

Django sekarang menggunakan penggunaan kembali hubungan basisdata sama untuk beberapa permintaan. Ini menghindari kelebihan dari membangun kembali sebuah hubungan pada awal dari setiap permintaan. Untuk kesesuaian kebelakang, fitur ini ditiadakan secara awalan. Lihat Hubungan tetap untuk rincian.

### Penemuan percobaan di tiap modul percobaan

Django 1.6 dibekali dengan pejalan percobaan baru yang mengizinkan lebih keluwesan di tempat dari percobaan. Pejalan sebelumnya (`django.test.simple.DjangoTestSuiteRunner`) menemukan percobaan hanya di modul `models.py` dan `tests.py` dari paket Python di `INSTALLED_APPS`.

Pejalan baru (`django.test.runner.DiscoverRunner`) menggunakan fitur penemuan percobaan dibangun kedalam `unittest2` (versi dari `unittest` di pustaka standar Python 2.7+, dan digabung dengan Django). Dengan penemuan percobaan, percobaan dapat ditempatkan di tiap modul yang namanya cocok dengan pola `test*.py`.

Sebagai tambahan, label percobaan disediakan pada `./manage.py test` untuk menunjuk percobaan khusus untuk berjalan harus sekarang menjadi jalur bertitik Python penuh (atau jalur direktori), daripada halur-semu `applabel.TestCase.test_method_name`. Ini mengizinkan menjalankan percobaan ditempatkan dimana saja di basis kode anda, daripada hanya di `INSTALLED_APPS`. Untuk rincian lebih, lihat Percobaan di Django.

Perubahan ini adalah kesesuaian-kebelakang; lihat backwards-incompatibility notes.

### Mengetahui pengumpulan zona waktu

Dukungan untuk time zones diperkenalkan di DJango 1.4 tidak bekerja baik dengan `QuerySet.dates()`: pengumpulan selalu dilakukan di UTC. Batasan ini telah diangkat di Django 1.6. Gunakan `QuerySet.datetimes() <django.db.models.query.QuerySet.datetimes>`untuk melakukan mengetahui pengumpulan zona waktu di :class:`~django.db.models.DateTimeField()`.

### Dukungan untuk savepoint di SQLite

Django 1.6 menambahkan dukungan untuk savepoint di SQLite, dengan beberapa limitations.

### Bidang model `BinaryField`

Bidang model `django.db.models.BinaryField` baru mengizinkan penyimpanan dari data biner mentah di basisdata.

### GeoDjango dari widget

GeoDjango sekarang menyediakan form fields and widgets untuk bidang khusus-geo nya. Mereka adalah berdasarkan-OpenLayer secara awalan, tetapi mereka dapat disesuaiakan untuk menggunakan apapun kerangka kerja JS lain.

### Perintah pengelolaan `check` ditambahkan untuk mengecek kesesuaian

Sebuah perintah pengelolaan `check` telah ditambahkan, mengadakan anda untuk memeriksa jika konfigurasi anda saat ini (saat ini bertujuan pada pengaturan) adalah cocok dengan versi saat ini dari Django.

### Algoritma `Model.save()` berubah

Metode `Model.save()` sekarang mencoba secara langsung `UPDATE` basisdata jika instance mempunyai sebuah nilai primary key. Sebelumnya `SELECT` telah dilakukan untuk menentukan jika `UPDATE` atau `INSERT` dibutuhkan. Algoritma baru dibutuhkan jika hanya satu permintaan untuk memperbaharui baris yang ada selagi algoritma lama membutuhkan dua. Lihat `Model.save()` untuk lebih rinci.

Di beberapa kasus yang jarang basisdata tidak melaporkan bahwa sebuah baris yang cocok telah ditemukan ketika melakukan sebuah `UPDATE`. Sebuah contoh adalah pemicu `ON UPDATE` PostgreSQL yang mengembalikan `NULL`. Dalam kasus tersebut itu memungkinkan menyetel bendera `django.db.models.Options.select_on_save` untuk memaksa menyimpan menggunakan algoritma lama.

### Fitur kecil

- Backend otentifikasi dapat memunculkan `PermissionDenied` untuk segera menggagalkan rantai otentifikasi.
- Bendera `HttpOnly` dapat disetel di kue CSRF dengan `CSRF_COOKIE_HTTPONLY`.
- `assertQuerysetEqual()` sekarang diperiksa untuk urutan tidak ditentukan dan memunculkan `ValueError` jika urutan tidak ditentukan dilihat. Urutan dilihat sebagai tidak ditentukan jika `QuerySet` diberikan tidak diurutkan dan ada lebih dari satu nilai terurut untuk dibandingkan.
- Ditambahkan `earliest()` untuk simetri dengan `latest()`.
- Sebagai tambahan pada `year`, `month` dan `day`, ORM sekarang mendukung pencarian `hour`, `minute` dan `second`.
- Django sekarang membungkus pengecualian PEP-249
- Widget awalan untuk `EmailField`, `URLField`, `IntegerField`, `FloatField` dan `DecimalField` menggunakan atribut jenis baru tersedia di HTML5 (`type='email'`, `type='url'`, `type='number'`). Catat bagwa karena dukungan tak menentu dari jenis masukan `number` dengan angka lokal di peramban saat ini, Django hanya menggunakannya ketika bidang numerik tidak di lokalkan.
- Argumen `number` untuk lazy plural translations dapat disediakan pada waktu terjemahan daripada saat waktu penentuan.
- Untuk perintah pengelolaan penyesuaian: Pemeriksaan dari kehadiran pengaturan sah dalam perintah yang meminta itu dengan menggunakan pilihan internal `BaseCommand.can_import_settings` sekarang dilakukan berdiri sendiri dari menangani dari lokal yang harus aktif selama penjalanan dari perintah. Terakhir dapat sekarang dipengaruhi dengan pilihan internal `leave_locale_alone` baru. Lihat Pengelolaan perintah dan lokal untuk lebih rinci.
- `success_url` dari `DeletionMixin` sekarang ditambahkan dengan `__dict__` `object` nya.
- `HttpResponseRedirect` dan `HttpResponsePermanentRedirect` sekarang menyediakan sebuah atribut `url` (setara dengan tanggapan URL akan dialihkan).
- Backend penyimpanan sementara `MemcachedCache` sekarang menggunakan protokol `pickle` yang terakhir tersedia.
- Ditambahkan `SuccessMessageMixin` yang menyediakan sebuah atribut `success_message` untuk `FormView` berdasarkan kelas-kelas.
- Ditambahkan pilihan `django.db.models.ForeignKey.db_constraint` dan `django.db.models.ManyToManyField.db_constraint`.
- Pustaka jQuery ditanam di admin telah ditingkatkan ke versi 1.9.1.
- Umpan kongsi (`django.contrib.syndication`) sekarang dapat melewatkan konteks tambahan melalui cetakan umpan menggunakan callback `Feed.get_context_data()` baru.
- Kolom daftar admin mempunyai sebuah kelas `column-<field_name>` di HTML jadi kepalakolom dapat digaya dengan CSS, sebagai contoh untuk menyetel lebar kolom.
- isolation level dapat disesuaikan dibawah PostgreSQL.
- Etiket cetakan `blocktrans` sekarang mematuhi `TEMPLATE_STRING_IF_INVALID` untuk variabel tidak hadir di konteks, sama seprti penyusunan cetakan lain.
- `SimpleLazyObject` sekarang akan menghadirkan gambaran lebih membantu dalam keadaan mencari kesalahan shell.
- Generic `GeometryField` is now editable with the OpenLayers widget in the admin.
- Dokumentasi mengandung deployment checklist.
- Perintah `diffsettings` mendapatkan pilihan `--all`.
- `django.forms.fields.Field.__init__` sekarang memanggil `super()`, mengizinkan campuran bidang untuk menerapkan metode `__init__()` yang akan dapat dihandalkan dipanggil.
- Parameter `validate_max` telah ditambahkan ke `BaseFormSet` dan `formset_factory()`, dan `ModelForm` dan versi berderet dari yang sama. Perilaku dari pengesahan untuk formset dengan `max_num` telah dijelaskan. Sebelumnya perilaku tidak terdokumentasi yang mengeraskan formset terhadap serangan kelelahan ingatan telah didokumentasikan, dan tidak terdokumentasi terbatas dari lebih tinggi 1000 atau `max_num` formulir telah dirubah jadi itu selalu 1000 lebih daripada `max_num`.
- Ditambahkan `BCryptSHA256PasswordHasher` untuk menyelesaikan masalah pemotongan sandi dengan bcrypt.
- Pillow sekarang memilih pustaka mengubah gambar untuk menggunakan dengan Django. PIL ditunda pengusangan (dukungan untuk dipindahkan di Django 1.8). Untuk meningkatkan, anda harus pertama melepas PIL, kemudian pasang Pillow.

- `ModelForm` menerima beberapa pilihan `Meta` baru.
  - Bidang-bidang disertakan dalam daftar `localized_fields` akan dilokalkan (dengan menyetel `localize` pada bidang formulir).
  - Pilihan `labels`, `help_texts` dan `error_messages` mungkin digunakan untuk menyesuaikan bidang awalan, lihat Mengesampingan nilai awal untuk rincian.
- Argumen `choices` pada bidang model sekarang menerima sebuah perulangan dari perulangan sebagai gantinya membutuhkan sebuah perulangan dari daftar atau tuple.
- Alasan frase dapat disesuaikan di tanggapan HTTP menggunakan `reason_phrase`.
- Ketika memberikan URL dari halaman selanjutnya untuk `logout()`, `password_reset()`, `password_reset_confirm()`, dan `password_change()`, anda dapat sekarang melewati nama URL dan mereka akan diselesaikan.
- Pilihan `dumpdata --pks` baru menentukan primary key dari obyek untuk membuang. Pilihan ini dapat hanya digunakan dengan satu model.
- Ditambahkan metode `QuerySet` `first()` dan `last()` yang metode kenyamanan mengembalikan obyek pertama atau terakhir mencocokkan saringan. Mengembalikan `None` jika tidak ada pencocokan obyek.
- `View` dan `RedirectView` sekarang mendukung metode HTTP `PATCH`.
- `GenericForeignKey` sekarang mengambil sebuah pilihan argumen `for_concrete_model`, yang ketika disetel ke `False` mengizinkan bidang untuk mengacu model proxy. Awalan adalah `True` untuk memelihara perilaku lama.
- `LocaleMiddleware` sekarang menyimpan bahasa aktif di sesi jika itu tidak hadir disana. Ini mencegah kehilangan dari pengaturan bahasa setelah menyiram sesi, sebagai contoh keluar.
- `SuspiciousOperation` telah dibedakan menjadi sejumlah subkelas, dan setiap akan masuk untuk mencocokan pencatat bernama dibawah hirarki pencatatan `django.security`. Bersama dengan perubahan ini, sebuah mekanisme `handler400` dan tampilan awal digunakan ketika kapanpun `SuspiciousOperation` mencapai penangan WSGI untuk mengembalikan sebuah `HttpResponseBadRequest`.
- Pengecualian `DoesNotExist` sekarang menyertakan sebuah pesan yang menunjukkan nama dari atribut digunakan untuk pencarian.
- Metode `get_or_create()` tidak lagi membutuhkan setidaknya satu argumen katakunci.
- Kelas `SimpleTestCase` termasuk pembantu tuntutan baru untuk percobaan kesalahan formset: `assertFormsetError()`.
- Daftar dari bidang-bidang terkait ditambahkan pada `QuerySet` oleh `select_related()` dapat dibersihkan menggunakan `select_related(None)`.
- Metode `get_extra()` dan `get_max_num()` pada `InlineModelAdmin` mungkin dikesampingkan untuk menyesuaikan jumlah tambahan dan maksimal dari formulir berderet.
- Formset sekarang mempunyai sebuah metode `total_error_count()`.
- Bidang-bidang `ModelForm` sekarang dapat menimpa pesan-pesan kesalahan ditentukan di bidang model dengan menggunakan argumen `error_messages` dari pembangun `Field`. Untuk mengambil kesimpulan dari fitur ini dengan bidang penyesuaian anda, see the updated recommendation untuk memunculkan `ValidationError`.
- `ModelAdmin` sekarang mempertahankan penyaring pada daftar tampilan setelah membuat, menyunting atau menghapus sebuah obyek. Itu memungkinkan menyimpan kembali perilaku sebelumnya dari membersihkan penyaring dengan mengatur atribut `preserve_filters` menjadi `False`.
- Ditambahkan `FormMixin.get_prefix` (yang mengembalikan `FormMixin.prefix` secara awalan) untuk mengizinkan menyesuaikan `prefix` dari formulir.
- Permintaan mentah (`Manager.raw()` atau `cursor.execute()`) sekarang dapat menggunakan gaya parameter "pyformat", dimana placeholder dalam permintaan diberikan sebagai `'%(name)s'` dan parameter dilewatkan sebagai sebuah kamus daripada sebuah daftar (kecuali di SQLite). Ini telam lama mungkin (tetapi bukan secara resmi didukung) di MySQL dan PostgreSQL, dan sekarang juga tersedia di Oracle.
- Perhitungan putaran awal untuk pengacak sandi PBKDF2 telah ditingkatkan oleh 20%. Perubahan kesesuaian kebelakang tidak akan mempengaruhi sandi atau pengguna yang mempunyai disubkelaskan `django.contrib.auth.hashers.PBKDF2PasswordHasher` untuk merubah nilai awal. Sandi will be upgraded untuk menggunakan perhitungan putaran baru sesuai kebutuhan.

## Perubahan bertentangan kebelakang di 1.6

Peringatan

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

### Model pengelolaan transaksi baru

#### Perubahan perilaku

Pembenaran otomatis tingkat-basisdata diadakan secara awalan di Django 1.6. Selagi ini tidak merubah jiwa umum dari pengelolaan transaksi Django, ada sedikit ketidaksesuaian-kebelakang.

#### Savepoints dan `assertNumQueries`

Perubahan di pengelolaan transaksi dapat menghasilkan di pernyataan tambahan untuk membuat, menerbitkan atau menyimpan kembali titik penyimpanan sampai terbitan ini.

Jika percobaan menggunakan `assertNumQueries()` gagal karena dari angka tertinggi dari permintaan daripada diharapkan, periksa bahwa permintaan tambahan dikaitkan ke titik penyimpanan, dan menyesuaikan angka yang diharapkan dari permintaan sesuai dengan itu.

#### Pilihan perbaikan otomatis untuk PostgreSQL

Di versi sebelumnya, perbaikan otomatis tingkatan-basisdata hanya sebuah pilihan untuk PostgreSQL, dan itu ditiadakan secara awalan. Pilihan ini sekarang diabaikan dan dapat dipindah.

### Pejalan percobaan baru

Untuk merawat ketetapan lebih hebat dengan modul unittest Python, pejalan percobaan baru (`django.test.runner.DiscoverRunner`) tidak secara otomatis mendukung beberapa jenis dari percobaan yang telah didukung oleh pejalan sebelumnya:

- Percobaan di berkas `models.py` dan `tests/__init__.py` tidak lagi ditemukan dan berjalan. Pindahkan mereka ke sebuah berkas yang namanya dimulai dengan `test`.
- Doctest tidak akan lagi secara otomatis ditemukan. Untuk memadukan doctest ke deretan percobaan anda, ikuti recommendations in the Python documentation.

Django menggabungkan versi dirubah dari modul `doctest` dari pustaka standar Python (di `django.test._doctest`) dan menyertakan beberapa kegunaan doctest tambahan. Kegunaan ini diusangkan dan akan dipindahkan di Django 1.8; deretan doctest harus diperbaharui untuk bekerja dengan modul doctest pustaka standar (atau dirubah ke percobaan unittest-sesuai).

Jika anda berharap menunda perbaharuan ke deretan percobaan anda, anda dapat menyetel pengaturan `TEST_RUNNER` anda menjadi `django.test.simple.DjangoTestSuiteRunner` untuk sepenuhnya menyimpan kembali perilaku percobaan lama. `DjangoTestSuiteRunner` diusangkan tetapi tidak akan dipindahkan dari Django sampai versi 1.8.

### Perpindahan dari pejalan percobaan penyesuaian GeoDjango `django.contrib.gis.tests.GeoDjangoTestSuiteRunner`

Ini adalah untuk pengembang yang bekerja pada aplikasi GeoDjango itu sendiri dan terkait ke barang diatas tentang perubahan di penjalan percobaan:

Penjalan percobaan `django.contrib.gis.tests.GeoDjangoTestSuiteRunner` telah dipindahkan dan setelan pengerjaan percobaan GeoDajngo berdiri sendiri itu terapkan tidak didukung lagi. Untuk menjalankan percobaan GeoDjango cukup gunakan `DiscoverRunner` baru dan tentukan aplikasi `django.contrib.gis`.

### Menyesuaikan model user di percobaan

Perkenalan dari pejalan percobaan baru juga sedikit merubah cara dimana model percobaan diimpor. Sebagai hasilnya, percobaan apapun yang menimpa `AUTH_USER_MODEL` untuk mencoba perilaku dengan satu dari model pengguna percobaan Dajngo ( `django.contrib.auth.tests.custom_user.CustomUser` dan `django.contrib.auth.tests.custom_user.ExtensionUser`) harus sekarang secara eksplisit impor model User di modul percobaan anda:

    from django.contrib.auth.tests.custom_user import CustomUser

    @override_settings(AUTH_USER_MODEL='auth.CustomUser')
    class CustomUserFeatureTests(TestCase):
        def test_something(self):
            # Test code here ...

Impor ini memaksa model pengguna penyesuaian untuk didaftarkan. Tanpa impor ini, percobaan akan tidak dapat bertukar di model pengguna penyesuaian, dan anda akan mendapatkan sebuah pelaporan kesalahan:

    ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed

### Sadar-zona waktu pencarian `day`, `month`, dan `week_day`

Django 1.6 memperkenalkan dukungan zona waktu untuk pencarian `day`, `month`, dan `week_day` ketika `USE_TZ` adalah `True`. Pencarian ini sebelumnya dilakukan di UTC tanpa memperhatikan dari zona waktu sekarang.

Ini membutuhkan time zone definitions in the database. Jika anda sedang menggunakan SQLite, anda harus memasang pytz. Jika anda sedang menggunakan MySQL, anda harus memasang pytz dan memuat tabel zona waktu dengan mysql_tzinfo_to_sql.

### Tambahan dari `QuerySet.datetimes()`

Ketika time zone support ditambahkan di Django 1.4 telah aktif, pencarian `QuerySet.dates()` mengembalikan hasil tidak diharapkan, karena pengumpulan telah dilakukan dalam UTC. Untuk memperbaiki ini, Django 1.6 memperkenalkan API baru, `QuerySet.datetimes()`. Ini membutuhkan sedikit perubahan di kode anda.

#### `QuerySet.dates()` mengembalikan obyek `date`

`QuerySet.dates()` sekarang mengemblikan sebuah daftar dari `date`. Itu digunakan untuk mengembalikan sebuah daftar `datetime`.

`QuerySet.datetimes()` mengembalikan sebuah daftar dari `datetime`.

#### `QuerySet.dates()` tidak lagi digunakan pada `DateTimeField`

`QuerySet.dates()` memunculkan sebuah kesalahan jika itu digunakan di `DateTimeField` ketika dukungan zona waktu aktif. Gunakan `QuerySet.datetimes()` sebagai gantinya.

#### `date_hierarchy` membutuhkan penentuan zona waktu

Fitur `date_hierarchy` dari admin sekarang bergantung pada `QuerySet.datetimes()` ketika itu digunakan di `DateTimeField`.

Ini membutuhkan penentuan zona waktu di basisdata ketika `USE_TZ` adalah `True`. Learn more.

#### `date_list` dalam tampilan umum membutuhkan penentuan zona waktu

Untuk alasan sama, mengakses `date_list` di konteks dari tampilan umum berdasarkan-tanggal membutuhkan penentuan zona waktu di basisdata ketika tampilan berdasarkan pada `DateTimeField` dan `USE_TZ` adalah `True`. Learn more.

### Pencarian baru mungkin bertabrakan dengan bidang-bidang model

Django 1.6 memperkenalkan pencarian `hour`, `minute`, dan `second` di `DateTimeField`. Jika anda mempunyai bidang model dipanggil `hour`, `minute`, atau `second`, pencarian baru akan bentrok dengan nama bidang anda. Tambahkan sebuah pencarian `exact` jelas jika ini adalah sebuah masalah.

### `BooleanField` tidak lagi disetel ke False`

Ketika sebuah `BooleanField` tidak mempunyai `default` jelas, nilai awalan tersirat adalah `None`. Dalam versi sebelumnya dari Django, itu adalah `False`, tetapi itu tidak mewakili secara akurat kekurangan dari sebuah nilai.

Kode yang bergantung pada nilai awalan menjadi `False` mungkin memunculkan sebuah pengecualian ketika menyimpan instance model baru ke basisdata, karena `None` bukan sebuah nilai yang dapat diterima untuk sebuah `BooleanField`. Anda harus juga menentukan `default=False` di penentuan bidang, atau memastikan bidang disetel ke `True` atau `False` sebelum menyimpan obyek.

### Terjemahan dan komentar dalam cetakan

#### Pengeluaran dari terjemahan setelah komentar

Pengeluaran dari harfiah dapat diterjemahkan dari cetakan dengan perintah `makemessages` sekarang dengan benar mengenali gagasan i18n ketika mereka ditempatkan setelah sebuah `{#` / `#}`- ketik komentar di baris sama. Sebagai contoh:

    {# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}

#### Tempat untuk komentar penterjemah

Komentar untuk penterjemah dalam cetakan ditentukan menggunakan `{#` / `#}` harus pada akhir dari sebuah baris. Jika mereka tidak, komentar diabaikan dan `makemessages` akan membangkitkan sebuah peringatan. Sebagai contoh:

    {# Translators: This is ignored #}{% trans "Translate me" %}
    {{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
    <h1>{% trans "Welcome" %}</h1>

### Mengutip dalam `reverse()`

Ketika membalikkan URL, Django tidak memberlakukan `django.utils.http.urlquote` pada argumen-argumen sebelum menyisipkan mereka dalam pola URL. Kesalahan ini diperbaiki di Django 1.6. Jika anda bekerja disekitar kesalahan ini dengan memberlakukan kutipan URL sebelum melewatkan argumen pada `reverse()`, ini mungkin menghasilkan kutipan-ganda. Jika ini terjadi, cukup pindahkan kutipan URL dari kode anda. Ini akan juga mengganti karakter khusus dalam URL digunakan dalam `assertRedirects()` dengan versi tersandikan mereka.

### Penyimpanan dari alamat IP dalam aplikasi komentar

Aplikasi komentar sekarang menggunakan sebuah `GenericIPAddressField` untuk menyimpan alamat IP komentar, untuk mendukung komentar diajukan dari alamat IPv6. Sampai sekarang, itu menyimpan mereka di sebuah `IPAddressField`, yang hanya berarti mendukung IPv4. Ketika menyimpan sebuah komentar yang dibuat dari alamat IPv6, alamat akan secara diam dipotong di basisdata MySQL, dan memunculkan sebuah pengecualian di Oracle. Anda akan butuh merubah jenis kolom di basisdata anda untuk mengambil keuntungan dari perubahan ini.

Untuk MySQL, jalankan permintaan ini di basisdata proyek anda:

    ALTER TABLE django_comments MODIFY ip_address VARCHAR(39);

Untuk Oracle, jalankan permintaan ini:

    ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));

Jika anda tidak memberlakukan perubahan ini, perilaku tidak berubah: di MySQL, alamat IPv6 secara diam dipotong; di Oracle, sebuah pengecualian dibangkitkan. Tidak ada perubahan basisdata dibutuhkan untuk basisdata SQLite atau PostgreSQL.

### Harfiah persen di permintaan `cursor.execute`

Ketika anda sedang menjalankan permintaan SQL mentah melalui metode cursor.execute, aturan mengenai hardiah persen ganda (`%`) didalam permintaan telah kompak. Perilaku lama bergantung di backend basisdata. Sekarang, lintas semua backend, anda hanya butuh menggandakan karakter persen harfiah jika anda sedang juga menyediakan parameter pengganti. Sebagai contoh:

    # No parameters, no percent doubling
    cursor.execute("SELECT foo FROM bar WHERE baz = '30%'")

    # Parameters passed, non-placeholders have to be doubled
    cursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s", [self.id])

Pengguna `SQLite` butuh memeriksa dan memperbaharui permintaan tersebut.

### Teks bantuan dari bidang formulir model untuk bidang ManyToManyField

Membangun HTML dari bidang formulir model sesuai pada bidang model `ManyToManyField` digunakan untuk mendapatkan kalimat kode-keras:

> Tekan "Control", atau "Command" pada Mac, untuk memilih lebih dari satu.

(atau terjemahannya pada lokal aktif) dikenakan sebagai bantuan lagenda ditampilkan bersama mereka jika tak ada `model` maupun `form` atribut `help_text` telah ditentukan oleh pengguna (atau string ini telah ditambahkan ke setiap `help_text` yang telah disediakan).

Sejak ini terjadi di lapisan model, tidak ada cara mencegah teks dari muncul di kasus-kasus domana itu tidak berlaku seperti bidang formulir yang menerapkan interaksi pengguna yang anda tidak melibatkan papan kunci dan/atau sebuah tetikus.

Dimulai dengan Django 1.6, sebagai sebuah ketentuan kesesuaian-kebelakang sementara ad-hoc, logika untuk menambahkan kalimat "Hold down..." telah dipindahkan ke lapisan bidang formulir model dan dirubah untuk menambahkan hanya teks ketika widget terkait adalah `SelectMultiple` atau subkelas terpilih.

Perubahan ini dapat mempengaruhi anda di cara ketidaksesuaian kebelakang jika anda menggunakan bidang formulir model penyesuaian dan/atau widget untuk bidang model `ManyToManyField` yang UI nya bergantung pada ketentuan otomatis dari kalimat kode-kerasyang disebutkan. Penerapan bidang formulir ini butuh menyesuaikan ke skenario baru dengan menyediakan penanganan milik mereka dari atribut `help_text`.

Apliaksi yang menggunakan fasilitas model form Django bersama-sama dengan formulir siap-pakai Django fields dan widgets tidak terpengaruh tetapi butuh disadari dari apa digambarkan dalam Mung dari teks bantuan dari bidang formulir model untuk bidang-bidang ManyToManyField dibawah.

### Perulangan QuerySet

Perulangan `QuerySet` telah berubah untuk segera merubah semua baris yang diambil pada obyek `Model`. Di Django 1.5 dan lebih awal untuk mengambil baris telah dirubah ke obyek `Model` dalam 100 potongan.

Kode yang ada akan bekerja, tetapi sejumlah baris dirubah ke obyek mungkin berubah dalam kasus penggunaan tertentu. Penggunaan seperti itu termasuk sebagian berulang terhadap sebuah queryset atau penggunaan apapun yang mengakhiri melakukan `__bool__` atau `__contains__`.

Terutama kebanyakan backend basisdata melakukan pengambilan semua baris dalam satu pergi sudah di 1.5.

Itu masih memungkinkan merubah barisan diambil pada obyek `Model` lazily dengan menggunakan metode `iterator()`.

### `BoundField.label_tag` sekarang menyertakan `label_suffix` formulir

Ini adalah konsisten dengan bagaimana metode seperti `Form.as_p` dan `Form.as_ul` membangun label.

Jika anda secara manual membangun `label_tag` dalam cetakan anda:

    {{ form.my_field.label_tag }}: {{ form.my_field }}

anda akan ingin memindahkan titik dua (atau apapun pemisah lainnya anda mungkin gunakan) untuk menghindari penggandaan itu ketika meningkatkan ke Django 1.6. Cetakan berikut di Django 1.6 akan membangun secara mirip ke cetakan diatas di Django 1.5, kecuali bahwa titik koma akan muncul didalam unsur `<label>`.

    {{ form.my_field.label_tag }} {{ form.my_field }}

akan membangun sesuatu seperti:

    <label for="id_my_field">My Field:</label> <input id="id_my_field" type="text" name="my_field" />

Jika anda ingin menjaga perilaku saat ini dari membangun `label_tag` tanpa `label_suffix`, instatiate formulir `label_suffix=''`. Anda dapat juga menyesuaikan `label_suffix` di berdasarkan per-bidang menggunakan parameter `label_suffix` baru di `label_tag()`.

### Tampilan admin parameter GET `_changelist_filters`

Untuk mencapai melindungi dan meyimpan kembali daftar tampilan penyaring, tampilan admin sekarang melewatkan sekitar _changelist_filters parameter GET. Itu adalah penting bahwa akun anda untuk perubahan itu jika anda mempunyai penyesuaian cetakan admin atau jika percobaan anda bergantung pada URL sebelumnya. Jika anda ingin merubah ke perilaku aslinya anda dapat menyetel atribut `preserve_filters` menjadi `False`.

### Penyetelan kembali sandi `django.contrib.auth` menggunakan pengkodean berbasis 64 dari PK `User`

Versi lampau dari Django menggunakan penyandian base 36 dari primary key `User` di tampilan setel kembali sandi dan URL (`django.contrib.auth.views.password_reset_confirm()`). Penyandian base 36 adalah cukup jika perimary key user adalah sebuah integer, bagaimanapun, dengan perkenalan dari penyesuaian model user di Django 1.5, yang anggapan mungkin tidak lagi menjadi benar.

`django.contrib.auth.views.password_reset_confirm()` telah dirubah untuk mengambil parameter `uidb64` daripada `uidb36`. Jika anda membalik tampilan ini, sebagai contoh di penyesuaian cetakan `password_reset_email.html`, pastikan untuk memperbaharui kode anda.

Sebuah shim sementara untuk `django.contrib.auth.views.password_reset_confirm()` yang akan mengizinkan tautan setel kembali sandi dibangkitkan sebelum Django 1.6 untuk melanjutkan bekerja telah ditambahkan untuk menyediakan kesesuaian kebelakang; ini akan dipindahkan di Django 1.7. Dengan demikian, selama situs anda telah menjalankan Django 1.6 untuk lebih dari `PASSWORD_RESET_TIMEOUT_DAYS`, perubahan ini tidak akan mempunyai pengaruh. Jika tidak (sebagai contoh, jika anda meningkatkan secara langsung dari Django 1.5 ke Django 1.7), kemudian apapun tauran setel kembali sandi dibangkitkan sebelum anda meningkatkan ke Django 1.7 atau terakhir tidak akan bekerja setelah peningkatan.

Sebagai tambahan, jika anda mempunyai apapun penyesuaian URL setel kembali sandi, anda akan butuh memperbaharui mereka dengan mengganti `uidb36` dengan `uidb64` dan tanda garis yang mengikuti pola dengan sebuah garis miring. Juga tambah `_\-` ke daftar dari karakter yang mungkin cocok dengan pola `uidb64`.

Sebagai contoh:

    url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
        'django.contrib.auth.views.password_reset_confirm',
        name='password_reset_confirm'),

menjadi:

    url(r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>.+)/$',
        'django.contrib.auth.views.password_reset_confirm',
        name='password_reset_confirm'),

Anda mungkin juga ingin menambahkan shim untuk mendukung gaya lama tautan setel kembali. Menggunakan contoh diatas, anda akan merubah url yang ada dengan mengganti `django.contrib.auth.views.password_reset_confirm` dengan `django.contrib.auth.views.password_reset_confirm_uidb36` dan juga memindahkan argumen `name` jadi itu tidak bertentangan dengan url baru:

    url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
        'django.contrib.auth.views.password_reset_confirm_uidb36'),

Anda dapat memindahkan pola URL ini setelah aplikasi anda telah disebarkan dengan Django 1.6 untuk `PASSWORD_RESET_TIMEOUT_DAYS`.

### Serialisasi sesi awalan diganti ke JSON

Secara riwayat, `django.contrib.sessions` menggunakan `pickle` untuk menserialisasikan data sesi sebelum menyimpannya di backend. Jika anda sedang menggunakan signed cookie session backend dan `SECRET_KEY` dikenal oleh seorang penyerang (tidak ada kerentanan warisan di Django yang akan menyebabkan itu bocor), penyerang dapat memasukkan sebuah string ke dalam sesi yang, ketika tidak mengawetkan, menjalankan kode berubah-ubah di peladen. Teknik untuk melakukannya adalah sederhana dan mudah tersedia di internet. Meskipun penyimpanan sesi kue menandai data disimpan-kue untuk mencegah rusak, sebuah bocoran `SECRET_KEY` segera meningkatkan kerentanan ke pengerjaan kode terpencil.

Serangan ini dapat diredakan dengan menserialkan data sesi menggunakan JSON daripada `pickle`. Untuk menfasilitasi ini, Django 1.5.3 memperkenalkan pengaturan baru, `SESSION_SERIALIZER`, untuk menyesuaikan bentuk serialisasi sesi. Untuk kesesuaian kebelakang, awalan pengaturan ini menggunakan `pickle` di Django 1.5.3, tetapi kami telah merubah awalan ke JSOn di 1.6. Jika anda meningkatkan dan mengganti dari pickle ke JSON, sesi dibuat sebelum peningkatan akan hilang. Selagi serialisasi JSON tidak mendukung semua obyek Python seperti `pickle` lakukan, kami sangat menganjurkan menggunakan sesi serialisasi-JSON. Waspada dari berikut ketika memeriksa kode anda untuk menentukan jika serialisasi JSON akan bekerja untuk aplikasi anda:

- JSON membutuhkan kunci string, jadi anda kemungkinan akan berjalan kedalam masalah jika anda sedang menggunakan kunci bukan-string di `request.session`.
- Setel kadaluarsa sesi dengan melewatkan nilai `datetime` ke `set_expiry()` akan tidak bekerja seperti nilai `datetime` adalah tidak dapat serialisasi di JSON. Anda dapat menggunakan nilai integer sebagai gantinya.

Lihat dokumentasi Serialisasi sesi untuk lebih rinci.

### Perubahan Object Relational Mapper

Django 1.6 mengandung banyak perubahan pada ORM. Perubahan ini dibagi menjadi tiga kategori:

1. Perbaikan kesalahan (sebagai contoh klausa join benar untuk hubungan umum, memadukan permintaan, kenaikan join, dan perbaikan memotong join)
2. Perssiapan untuk fitur baru. Sebagai contoh, ORM sekarang secara internal siap untuk foreign key banyak kolom.
3. Pembersihan umum.

Perubahan ini dapat menghasilkan di beberapa masalah kesesuaian. Sebagai contoh, beberapa permintaan akan sekarang membangkitkan nama lain tabel berbeda. Ini dapat mempengaruhi `QuerySet.extra()`. Sebagai tambahan beberapa permintaan akan sekarang membuat hasil berbeda. Sebuah contoh adalah `exclude(condition)` dimana kondisi adalah satu rumit (mengacu banyak penyertaan didalam `Q objects`). Dalam banyak kasus permintaan yang dipengaruhi tidak membuat hasil di Django 1.5 tetapi melakukan sekarang. Sayangnya ada juga kasus-kasus yang membuat hasil berbeda, tetapi juga tidak Django 1.5 maupun 1.6 membuat hasil benar.

Akhirnya, terdapat banyak perubahan pada API internal ORM.

### Bermacam-macam

- `django.db.models.query.EmptyQuerySet` tidak dapat diinstiasikan lagi - itu adalah hanya berguna sebagai penanda kelas untuk memeriksa jika `none()` telah dipanggil: `isinstance(qs.none(), EmptyQuerySet)`

- Jika kode CSS/JavaScript anda digunakan untuk mengakses widget masukan HTML berdasarkan jenis, anda harus meninjau kembali itu seperti widget `type='text'` mungkin sekarang mengeluarkan seperti `type='email'`, `type='url'` atau `type='number'` tergantung pada jenis bidang yang sesuai mereka.

- `error_messages` bidang formulir yang mengandung placeholder harus sekarang selalu menggunakan bernama placeholder(`"ilai '%(value)' terlalu besar"` daripada `"Nilai '%s' terlalu besar"`). Lihat bidang sesuai untuk rincian tentang nama-nama dari placeholder. Perubahan di 1.6 terutama mempengaruhi `DecimalField` dan `ModelMultipleChoiceField`.

- Beberapa `error_messages` untuk `IntegerField`, `EmailField`, `IPAddressField`, `GenericIPAddressField`, dan `SlugField` telah tertindih karena mereka menggandakan pesan kesalahan yang sudah disediakan oleh pengecek diikat ke bidang.

- Karena sebuah perubahan di alur kerja pengesahan formulir, metode `TypedChoiceField` `coerce` harus selalu mengembalikan sebuah nilai hadir di atribut bidang `choices`. Batasan tersebut harus diangkat kembali di Django 1.7.

- Telah ada perubahan di cara waktu habis ditangani di backend cache. Secara eksplisit melewatkan di `timeout=None` tidak lagi mengasilkan di penggunaan awalan waktu habis. itu akan sekarang menyetel waktu habis bukan-kadaluarsa. Melewatkan 0 kedalam backend memcached tidak lagi menggunakan awalan waktu habis, dan sekarang akan menyetel-dan-berakhir-segera nilai.

- Aplikasi `django.contrib.flatpages` digunakan untuk menyetel kepala HTTP penyesuaian untuk tujuan mencari kesalahan. Kegunaan ini tidak didokumentasikan dan membuat menyembunyikan tidak efektif jadi itu telah dipindahkan, bersama dengan penerapan umumnya, sebelumnya tersedia di `django.core.xheaders`.

- `XViewMiddleware` telah dipindahkan dari `django.middleware.doc` ke `django.contrib.admindocs.middleware` karena itu adalah sebuah penerapan rincian dari admindoc, terbukti tidak menjadi digunakan kembali secara umum.

- `GenericIPAddressField` sekarang akan hanya mengizinkan nilai `blank` jika nilai `null` juga diizinkan. Membuat sebuah `GenericIPAddressField` dimana `blank` diizinkan tetapi `null` tidak akan memicu sebuah kesalahan pengesahan model karena nilai `blank` selalu disimpan sebagai `null`. Sebelumnya, menyimpan nilai `blank` di bidang yang tidak mengizinkan `null` akan menyebabkan pengecualian basisdata pada waktu berjalan.

- Jika sebuah pengecualian `NoReverseMatch` dimunculkan dari sebuah metode ketika membangun sebuah cetakan, itu adalah tidak diam. Sebagai contoh, `{{ obj.view_href }}` akan menyebabkan cetakan membangun menjadi gagal jika `view_href()` memunculkan `NoReverseMatch`. Tidak ada perubahan pada etiket `{% url %}`, itu menyebabkan membangun cetakan menjadi gagal seperti selalu ketika `NoReverseMatch` dimunculkan.

- `django.test.Client.logout()` sekarang memanggil `django.contrib.auth.logout()` yang akan mengirim sinyal `user_logged_out()`.

- Authentication views sekarang dibalik berdasarkan nama, ukan tempat mereka di `django.contrib.auth.views`. Jika anda sedang menggunakan tampilan tanpa sebuah `name`, anda harus memperbaharui `urlpatterns` anda untuk menggunakan `url()` dengan parameter `name`. Sebagai contoh:

      (r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete')

  menjadi:

      url(r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete', name='password_reset_complete')

- `RedirectView` sekarang mempunyai atribut pattern_name yang mengizinkannya memilih sasaran dengan membalikkan URL.

- Di Django 1.4 dan 1.5, string kosong tidak sengaja dianggap sandi yang sah. Ini berarti `set_password()` akan menyimpan sandi kosong sebagai sandi tidak berguna seperti `set_unusable_password()` lakukan, dan dengan demikian `check_password()` selalu dikembalikan `False` untuk sandi kosong. Ini telah diperbaiki di terbitan ini: sandi kosong adalah sekarang sah.

- Admin `changelist_view` sebelumnya menerima sebuah parameter GET `pop` untuk menandakan itu telah ditampilkan di popup. Parameter ini telah dinamai menjadi `_popup` untuk tetap konsisten dengan sisa dari tampilan admin. Anda harus memperbaharui cetakan penyesuaian anda jika mereka menggunakan nama parameter sebelumnya.

- `validate_email()` sekarang menerima alamat surel dengan `localhost` sebagai ranah.

- Pilihan baru `makemessages --keep-pot` mencegah menghapus berkas .pot sementara dibangkitkan sebelum pembuatan berkas .po.

- `django.core.servers.basehttp.WSGIServerException` yang tidak didokumentasikan telah dipindahkan. Gunakan `socket.error` disediakan oleh pustaka standar sebagai gantinya. Perubahan ini juga diterbitkan di Django 1.5.5.

- Tanda tangan dari `django.views.generic.base.RedirectView.get_redirect_url()` telah berubah dan sekarang menerima argumen penempatan juga (`*args, **kwargs`). Apapun kelompok ditangkap tidak bernama akan sekarang diloloskan ke `get_redirect_url()` yang mungkin menghasilkan sebuah `TypeError` jika anda tidak memperbaharui tanda tangan dari metode penyesuaian anda.

## Fitur diusangkan di 1.6

### Transaksi pengelolaan API

Pengelolaan transaksi sepenuhnya dirombak di Django 1.6, dan API saat ini diusangkan:

- `django.middleware.transaction.TransactionMiddleware`
- `django.db.transaction.autocommit`
- `django.db.transaction.commit_on_success`
- `django.db.transaction.commit_manually`
- Pengaturan `TRANSACTIONS_MANAGED`

### `django.contrib.comments`

Kerangka kerja komentar Django telah diusangkan dan tidak lagi didukung. Itu akan tersedia di Django 1.6 dan 1.7, dan dipindahkan di Django 1.8. Kebanyakan pengguna akan menjadi lebih baik dilayani dengan pemecahan penyesuaian, atau produk disimpan seperti Disqus.

Kode dahulu dikenal sebagai `django.contrib.comments` still available in an external repository.

### Mendukung untuk PostgreSQL versi lebih lama dari 8.4

Akhir dari masa dukungan hulu telah tercapai di Desember 2011 untuk PostgreSQL 8.2 dan di February 2013 untuk 8.3. Sebagai konsekuensinya, Django 1.6 menyetel 8.4 sebagai versi minimal PostgreSQL itu secara resmi dukung.

Anda sangat didorong menggunakan versi paling terakhir dari PostgreSQL tersedia, karena dari perbaikan peningkatan dan untuk mengambil keuntungan dari replikasi aliran alamiah tersedia di PostgreSQL 9.x.

### Perubahan ke `cycle` dan `firstof`

Sistem cetakan umumnya meloloskan semua variabel untuk menghindari serangan XSS. Bagaimanaoun, karena sebuah kecelakaan sejarah, etiket `cycle` dan `firstof` membangun argumen mereka dengan adanya.

Django 1.6 mulai mengolah untuk memperbaiki ketidak konsistenannya. Pustaka cetakan `future` menyediakan penerapan lain dari `cycle` dan `firstof` yang meloloskan otomatis masukan mereka. Jika anda sedang menggunakan etiket ini, anda dianjurkan untuk menyertakan baris berikut pada atas dari cetakan anda untuk mengadakan perilaku baru:

    {% load cycle from future %}

atau:

    {% load firstof from future %}

Etiket menerapkan perilaku lama telah diusangkan, dan di Django 1.8, perilaku lama akan diganti dengan perilaku baru. Untuk memastikan kesesuaian dengan versi masa depan dari Django, cetakan yang ada harus dirubah untuk menggunakan versi `future`.

Jika diperlukan, anda dapat sementara meniadakan pelolosan-otomatis dengan `mark_safe()` atau `{% autoescape off %}`.

### Pengaturan `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`

`CacheMiddleware` dan `UpdateCacheMiddleware` digunakan untuk menyediakan cara untuk menyimpan sementara permintaan hanya jika mereka tidak dibuat oleh pengguna masuk. Mekanisme ini telah sebagian besar tidak efektif karena middleware dengan benar mengambil kedalam akun kepala HTTP `Vary: Cookie`, dan kepala ini sedang dikirim di berbagai kesempatan, seperti:

- mengkases sesi, atau
- menggunakan perlindungan CSRF, yang menghidupkan secara awal, atau
- menggunakan pustaka sisi klien yang menyetel kue, seperti Google Analytics.

Ini membuat tembolok secara efektif bekerja pada berdasarkan per-sesi tanpa memperhatikan pengaturan `CACHE_MIDDLEWARE_ANONYMOUS_ONLY`.

### Pengaturan `SEND_BROKEN_LINK_EMAILS`

`CommonMiddleware` digunakan untuk menyediakan pelaporan dasar dari tautan rusak oleh surel ketika `SEND_BROKEN_LINK_EMAILS` disetel menjadi `True`.

Karena masalah pengurutan yang keras kepala diantara `CommonMiddleware` dan `LocaleMiddleware`, fitur ini telah dipisah menjadi middleware: `BrokenLinkEmailsMiddleware`.

Jika anda bergantung pada fitur ini, anda harus menambahkan `'django.middleware.common.BrokenLinkEmailsMiddleware'` ke pengaturan `MIDDLEWARE_CLASSES` anda dan memindahkan `SEND_BROKEN_LINK_EMAILS` dari pengaturan anda.

### Metode `_has_changed` di widgets

Jika anda menentukan widget formulir anda sendiri dan menentukan metode `_has_changed` pada sebuah widget anda harus sekarang menentukan metode ini di bidang formulir itu sendiri.

### Model `module_name` atribut _meta

`Model._meta.module_name` telah dinamai kembali ke `model_name`. Meskipun menjadi sebuah API pribadi, itu akan melalui jalur pengusangan biasa.

### Model `get_(add|change|delete)_permission` _meta methods

Metode `Model._meta.get_(add|change|delete)_permission` telah diusangkan. Bahkan jika mereka adalah bukan bagian dari API umum mereka akan juga pergi melalui jalur pengusangan biasa. Anda dapat mengganti mereka dengan `django.contrib.auth.get_permission_codename('action', Model._meta)` dimana `'action'` adalah `'add'`, `'change'`, atau `'delete'`.

### `get_query_set` dan metode mirip dinamai kembali menjadi `get_queryset`

Metode yang mengembalikan sebuah `QuerySet` seperti `Manager.get_query_set` atau `ModelAdmin.queryset` telah dinamai menjadi `get_queryset`.

Jika anda sedang menulis pustaka yang menerapkan, sebagai contoh, sebuah metode `Manager.get_query_set`, dan anda butuh mendukung versi Django lama, anda harus menamai kembali cara dan kondisional tambah sebuah nama lain dengan nama lama:

    class CustomManager(models.Manager):
        def get_queryset(self):
            pass # ...

        if django.VERSION < (1, 6):
            get_query_set = get_queryset

        # For Django >= 1.6, models.Manager provides a get_query_set fallback
        # that emits a warning when used.

Jika anda sedang menulis pustaka yang butuh memanggil metode `get_queryset` dan harus mendukung versi Django lama, anda harus menulis:

    get_queryset = (some_manager.get_query_set
                    if hasattr(some_manager, 'get_query_set')
                    else some_manager.get_queryset)
    return get_queryset() # etc

Di kasus umum dari penyesuaian pengelola yang kedua menerapkan metode `get_queryset` milik nya dan memanggil metode itu, dan butuh bekerja dengan versi Django terlama, dan pustaka yang belum diperbaharui, itu adalah berguna untuk menentukan sebuah metode `get_queryset_compat` seperti dibawah dan menggunakannya secara internal ke pengelola anda:

    class YourCustomManager(models.Manager):
        def get_queryset(self):
            return YourCustomQuerySet() # for example

        if django.VERSION < (1, 6):
            get_query_set = get_queryset

        def active(self): # for example
            return self.get_queryset_compat().filter(active=True)

        def get_queryset_compat(self):
            get_queryset = (self.get_query_set
                            if hasattr(self, 'get_query_set')
                            else self.get_queryset)
            return get_queryset()

Ini membantu mengecilkan perubahan yang dibutuhkan, tetapi juga bekerja dengan benar di kasus dari subkelas (seperti `RelatedManagers` dari Django 1.5) yang mungkin menimpa salah satu `get_query_set` atau `get_queryset`.

### tampilan `jalan pintas` dan URLconf

Tampilan `jalan pintas` dipindahkan dari `django.views.defaults` ke `django.contrib.contenttypes.views` segera setelah terbitan 1.0, tetapi tempat lama tidak pernah diusangkan. Kekeliruan ini diperbaiki di Django 1.6 dan anda seharusnya sekarang gunakan tempat baru.

URLconf `django.conf.urls.shortcut` juga telah diusangkan. Jika anda sedang menyertakan itu di sebuah URLconf, cukup ganti:

    (r'^prefix/', include('django.conf.urls.shortcut')),

dengan:

    (r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$', 'django.contrib.contenttypes.views.shortcut'),

### `ModelForm` tanpa `fields` atau `exclude`

Sebelumnya, jika anda ingin sebuah `ModelForm` untuk memakai semua bidang pada model, anda dapat cukup menghilangkan atribut `Meta.fields`, dan semua bidang akan digunakan.

Ini dapat membawa pada masalah keamanan dimana bidang ditambahkan ke model dan, tidak sengaja, secara otomatis menjadi dapat disunting oleh pengguna akhir. Di beberapa kasus, khususnya dengan bidang boolean, itu memungkinkan untuk masalah ini secara lengkap nampak. Ini adalah sebuah formulir Mass assignment vulnerability.

Untuk alasan ini, perilaku ini diusangkan, dan menggunakan pilihan `Meta.exclude` sangat kecil. Meskipun semua bidang yang dimaksud untuk penyertaan di formulir harus didaftarkan secara eksplisit di atribut `field`.

Jika perhatian keamanan sangat tidak berlaku di kasus anda, ada sebuah jalan pintas untuk secara eksplisit mengindikasikan bahwa semua bidang harus digunakan - gunakan nilai khusus ``"__all__"` untuk atribut bidang:

    class MyModelForm(ModelForm):
        class Meta:
            fields = "__all__"
            model = MyModel

Jika anda mempunyai penyesuaian `ModelForms` yang hanya butuh digunakan di admin, ada pilihan lain. Admin mempunyai metode sendiri untuk menentukan bidang (`fieldsets` dll), dan juga menambahkan daftar dari bidang ke `ModelForm` adalah berlebihan. Sebagai gantinya, cukup hilangkan kelas sebelah dalam `Meta` dari `ModelForm`, atau hilangkan atribut `Meta.model`. Sejak subkelas `ModelAdmin` mengetahui model mana ini untuk, itu dapat menambahkan atribut yang dibutuhkan untuk memperoleh fungsi `ModelForm`. Perilaku ini juga bekerja untuk versi Django lebih awal.

### `UpdateView` dan `CreateView` tanpa bidang eksplisit

Tampilan umum `CreateView` dan `UpdateView`, dan apapun diperoleh dari `ModelFormMixin`, adalah rentan pada masalah keamanan digambarkan di bagian diatas, karena mereka dapat secara otomatis membuat sebuah `ModelForm` yang menggunakan semua bidang untuk sebuah model.

Untuk alasan ini, jika anda menggunakan tampilan ini untuk menyunting model, adna harus juga memasok atribut `field` (baru di Django 1.6), yaitu sebuah daftar bidang model dan bekerja di cara sama seperti atribut `ModelForm` `Meta.fields`. Cara lain, anda dapat menyetel atribut `form_class` ke `ModelForm` yang secara jelas menentukan bidang-bidang akan digunakan. Menentukan sebuah subkelas `UpdateView` or `CreateView` untuk digunakan dengan sebuah model tetapi tanpa sebuah daftar jelas dari bidang-bidang adalah diusangkan.

### Mung dari teks bantuan dari bidang formulir model untuk bidang-bidang `ManyToManyField`

Semua penanganan khusus dari atribut `help_text` dari bidang model `ManyToManyField` dilakukan oleh model standar atau bidang formulir model seperti digambarkan di Teks bantuan dari bidang formulir model untuk bidang ManyToManyField diatas adalah diusangkan dan akan dipindahkan di Django 1.8.

Teks bantuan dari bidang-bidang ini akan butuh ditangani antara oleh aplikasi, penyesuaian bidang formulir atau widget, cukup seperti terjadi dengan sisa dari jenis bidang model.