---
title: "Django 1.8 versionsinformation"
version: 6.1
locale: sv
source: https://docs.djangoproject.com/sv/6.1/releases/1.8/
canonical: https://djangodocs.dev/sv/6.1/releases/1.8/
---
# Django 1.8 versionsinformation

*1 april 2015*

Välkommen till Django 1.8!

Dessa versionsinformation täcker [nya funktioner](#whats-new-1-8), samt några [bakåtkompatibla ändringar](#backwards-incompatible-1-8) som du bör vara medveten om när du uppgraderar från Django 1.7 eller äldre versioner. Vi har också [börjat utfasningsprocessen för vissa funktioner](#deprecated-features-1-8), och vissa funktioner har nått slutet av sin utfasningsprocess och [har tagits bort](#removed-features-1-8).

Se guiden [Så här uppgraderar du Django till en nyare version](/sv/6.1/howto/upgrade-version/) om du ska uppdatera ett befintligt projekt.

Django 1.8 har utsetts till Djangos andra [long-term support release](/sv/6.1/internals/release-process/#term-Long-term-support-release). Den kommer att få säkerhetsuppdateringar i minst tre år efter lanseringen. Support för den tidigare LTS, Django 1.4, kommer att upphöra 6 månader från utgivningsdatumet för Django 1.8.

## Kompatibilitet med Python

Django 1.8 kräver Python 2.7, 3.2, 3.3, 3.4 eller 3.5. Vi **rekommenderar** starkt och stöder endast officiellt den senaste versionen av varje serie.

Django 1.8 är den första utgåvan som stöder Python 3.5.

På grund av att uppströmsstödet för Python 3.2 upphörde i februari 2016 kommer vi inte att testa Django 1.8.x på Python 3.2 efter slutet av 2016.

## Vad är nytt i Django 1.8

### aPI för `Model._meta`

Django har nu ett formaliserat API för [Model.\_meta](/sv/6.1/ref/models/meta/), vilket ger ett officiellt stöd för att [hämta fält](/sv/6.1/ref/models/meta/#model-meta-field-api) och filtrera fält baserat på deras [attribut](/sv/6.1/ref/models/fields/#model-field-attributes).

Objektet `Model._meta` har varit en del av Django sedan dagarna före 0.96 ”Magic Removal” - det var bara inte ett officiellt, stabilt API. Som ett erkännande av detta har vi strävat efter att upprätthålla bakåtkompatibilitet med den gamla API-slutpunkten där det är möjligt. API-slutpunkter som inte är en del av det nya officiella API:et har dock föråldrats och kommer så småningom att tas bort.

### Flera mallmotorer

Django 1.8 definierar ett stabilt API för integrering av mallbackends. Det innehåller inbyggt stöd för Djangos mallspråk och för [`Jinja2`](/sv/6.1/topics/templates/#django.template.backends.jinja2.Jinja2). Det stöder rendering av mallar med flera motorer inom samma projekt. Läs mer om de nya funktionerna i [topic guide](/sv/6.1/topics/templates/) och kontrollera uppgraderingsinstruktionerna i äldre versioner av dokumentationen.

### Förbättringar av säkerheten

Flera funktioner i tredjepartsbiblioteket [django-secure](https://pypi.org/project/django-secure/) har integrerats i Django. [`django.middleware.security.SecurityMiddleware`](/sv/6.1/ref/middleware/#django.middleware.security.SecurityMiddleware) ger flera säkerhetsförbättringar i request/response-cykeln. Det nya [`check --deploy`](/sv/6.1/ref/django-admin/#cmdoption-check-deploy)-alternativet låter dig kontrollera din produktionsinställningsfil för sätt att öka säkerheten på din webbplats.

### Ny PostgreSQL-specifik funktionalitet

Django har nu en modul med tillägg för PostgreSQL-specifika funktioner, såsom [`ArrayField`](/sv/6.1/ref/contrib/postgres/fields/#django.contrib.postgres.fields.ArrayField), [`HStoreField`](/sv/6.1/ref/contrib/postgres/fields/#django.contrib.postgres.fields.HStoreField), [Område Fält](/sv/6.1/ref/contrib/postgres/fields/#range-fields) och [`unaccent`](/sv/6.1/ref/contrib/postgres/lookups/#std-fieldlookup-unaccent) lookup. En fullständig uppdelning av funktionerna finns [i dokumentationen](/sv/6.1/ref/contrib/postgres/).

### Nya datatyper

- Django har nu en [`UUIDField`](/sv/6.1/ref/models/fields/#django.db.models.UUIDField) för lagring av universellt unika identifierare. Den lagras som den ursprungliga datatypen `uuid` på PostgreSQL och som ett teckenfält med fast längd på andra backends. Det finns en motsvarande [`formfält`](/sv/6.1/ref/forms/fields/#django.forms.UUIDField).
- Django har nu en [`DurationField`](/sv/6.1/ref/models/fields/#django.db.models.DurationField) för lagring av tidsperioder - modellerad i Python av [`timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta). Den lagras i den ursprungliga datatypen `intervall` på PostgreSQL, som en ```INTERVAL DAY(9) TO SECOND(6) `` på Oracle och som en ``bigint``` av mikrosekunder på andra backends. Datum- och tidsrelaterad aritmetik har också förbättrats på alla backends. Det finns en motsvarande [`formulärsfält`](/sv/6.1/ref/forms/fields/#django.forms.DurationField).

### Frågeuttryck, villkorsuttryck och databasfunktioner

[Query Expressions](/sv/6.1/ref/models/expressions/) gör att du kan skapa, anpassa och komponera komplexa SQL-uttryck. Detta har gjort det möjligt för Annotate att acceptera andra uttryck än aggregat. Aggregat kan nu referera till flera fält samt utföra aritmetik, liknande `F()`-objekt. [`order_by()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.order_by) har också fått möjlighet att acceptera uttryck.

[Conditional Expressions](/sv/6.1/ref/models/conditional-expressions/) gör att du kan använda [`if`](https://docs.python.org/3/reference/compound_stmts.html#if) … [`elif`](https://docs.python.org/3/reference/compound_stmts.html#elif) … [`else`](https://docs.python.org/3/reference/compound_stmts.html#else) logik inom frågor.

En samling av [databasfunktioner](/sv/6.1/ref/models/database-functions/) ingår också med funktionalitet som [`Coalesce`](/sv/6.1/ref/models/database-functions/#django.db.models.functions.Coalesce), [`Concat`](/sv/6.1/ref/models/database-functions/#django.db.models.functions.Concat) och [`Substr`](/sv/6.1/ref/models/database-functions/#django.db.models.functions.Substr).

### uppsättning av `TestCase`-data

[`TestCase`](/sv/6.1/topics/testing/tools/#django.test.TestCase) has been refactored to allow for data
initialization at the class level using transactions and savepoints. Database
backends which do not support transactions, like MySQL with the MyISAM storage
engine, will still be able to run these tests but won’t benefit from the
improvements. Tests are now run within two nested
[`atomic()`](/sv/6.1/topics/db/transactions/#django.db.transaction.atomic) blocks: one for the whole class and one
for each test.

- Klassmetoden [`TestCase.setUpTestData()`](/sv/6.1/topics/testing/tools/#django.test.TestCase.setUpTestData) ger möjlighet att ställa in testdata på klassnivå. Att använda denna teknik kan påskynda testerna jämfört med att använda `setUp()`.
- Laddning av fixturer inom `TestCase` utförs nu en gång för hela `TestCase`.

### Mindre funktioner

#### [`django.contrib.admin`](/sv/6.1/ref/contrib/admin/#module-django.contrib.admin)

- [`ModelAdmin`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin) har nu en [`has_module_permission()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_module_permission)-metod för att tillåta begränsning av åtkomst till modulen på adminindexsidan.
- [`InlineModelAdmin`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin) har nu ett attribut [`show_change_link`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.InlineModelAdmin.show_change_link) som stöder visning av en länk till ett inline-objekts ändringsformulär.
- Använd det nya `django.contrib.admin.RelatedOnlyFieldListFilter` i [`ModelAdmin.list_filter`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter) för att begränsa `list_filter`-valen till främmande objekt som är kopplade till dem från `ModelAdmin`.
- Metoden [`ModelAdmin.delete_view()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.delete_view) visar en sammanfattning av objekt som ska raderas på sidan för bekräftelse av radering.
- Det jQuery-bibliotek som är inbäddat i admin har uppgraderats till version 1.11.2.
- Du kan nu ange [`AdminSite.site_url`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.site_url) för att visa en länk till frontend-webbplatsen.
- Du kan nu ange [`ModelAdmin.show_full_result_count`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.show_full_result_count) för att styra om hela antalet objekt ska visas på en filtrerad adminsida eller inte.
- Metoden `AdminSite.password_change()` har nu en parameter för `extra_context`.
- Du kan nu styra vem som får logga in på adminsidan genom att åsidosätta endast [`AdminSite.has_permission()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.has_permission) och [`AdminSite.login_form`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.login_form). Mallen `base.html` har ett nytt block `usertools` som innehåller det användarspecifika sidhuvudet. En ny kontextvariabel `has_permission`, som får sitt värde från [`has_permission()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.has_permission), anger om användaren kan komma åt webbplatsen.
- I rullgardinsmenyer för främmande nycklar finns nu knappar för att ändra eller ta bort relaterade objekt med hjälp av en popup.

#### [`django.contrib.admindocs`](/sv/6.1/ref/contrib/admin/admindocs/#module-django.contrib.admindocs)

- reStructuredText tolkas nu i modelldokumentationer.

#### [`django.contrib.auth`](/sv/6.1/topics/auth/#module-django.contrib.auth)

- Auktoriseringsbackends kan nu höja [`PermissionDenied`](/sv/6.1/ref/exceptions/#django.core.exceptions.PermissionDenied) i [`has_perm()`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_perm) och [`has_module_perms()`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User.has_module_perms) för att kortsluta behörighetskontrollen.
- [`PasswordResetForm`](/sv/6.1/topics/auth/default/#django.contrib.auth.forms.PasswordResetForm) har nu en metod [`send_mail()`](/sv/6.1/topics/auth/default/#django.contrib.auth.forms.PasswordResetForm.send_mail) som kan åsidosättas för att anpassa det e-postmeddelande som ska skickas.
- Den `max_length` av [`Permission.name`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.Permission.name) har ökats från 50 till 255 tecken. Kör databasmigreringen.
- [`USERNAME_FIELD`](/sv/6.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD) och [`REQUIRED_FIELDS`](/sv/6.1/topics/auth/customizing/#django.contrib.auth.models.CustomUser.REQUIRED_FIELDS) stöder nu [`ForeignKey`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey).
- Standardantalet iterationer för PBKDF2-lösenordshasher har ökats med 33%. Denna bakåtkompatibla ändring kommer inte att påverka användare som har underklassat `django.contrib.auth.hashers.PBKDF2PasswordHasher` för att ändra standardvärdet.

#### [`django.contrib.gis`](/sv/6.1/ref/contrib/gis/#module-django.contrib.gis)

- En ny [GeoJSON serializer](/sv/6.1/ref/contrib/gis/serializers/) är nu tillgänglig.
- Det är nu tillåtet att inkludera en underfråga som ett geografiskt uppslagsargument, t.ex. `City.objects.filter(point__within=Country.objects.filter(continent='Africa').values('mpoly'))`.
- SpatiaLite backend stöder nu aggregaten `Collect` och `Extent` när databasversionen är 3.0 eller senare.
- Initialiseringskommandona PostGIS 2 `CREATE EXTENSION postgis` och SpatiaLite `SELECT InitSpatialMetaData` körs nu automatiskt av [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate).
- GDAL-gränssnittet stöder nu hämtning av egenskaper för [raster (bild) datafil](/sv/6.1/ref/contrib/gis/gdal/#raster-data-source-objects).
- Kompatibilitetsshims för `SpatialRefSys` och `GeometryColumns` som ändrades i Django 1.2 har tagits bort.
- Alla GDAL-relaterade undantag tas nu upp med `GDALException`. Den tidigare `OGRException` har behållits för bakåtkompatibilitet men bör inte användas längre.

#### [`django.contrib.sessions`](/sv/6.1/topics/http/sessions/#module-django.contrib.sessions)

- Session cookie is now deleted after
  [`flush()`](/sv/6.1/topics/http/sessions/#django.contrib.sessions.backends.base.SessionBase.flush) is called.

#### [`django.contrib.sitemaps`](/sv/6.1/ref/contrib/sitemaps/#module-django.contrib.sitemaps)

- Med det nya attributet [`Sitemap.i18n`](/sv/6.1/ref/contrib/sitemaps/#django.contrib.sitemaps.Sitemap.i18n) kan du generera en webbplatskarta baserat på inställningen [`LANGUAGES`](/sv/6.1/ref/settings/#std-setting-LANGUAGES).

#### [`django.contrib.sites`](/sv/6.1/ref/contrib/sites/#module-django.contrib.sites)

- [`get_current_site()`](/sv/6.1/ref/contrib/sites/#django.contrib.sites.shortcuts.get_current_site) kommer nu att söka upp den aktuella webbplatsen baserat på [`request.get_host()`](/sv/6.1/ref/request-response/#django.http.HttpRequest.get_host) om inställningen [`SITE_ID`](/sv/6.1/ref/settings/#std-setting-SITE_ID) inte är definierad.
- Standardklassen [`Site`](/sv/6.1/ref/contrib/sites/#django.contrib.sites.models.Site) som skapas när man kör `migrate` respekterar nu inställningen [`SITE_ID`](/sv/6.1/ref/settings/#std-setting-SITE_ID) (istället för att alltid använda `pk=1`).

#### Cache

- Metoden `incr()` för backend `django.core.cache.backends.locmem.LocMemCache` är nu trådsäker.

#### Kryptografi

- The `max_age` parameter of the
  [`django.core.signing.TimestampSigner.unsign()`](/sv/6.1/topics/signing/#django.core.signing.TimestampSigner.unsign) method now also accepts a
  [`datetime.timedelta`](https://docs.python.org/3/library/datetime.html#datetime.timedelta) object.

#### Databas backends

- MySQL-backend tar inte längre bort mikrosekunder från `datetime`-värden eftersom MySQL 5.6.4 och senare stöder bråkdelar av sekunder beroende på deklarationen av datetime-fältet (när `DATETIME` innehåller bråkdelar med precision större än 0). Nya datetime-databaskolumner som skapats med Django 1.8 och MySQL 5.6.4 och senare kommer att stödja mikrosekunder. Se [MySQL database notes](/sv/6.1/ref/databases/#mysql-fractional-seconds) för mer information.
- MySQL-backend skapar inte längre explicita index för utländska nycklar när InnoDB-lagringsmotorn används, eftersom MySQL redan skapar dem automatiskt.
- Oracles backend definierar inte längre funktionen `connection_persists_old_columns` som `True`. Istället kommer Oracle nu att inkludera en cache-busting-klausul när beskrivningen av en tabell hämtas.

#### E-postadress

- [E-postbackends](/sv/6.1/topics/email/#topic-email-backends) stöder nu protokollet context manager för att öppna och stänga anslutningar.
- SMTP-backend för e-post stöder nu autentisering med `keyfile` och `certfile` med inställningarna [`EMAIL_SSL_CERTFILE`](/sv/6.1/ref/settings/#std-setting-EMAIL_SSL_CERTFILE) och [`EMAIL_SSL_KEYFILE`](/sv/6.1/ref/settings/#std-setting-EMAIL_SSL_KEYFILE).
- The [SMTP EmailBackend](/sv/6.1/topics/email/#topic-email-smtp-backend) now supports
  setting the `timeout` parameter with the [`EMAIL_TIMEOUT`](/sv/6.1/ref/settings/#std-setting-EMAIL_TIMEOUT) setting.
- [`EmailMessage`](/sv/6.1/topics/email/#django.core.mail.EmailMessage) och `EmailMultiAlternatives` har nu stöd för parametern `reply_to`.

#### Fil delning

- [`Storage.get_available_name()`](/sv/6.1/ref/files/storage/#django.core.files.storage.Storage.get_available_name) och [`Storage.save()`](/sv/6.1/ref/files/storage/#django.core.files.storage.Storage.save) tar nu ett `max_length`-argument för att implementera begränsningar för maximal filnamnslängd på lagringsnivå. Filnamn som överskrider detta argument kommer att avkortas. Detta förhindrar ett databasfel när man lägger till ett unikt suffix till ett långt filnamn som redan finns på lagringsenheten. Se [deprecation note](#storage-max-length-update) om hur du lägger till detta argument i dina anpassade lagringsklasser.

#### Formulär

- Formulärwidgets återger nu attribut med värdet `True` eller `False` som booleska HTML5-attribut.
- The new [`has_error()`](/sv/6.1/ref/forms/api/#django.forms.Form.has_error) method allows checking
  if a specific error has happened.
- Om [`required_css_class`](/sv/6.1/ref/forms/api/#django.forms.Form.required_css_class) definieras på ett formulär, kommer taggarna `<label>` för obligatoriska fält att ha denna klass i sina attribut.
- Renderingen av icke-fältfel i oordnade listor (`<ul>`) inkluderar nu `nonfield` i sin lista över klasser för att skilja dem från fältspecifika fel.
- [`Field`](/sv/6.1/ref/forms/fields/#django.forms.Field) accepterar nu ett [`label_suffix`](/sv/6.1/ref/forms/fields/#django.forms.Field.label_suffix)-argument, som kommer att åsidosätta formulärets [`label_suffix`](/sv/6.1/ref/forms/api/#django.forms.Form.label_suffix). Detta gör det möjligt att anpassa suffixet per fält - tidigare var det inte möjligt att åsidosätta ett formulärs [`label_suffix`](/sv/6.1/ref/forms/api/#django.forms.Form.label_suffix) när man använde genvägar som `{{ form.as_p }}` i mallar.
- [`SelectDateWidget`](/sv/6.1/ref/forms/widgets/#django.forms.SelectDateWidget) accepterar nu ett [`empty_label`](/sv/6.1/ref/forms/widgets/#django.forms.SelectDateWidget.empty_label)-argument, som kommer att åsidosätta etiketten för topplistans val när [`DateField`](/sv/6.1/ref/forms/fields/#django.forms.DateField) inte krävs.
- När en [`ImageField`](/sv/6.1/ref/forms/fields/#django.forms.ImageField) har rensats och validerats kommer objektet `UploadedFile` att ha ett ytterligare `image`-attribut som innehåller Pillow `Image`-instansen som används för att kontrollera om filen var en giltig bild. Det kommer också att uppdatera `UploadedFile.content_type` med bildens innehållstyp som bestäms av Pillow.
- Du kan nu skicka en callable som returnerar en iterabel av val när du instansierar en [`ChoiceField`](/sv/6.1/ref/forms/fields/#django.forms.ChoiceField).

#### Generiska åsikter

- Generic views that use
  [`MultipleObjectMixin`](/sv/6.1/ref/class-based-views/mixins-multiple-object/#django.views.generic.list.MultipleObjectMixin) may now specify the
  ordering applied to the
  [`queryset`](/sv/6.1/ref/class-based-views/mixins-multiple-object/#django.views.generic.list.MultipleObjectMixin.queryset) by setting
  [`ordering`](/sv/6.1/ref/class-based-views/mixins-multiple-object/#django.views.generic.list.MultipleObjectMixin.ordering) or overriding
  [`get_ordering()`](/sv/6.1/ref/class-based-views/mixins-multiple-object/#django.views.generic.list.MultipleObjectMixin.get_ordering).
- The new [`SingleObjectMixin.query_pk_and_slug`](/sv/6.1/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.query_pk_and_slug)
  attribute allows changing the behavior of
  [`get_object()`](/sv/6.1/ref/class-based-views/mixins-single-object/#django.views.generic.detail.SingleObjectMixin.get_object)
  so that it’ll perform its lookup using both the primary key and the slug.
- The [`get_form()`](/sv/6.1/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_form) method doesn’t
  require a `form_class` to be provided anymore. If not provided
  `form_class` defaults to
  [`get_form_class()`](/sv/6.1/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_form_class).
- Placeholders in [`ModelFormMixin.success_url`](/sv/6.1/ref/class-based-views/mixins-editing/#django.views.generic.edit.ModelFormMixin.success_url) now support the
  Python [`str.format()`](https://docs.python.org/3/library/stdtypes.html#str.format) syntax. The legacy `%(<foo>)s` syntax is still
  supported but will be removed in Django 1.10.

#### Internationalisering

- [`FORMAT_MODULE_PATH`](/sv/6.1/ref/settings/#std-setting-FORMAT_MODULE_PATH) kan nu vara en lista med strängar som representerar sökvägar till moduler. Detta gör det möjligt att importera flera formatmoduler från olika återanvändbara appar. Det gör det också möjligt att åsidosätta dessa anpassade format i ditt huvudsakliga Django-projekt.

#### Loggning

- Klassen [`django.utils.log.AdminEmailHandler`](/sv/6.1/ref/logging/#django.utils.log.AdminEmailHandler) har nu en [`send_mail()`](/sv/6.1/ref/logging/#django.utils.log.AdminEmailHandler.send_mail)-metod för att göra den mer underklassvänlig.

#### Kommandon för hantering

- Databasanslutningar stängs nu alltid efter att ett hanteringskommando som anropas från kommandoraden har slutfört sitt arbete.
- Kommandon från alternativa paketformat som eggs upptäcks nu också.
- Det nya alternativet [`dumpdata --output`](/sv/6.1/ref/django-admin/#cmdoption-dumpdata-output) gör det möjligt att ange en fil till vilken de serialiserade data skrivs.
- De nya alternativen [`makemessages --exclude`](/sv/6.1/ref/django-admin/#cmdoption-makemessages-exclude) och [`compilemessages --exclude`](/sv/6.1/ref/django-admin/#cmdoption-compilemessages-exclude) gör det möjligt att utesluta specifika lokaliteter från bearbetning.
- [`compilemessages`](/sv/6.1/ref/django-admin/#django-admin-compilemessages) har nu ett `--use-fuzzy` eller `-f` alternativ som inkluderar fuzzy-översättningar i kompilerade filer.
- Alternativet [`loaddata --ignorenonexistent`](/sv/6.1/ref/django-admin/#cmdoption-loaddata-ignorenonexistent) ignorerar nu data för modeller som inte längre finns.
- [`runserver`](/sv/6.1/ref/django-admin/#django-admin-runserver) använder nu daemon-trådar för snabbare laddning.
- [`inspectdb`](/sv/6.1/ref/django-admin/#django-admin-inspectdb) ger nu ut `Meta.unique_together`. Det går också att introspektera [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField) för MySQL- och PostgreSQL-databaser.
- När man anropar hanteringskommandon med alternativ med [`call_command()`](/sv/6.1/ref/django-admin/#django.core.management.call_command) kan alternativnamnet matcha kommandoradens alternativnamn (utan de inledande bindestrecken) eller det slutliga variabelnamnet för alternativets destination, men i båda fallen är det resulterande alternativet som tas emot av kommandot nu alltid namnet `dest` som anges i kommandots alternativdefinition (så länge kommandot använder modulen [`argparse`](https://docs.python.org/3/library/argparse.html#module-argparse)).
- Kommandot [`dbshell`](/sv/6.1/ref/django-admin/#django-admin-dbshell) stöder nu MySQL:s valfria inställning för SSL-certifikatutfärdare (`--ssl-ca`).
- Det nya [`makemigrations --name`](/sv/6.1/ref/django-admin/#cmdoption-makemigrations-name) gör det möjligt att ge migreringarna ett eget namn i stället för ett genererat namn.
- Kommandot [`loaddata`](/sv/6.1/ref/django-admin/#django-admin-loaddata) förhindrar nu upprepad laddning av fixturer. Om [`FIXTURE_DIRS`](/sv/6.1/ref/settings/#std-setting-FIXTURE_DIRS) innehåller dubbletter eller en standardkatalog för fixturer (`app_name/fixtures`), kommer ett undantag att göras.
- Det nya alternativet `makemigrations --exit` gör det möjligt att avsluta med en felkod om inga migreringar skapas.
- Med det nya kommandot [`showmigrations`](/sv/6.1/ref/django-admin/#django-admin-showmigrations) kan du lista alla migreringar och deras beroenden i ett projekt.

#### Middleware

- Med attributet [`CommonMiddleware.response_redirect_class`](/sv/6.1/ref/middleware/#django.middleware.common.CommonMiddleware.response_redirect_class) kan du anpassa de omdirigeringar som utfärdas av mellanvaran.
- Ett felsökningsmeddelande kommer att loggas till `django.request` logger när en middleware ger upphov till ett [`MiddlewareNotUsed`](/sv/6.1/ref/exceptions/#django.core.exceptions.MiddlewareNotUsed) undantag i [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG)-läge.

#### Migreringar

- Operationen [`RunSQL`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL) kan nu hantera parametrar som skickas till SQL-satserna.
- Det är nu möjligt att ha migreringar (troligen [datamigreringar](/sv/6.1/topics/migrations/#data-migrations)) för applikationer utan modeller.
- Migreringar kan nu [serialisera modellhanterare](/sv/6.1/topics/migrations/#using-managers-in-migrations) som en del av modelltillståndet.
- En [generisk mekanism för att hantera borttagandet av modellfält](/sv/6.1/topics/migrations/#migrations-removing-model-fields) lades till.
- Klassmetoden/attributet [`RunPython.noop()`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython.noop) och [`RunSQL.noop`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL.noop) lades till för att underlätta att göra `RunPython` och `RunSQL`-operationer reversibla.
- Migreringsoperationerna [`RunPython`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython) och [`RunSQL`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL) anropar nu metoden [`allow_migrate()`](/sv/6.1/topics/db/multi-db/#allow_migrate) för databasroutrar. Routern kan använda de nyligen introducerade argumenten `app_label` och `hints` för att fatta ett routningsbeslut. För att dra nytta av den här funktionen måste du uppdatera routern till den nya `allow_migrate`-signaturen, se [deprecation section](#deprecated-signature-of-allow-migrate) för mer information.

#### Modeller

- Django loggar nu högst 9000 förfrågningar i `connections.queries`, för att förhindra överdriven minnesanvändning i långvariga processer i felsökningsläge.
- Det finns nu ett alternativ för modellen `Meta` för att definiera en [`standardrelaterat namn`](/sv/6.1/ref/models/options/#django.db.models.Options.default_related_name) för alla relationsfält i en modell.
- Pickling av modeller och querysets över olika versioner av Django stöds inte officiellt (det kan fungera, men det finns ingen garanti). En extra variabel som anger den aktuella Django-versionen läggs nu till i det inlagda tillståndet för modeller och querysets, och Django ger upphov till en `RuntimeWarning` när dessa objekt avplockas i en annan version än den där de inplockades.
- Lagt till [`Model.from_db()`](/sv/6.1/ref/models/instances/#django.db.models.Model.from_db) som Django använder när objekt laddas med hjälp av ORM. Metoden gör det möjligt att anpassa modellens laddningsbeteende.
- med `extra(select={...})` kan du nu undkomma en bokstavlig `%s`-sekvens med hjälp av `%%s`.
- [Custom Lookups](/sv/6.1/howto/custom-lookups/) kan nu registreras med hjälp av ett dekoratormönster.
- Det nya attributet [`Transform.bilateral`](/sv/6.1/ref/models/lookups/#django.db.models.Transform.bilateral) gör det möjligt att skapa bilaterala transformationer. Dessa transformationer tillämpas på både `lhs` och `rhs` när de används i ett uppslagsuttryck, vilket ger möjligheter till mer sofistikerade uppslagningar.
- SQL-specialtecken (, %, \_) escapas nu korrekt när en mönsteruppslagning (t.ex. `contains`, `startswith`, etc.) används med ett `F()`-uttryck som höger sida. I dessa fall utförs escapingen av databasen, vilket kan leda till något komplexa frågor som involverar nästlade `REPLACE`-funktionsanrop.
- Du kan nu uppdatera modellinstanser genom att använda [`Model.refresh_from_db()`](/sv/6.1/ref/models/instances/#django.db.models.Model.refresh_from_db).
- Du kan nu få en uppsättning uppskjutna fält för en modell med [`Model.get_deferred_fields()`](/sv/6.1/ref/models/instances/#django.db.models.Model.get_deferred_fields).
- Modellfältets `default` används nu när primärnyckelfältet är inställt på `None`.

#### Signaler

- Undantag från `(mottagare, undantag)`-tuplerna som returneras av [`Signal.send_robust()`](/sv/6.1/topics/signals/#django.dispatch.Signal.send_robust) har nu sin traceback bifogad som ett `__traceback__`-attribut.
- Argumentet `environ`, som innehåller WSGI-miljöstrukturen från begäran, lades till i signalen [`request_started`](/sv/6.1/ref/signals/#django.core.signals.request_started).
- Du kan nu importera [`setting_changed()`](/sv/6.1/ref/signals/#django.test.signals.setting_changed)-signalen från `django.core.signals` för att undvika att ladda `django.test` i situationer som inte är test. Django gör inte längre det själv.

#### Ramverk för systemkontroll

- [`register`](/sv/6.1/topics/checks/#django.core.checks.register) kan nu användas som en funktion.

#### Mallar

- [`urlize`](/sv/6.1/ref/templates/builtins/#std-templatefilter-urlize) stöder nu länkar som endast innehåller domäner och som innehåller tecken efter toppdomänen (t.ex. `djangoproject.com/` och `djangoproject.com/download/`).
- [`urlize`](/sv/6.1/ref/templates/builtins/#std-templatefilter-urlize) behandlar inte utropstecken i slutet av en domän eller dess frågesträng som en del av URL:en (URL:en i t.ex. `'djangoproject.com!` är `djangoproject.com`)
- Lagt till en [`locmem.Loader`](/sv/6.1/ref/templates/api/#django.template.loaders.locmem.Loader)-klass som laddar Django-mallar från en Python-ordbok.
- Taggen [`now`](/sv/6.1/ref/templates/builtins/#std-templatetag-now) kan nu lagra sin utdata i en kontextvariabel med den vanliga syntaxen: `{% now 'j n Y' as varname %}`.

#### Förfrågningar och svar

- `WSGIRequest` respekterar nu sökvägar som börjar med `//`.
- Metoden [`HttpRequest.build_absolute_uri()`](/sv/6.1/ref/request-response/#django.http.HttpRequest.build_absolute_uri) hanterar nu sökvägar som börjar med `//` korrekt.
- Om [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är `True` och en begäran ger upphov till en [`SuspiciousOperation`](/sv/6.1/ref/exceptions/#django.core.exceptions.SuspiciousOperation), kommer svaret att återges med en detaljerad felsida.
- Argumentet `query_string` i [`QueryDict`](/sv/6.1/ref/request-response/#django.http.QueryDict) är nu valfritt, med `None` som standard, så en tom `QueryDict` kan nu instansieras med `QueryDict()` istället för `QueryDict(None)` eller `QueryDict('')`.
- Attributen `GET` och `POST` i ett [`HttpRequest`](/sv/6.1/ref/request-response/#django.http.HttpRequest)-objekt är nu ``` QueryDict``er i stället för lexikon, och attributet ``FILES` ``` är nu en `MultiValueDict`. Detta gör att denna klass överensstämmer med dokumentationen och med `WSGIRequest`.
- Attributet [`HttpResponse.charset`](/sv/6.1/ref/request-response/#django.http.HttpResponse.charset) lades till.
- `WSGIRequestHandler` följer nu RFC vid konvertering av URI till IRI, med hjälp av `uri_to_iri()`.
- Metoden [`HttpRequest.get_full_path()`](/sv/6.1/ref/request-response/#django.http.HttpRequest.get_full_path) undviker nu osäkra tecken från sökvägsdelen av en URI (Uniform Resource Identifier) på rätt sätt.
- [`HttpResponse`](/sv/6.1/ref/request-response/#django.http.HttpResponse) implementerar nu några ytterligare metoder som [`getvalue()`](/sv/6.1/ref/request-response/#django.http.HttpResponse.getvalue) så att instanser kan användas som strömobjekt.
- Den nya [`HttpResponse.setdefault()`](/sv/6.1/ref/request-response/#django.http.HttpResponse.setdefault)-metoden gör det möjligt att ställa in en header om den inte redan har ställts in.
- Du kan använda den nya [`FileResponse`](/sv/6.1/ref/request-response/#django.http.FileResponse) för att strömma filer.
- Dekoratorn [`condition()`](/sv/6.1/topics/http/decorators/#django.views.decorators.http.condition) för villkorlig vybehandling stöder nu rubriken `If-unmodified-since`.

#### Tester

- Metoderna [`RequestFactory.trace()`](/sv/6.1/topics/testing/advanced/#django.test.RequestFactory) och [`Client.trace()`](/sv/6.1/topics/testing/tools/#django.test.Client.trace) implementerades, så att du kan skapa `TRACE`-förfrågningar i dina tester.
- Argumentet `count` lades till i [`assertTemplateUsed()`](/sv/6.1/topics/testing/tools/#django.test.SimpleTestCase.assertTemplateUsed). Detta gör att du kan hävda att en mall återgavs ett visst antal gånger.
- Den nya [`assertJSONNotEqual()`](/sv/6.1/topics/testing/tools/#django.test.SimpleTestCase.assertJSONNotEqual)-assertionen gör att du kan testa att två JSON-fragment inte är lika.
- Lagt till alternativ till kommandot [`test`](/sv/6.1/ref/django-admin/#django-admin-test) för att bevara testdatabasen ([`--keepdb`](/sv/6.1/ref/django-admin/#cmdoption-test-keepdb)), för att köra testfallen i omvänd ordning ([`--reverse`](/sv/6.1/ref/django-admin/#cmdoption-test-reverse)) och för att aktivera SQL-loggning för misslyckade tester ([`--debug-sql`](/sv/6.1/ref/django-admin/#cmdoption-test-debug-sql)).
- Lagt till attributet [`resolver_match`](/sv/6.1/topics/testing/tools/#django.test.Response.resolver_match) för att testa klientsvar.
- Flera inställningar har lagts till som gör det möjligt att anpassa parametrarna för testtabellutrymmen för Oracle: [`DATAFILE`](/sv/6.1/ref/settings/#std-setting-DATAFILE), [`DATAFILE_TMP`](/sv/6.1/ref/settings/#std-setting-DATAFILE_TMP), [`DATAFILE_MAXSIZE`](/sv/6.1/ref/settings/#std-setting-DATAFILE_MAXSIZE) och [`DATAFILE_TMP_MAXSIZE`](/sv/6.1/ref/settings/#std-setting-DATAFILE_TMP_MAXSIZE).
- Dekoratorn [`override_settings()`](/sv/6.1/topics/testing/tools/#django.test.override_settings) kan nu påverka huvudroutern i [`DATABASE_ROUTERS`](/sv/6.1/ref/settings/#std-setting-DATABASE_ROUTERS).
- Lagt till stöd för testklient för filuppladdningar med filliknande objekt.
- En delad cache används nu vid testning med en SQLite-databas i minnet när Python 3.4+ och SQLite 3.7.13+ används. Detta gör det möjligt att dela databasen mellan trådar.

#### Validerare

- [`URLValidator`](/sv/6.1/ref/validators/#django.core.validators.URLValidator) stöder nu IPv6-adresser, Unicode-domäner och webbadresser som innehåller autentiseringsdata.

## Bakåtkompatibla ändringar i 1.8

> **Warning**
>
> Utöver de ändringar som beskrivs i det här avsnittet bör du granska [deprecation plan](/sv/6.1/internals/deprecation/#deprecation-removed-in-1-8) för alla funktioner som har tagits bort. Om du inte har uppdaterat din kod inom utfasningstiden för en viss funktion kan borttagningen av den framstå som en bakåtkompatibel ändring.

### Operationer för relaterade objekt körs i en transaktion

Some operations on related objects such as
[`add()`](/sv/6.1/ref/models/relations/#django.db.models.fields.related.RelatedManager.add) or direct
assignment ran multiple data modifying queries without wrapping them in
transactions. To reduce the risk of data corruption, all data modifying methods
that affect multiple related objects (i.e. `add()`, `remove()`,
`clear()`, and direct assignment) now perform their data modifying queries
from within a transaction, provided your database supports transactions.

Detta har en bakåtkompatibel bieffekt, signalhanterare som utlöses från dessa metoder exekveras nu inom metodens transaktion och alla undantag i en signalhanterare kommer att förhindra hela operationen.

### Att tilldela osparade objekt till relationer ger upphov till ett fel

> **Note**
>
> För att lättare tillåta användning av modeller i minnet, återkallades denna ändring i Django 1.8.4 och ersattes med en kontroll under `model.save()`. Till exempel:
>
> ```pycon
> >>> book = Book.objects.create(name="Django")
> >>> book.author = Author(name="John")
> >>> book.save()
> Traceback (most recent call last):
> ...
> ValueError: save() prohibited to prevent data loss due to unsaved related object 'author'.
> ```
>
> En liknande kontroll av tilldelning för att vända en-till-en-relationer togs bort i Django 1.8.5.

Tilldelning av osparade objekt till en [`ForeignKey`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey), [`GenericForeignKey`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericForeignKey) och [`OneToOneField`](/sv/6.1/ref/models/fields/#django.db.models.OneToOneField) ger nu upphov till en [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError).

Tidigare ignorerades tilldelningen av ett osparat objekt i tysthet. Ett exempel:

```pycon
>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.author.save()
>>> book.save()

>>> Book.objects.get(name="Django")
>>> book.author
>>>
```

Nu kommer ett felmeddelande att visas för att förhindra dataförlust:

```pycon
>>> book.author = Author(name="john")
Traceback (most recent call last):
...
ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.
```

Om du vill tillåta tilldelning av osparade instanser (det gamla beteendet) och inte är orolig för risken för dataförlust (t.ex. om du aldrig sparar objekten i databasen), kan du inaktivera denna kontroll genom att använda attributet `ForeignKey.allow_unsaved_instance_assignment`. (Detta attribut togs bort i 1.8.4 eftersom det inte längre är relevant)

### Hanteringskommandon som endast accepterar positionella argument

If you have written a custom management command that only accepts positional
arguments and you didn’t specify the `args` command variable, you might get
an error like `Error: unrecognized arguments: ...`, as variable parsing is
now based on [`argparse`](https://docs.python.org/3/library/argparse.html#module-argparse) which doesn’t implicitly accept positional
arguments. You can make your command backwards compatible by simply setting the
`args` class variable. However, if you don’t have to keep compatibility with
older Django versions, it’s better to implement the new
[`add_arguments()`](/sv/6.1/howto/custom-management-commands/#django.core.management.BaseCommand.add_arguments) method as described
in [Hur man skapar egna kommandon för django-admin](/sv/6.1/howto/custom-management-commands/).

### Anpassade kommandoparametrar för testhantering via testrunner

The method to add custom arguments to the `test` management command through
the test runner has changed. Previously, you could provide an `option_list`
class variable on the test runner to add more arguments (à la
[`optparse`](https://docs.python.org/3/library/optparse.html#module-optparse)). Now to implement the same behavior, you have to create an
`add_arguments(cls, parser)` class method on the test runner and call
`parser.add_argument` to add any custom arguments, as parser is now an
[`argparse.ArgumentParser`](https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser) instance.

### Modellkontroll säkerställer att automatiskt genererade kolumnnamn ligger inom de gränser som anges av databasen

Ett fältnamn som är längre än kolumnnamnets längd som stöds av en databas kan skapa problem. Med MySQL får du till exempel ett undantag som försöker skapa kolumnen, och med PostgreSQL trunkeras kolumnnamnet av databasen (du kan se en varning i PostgreSQL-loggarna).

En modellkontroll har införts för att bättre varna användarna för detta scenario innan databastabellerna faktiskt skapas.

Om du har en befintlig modell där denna kontroll verkar vara en falsk positiv, till exempel på PostgreSQL där namnet redan trunkerades, använd helt enkelt [`db_column`](/sv/6.1/ref/models/fields/#django.db.models.Field.db_column) för att ange namnet som används.

Kontrollen gäller även de kolumner som genereras i en implicit `ManyToManyField.through`-modell. Om du stöter på problem där, använd [`through`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField.through) för att skapa en explicit modell och ange sedan [`db_column`](/sv/6.1/ref/models/fields/#django.db.models.Field.db_column) på dess kolumn(er) efter behov.

### Sökningar i Query-relationer kontrollerar nu objekttyper

Förfrågningar om modelluppslagningar kontrollerar nu om objektet som skickas är av rätt typ och ger upphov till ett [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) om så inte är fallet. Tidigare brydde sig Django inte om objektet var av rätt typ; det använde bara objektets relaterade fältattribut (t.ex. `id`) för uppslagningen. Nu uppstår ett fel för att förhindra felaktiga uppslagningar:

```pycon
>>> book = Book.objects.create(name="Django")
>>> book = Book.objects.filter(author=book)
Traceback (most recent call last):
...
ValueError: Cannot query "<Book: Django>": Must be "Author" instance.
```

### `select_related()` kontrollerar nu angivna fält

`select_related()` validerar nu att de angivna fälten faktiskt existerar. Tidigare ignorerades icke-existerande fält i tysthet. Nu genereras ett felmeddelande:

```pycon
>>> book = Book.objects.select_related("nonexistent_field")
Traceback (most recent call last):
...
FieldError: Invalid field name(s) given in select_related: 'nonexistent_field'
```

Valideringen säkerställer också att det angivna fältet är relationellt:

```pycon
>>> book = Book.objects.select_related("name")
Traceback (most recent call last):
...
FieldError: Non-relational field given in select_related: 'name'
```

### Standard `EmailField.max_length` ökad till 254

Det gamla standardvärdet på 75 tecken för `max_length` kunde inte lagra alla möjliga e-postadresser som uppfyller RFC3696/5321. För att kunna lagra alla möjliga giltiga e-postadresser har `max_length` ökats till 254 tecken. Du måste generera och tillämpa databasmigreringar för dina berörda modeller (eller lägga till `max_length=75` om du vill behålla längden på dina aktuella fält). En migrering för [`django.contrib.auth.models.User.email`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User.email) ingår.

### Stöd för PostgreSQL-versioner äldre än 9.0

Slutet på uppströms stödperioder nåddes i juli 2014 för PostgreSQL 8.4. Som en följd av detta ställer Django 1.8 9.0 som den minsta PostgreSQL-versionen som den officiellt stöder.

Detta inkluderar också att släppa stöd för PostGIS 1.3 och 1.4 eftersom dessa versioner inte stöds på versioner av PostgreSQL senare än 8.4.

Django kräver nu också användning av Psycopg2 version 2.4.5 eller högre (eller 2.5+ om du vill använda [`django.contrib.postgres`](/sv/6.1/ref/contrib/postgres/#module-django.contrib.postgres)).

### Stöd för MySQL-versioner äldre än 5.5

Slutet på uppströms stödperioder nåddes i januari 2012 för MySQL 5.0 och december 2013 för MySQL 5.1. Som en följd av detta sätter Django 1.8 5.5 som den minsta MySQL-versionen som den officiellt stöder.

### Stöd för Oracle-versioner äldre än 11.1

Slutet på uppströms supportperioder nåddes i juli 2010 för Oracle 9.2, januari 2012 för Oracle 10.1 och juli 2013 för Oracle 10.2. Som en följd av detta sätter Django 1.8 11.1 som den minsta Oracle-versionen som den officiellt stöder.

### Specifika behörigheter används i stället för roller för tester på Oracle

Tidigare versioner av Django gav rollerna CONNECT och RESOURCE till testanvändaren på Oracle. Dessa roller har tagits bort, så Django 1.8 använder istället de specifika underliggande behörigheterna. Detta ändrar de privilegier som krävs av huvudanvändaren för att köra tester (såvida inte projektet är konfigurerat för att undvika att skapa en testanvändare). De exakta privilegier som krävs nu beskrivs i [Oracle notes](/sv/6.1/ref/databases/#oracle-notes).

### `AbstractUser.last_login` tillåter null-värden

Fältet [`AbstractUser.last_login`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User.last_login) tillåter nu null-värden. Tidigare var standardvärdet den tidpunkt då användaren skapades, vilket var missvisande om användaren aldrig loggade in. Om du använder standardanvändaren ([`django.contrib.auth.models.User`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User)) ska du köra databasmigreringen som ingår i `contrib.auth`.

Om du använder en anpassad användarmodell som ärver från `AbstractUser` måste du köra [`makemigrations`](/sv/6.1/ref/django-admin/#django-admin-makemigrations) och generera en migrering för din app som innehåller den modellen. Om du vill ställa in `last_login` till `NULL` för användare som inte har loggat in kan du också köra den här frågan:

```
from django.db import models
from django.contrib.auth import get_user_model
from django.contrib.auth.models import AbstractBaseUser

UserModel = get_user_model()
if issubclass(UserModel, AbstractBaseUser):
    UserModel._default_manager.filter(last_login=models.F("date_joined")).update(
        last_login=None
    )
```

### [`django.contrib.gis`](/sv/6.1/ref/contrib/gis/#module-django.contrib.gis)

- Stöd för GEOS 3.1 och GDAL 1.6 har tagits bort.
- Stöd för SpatiaLite \< 2.4 har tagits bort.
- GIS-specifika uppslagningar har omarbetats för att använda API:et [`django.db.models.Lookup`](/sv/6.1/ref/models/lookups/#django.db.models.Lookup).
- Standardrepresentationen `str` för [`GEOSGeometry`](/sv/6.1/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry)-objekt har ändrats från WKT- till EWKT-format (inklusive SRID). Eftersom denna representation används i serialiseringsramverket innebär det att `dumpdata`-utdata nu kommer att innehålla SRID-värdet för geometriobjekt.

### Prioritering av kontextprocessorer för `TemplateResponse` i linje med `render`

Konstruktören [`TemplateResponse`](/sv/6.1/ref/template-response/#django.template.response.TemplateResponse) är utformad för att vara en direkt ersättning för funktionen [`render()`](/sv/6.1/topics/http/shortcuts/#django.shortcuts.render). Den hade dock en liten inkompatibilitet, i det att för `TemplateResponse` kunde kontextdata från den passerade kontextordboken skuggas av kontextdata som returnerades från kontextprocessorer, medan det för `render` var tvärtom. Detta var en bugg, och beteendet för `render` är mer lämpligt, eftersom det tillåter att de globalt definierade kontextprocessorerna åsidosätts lokalt i vyn. Om du förlitade dig på att kontextdata i en `TemplateResponse` kunde åsidosättas med hjälp av en kontextprocessor, måste du ändra din kod.

### Åsidosätta `setUpClass` / `tearDownClass` i testfall

Dekoratörerna [`override_settings()`](/sv/6.1/topics/testing/tools/#django.test.override_settings) och [`modify_settings()`](/sv/6.1/topics/testing/tools/#django.test.modify_settings) agerar nu på klassnivå när de används som klassdekoratörer. Som en konsekvens, när man åsidosätter `setUpClass()` eller `tearDownClass()`, bör alltid `super` implementationen anropas.

### Borttagning av `django.contrib.formtools`

Appen formtools contrib har flyttats till ett separat paket och de relevanta dokumentationssidorna har uppdaterats eller tagits bort.

Det nya paketet finns tillgängligt på GitHub och på PyPI.

### Databasanslutning laddas om mellan tester

Django stängde tidigare databasanslutningar mellan varje test inom ett `TestCase`. Detta är inte längre fallet eftersom Django nu omsluter hela `TestCase` inom en transaktion. Om några av dina tester förlitade sig på det gamla beteendet, bör du låta dem ärva från `TransactionTestCase` istället.

### Uppstädning av namnrymden `django.template`

Om du har förlitat dig på privata API:er som exponeras i modulen `django.template` kan du behöva importera dem från `django.template.base` istället.

Även privata API:er `django.template.base.compile_string()`, `django.template.loader.find_template()` och `django.template.loader.get_template_from_string()` togs bort.

### `model` attribut på privata modellrelationer

I tidigare versioner av Django, på en modell med en omvänd foreign key-relation (till exempel), returnerade `model._meta.get_all_related_objects()` relationen som en `django.db.models.related.RelatedObject` med attributet `model` inställt på källan till relationen. Nu returnerar denna metod relationen som `django.db.models.fields.related.ManyToOneRel` (privata API `RelatedObject` har tagits bort), och attributet `model` är inställt på målet för relationen istället för källan. Källmodellen är tillgänglig via attributet `related_model` i stället.

Tänk på detta exempel från handledningen i Django 1.8:

```pycon
>>> p = Poll.objects.get(pk=1)
>>> p._meta.get_all_related_objects()
[<ManyToOneRel: polls.choice>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Poll'>
>>> p._meta.get_all_related_objects()[0].related_model
<class 'polls.models.Choice'>
```

och jämför det med beteendet på äldre versioner:

```pycon
>>> p._meta.get_all_related_objects()
[<RelatedObject: polls:choice related to poll>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Choice'>
```

För att komma åt källmodellen kan du använda ett mönster som detta för att skriva kod som fungerar med både Django 1.8 och äldre versioner:

```
for relation in opts.get_all_related_objects():
    to_model = getattr(relation, "related_model", relation.model)
```

Observera också att `get_all_related_objects()` är föråldrad i 1.8.

### Databas backend API

Följande ändringar av API:et för databasbackend dokumenteras för att hjälpa dem som skriver backend från tredje part att uppdatera sin kod:

- klasserna `BaseDatabaseXXX` har flyttats till `django.db.backends.base`. Importera dem från de nya platserna:

  ```
  from django.db.backends.base.base import BaseDatabaseWrapper
  from django.db.backends.base.client import BaseDatabaseClient
  from django.db.backends.base.creation import BaseDatabaseCreation
  from django.db.backends.base.features import BaseDatabaseFeatures
  from django.db.backends.base.introspection import BaseDatabaseIntrospection
  from django.db.backends.base.introspection import FieldInfo, TableInfo
  from django.db.backends.base.operations import BaseDatabaseOperations
  from django.db.backends.base.schema import BaseDatabaseSchemaEditor
  from django.db.backends.base.validation import BaseDatabaseValidation
  ```
- Attributen `data_types`, `data_types_suffix` och `data_type_check_constraints` har flyttats från klassen `DatabaseCreation` till `DatabaseWrapper`.
- Metoden ```SQLCompiler.as_sql() `` tar nu en ``subquery``` parameter ([#24164](https://code.djangoproject.com/ticket/24164)).
- Metoden `BaseDatabaseOperations.date_interval_sql()` tar nu bara en `timedelta` parameter.

### [`django.contrib.admin`](/sv/6.1/ref/contrib/admin/#module-django.contrib.admin)

- `AdminSite` no longer takes an `app_name` argument and its `app_name`
  attribute has been removed. The application name is always `admin` (as
  opposed to the instance name which you can still customize using
  `AdminSite(name="...")`).
- Metoden `ModelAdmin.get_object()` (privat API) tar nu ett tredje argument med namnet `from_field` för att ange vilket fält som ska matcha det angivna `object_id`.
- Metoden [`ModelAdmin.response_delete()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.response_delete) tar nu ett andra argument med namnet `obj_id` som är den serialiserade identifieraren som används för att hämta objektet innan det raderas.

### Standard autoescaping av funktioner i `django.template.defaultfilters`

För att göra inbyggda mallfilter som matar ut HTML ”säkra som standard” när de anropas i Python-kod, har följande funktioner i `django.template.defaultfilters` ändrats för att automatiskt undkomma deras ingångsvärde:

- ”Ansluta
- `linebreaksbr`
- `linebreaks_filter`
- `linenummer`
- ”oordnad lista
- `urlize`
- `urlizetrunc`

Du kan återgå till det gamla beteendet genom att ange `autoescape=False` om du skickar betrott innehåll. Den här ändringen har ingen effekt när du använder motsvarande filter i mallar.

### Diverse

- `connections.queries` är nu ett skrivskyddat attribut.
- Databasanslutningar betraktas som likvärdiga endast om de är samma objekt. De är inte hashbara längre.
- [`GZipMiddleware`](/sv/6.1/ref/middleware/#django.middleware.gzip.GZipMiddleware) används för att inaktivera komprimering för vissa innehållstyper när begäran kommer från Internet Explorer, för att komma runt en bugg i IE6 och tidigare. Detta beteende kunde påverka prestandan i IE7 och senare. Den har tagits bort.
- `URLField.to_python` lägger inte längre till ett efterföljande snedstreck i webbadresser utan sökväg.
- Mallfiltret [`length`](/sv/6.1/ref/templates/builtins/#std-templatefilter-length) returnerar nu `0` för en odefinierad variabel, i stället för en tom sträng.
- `ForeignKey.default_error_message['invalid']` har ändrats från `'%(model)s instance with pk %(pk)r does not exist.'` till `'%(model)s instance with %(field)s %(value)r does not exist.'` Om du använder detta meddelande i din egen kod, uppdatera listan över interpolerade parametrar. Internt kommer Django att fortsätta att tillhandahålla parametern `pk` i `params` för bakåtkompatibilitet.
- `UserCreationForm.error_messages['duplicate_username']` används inte längre. Om du vill anpassa felmeddelandet kan du [åsidosätta det på formuläret](/sv/6.1/topics/forms/modelforms/#modelforms-overriding-default-fields) med hjälp av nyckeln `'unique'` i `Meta.error_messages['username']` eller, om du har ett anpassat formulärfält för `'username'`, med hjälp av nyckeln `'unique'` i dess [`error_messages`](/sv/6.1/ref/forms/fields/#django.forms.Field.error_messages)-argument.
- Blocket `usertools` i mallen `base.html` i [`django.contrib.admin`](/sv/6.1/ref/contrib/admin/#module-django.contrib.admin) kräver nu att kontextvariabeln `has_permission` är inställd. Om du har några anpassade adminvyer som använder den här mallen, uppdatera dem för att skicka [`AdminSite.has_permission()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.has_permission) som den här nya variabelns värde eller helt enkelt inkludera [`AdminSite.each_context(request)`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.each_context) i sammanhanget.
- Interna ändringar gjordes i widgeten [`ClearableFileInput`](/sv/6.1/ref/forms/widgets/#django.forms.ClearableFileInput) för att möjliggöra mer anpassning. Det odokumenterade attributet `url_markup_template` togs bort till förmån för `template_with_initial`.
- För att vara konsekvent med andra större leverantörer har `en_GB` nu måndag som första dag i veckan.
- Sekunder har tagits bort från alla lokala som hade dem i `TIME_FORMAT`, `DATETIME_FORMAT` eller `SHORT_DATETIME_FORMAT`.
- Den maximala standardstorleken för Oracle test tablespace har ökat från 300M (eller 200M, före 1.7.2) till 500M.
- `reverse()` och `reverse_lazy()` returnerar nu Unicode-strängar istället för bytestrings.
- `CacheClass` shim har tagits bort från alla cache backends. Dessa alias tillhandahölls för bakåtkompatibilitet med Django 1.3. Om du fortfarande använder dem, uppdatera ditt projekt så att du använder det riktiga klassnamnet som finns i [`BACKEND`](/sv/6.1/ref/settings/#std-setting-CACHES-BACKEND) nyckeln i [`CACHES`](/sv/6.1/ref/settings/#std-setting-CACHES) inställning.
- Som standard hoppar [`call_command()`](/sv/6.1/ref/django-admin/#django.core.management.call_command) nu alltid över kontrollramverket (om du inte ger det `skip_checks=False`).
- Vid iteration över rader använder [`File`](/sv/6.1/ref/files/file/#django.core.files.File) nu [**universal newlines**](https://peps.python.org/pep-0278/). Följande anses avsluta en rad: Unix-konventionen för radavslut `'\n'`, Windows-konventionen `'\r\n'` och den gamla Macintosh-konventionen `'\r'`.
- Memcached-cache-backends `MemcachedCache` och `PyLibMCCache` kommer att radera en nyckel om `set()` misslyckas. Detta är nödvändigt för att säkerställa att sessionslagret `cache_db` alltid hämtar de mest aktuella sessionsdata.
- Privata API:er `override_template_loaders` och `override_with_test_loader` i `django.test.utils` togs bort. Åsidosätt `TEMPLATES` med `override_settings` istället.
- Varningar från MySQL-databasens backend konverteras inte längre till undantag när [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är `True`.
- [`HttpRequest`](/sv/6.1/ref/request-response/#django.http.HttpRequest) har nu en förenklad `repr` (t.ex. `<WSGIRequest: GET '/somepath/'>`). Detta kommer inte att förändra beteendet hos [`SafeExceptionReporterFilter`](/sv/6.1/howto/error-reporting/#django.views.debug.SafeExceptionReporterFilter)-klassen.
- Klassbaserade vyer som använder [`ModelFormMixin`](/sv/6.1/ref/class-based-views/mixins-editing/#django.views.generic.edit.ModelFormMixin) kommer att ge upphov till ett [`ImproperlyConfigured`](/sv/6.1/ref/exceptions/#django.core.exceptions.ImproperlyConfigured) undantag när både attributen `fields` och `form_class` är specificerade. Tidigare ignorerades `fields` i tysthet.
- När testklienten följer omdirigeringar ger den nu upphov till [`RedirectCycleError`](/sv/6.1/ref/exceptions/#django.test.client.RedirectCycleError) om den upptäcker en loop eller når en maximal gräns för omdirigering (i stället för att passera tyst).
- Översättbara strängar som anges som fältets `default`-parameter omvandlas senare till konkreta strängar, så returtypen för `Field.get_default()` är annorlunda i vissa fall. Det sker ingen ändring av standardvärden som är resultatet av en callable.
- `GenericIPAddressField.empty_strings_allowed` är nu `False`. Databasbackends som tolkar tomma strängar som null (endast Oracle bland de backends som Django inkluderar) kommer inte längre att konvertera null-värden tillbaka till en tom sträng. Detta är i överensstämmelse med andra backends.
- När attributet `BaseCommand.leave_locale_alone` är `False` avaktiveras nu översättningar istället för att tvinga fram ”en-us” locale. Om dina modeller innehöll icke-engelska strängar och du räknade med att engelska översättningar skulle aktiveras i hanteringskommandon, kommer detta inte att hända längre. Det kan vara så att nya databasmigreringar genereras (en gång) efter migrering till 1.8.
- [`django.utils.translation.get_language()`](/sv/6.1/ref/utils/#django.utils.translation.get_language) now returns `None` instead
  of [`LANGUAGE_CODE`](/sv/6.1/ref/settings/#std-setting-LANGUAGE_CODE) when translations are temporarily deactivated.
- När det inte finns någon översättning för en viss bokstav hämtas nu reservalternativet från [`LANGUAGE_CODE`](/sv/6.1/ref/settings/#std-setting-LANGUAGE_CODE)-språket (i stället för från det oöversatta `msgid`-meddelandet).
- Fältet `name` i [`django.contrib.contenttypes.models.ContentType`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType) har tagits bort genom en migrering och ersatts av en egenskap. Det betyder att det inte längre är möjligt att fråga eller filtrera en `ContentType` med detta fält.

  Var försiktig om du uppgraderar till Django 1.8 och hoppar över Django 1.7. Om du kör `manage.py migrate --fake` kommer den här migreringen att hoppas över och du kommer att se ett `RuntimeError: Error creating new content types.` undantag eftersom kolumnen `name` inte kommer att tas bort från databasen. Använd `manage.py migrate --fake-initial` för att fejka endast den första migreringen istället.
- Det nya alternativet [`migrate --fake-initial`](/sv/6.1/ref/django-admin/#cmdoption-migrate-fake-initial) gör det möjligt att fejka initiala migreringar. I 1.7 fejkades initiala migreringar alltid automatiskt om alla tabeller som skapades i en initial migrering redan existerade.
- En app *utan* migreringar med en `ForeignKey` till en app *med* migreringar kan nu resultera i ett foreign key constraint error när databasen migreras eller tester körs. I Django 1.7 kunde detta misslyckas tyst och resultera i en saknad begränsning. För att lösa felet, lägg till migreringar i appen utan dem.

## Funktioner som inte längre är aktuella i 1.8

### Valda metoder i `django.db.models.options.Options`

Som en del av formaliseringen av API:et `Model._meta` (från klassen [`django.db.models.options.Options`](/sv/6.1/ref/models/meta/#django.db.models.options.Options)), har ett antal metoder blivit föråldrade och kommer att tas bort i Django 1.10:

- `get_all_field_names()`
- `get_all_related_objects()`
- `get_all_related_objects_with_model()`
- `get_all_related_many_to_many_objects()`
- `get_all_related_m2m_objects_with_model()`
- `get_concrete_fields_with_model()`
- `get_field_by_name()`
- `get_fields_with_model()`
- `get_m2m_with_model()`

### Laddar `cycle` och `firstof` malltaggar från `future` bibliotek

Django 1.6 introducerade `{% load cycle from future %}` och `{% load firstof from future %}` syntax för framåtkompatibilitet av [`cycle`](/sv/6.1/ref/templates/builtins/#std-templatetag-cycle) och [`firstof`](/sv/6.1/ref/templates/builtins/#std-templatetag-firstof) malltaggar. Denna syntax är nu föråldrad och kommer att tas bort i Django 1.10. Du kan helt enkelt ta bort `{% load ... from future %}`-taggarna.

### `django.conf.urls.patterns()` \`\`

Förr i tiden med Django uppmuntrades det att referera till vyer som strängar i `urlpatterns`:

```
urlpatterns = patterns(
    "",
    url("^$", "myapp.views.myview"),
)
```

och Django skulle magiskt importera `myapp.views.myview` internt och förvandla strängen till en riktig funktionsreferens. För att minska upprepning när man refererar till många vyer från samma modul, tar funktionen `patterns()` ett obligatoriskt initialt `prefix` argument som är prepended till alla views-as-strängar i den uppsättningen av `urlpatterns`:

```
urlpatterns = patterns(
    "myapp.views",
    url("^$", "myview"),
    url("^other/$", "otherview"),
)
```

I den moderna eran har vi uppdaterat handledningen för att istället rekommendera att du importerar din views-modul och refererar till dina view-funktioner (eller klasser) direkt. Detta har ett antal fördelar, som alla härrör från det faktum att vi använder vanliga Python i stället för ”Django String Magic”: felen när du skriver fel på ett vy-namn är mindre otydliga, IDE kan hjälpa till med autokomplettering av vy-namn, etc.

Så nuförtiden är det mycket mer sannolikt att ovanstående användning av `prefix` arg skrivs (och skrivs bättre) som:

```
from myapp import views

urlpatterns = patterns(
    "",
    url("^$", views.myview),
    url("^other/$", views.otherview),
)
```

Därför har `patterns()` inget större syfte och är en börda när man lär upp nya användare (genom att svara på nybörjarens fråga ”varför behöver jag den här tomma strängen som första argument till `patterns()`?”). Av dessa anledningar avregistrerar vi den. Att uppdatera din kod är så enkelt som att se till att `urlpatterns` är en lista över `django.conf.urls.url()` instanser. Till exempel:

```
from django.conf.urls import url
from myapp import views

urlpatterns = [
    url("^$", views.myview),
    url("^other/$", views.otherview),
]
```

### Skicka en sträng som `view` till `django.conf.urls.url()`

Relaterat till föregående punkt, att referera till vyer som strängar i funktionen `url()` är föråldrat. Skicka istället den anropsbara vyn enligt beskrivningen i föregående avsnitt.

### Mallrelaterade inställningar

Som en konsekvens av refaktoriseringen av flera mallmotorer, är flera inställningar borttagna till förmån för [`TEMPLATES`](/sv/6.1/ref/settings/#std-setting-TEMPLATES):

- `TILLÅTET_INKLUDERA_RÖTTER`
- `TEMPLATE_KONTEXT_PROCESSORER`
- `TEMPLATE_DEBUG`
- `TEMPLATE_DIRS`
- `TEMPLATE_LADDARE`
- `TEMPLATE_STRING_IF_INVALID`

### `django.core.context_processors`

Inbyggda mallkontextprocessorer har flyttats till `django.template.context_processors`.

### `django.test.SimpleTestCase.urls`

Attributet `SimpleTestCase.urls` för att ange URLconf-konfiguration i tester har föråldrats och kommer att tas bort i Django 1.10. Använd [`@override_settings(ROOT_URLCONF=...)`](/sv/6.1/topics/testing/tools/#django.test.override_settings) istället.

### `prefix` argument till [`i18n_patterns()`](/sv/6.1/topics/i18n/translation/#django.conf.urls.i18n.i18n_patterns)

Relaterat till föregående punkt, argumentet `prefix` till [`django.conf.urls.i18n.i18n_patterns()`](/sv/6.1/topics/i18n/translation/#django.conf.urls.i18n.i18n_patterns) har utgått. Skicka helt enkelt en lista med `django.conf.urls.url()`-instanser istället.

### Använda ett felaktigt antal uppackade värden i [`for`](/sv/6.1/ref/templates/builtins/#std-templatetag-for)-malltaggen

Att använda ett felaktigt antal uppackade värden i [`for`](/sv/6.1/ref/templates/builtins/#std-templatetag-for) tag kommer att ge upphov till ett undantag istället för att misslyckas tyst i Django 1.10.

### Skicka en prickad sökväg till `reverse()` och [`url`](/sv/6.1/ref/templates/builtins/#std-templatetag-url)

Att vända webbadresser efter Python-sökväg är en dyr operation eftersom det leder till att sökvägen som vänds importeras. Detta beteende har också resulterat i en [security issue](https://www.djangoproject.com/weblog/2014/apr/21/security/#s-issue-unexpected-code-execution-using-reverse). Använd [namngivna URL-mönster](/sv/6.1/topics/http/urls/#naming-url-patterns) för att vända istället.

Om du använder [`django.contrib.sitemaps`](/sv/6.1/ref/contrib/sitemaps/#module-django.contrib.sitemaps), lägg till argumentet `name` i `url` som refererar till [`django.contrib.sitemaps.views.sitemap()`](/sv/6.1/ref/contrib/sitemaps/#django.contrib.sitemaps.views.sitemap):

```
from django.contrib.sitemaps.views import sitemap

url(
    r"^sitemap\.xml$",
    sitemap,
    {"sitemaps": sitemaps},
    name="django.contrib.sitemaps.views.sitemap",
)
```

för att säkerställa kompatibilitet vid reversering av Python-sökväg tas bort i Django 1.10.

På samma sätt för GIS-webbplatskartor, lägg till `name='django.contrib.gis.sitemaps.views.kml'` eller `name='django.contrib.gis.sitemaps.views.kmz'`.

Om du använder en Python-sökväg för inställningen [`LOGIN_URL`](/sv/6.1/ref/settings/#std-setting-LOGIN_URL) eller [`LOGIN_REDIRECT_URL`](/sv/6.1/ref/settings/#std-setting-LOGIN_REDIRECT_URL) ska du använda namnet på `url()` istället.

### Aggregerade metoder och moduler

Modulerna `django.db.models.sql.aggregates` och `django.contrib.gis.db.models.sql.aggregates` (båda privata API), har utgått eftersom `django.db.models.aggregates` och `django.contrib.gis.db.models.aggregates` nu också ansvarar för SQL-generering. De gamla modulerna kommer att tas bort i Django 1.10.

Om du använde de gamla modulerna, se [Query Expressions](/sv/6.1/ref/models/expressions/) för instruktioner om hur du skriver om anpassade aggregat med hjälp av det nya stabila API:et.

Följande metoder och egenskaper för `django.db.models.sql.query.Query` har också utgått och bakåtkompatibiliteten kommer att tas bort i Django 1.10:

- `Query.aggregates`, ersatt av `annotations`.
- `Query.aggregate_select`, ersatt av `annotation_select`.
- `Query.add_aggregate()`, ersatt av `add_annotation()`.
- `Query.set_aggregate_mask()`, ersatt av `set_annotation_mask()`.
- `Query.append_aggregate_mask()`, ersatt av `append_annotation_mask()`.

### Utökade argument för hanteringskommandon genom `Command.option_list`

Management commands now use [`argparse`](https://docs.python.org/3/library/argparse.html#module-argparse) instead of [`optparse`](https://docs.python.org/3/library/optparse.html#module-optparse) to
parse command-line arguments passed to commands. This also means that the way
to add custom arguments to commands has changed: instead of extending the
`option_list` class list, you should now override the
[`add_arguments()`](/sv/6.1/howto/custom-management-commands/#django.core.management.BaseCommand.add_arguments) method and add
arguments through `argparse.add_argument()`. See
[this example](/sv/6.1/howto/custom-management-commands/#custom-commands-options) for more details.

### `django.core.management.NoArgsCommand`

Klassen `NoArgsCommand` är nu föråldrad och kommer att tas bort i Django 1.10. Använd [`BaseCommand`](/sv/6.1/howto/custom-management-commands/#django.core.management.BaseCommand) istället, som inte tar några argument som standard.

### Lista alla migreringar i ett projekt

Alternativet `--list` i hanteringskommandot [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate) är föråldrat och kommer att tas bort i Django 1.10. Använd [`showmigrations`](/sv/6.1/ref/django-admin/#django-admin-showmigrations) istället.

### alternativet `cache_choices` för `ModelChoiceField` och `ModelMultipleChoiceField`

[`ModelChoiceField`](/sv/6.1/ref/forms/fields/#django.forms.ModelChoiceField) och [`ModelMultipleChoiceField`](/sv/6.1/ref/forms/fields/#django.forms.ModelMultipleChoiceField) tog ett odokumenterat, otestat alternativ `cache_choices`. Detta cachade querysets mellan flera renderingar av samma `Form`-objekt. Detta alternativ är föremål för en accelererad utfasning och kommer att tas bort i Django 1.9.

### `django.template.resolve_variable()`

Funktionen har varit informellt markerad som ”Deprecated” under en tid. Ersätt `resolve_variable(path, context)` med `django.template.Variable(path).resolve(context)`.

### `django.contrib.webdesign`

Den tillhandahöll [`lorem`](/sv/6.1/ref/templates/builtins/#std-templatetag-lorem) malltagg som nu ingår i de inbyggda taggarna. Ta helt enkelt bort `'django.contrib.webdesign'` från [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS) och `{% load webdesign %}` från dina mallar.

### `error_message` argument till `django.forms.RegexField`

Det gav bakåtkompatibilitet för kod från före 1.0, men dess funktionalitet är överflödig. Använd `Field.error_messages['invalid']` istället.

### Gammal syntax för :tfilter:unordered\_list

Ett äldre (pre-1.0), mer restriktivt och mångordigt indataformat för mallfiltret [`unordered_list`](/sv/6.1/ref/templates/builtins/#std-templatefilter-unordered_list) har tagits bort:

```
["States", [["Kansas", [["Lawrence", []], ["Topeka", []]]], ["Illinois", []]]]
```

Med hjälp av den nya syntaxen blir detta:

```
["States", ["Kansas", ["Lawrence", "Topeka"], "Illinois"]]
```

### `django.forms.Field._has_changed()`

Byt namn på denna metod till [`has_changed()`](/sv/6.1/ref/forms/fields/#django.forms.Field.has_changed) genom att ta bort det inledande understrecket. Det gamla namnet kommer fortfarande att fungera fram till Django 1.10.

### `django.utils.html.remove_tags()` och `removetags` mallfilter

`django.utils.html.remove_tags()` samt mallfiltret `removetags` har föråldrats eftersom de inte kan garantera säker utmatning. Deras existens kommer sannolikt att leda till att de används i säkerhetskänsliga sammanhang där de faktiskt inte är säkra.

Den oanvända och odokumenterade funktionen `django.utils.html.strip_entities()` har också utgått.

### `is_admin_site` argument till `django.contrib.auth.views.password_reset()`

Det är ett gammalt alternativ som inte längre borde vara nödvändigt.

### `UnderfältBas`

`django.db.models.fields.subclassing.SubfieldBase` har blivit föråldrad och kommer att tas bort i Django 1.10. Historiskt sett användes det för att hantera fält där typkonvertering behövdes vid laddning från databasen, men det användes inte i `.values()`-anrop eller i aggregat. Det har ersatts med [`from_db_value()`](/sv/6.1/ref/models/fields/#django.db.models.Field.from_db_value).

Det nya tillvägagångssättet anropar inte [`to_python()`](/sv/6.1/ref/models/fields/#django.db.models.Field.to_python)-metoden vid tilldelning som var fallet med `SubfieldBase`. Om du behöver det beteendet, återimplementera klassen `Creator` från Djangos källkod \<<https://github.com/django/django/blob/stable/1.8.x/django/db/models/fields/subclassing.py#L31-L44>\>\` i ditt projekt.

### `django.utils.checksums`

Modulen `django.utils.checksums` har blivit föråldrad och kommer att tas bort i Django 1.10. Funktionaliteten som den tillhandahöll (validering av kontrollsumma med Luhn-algoritmen) var odokumenterad och användes inte i Django. Modulen har flyttats till paketet [django-localflavor](https://pypi.org/project/django-localflavor/) (version 1.1+).

### `InlineAdminForm.original_content_type_id`

Attributet `original_content_type_id` på `InlineAdminForm` har blivit föråldrat och kommer att tas bort i Django 1.10. Historiskt sett användes det för att konstruera URL:en ”view on site”. Denna URL är nu tillgänglig med hjälp av attributet `absolute_url` i formuläret.

### `django.views.generic.edit.FormMixin.get_form()`’s `form_class` argument

`FormMixin` subklasser som åsidosätter `get_form()` metoden bör se till att tillhandahålla ett standardvärde för `form_class` argumentet eftersom det nu är valfritt.

### Rendering templates loaded by [`get_template()`](/sv/6.1/topics/templates/#django.template.loader.get_template) with a [`Context`](/sv/6.1/ref/templates/api/#django.template.Context)

The return type of [`get_template()`](/sv/6.1/topics/templates/#django.template.loader.get_template) has changed
in Django 1.8: instead of a [`django.template.Template`](/sv/6.1/ref/templates/api/#django.template.Template), it returns a
`Template` instance whose exact type depends on which backend loaded it.

Båda klasserna tillhandahåller en `render()`-metod, men den förra tar en [`django.template.Context`](/sv/6.1/ref/templates/api/#django.template.Context) som argument medan den senare förväntar sig en [`dict`](https://docs.python.org/3/library/stdtypes.html#dict). Denna ändring verkställs genom en deprecation path för Django-mallar.

All this also applies to [`select_template()`](/sv/6.1/topics/templates/#django.template.loader.select_template).

### [`Template`](/sv/6.1/ref/templates/api/#django.template.Template) och [`Context`](/sv/6.1/ref/templates/api/#django.template.Context) klasser i mallsvar

Vissa metoder i [`SimpleTemplateResponse`](/sv/6.1/ref/template-response/#django.template.response.SimpleTemplateResponse) och [`TemplateResponse`](/sv/6.1/ref/template-response/#django.template.response.TemplateResponse) accepterade [`django.template.Context`](/sv/6.1/ref/templates/api/#django.template.Context) och [`django.template.Template`](/sv/6.1/ref/templates/api/#django.template.Template) objekt som argument. De bör nu ta emot [`dict`](https://docs.python.org/3/library/stdtypes.html#dict) respektive backend-beroende mallobjekt.

Detta gäller även för returtyperna om du har underklassat någon av mallsvarsklasserna.

Kontrollera [template response API-dokumentation](/sv/6.1/ref/template-response/) för detaljer.

### argumentet `aktuell_app` för mallrelaterade API:er

Följande funktioner och klasser kommer inte längre att acceptera en `current_app` parameter för att ställa in ett URL-namnområde i Django 1.10:

- `django.shortcuts.render()`
- `django.template.Context()`
- `django.template.RequestContext()`
- `django.template.response.TemplateResponse()` \`\`

Ställ in `request.current_app` istället, där `request` är det första argumentet till dessa funktioner eller klasser. Om du använder en vanlig `Context`, använd en `RequestContext` istället.

### argumenten `dictionary` och `context_instance` i renderingsfunktioner

Följande funktioner kommer inte längre att acceptera parametrarna `dictionary` och `context_instance` i Django 1.10:

- `django.shortcuts.render()`
- `django.shortcuts.render_to_response()`
- `django.template.loader.render_to_string()`

Använd parametern `context` istället. När `dictionary` skickas som ett positionellt argument, vilket är det vanligaste idiomet, behövs inga ändringar.

Om du skickar en [`Context`](/sv/6.1/ref/templates/api/#django.template.Context) i `context_instance`, skicka en [`dict`](https://docs.python.org/3/library/stdtypes.html#dict) i `context` parametern istället. Om du skickar en [`RequestContext`](/sv/6.1/ref/templates/api/#django.template.RequestContext), skicka begäran separat i parametern `request`.

### `dirs`-argument för funktioner för att hitta mallar

Följande funktioner kommer inte längre att acceptera en `dirs` parameter för att åsidosätta `TEMPLATE_DIRS` i Django 1.10:

- [`django.template.loader.get_template()`](/sv/6.1/topics/templates/#django.template.loader.get_template)
- [`django.template.loader.select_template()`](/sv/6.1/topics/templates/#django.template.loader.select_template)
- [`django.shortcuts.render()`](/sv/6.1/topics/http/shortcuts/#django.shortcuts.render)
- `django.shortcuts.render_to_response()`

Parametern fungerade inte konsekvent mellan olika mallinläsare och fungerade inte för inkluderade mallar.

### `django.template.loader.BaseLoader`

`django.template.loader.BaseLoader` döptes om till `django.template.loaders.base.Loader`. Om du har skrivit en anpassad mallladdare som ärver `BaseLoader` måste du ärva `Loader` istället.

### `django.test.utils.TestTemplateLoader`

Privata API `django.test.utils.TestTemplateLoader` är föråldrat till förmån för `django.template.loaders.locmem.Loader` och kommer att tas bort i Django 1.9.

### Stöd för argumentet `max_length` i anpassade `Storage`-klasser

`Storage` subklasser bör lägga till `max_length=None` som en parameter till [`get_available_name()`](/sv/6.1/ref/files/storage/#django.core.files.storage.Storage.get_available_name) och/eller [`save()`](/sv/6.1/ref/files/storage/#django.core.files.storage.Storage.save) om de åsidosätter någon av metoderna. Stöd för lagringsenheter som inte accepterar detta argument kommer att tas bort i Django 1.10.

### `qn` ersatt av `compiler`

I tidigare Django-versioner accepterade olika interna ORM-metoder (mestadels `as_sql`-metoder) ett `qn`-argument (för ”citatnamn”), vilket var en referens till en funktion som citerade identifierare för att skicka till databasen. I Django 1.8 har det argumentet bytt namn till `compiler` och är nu en fullständig `SQLCompiler`-instans. För bakåtkompatibilitet utför anrop av en `SQLCompiler`-instans samma namnkvot som `qn`-funktionen brukade göra. Denna bakåtkompatibilitets-shim är dock omedelbart föråldrad: du bör byta namn på dina `qn`-argument till `compiler` och anropa compiler.quote\_name\_unless\_alias(…) \`\` där du tidigare kallade qn(…) .

### Standardvärde för `RedirectView.permanent`

Standardvärdet för attributet [`RedirectView.permanent`](/sv/6.1/ref/class-based-views/base/#django.views.generic.base.RedirectView.permanent) kommer att ändras från `True` till `False` i Django 1.9.

### Använda `AuthenticationMiddleware` utan `SessionAuthenticationMiddleware`

`django.contrib.auth.middleware.SessionAuthenticationMiddleware` lades till i Django 1.7. I Django 1.7.2 flyttades dess funktionalitet till `auth.get_user()` och, för bakåtkompatibilitet, aktiveras den endast om `'django.contrib.auth.middleware.SessionAuthenticationMiddleware'` finns i `MIDDLEWARE_CLASSES`.

I Django 1.10 kommer sessionsverifiering att aktiveras oavsett om `SessionAuthenticationMiddleware` är aktiverat eller inte (vid vilken tidpunkt `SessionAuthenticationMiddleware` inte kommer att ha någon betydelse). Du kan lägga till det i din `MIDDLEWARE_CLASSES` någon gång innan dess för att välja in. Läs [uppgraderingsöverväganden](/sv/6.1/topics/auth/default/#session-invalidation-on-password-change) först.

### `django.contrib.sitemaps.FlatPageSitemap`

`django.contrib.sitemaps.FlatPageSitemap` har flyttats till `django.contrib.flatpages.sitemaps.FlatPageSitemap`. Den gamla importplatsen är föråldrad och kommer att tas bort i Django 1.9.

### Modell `Field.related`

Private attribute `django.db.models.Field.related` is deprecated in favor
of `Field.rel`. The latter is an instance of
`django.db.models.fields.related.ForeignObjectRel` which replaces
`django.db.models.related.RelatedObject`. The `django.db.models.related`
module has been removed and the `Field.related` attribute will be removed in
Django 1.10.

### `ssi` mall tagg

Malltaggen `ssi` gör att filer kan inkluderas i en mall med absolut sökväg. Detta är av begränsad användning i de flesta distributionssituationer, och [`include`](/sv/6.1/ref/templates/builtins/#std-templatetag-include)-taggen är ofta mer meningsfull. Denna tagg är nu föråldrad och kommer att tas bort i Django 1.10.

### `=` som jämförelseoperator i `if` malltagg

Att använda ett enda likhetstecken med malltaggen `{% if %}` för jämlikhetstestning var odokumenterat och otestat. Det är nu föråldrat till förmån för `==`.

### `%(<foo>)s` syntax i `ModelFormMixin.success_url`

Den äldre syntaxen `%(<foo>)s` i [`ModelFormMixin.success_url`](/sv/6.1/ref/class-based-views/mixins-editing/#django.views.generic.edit.ModelFormMixin.success_url) är föråldrad och kommer att tas bort i Django 1.10.

### aggregerade metoder för `GeoQuerySet`

Aggregatmetoderna `collect()`, `extent()`, `extent3d()`, `make_line()` och `unionagg()` är föråldrade och bör ersättas av sina funktionsbaserade aggregatmotsvarigheter (`Collect`, `Extent`, `Extent3D`, `MakeLine` och `Union`).

### Signatur för routermetoden ”allow\_migrate

Signaturen för metoden [`allow_migrate()`](/sv/6.1/topics/db/multi-db/#allow_migrate) för databasroutrar har ändrats från `allow_migrate(db, model)` till `allow_migrate(db, app_label, model_name=None, **hints)`.

När `model_name` är inställt kan det värde som tidigare gavs genom det positionella argumentet `model` nu hittas i ordlistan `hints` under nyckeln `'model'`.

Efter att ha bytt till den nya signaturen kommer routern också att anropas av operationerna [`RunPython`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython) och [`RunSQL`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL).

## Funktioner borttagna i 1.8

Dessa funktioner har nått slutet av sin utfasningscykel och tas bort i Django 1.8. Se [Funktioner som inte längre är aktuella i 1.6](/sv/6.1/releases/1.6/#deprecated-features-1-6) för detaljer, inklusive hur man tar bort användningen av dessa funktioner.

- `django.contrib.comments` är borttagen.
- Följande API:er för transaktionshantering har tagits bort:

  - `TransactionMiddleware`
  - dekoratorerna och kontexthanterarna `autocommit`, `commit_on_success` och `commit_manually`, definierade i `django.db.transaction`
  - funktionerna `commit_unless_managed` och `rollback_unless_managed`, som också definieras i `django.db.transaction`
  - inställningen `TRANSACTIONS_MANAGED`
- Malltaggarna [`cycle`](/sv/6.1/ref/templates/builtins/#std-templatetag-cycle) och [`firstof`](/sv/6.1/ref/templates/builtins/#std-templatetag-firstof) skriver ut sina argument automatiskt.
- Inställningen `SEND_BROKEN_LINK_EMAILS` har tagits bort.
- `django.middleware.doc.XViewMiddleware` tas bort.
- Aliaset `Model._meta.module_name` har tagits bort.
- De bakåtkompatibla shims som infördes för att byta namn på `get_query_set` och liknande queryset-metoder tas bort. Detta påverkar följande klasser: `BaseModelAdmin`, `ChangeList`, `BaseCommentNode`, `GenericForeignKey`, `Manager`, `SingleRelatedObjectDescriptor` och `ReverseSingleRelatedObjectDescriptor`.
- De bakåtkompatibla shims som infördes för att byta namn på attributen `ChangeList.root_query_set` och `ChangeList.query_set` tas bort.
- `django.views.defaults.shortcut` och `django.conf.urls.shortcut` tas bort.
- Stöd för modulen Python Imaging Library (PIL) har tagits bort.
- Följande privata API:er har tagits bort:

  - `django.db.backend`
  - `django.db.close_connection()`
  - `django.db.backends.creation.BaseDatabaseCreation.set_autocommit()`
  - `django.db.transaction.is_managed()` \`\`
  - `django.db.transaction.managed()`
- `django.forms.widgets.RadioInput` tas bort.
- Modulen `django.test.simple` och klassen `django.test.simple.DjangoTestSuiteRunner` tas bort.
- Modulen `django.test._doctest` har tagits bort.
- Inställningen `CACHE_MIDDLEWARE_ANONYMOUS_ONLY` tas bort. Denna ändring påverkar både `django.middleware.cache.CacheMiddleware` och `django.middleware.cache.UpdateCacheMiddleware` trots avsaknaden av en varning för avskrivning i den senare klassen.
- Usage of the hardcoded *Hold down ”Control”, or ”Command” on a Mac, to select
  more than one.* string to override or append to user-provided `help_text`
  in forms for `ManyToMany` model fields is not performed by Django anymore
  either at the model or forms layer.
- Metoderna `Model._meta.get_(add|change|delete)_permission` har tagits bort.
- Sessionsnyckeln `django_language` läses inte längre av bakåtkompatibilitetsskäl.
- Geografiska webbplatskartor har tagits bort (`django.contrib.gis.sitemaps.views.index` och `django.contrib.gis.sitemaps.views.sitemap`).
- `django.utils.html.fix_ampersands`, mallfiltret `fix_ampersands` och `django.utils.html.clean_html` tas bort.