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

*2 september 2014*

Välkommen till Django 1.7!

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

## Kompatibilitet med Python

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

Django 1.6-serien är den sista som stödjer Python 2.6. Django 1.7 är den första utgåvan som stöder Python 3.4.

Denna förändring bör endast påverka ett litet antal Django-användare, eftersom de flesta leverantörer av operativsystem idag levererar Python 2.7 eller nyare som standardversion. Om du fortfarande använder Python 2.6 måste du dock hålla dig till Django 1.6 tills du kan uppgradera din Python-version. Enligt [vår supportpolicy](/sv/6.1/internals/release-process/) kommer Django 1.6 att fortsätta att få säkerhetsstöd fram till lanseringen av Django 1.8.

## Vad är nytt i Django 1.7

### Migrering av scheman

Django har nu inbyggt stöd för schemamigreringar. Det gör att modeller kan uppdateras, ändras och raderas genom att skapa migreringsfiler som representerar modelländringarna och som kan köras på vilken utvecklings-, staging- eller produktionsdatabas som helst.

Migreringar behandlas i [deras egen dokumentation](/sv/6.1/topics/migrations/), men några av de viktigaste funktionerna är:

- `syncdb` har utgått och ersatts av `migrate`. Oroa dig inte - anrop till `syncdb` kommer fortfarande att fungera som tidigare.
- Det nya kommandot ”Makemigrations” gör det enkelt att automatiskt upptäcka ändringar i dina modeller och göra migreringar för dem.

  `django.db.models.signals.pre_syncdb` och `django.db.models.signals.post_syncdb` har utgått och ersatts av [`pre_migrate`](/sv/6.1/ref/signals/#django.db.models.signals.pre_migrate) respektive [`post_migrate`](/sv/6.1/ref/signals/#django.db.models.signals.post_migrate). Dessa nya signaler har något annorlunda argument. Kontrollera dokumentationen för detaljer.
- Metoden `allow_syncdb` på databasroutrar kallas nu `allow_migrate`, men utför fortfarande samma funktion. Routrar med `allow_syncdb`-metoder kommer fortfarande att fungera, men det metodnamnet är föråldrat och du bör ändra det så snart som möjligt (inget mer än att byta namn krävs).
- `initial_data` fixturer laddas inte längre för appar med migreringar; om du vill ladda initiala data för en app föreslår vi att du skapar en migrering för din applikation och definierar en [`RunPython`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunPython) eller [`RunSQL`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL) operation i avsnittet `operations` i migreringen.
- Testets rollback-beteende är annorlunda för appar med migreringar; i synnerhet kommer Django inte längre att emulera rollbacks på icke-transaktionsdatabaser eller inuti `TransactionTestCase` [om inte specifikt begärts](/sv/6.1/topics/testing/overview/#test-case-serialized-rollback).
- Det är inte rekommenderat att låta appar utan migreringar vara beroende av (ha en [`ForeignKey`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey) eller [`ManyToManyField`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField) till) appar med migreringar.

### Refaktor för app-laddning

Historiskt sett var Django-applikationer tätt kopplade till modeller. En singleton som kallas ”app cache” hanterade både installerade applikationer och modeller. Modulen models användes som en identifierare för applikationer i många API:er.

När konceptet med [Django-applikationer](/sv/6.1/ref/applications/) mognade visade den här koden vissa brister. Den har omarbetats till ett ”app-register” där modellmoduler inte längre har en central roll och där det är möjligt att bifoga konfigurationsdata till applikationer.

Förbättringarna hittills inkluderar:

- Program kan köra kod vid start, innan Django gör något annat, med [`ready()`](/sv/6.1/ref/applications/#django.apps.AppConfig.ready)-metoden i deras konfiguration.
- Applikationsetiketter tilldelas korrekt till modeller även när de definieras utanför `models.py`. Du behöver inte längre ange [`app_label`](/sv/6.1/ref/models/options/#django.db.models.Options.app_label) uttryckligen.
- Det är möjligt att helt utelämna `models.py` om en applikation inte har några modeller.
- Applikationer kan märkas om med attributet [`label`](/sv/6.1/ref/applications/#django.apps.AppConfig.label) i applikationskonfigurationer, för att komma runt etikettkonflikter.
- Namnet på applikationer kan anpassas i administratören med [`verbose_name`](/sv/6.1/ref/applications/#django.apps.AppConfig.verbose_name) i applikationskonfigurationer.
- The admin automatically calls [`autodiscover()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.autodiscover)
  when Django starts. You can consequently remove this line from your
  URLconf.
- Django importerar alla applikationskonfigurationer och modeller så snart den startar, genom en deterministisk och okomplicerad process. Detta bör göra det lättare att diagnostisera importproblem som t.ex. importloopar.

### Ny metod för fältunderklasser

För att underlätta både schemamigreringar och för att göra det enklare att lägga till sammansatta nycklar i framtida versioner av Django har API:et [`Field`](/sv/6.1/ref/models/fields/#django.db.models.Field) nu en ny obligatorisk metod: `deconstruct()`.

Denna metod tar inga argument och returnerar en tupel med fyra objekt:

- `namn`: Fältets attributnamn i dess överordnade modell, eller `None` om det inte är en del av en modell
- `Sökväg`: En prickad Python-sökväg till klassen för detta fält, inklusive klassnamnet.
- `args`: Positionella argument, som en lista
- `kwargs`: Nyckelordets argument, som en dikt

Dessa fyra värden gör att alla fält kan serialiseras till en fil och att fältet kan kopieras på ett säkert sätt, vilket är två viktiga delar av dessa nya funktioner.

Denna ändring bör inte påverka dig om du inte skriver anpassade Field-subklasser; om du gör det kan du behöva omimplementera metoden `deconstruct()` om din subklass ändrar metodsignaturen för `__init__` på något sätt. Om ditt fält bara ärver från ett inbyggt Django-fält och inte åsidosätter `__init__`, behövs inga ändringar.

Om du behöver åsidosätta `deconstruct()` är ett bra ställe att börja med de inbyggda Django-fälten (`django/db/models/fields/__init__.py`) eftersom flera fält, inklusive `DecimalField` och `DateField`, åsidosätter det och visar hur man anropar metoden på superklassen och helt enkelt lägger till eller tar bort extra argument.

Detta innebär också att alla argument till fält själva måste vara serialiserbara; för att se vad vi anser vara serialiserbart, och för att ta reda på hur du gör dina egna klasser serialiserbara, läs [migration serialization documentation](/sv/6.1/topics/migrations/#migration-serializing).

### Anropa anpassade metoder för `QuerySet` från `Manager`

Historiskt sett var det rekommenderade sättet att skapa återanvändbara modellfrågor att skapa metoder för en anpassad `Manager`-klass. Problemet med detta tillvägagångssätt var att efter det första metodanropet fick du tillbaka en `QuerySet`-instans och kunde inte anropa ytterligare anpassade managermetoder.

Även om det inte finns dokumenterat var det vanligt att man kringgick problemet genom att skapa ett eget `QuerySet` så att egna metoder kunde kedjas, men lösningen hade ett antal nackdelar:

- Den anpassade `QuerySet` och dess anpassade metoder försvann efter det första anropet till `values()` eller `values_list()`.
- Att skriva en anpassad `Manager` var fortfarande nödvändigt för att returnera den anpassade `QuerySet`-klassen och alla metoder som önskades på `Manager` var tvungna att proxies till `QuerySet`. Hela processen gick emot DRY-principen.

Klassmetoden [`QuerySet.as_manager()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.as_manager) kan nu direkt [skapa Manager med QuerySet-metoder](/sv/6.1/topics/db/managers/#create-manager-with-queryset-methods):

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

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

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

Food.objects.pizzas().vegetarian()
```

### Använda en anpassad manager vid traversing av omvända relationer

Det är nu möjligt att [specificera en anpassad chef](/sv/6.1/topics/db/queries/#using-custom-reverse-manager) när man går igenom en omvänd relation:

```
class Blog(models.Model):
    pass

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

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

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

### Nytt ramverk för systemkontroll

Vi har lagt till en ny [Systemkontrollramverk](/sv/6.1/ref/checks/) för att upptäcka vanliga problem (som ogiltiga modeller) och ge tips för att lösa dessa problem. Ramverket är utbyggbart så att du kan lägga till dina egna kontroller för dina egna appar och bibliotek.

För att utföra systemkontroller använder du hanteringskommandot [`check`](/sv/6.1/ref/django-admin/#django-admin-check). Detta kommando ersätter det äldre kommandot `validate`.

### Nytt `Prefetch`-objekt för avancerade `prefetch_related`-operationer.

Det nya [`Prefetch`](/sv/6.1/ref/models/querysets/#django.db.models.Prefetch)-objektet gör det möjligt att anpassa prefetch-operationer.

Du kan ange den `QuerySet` som används för att traversera en viss relation eller anpassa lagringsplatsen för prefetch-resultat.

This enables things like filtering prefetched relations, calling
[`select_related()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.select_related) from a prefetched
relation, or prefetching the same relation multiple times with different
querysets. See [`prefetch_related()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.prefetch_related)
for more details.

### Snabbkommandon för administratörer stöder tidszoner

Genvägarna ”today” och ”now” bredvid inmatningswidgets för datum och tid i admin fungerar nu i [aktuell tidszon](/sv/6.1/topics/i18n/timezones/#default-current-time-zone). Tidigare använde de webbläsarens tidszon, vilket kunde resultera i att fel värde sparades när det inte stämde överens med den aktuella tidszonen på servern.

Dessutom visar widgetarna nu ett hjälpmeddelande när webbläsarens och serverns tidszon skiljer sig åt, för att klargöra hur det värde som anges i fältet ska tolkas.

### Använda databasmarkörer som kontexthanterare

Före Python 2.7 kunde databasmarkörer användas som kontexthanterare. Den specifika backend-markören definierade beteendet hos kontexthanteraren. Beteendet för magiska metoduppslagningar ändrades med Python 2.7 och markörer var inte längre användbara som kontexthanterare.

Django 1.7 tillåter att en markör används som en kontexthanterare. Det vill säga, följande kan användas:

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

istället för:

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

### Anpassade uppslagningar

Det är nu möjligt att skriva egna lookups och transforms för ORM. Anpassade lookups fungerar precis som Djangos inbyggda lookups (t.ex. `lte`, `icontains`) medan transforms är ett nytt koncept.

Klassen [`django.db.models.Lookup`](/sv/6.1/ref/models/lookups/#django.db.models.Lookup) ger ett sätt att lägga till uppslagsoperatorer för modellfält. Som ett exempel är det möjligt att lägga till operatorn `day_lte` för `DateFields`.

Klassen [`django.db.models.Transform`](/sv/6.1/ref/models/lookups/#django.db.models.Transform) tillåter transformationer av databasvärden före den slutliga uppslagningen. Det är till exempel möjligt att skriva en `year`-transform som extraherar år från fältets värde. Transformationer tillåter kedjning. Efter att `year`-transformationen har lagts till i `DateField` är det möjligt att filtrera på det transformerade värdet, till exempel `qs.filter(author__birthdate__year__lte=1981)`.

Mer information om både anpassade lookups och transformationer finns i dokumentationen [custom lookups](/sv/6.1/howto/custom-lookups/).

### Förbättringar av felhanteringen för `Form`

#### `Form.add_error()`

Tidigare fanns det två huvudmönster för att hantera fel i formulär:

- Reser en [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) från inom vissa funktioner (t.ex. `Field.clean()`, `Form.clean_<fieldname>()`, eller `Form.clean()` för icke-fältfel.)
- Fifflande med `Form._errors` när man riktar in sig på ett specifikt fält i `Form.clean()` eller lägger till fel från utanför en ”clean”-metod (t.ex. direkt från en vy).

Att använda det förra mönstret var enkelt eftersom formuläret kan gissa från sammanhanget (dvs. vilken metod som gav upphov till undantaget) var felen hör hemma och automatiskt bearbeta dem. Detta är fortfarande det kanoniska sättet att lägga till fel när det är möjligt. Det senare var dock krångligt och felbenäget, eftersom bördan av att hantera kantfall föll på användaren.

The new [`add_error()`](/sv/6.1/ref/forms/api/#django.forms.Form.add_error) method allows adding errors
to specific form fields from anywhere without having to worry about the details
such as creating instances of `django.forms.utils.ErrorList` or dealing with
`Form.cleaned_data`. This new API replaces manipulating `Form._errors`
which now becomes a private API.

Se [Rengöring och validering av fält som är beroende av varandra](/sv/6.1/ref/forms/validation/#validating-fields-with-clean) för ett exempel där man använder `Form.add_error()`.

#### Metadata om fel

Konstruktören [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) accepterar metadata som felets `code` eller `params` som sedan är tillgängliga för interpolering i felmeddelandet (se [Upphävande av ValidationError](/sv/6.1/ref/forms/validation/#raising-validation-error) för mer information); före Django 1.7 kasserades dock dessa metadata så snart felen lades till i [`Form.errors`](/sv/6.1/ref/forms/api/#django.forms.Form.errors).

[`Form.errors`](/sv/6.1/ref/forms/api/#django.forms.Form.errors) och `django.forms.utils.ErrorList` lagrar nu `ValidationError`-instanser så att dessa metadata kan hämtas när som helst via den nya [`Form.errors.as_data`](/sv/6.1/ref/forms/api/#django.forms.Form.errors.as_data)-metoden.

De hämtade `ValidationError`-instanserna kan sedan identifieras tack vare deras fel `code` vilket möjliggör saker som att skriva om felmeddelandet eller skriva anpassad logik i en vy när ett visst fel finns. Det kan också användas för att serialisera felen i ett anpassat format, t.ex. XML.

Den nya metoden [`Form.errors.as_json()`](/sv/6.1/ref/forms/api/#django.forms.Form.errors.as_json) är en bekvämlighetsmetod som returnerar felmeddelanden tillsammans med felkoder serialiserade som JSON. `as_json()` använder `as_data()` och ger en idé om hur det nya systemet kan utökas.

#### Felbehållare och bakåtkompatibilitet

Stora förändringar av de olika felbehållarna var nödvändiga för att stödja funktionerna ovan, särskilt [`Form.errors`](/sv/6.1/ref/forms/api/#django.forms.Form.errors), `django.forms.utils.ErrorList` och de interna lagren av [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError). Dessa behållare som tidigare lagrade felsträngar lagrar nu `ValidationError`-instanser och offentliga API:er har anpassats för att göra detta så transparent som möjligt, men om du har använt privata API:er är vissa av ändringarna bakåtkompatibla; se [ValidationError konstruktör och intern lagring](#validation-error-constructor-and-internal-storage) för mer information.

### Mindre funktioner

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

- Du kan nu implementera attributen [`site_header`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.site_header), [`site_title`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.site_title) och [`index_title`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite.index_title) på en anpassad [`AdminSite`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.AdminSite) för att enkelt kunna ändra adminwebbplatsens sidtitel och rubriktext. Inget mer behov av att åsidosätta mallar!
- Knappar i [`django.contrib.admin`](/sv/6.1/ref/contrib/admin/#module-django.contrib.admin) använder nu CSS-egenskapen `border-radius` för rundade hörn i stället för GIF-bakgrundsbilder.
- Vissa adminmallar har nu klasserna `app-<app_name>` och `model-<model_name>` i taggen `<body>` för att göra det möjligt att anpassa CSS per app eller per modell.
- Cellerna i adminändringslistan har nu en `field-<field_name>`-klass i HTML för att möjliggöra stilanpassningar.
- Administratörens sökfält kan nu anpassas per begäran tack vare den nya metoden [`django.contrib.admin.ModelAdmin.get_search_fields()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_search_fields).
- Metoden [`ModelAdmin.get_fields()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_fields) kan åsidosättas för att anpassa värdet på [`ModelAdmin.fields`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.fields).
- Förutom den befintliga syntaxen `admin.site.register` kan du använda den nya [`register()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.register)-dekoratorn för att registrera en [`ModelAdmin`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin).
- Du kan ange [`ModelAdmin.list_display_links`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display_links) `= None` för att inaktivera länkar i rutnätet på sidan med ändringslistan.
- Du kan nu ange [`ModelAdmin.view_on_site`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.view_on_site) för att styra om länken ”Visa på webbplatsen” ska visas eller inte.
- Du kan ange en fallande ordning för ett [`ModelAdmin.list_display`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display)-värde genom att prefixera `admin_order_field`-värdet med ett bindestreck.
- Metoden [`ModelAdmin.get_changeform_initial_data()`](/sv/6.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_changeform_initial_data) kan åsidosättas för att definiera anpassat beteende för att ställa in initiala ändringsformulärdata.

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

- Any `**kwargs` passed to
  [`email_user()`](/sv/6.1/ref/contrib/auth/#django.contrib.auth.models.User.email_user) are passed to the
  underlying [`send_mail()`](/sv/6.1/topics/email/#django.core.mail.send_mail) call.
- Dekoratorn [`permission_required()`](/sv/6.1/topics/auth/default/#django.contrib.auth.decorators.permission_required) kan ta en lista med behörigheter såväl som en enda behörighet.
- Du kan åsidosätta den nya [`AuthenticationForm.confirm_login_allowed()`](/sv/6.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm.confirm_login_allowed)-metoden för att lättare anpassa inloggningspolicyn.
- `django.contrib.auth.views.password_reset()` tar en valfri `html_email_template_name` parameter som används för att skicka ett HTML-e-postmeddelande i flera delar för återställning av lösenord.
- Metoden [`AbstractBaseUser.get_session_auth_hash()`](/sv/6.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash) lades till och om din [`AUTH_USER_MODEL`](/sv/6.1/ref/settings/#std-setting-AUTH_USER_MODEL) ärver från [`AbstractBaseUser`](/sv/6.1/topics/auth/customizing/#django.contrib.auth.models.AbstractBaseUser), ogiltigförklarar ändring av en användares lösenord nu gamla sessioner om `django.contrib.auth.middleware.SessionAuthenticationMiddleware` är aktiverat. Se [Inaktivering av session vid byte av lösenord](/sv/6.1/topics/auth/default/#session-invalidation-on-password-change) för mer information.

#### `django.contrib.formtools`

- Anrop till `WizardView.done()` inkluderar nu en `form_dict` för att göra det lättare att komma åt formulär genom deras stegnamn.

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

- Standardversionen av OpenLayers-biblioteket som ingår i widgetar har uppdaterats från 2.11 till 2.13.
- Förberedda geometrier stöder nu även predikaten `korsningar`, `disjunkt`, `överlappningar`, `touches` och `inom`, om GEOS 3.3 eller senare är installerat.

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

- Backends för [`django.contrib.messages`](/sv/6.1/ref/contrib/messages/#module-django.contrib.messages) som använder cookies, kommer nu att följa inställningarna [`SESSION_COOKIE_SECURE`](/sv/6.1/ref/settings/#std-setting-SESSION_COOKIE_SECURE) och [`SESSION_COOKIE_HTTPONLY`](/sv/6.1/ref/settings/#std-setting-SESSION_COOKIE_HTTPONLY).
- Kontextprocessorn [messages](/sv/6.1/ref/contrib/messages/#message-displaying) lägger nu till en ordlista med standardnivåer under namnet `DEFAULT_MESSAGE_LEVELS`.
- [`Message`](/sv/6.1/ref/contrib/messages/#django.contrib.messages.Message)-objekt har nu ett `level_tag`-attribut som innehåller strängrepresentationen av meddelandenivån.

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

- [`RedirectFallbackMiddleware`](/sv/6.1/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware) har två nya attribut ([`response_gone_class`](/sv/6.1/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_gone_class) och [`response_redirect_class`](/sv/6.1/ref/contrib/redirects/#django.contrib.redirects.middleware.RedirectFallbackMiddleware.response_redirect_class)) som anger vilka typer av [`HttpResponse`](/sv/6.1/ref/request-response/#django.http.HttpResponse)-instanser som middlewaren returnerar.

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

- Sessionsbackend `"django.contrib.sessions.backends.cached_db"` respekterar nu [`SESSION_CACHE_ALIAS`](/sv/6.1/ref/settings/#std-setting-SESSION_CACHE_ALIAS). I tidigare versioner använde den alltid `standard`-cachen.

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

- Ramverket `` sitemap<django.contrib.sitemaps>` `` använder nu `` lastmod` `` för att ställa in en `Last-Modified` header i svaret. Detta gör det möjligt för [`ConditionalGetMiddleware`](/sv/6.1/ref/middleware/#django.middleware.http.ConditionalGetMiddleware) att hantera villkorliga `GET`-begäranden för sitemaps som anger `lastmod`.

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

- Den nya [`django.contrib.sites.middleware.CurrentSiteMiddleware`](/sv/6.1/ref/middleware/#django.contrib.sites.middleware.CurrentSiteMiddleware) gör det möjligt att ställa in den aktuella webbplatsen vid varje förfrågan.

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

- Klassen [static files storage classes](/sv/6.1/ref/contrib/staticfiles/#staticfiles-storages) kan underklassas för att åsidosätta de behörigheter som insamlade statiska filer och kataloger får genom att ange parametrarna [`file_permissions_mode`](/sv/6.1/ref/files/storage/#django.core.files.storage.FileSystemStorage.file_permissions_mode) och [`directory_permissions_mode`](/sv/6.1/ref/files/storage/#django.core.files.storage.FileSystemStorage.directory_permissions_mode). Se [`collectstatic`](/sv/6.1/ref/contrib/staticfiles/#django-admin-collectstatic) för exempel på användning.
- Backend `CachedStaticFilesStorage` får en syskonklass som heter `` ManifestStaticFilesStorage` `` som inte använder cachesystemet alls utan istället en JSON-fil som heter `staticfiles.json` för att lagra mappningen mellan det ursprungliga filnamnet (t.ex. `css/styles.css`) och det hashade filnamnet (t.ex. `css/styles.55e7cbb9ba48.css`). Filen `staticfiles.json` skapas när man kör hanteringskommandot [`collectstatic`](/sv/6.1/ref/contrib/staticfiles/#django-admin-collectstatic) och bör vara ett billigare alternativ för fjärrlagring som Amazon S3.

  Se [`ManifestStaticFilesStorage`](/sv/6.1/ref/contrib/staticfiles/#django.contrib.staticfiles.storage.ManifestStaticFilesStorage)-dokumenten för mer information.
- [`findstatic`](/sv/6.1/ref/contrib/staticfiles/#django-admin-findstatic) accepterar nu verbosity flaggnivå 2, vilket innebär att den kommer att visa de relativa sökvägarna till de kataloger den sökte i. Se [`findstatic`](/sv/6.1/ref/contrib/staticfiles/#django-admin-findstatic) för exempel på utdata.

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

- Syndikeringsflödets `updated`-element i [`Atom1Feed`](/sv/6.1/ref/utils/#django.utils.feedgenerator.Atom1Feed) använder nu `updateddate` istället för `pubdate`, vilket gör att `published`-elementet kan inkluderas i flödet (som förlitar sig på `pubdate`).

#### Cache

- Åtkomst till cacher som konfigurerats i [`CACHES`](/sv/6.1/ref/settings/#std-setting-CACHES) är nu tillgänglig via [`django.core.cache.caches`](/sv/6.1/topics/cache/#django.core.cache.caches). Detta diktliknande objekt tillhandahåller en annan instans per tråd. Det ersätter `django.core.cache.get_cache()` som nu är föråldrat.
- Om du instansierar cache backends direkt, var medveten om att de inte är tråd-säkra längre, eftersom [`django.core.cache.caches`](/sv/6.1/topics/cache/#django.core.cache.caches) nu ger olika instanser per tråd.
- Om argumentet [`TIMEOUT`](/sv/6.1/ref/settings/#std-setting-CACHES-TIMEOUT) i inställningen [`CACHES`](/sv/6.1/ref/settings/#std-setting-CACHES) anges som `None` kommer cache-nycklarna att anges som ”non-expiring” som standard. Tidigare var det bara möjligt att skicka `timeout=None` till cachebackendets `set()`-metod.

#### Cross Site Request Forgery

- Inställningen [`CSRF_COOKIE_AGE`](/sv/6.1/ref/settings/#std-setting-CSRF_COOKIE_AGE) underlättar användningen av sessionsbaserade CSRF-cookies.

#### E-postadress

- [`send_mail()`](/sv/6.1/topics/email/#django.core.mail.send_mail) accepterar nu en `html_message` parameter för att skicka ett flerdelat `text/plain` och `text/html` e-postmeddelande.
- The [SMTP EmailBackend](/sv/6.1/topics/email/#topic-email-smtp-backend) now accepts a
  `timeout` parameter.

#### Fil delning

- Fillåsning i Windows var tidigare beroende av paketet PyWin32; om det inte var installerat misslyckades fillåsningen i tysthet. Det beroendet har tagits bort och fillåsning implementeras nu inbyggt i både Windows och Unix.

#### Filuppladdning

- Det nya attributet [`UploadedFile.content_type_extra`](/sv/6.1/ref/files/uploads/#django.core.files.uploadedfile.UploadedFile.content_type_extra) innehåller extra parametrar som skickas till rubriken `content-type` på en filuppladdning.
- Den nya inställningen [`FILE_UPLOAD_DIRECTORY_PERMISSIONS`](/sv/6.1/ref/settings/#std-setting-FILE_UPLOAD_DIRECTORY_PERMISSIONS) styr filsystembehörigheterna för kataloger som skapas under filuppladdning, på samma sätt som [`FILE_UPLOAD_PERMISSIONS`](/sv/6.1/ref/settings/#std-setting-FILE_UPLOAD_PERMISSIONS) gör för själva filerna.
- Attributet [`FileField.upload_to`](/sv/6.1/ref/models/fields/#django.db.models.FileField.upload_to) är nu valfritt. Om det utelämnas eller ges `None` eller en tom sträng, kommer en underkatalog inte att användas för att lagra de uppladdade filerna.
- Uppladdade filer stängs nu uttryckligen innan svaret levereras till klienten. Delvis uppladdade filer stängs också så länge de har namnet `file` i uppladdningshanteraren.
- [`Storage.get_available_name()`](/sv/6.1/ref/files/storage/#django.core.files.storage.Storage.get_available_name) lägger nu till ett understreck plus en slumpmässig alfanumerisk sträng med 7 tecken (t.ex. `"_x3a1gho"`), snarare än att iterera genom ett understreck följt av ett nummer (t.ex. `"_1"`, `"_2"`, etc.) för att förhindra en överbelastningsattack. Den här ändringen gjordes även i säkerhetsversionerna 1.6.6, 1.5.9 och 1.4.14.

#### Formulär

- Taggarna `<label>` och `<input>` som återges av [`RadioSelect`](/sv/6.1/ref/forms/widgets/#django.forms.RadioSelect) och [`CheckboxSelectMultiple`](/sv/6.1/ref/forms/widgets/#django.forms.CheckboxSelectMultiple) när de loopar över radioknapparna eller kryssrutorna innehåller nu attributen `for` respektive `id`. Varje radioknapp eller kryssruta innehåller ett `id_for_label`-attribut för att mata ut elementets ID.
- Taggarna `<textarea>` som återges av [`Textarea`](/sv/6.1/ref/forms/widgets/#django.forms.Textarea) innehåller nu ett attribut `maxlength` om modellfältet [`TextField`](/sv/6.1/ref/models/fields/#django.db.models.TextField) har en `max_length`.
- [`Field.choices`](/sv/6.1/ref/models/fields/#django.db.models.Field.choices) låter dig nu anpassa etiketten för ”tomt val” genom att inkludera en tupel med en tom sträng eller `None` för nyckeln och den anpassade etiketten som värde. Standardalternativet `"----------"` kommer att utelämnas i detta fall.
- [`MultiValueField`](/sv/6.1/ref/forms/fields/#django.forms.MultiValueField) tillåter valfria underfält genom att sätta argumentet `require_all_fields` till `False`. Attributet `required` för varje enskilt fält kommer att respekteras, och ett nytt valideringsfel `incomplete` kommer att uppstå när något av de obligatoriska fälten är tomt.
- Metoden [`clean()`](/sv/6.1/ref/forms/api/#django.forms.Form.clean) på ett formulär behöver inte längre returnera `self.cleaned_data`. Om den returnerar en ändrad ordbok kommer den fortfarande att användas.
- Efter en tillfällig regression i Django 1.6 är det nu möjligt igen att få [`TypedChoiceField`](/sv/6.1/ref/forms/fields/#django.forms.TypedChoiceField) `coerce`-metoden att returnera ett godtyckligt värde.
- [`SelectDateWidget.months`](/sv/6.1/ref/forms/widgets/#django.forms.SelectDateWidget.months) kan användas för att anpassa ordalydelsen för de månader som visas i Select Widget.
- Parametrarna `min_num` och `validate_min` lades till i [`formset_factory()`](/sv/6.1/ref/forms/formsets/#django.forms.formsets.formset_factory) för att möjliggöra validering av ett minsta antal inskickade formulär.
- De metaklasser som används av `Form` och `ModelForm` har omarbetats för att stödja fler arvsscenarier. Den tidigare begränsningen som förhindrade att man ärvde från både `Form` och `ModelForm` samtidigt har tagits bort så länge som `ModelForm` visas först i MRO.
- Det är nu möjligt att ta bort ett fält från en `Form` vid subklassning genom att ställa in namnet till `None`.
- Det är nu möjligt att anpassa felmeddelandena för `ModelForm` begränsningarna `unique`, `unique_for_date` och `unique_together`. För att stödja `unique_together` eller någon annan `NON_FIELD_ERROR`, letar `ModelForm` nu efter `NON_FIELD_ERROR` nyckeln i `error_messages` dictionariet i `ModelForm` inre `Meta` klass. Se [överväganden angående modellens error\_messages](/sv/6.1/topics/forms/modelforms/#considerations-regarding-model-errormessages) för mer information.

#### Internationalisering

- Med attributet [`django.middleware.locale.LocaleMiddleware.response_redirect_class`](/sv/6.1/ref/middleware/#django.middleware.locale.LocaleMiddleware.response_redirect_class) kan du anpassa de omdirigeringar som utfärdas av mellanvaran.
- Klassen:~django.middleware.locale.LocaleMiddleware lagrar nu användarens valda språk med sessionsnyckeln `_language`. Detta bör endast nås med hjälp av konstanten `LANGUAGE_SESSION_KEY`. Tidigare lagrades det med nyckeln `django_language` och konstanten `LANGUAGE_SESSION_KEY` fanns inte, men nycklar som är reserverade för Django bör börja med ett understreck. För bakåtkompatibilitet läses `django_language` fortfarande från i 1.7. Sessioner kommer att migreras till den nya nyckeln när de skrivs.
- Taggen [`blocktrans`](/sv/6.1/topics/i18n/translation/#std-templatetag-blocktrans) har nu stöd för alternativet `trimmed`. Detta alternativ kommer att ta bort tecken för nya rader från början och slutet av innehållet i taggen `{% blocktrans %}`, ersätta alla blanksteg i början och slutet av en rad och slå samman alla rader till en med ett mellanslagstecken för att separera dem. Detta är mycket användbart för att indentera innehållet i en `{% blocktrans %}` tagg utan att indentationstecknen hamnar i motsvarande post i filen `.po`, vilket gör översättningsprocessen enklare.
- När du kör [`makemessages`](/sv/6.1/ref/django-admin/#django-admin-makemessages) från rotkatalogen i ditt projekt, kommer alla extraherade strängar nu automatiskt att distribueras till rätt app eller projektmeddelandefil. Se [Lokalisering: hur man skapar språkfiler](/sv/6.1/topics/i18n/translation/#how-to-create-language-files) för mer information.
- Kommandot [`makemessages`](/sv/6.1/ref/django-admin/#django-admin-makemessages) lägger nu alltid till kommandoradsflaggan `--previous` till kommandot `msgmerge`, vilket gör att tidigare översatta strängar i `.po`-filer behålls för luddiga strängar.
- Följande inställningar för att justera språkcookiealternativen introducerades: [`LANGUAGE_COOKIE_AGE`](/sv/6.1/ref/settings/#std-setting-LANGUAGE_COOKIE_AGE), [`LANGUAGE_COOKIE_DOMAIN`](/sv/6.1/ref/settings/#std-setting-LANGUAGE_COOKIE_DOMAIN) och [`LANGUAGE_COOKIE_PATH`](/sv/6.1/ref/settings/#std-setting-LANGUAGE_COOKIE_PATH).
- Lagt till [Lokalisering av format](/sv/6.1/topics/i18n/formatting/) för Esperanto.

#### Kommandon för hantering

- Det nya [`--no-color`](/sv/6.1/ref/django-admin/#cmdoption-no-color)-alternativet för `django-admin` inaktiverar färgläggning av kommandoutmatningen för hantering.
- De nya alternativen [`dumpdata --natural-foreign`](/sv/6.1/ref/django-admin/#cmdoption-dumpdata-natural-foreign) och [`dumpdata --natural-primary`](/sv/6.1/ref/django-admin/#cmdoption-dumpdata-natural-primary) samt de nya argumenten `use_natural_foreign_keys` och `use_natural_primary_keys` för `serializers.serialize()` gör det möjligt att använda naturliga primärnycklar vid serialisering.
- Det är inte längre nödvändigt att ange namnet på cachetabellen eller alternativet `--databas` för kommandot [`createcachetable`](/sv/6.1/ref/django-admin/#django-admin-createcachetable). Django hämtar denna information från din inställningsfil. Om du har konfigurerat flera cacheminnen eller flera databaser skapas alla cachetabeller.
- Kommandot [`runserver`](/sv/6.1/ref/django-admin/#django-admin-runserver) har fått flera förbättringar:

  - På Linux-system, om [pyinotify](https://pypi.org/project/pyinotify/) är installerat, laddas utvecklingsservern om omedelbart när en fil ändras. Tidigare pollade den filsystemet efter ändringar varje sekund. Det orsakade en liten fördröjning innan omladdningar och minskade batteritiden på bärbara datorer.
  - Dessutom laddas utvecklingsservern automatiskt om när en översättningsfil uppdateras, dvs. efter körning av [`compilemessages`](/sv/6.1/ref/django-admin/#django-admin-compilemessages).
  - Alla HTTP-förfrågningar loggas till konsolen, inklusive förfrågningar om statiska filer eller `favicon.ico` som tidigare filtrerades bort.
- Hanteringskommandon kan nu producera syntaxfärgad utdata under Windows om ANSICON tredjepartsverktyg är installerat och aktivt.
- [`collectstatic`](/sv/6.1/ref/contrib/staticfiles/#django-admin-collectstatic)-kommandot med symlink-alternativet stöds nu på Windows NT 6 (Windows Vista och senare).
- Initiala SQL-data fungerar nu bättre om Python-biblioteket [sqlparse](https://pypi.org/project/sqlparse/) är installerat.

  Observera att det är föråldrat till förmån för [`RunSQL`](/sv/6.1/ref/migration-operations/#django.db.migrations.operations.RunSQL) operation av migreringar, som drar nytta av det förbättrade beteendet.

#### Modeller

- Metoden [`QuerySet.update_or_create()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.update_or_create) lades till.
- Det nya alternativet [`default_permissions`](/sv/6.1/ref/models/options/#django.db.models.Options.default_permissions) model `Meta` gör att du kan anpassa (eller inaktivera) skapandet av standardbehörigheterna för att lägga till, ändra och ta bort.
- Explicit [`OneToOneField`](/sv/6.1/ref/models/fields/#django.db.models.OneToOneField) för [Arv från flera tabeller](/sv/6.1/topics/db/models/#multi-table-inheritance) upptäcks nu i abstrakta klasser.
- Det är nu möjligt att undvika att skapa en bakåtriktad relation för [`OneToOneField`](/sv/6.1/ref/models/fields/#django.db.models.OneToOneField) genom att ställa in dess [`related_name`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey.related_name) till `'+'` eller avsluta den med `'+'`.
- [`F uttryck`](/sv/6.1/ref/models/expressions/#django.db.models.F) stödjer potensoperatorn (`**`).
- Metoderna `remove()` och `clear()` för de relaterade hanterarna som skapats av `ForeignKey` och `GenericForeignKey` accepterar nu nyckelordsargumentet `bulk` för att styra om operationer ska utföras i bulk eller inte (dvs. med hjälp av `QuerySet.update()`). Standardvärdet är `True`.
- Det är nu möjligt att använda `None` som ett frågevärde för [`iexact`](/sv/6.1/ref/models/querysets/#std-fieldlookup-iexact) lookup.
- Det är nu möjligt att skicka en callable som värde för attributet [`limit_choices_to`](/sv/6.1/ref/models/fields/#django.db.models.ForeignKey.limit_choices_to) när man definierar en `ForeignKey` eller `ManyToManyField`.
- Anrop av [`only()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.only) och [`defer()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.defer) på resultatet av [`QuerySet.values()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.values) ger nu upphov till ett fel (tidigare skulle det antingen resultera i ett databasfel eller felaktiga data).
- Du kan använda en enda lista för `index_together` (i stället för en lista med listor) när du anger en enda uppsättning fält.
- Anpassade mellanliggande modeller som har mer än en främmande nyckel till någon av de modeller som deltar i en många-till-många-relation är nu tillåtna, förutsatt att du uttryckligen anger vilka främmande nycklar som ska användas genom att ange det nya [`ManyToManyField.through_fields`](/sv/6.1/ref/models/fields/#django.db.models.ManyToManyField.through_fields)-argumentet.
- Att tilldela en modellinstans till ett fält som inte är ett relationsfält ger nu upphov till ett fel. Tidigare fungerade detta om fältet accepterade heltal som indata eftersom det tog primärnyckeln.
- Heltalsfält valideras nu mot databasens backend-specifika min- och maxvärden baserat på deras [`internal_type`](/sv/6.1/ref/models/fields/#django.db.models.Field.get_internal_type). Tidigare förhindrade inte validering av modellfält att värden utanför deras associerade kolumndatatypintervall sparades, vilket resulterade i ett integritetsfel.
- Det är nu möjligt att explicit [`order_by()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.order_by) ett relationsfält `_id` genom att använda dess attributnamn.

#### Signaler

- Argumentet `enter` lades till i signalen [`setting_changed`](/sv/6.1/ref/signals/#django.test.signals.setting_changed).
- Modellsignalerna kan nu kopplas till med hjälp av en `str` i formuläret `'app_label.ModelName` \- precis som relaterade fält - för att enkelt referera till deras avsändare.

#### Mallar

- Metoden [`Context.push()`](/sv/6.1/ref/templates/api/#django.template.Context.push) returnerar nu en kontexthanterare som automatiskt anropar [`pop()`](/sv/6.1/ref/templates/api/#django.template.Context.pop) när `with`-satsen avslutas. Dessutom accepterar [`push()`](/sv/6.1/ref/templates/api/#django.template.Context.push) nu parametrar som skickas till konstruktören `dict` som används för att bygga den nya kontextnivån.
- Den nya [`Context.flatten()`](/sv/6.1/ref/templates/api/#django.template.Context.flatten)-metoden returnerar en `Context`-stack som en platt ordbok.
- `Context`-objekt kan nu jämföras för jämlikhet (internt använder detta [`Context.flatten()`](/sv/6.1/ref/templates/api/#django.template.Context.flatten) så den interna strukturen i varje `Context`-stack spelar ingen roll så länge deras utplattade version är identisk).
- Malltaggen [`widthratio`](/sv/6.1/ref/templates/builtins/#std-templatetag-widthratio) accepterar nu en `"as"`-parameter för att fånga resultatet i en variabel.
- Malltaggen [`include`](/sv/6.1/ref/templates/builtins/#std-templatetag-include) kommer nu också att acceptera allt med en `render()`-metod (t.ex. en `Template`) som ett argument. Strängargument kommer att sökas upp med [`get_template()`](/sv/6.1/topics/templates/#django.template.loader.get_template) som alltid.
- Det är nu möjligt att [`include`](/sv/6.1/ref/templates/builtins/#std-templatetag-include) mallar rekursivt.
- Mallobjekt har nu ett ursprungsattribut inställt när `TEMPLATE_DEBUG` är `True`. Detta gör att mallens ursprung kan inspekteras och loggas utanför infrastrukturen `django.template`.
- `TypeError`-undantag tystas inte längre när de uppstår under rendering av en mall.
- Följande funktioner accepterar nu en `dirs` parameter som är en lista eller tupel för att åsidosätta `TEMPLATE_DIRS`:

  - [`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()`
- Filtret [`time`](/sv/6.1/ref/templates/builtins/#std-templatefilter-time) accepterar nu tidszonsrelaterade [formatspecifikationer](/sv/6.1/ref/templates/builtins/#date-and-time-formatting-specifiers) `'e'`, `'O'` , `'T'` och `'Z'` och kan smälta [tidszonsmedvetna](/sv/6.1/topics/i18n/timezones/#naive-vs-aware-datetimes) `datetime`-instanser som utför den förväntade renderingen.
- Taggen [`cache`](/sv/6.1/topics/cache/#std-templatetag-cache) kommer nu att försöka använda cachen som heter ”template\_fragments” om den finns och annars återgå till att använda standardcachen. Den accepterar nu också ett valfritt `using` nyckelordsargument för att kontrollera vilken cache den använder.
- Det nya filtret [`truncatechars_html`](/sv/6.1/ref/templates/builtins/#std-templatefilter-truncatechars_html) trunkerar en sträng så att den inte är längre än det angivna antalet tecken, med hänsyn tagen till HTML.

#### Förfrågningar och svar

- Det nya attributet [`HttpRequest.scheme`](/sv/6.1/ref/request-response/#django.http.HttpRequest.scheme) anger schemat för begäran (normalt `http` eller `https`).
- Genvägen [`redirect()`](/sv/6.1/topics/http/shortcuts/#django.shortcuts.redirect) stöder nu relativa webbadresser.
- Den nya underklassen [`JsonResponse`](/sv/6.1/ref/request-response/#django.http.JsonResponse) av [`HttpResponse`](/sv/6.1/ref/request-response/#django.http.HttpResponse) hjälper till att enkelt skapa JSON-kodade svar.

#### Tester

- [`DiscoverRunner`](/sv/6.1/topics/testing/advanced/#django.test.runner.DiscoverRunner) har två nya attribut, [`test_suite`](/sv/6.1/topics/testing/advanced/#django.test.runner.DiscoverRunner.test_suite) och [`test_runner`](/sv/6.1/topics/testing/advanced/#django.test.runner.DiscoverRunner.test_runner), som gör det möjligt att åsidosätta hur tester samlas in och körs.
- Argumentet `fetch_redirect_response` lades till i [`assertRedirects()`](/sv/6.1/topics/testing/tools/#django.test.SimpleTestCase.assertRedirects). Eftersom testklienten inte kan hämta externa webbadresser gör detta att du kan använda `assertRedirects` med omdirigeringar som inte är en del av din Django-app.
- Korrekt hantering av schema när jämförelser görs i [`assertRedirects()`](/sv/6.1/topics/testing/tools/#django.test.SimpleTestCase.assertRedirects).
- Argumentet `secure` har lagts till i alla förfrågningsmetoder i [`Client`](/sv/6.1/topics/testing/tools/#django.test.Client). Om `True`, kommer begäran att göras via HTTPS.
- [`assertNumQueries()`](/sv/6.1/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries) skriver nu ut listan över exekverade frågor om påståendet misslyckas.
- Instansen `WSGIRequest` som genereras av testhanteraren är nu kopplad till attributet [`django.test.Response.wsgi_request`](/sv/6.1/topics/testing/tools/#django.test.Response.wsgi_request).
- Databasinställningarna för testning har samlats i en ordbok med namnet [`TEST`](/sv/6.1/ref/settings/#std-setting-DATABASE-TEST).

#### Verktyg

- Förbättrad [`strip_tags()`](/sv/6.1/ref/utils/#django.utils.html.strip_tags) noggrannhet (men den kan fortfarande inte garantera ett HTML-säkert resultat, som anges i dokumentationen).

#### Validerare

- [`RegexValidator`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator) accepterar nu de valfria argumenten [`flags`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator.flags) och Boolean [`inverse_match`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator.inverse_match). Attributet [`inverse_match`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator.inverse_match) avgör om [`ValidationError`](/sv/6.1/ref/exceptions/#django.core.exceptions.ValidationError) ska tas upp när det reguljära uttrycksmönstret matchar (`True`) eller inte matchar (`False`, som standard) det angivna `värdet`. Attributet [`flags`](/sv/6.1/ref/validators/#django.core.validators.RegexValidator.flags) anger de flaggor som används när en sträng med reguljära uttryck sammanställs.
- [`URLValidator`](/sv/6.1/ref/validators/#django.core.validators.URLValidator) accepterar nu ett valfritt `schemes`-argument som gör det möjligt att anpassa de accepterade URI-schemana (istället för standardvärdena `http(s)` och `ftp(s)`).
- [`validate_email()`](/sv/6.1/ref/validators/#django.core.validators.validate_email) accepterar nu adresser med IPv6-litteraler, som `example@[2001:db8::1]`, enligt RFC 5321.

## Bakåtkompatibla ändringar i 1.7

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

### `allow_syncdb` / `allow_migrate`

Medan Django fortfarande kommer att titta på `allow_syncdb`-metoder även om de bör bytas ut till `allow_migrate`, finns det en subtil skillnad i vilka modeller som skickas till dessa metoder.

För appar med migreringar kommer `allow_migrate` nu att godkännas [historical models](/sv/6.1/topics/migrations/#historical-models), som är speciella versionerade modeller utan anpassade attribut, metoder eller chefer. Se till att dina `allow_migrate`-metoder endast hänvisar till fält eller andra objekt i `model._meta`.

### initial\_data

Appar med migreringar laddar inte `initial_data`-fixturer när de har slutfört migreringen. Appar utan migreringar kommer att fortsätta att ladda dessa fixturer under fasen `migrate` som emulerar det gamla `syncdb`-beteendet, men alla nya appar kommer inte att ha detta stöd.

Istället uppmuntras du att ladda initiala data i migreringar om du behöver det (med hjälp av `RunPython`-operationen och dina modellklasser); detta har den extra fördelen att dina initiala data inte behöver uppdateras varje gång du ändrar schemat.

Dessutom har `initial_data`, precis som resten av Djangos gamla `syncdb`-kod, börjat avskrivas och kommer att tas bort i Django 1.9.

### `deconstruct()` och serialiserbarhet

Django kräver nu att alla Field-klasser och alla deras konstruktörsargument är serialiserbara. Om du ändrar konstruktörsignaturen i ditt anpassade fält på något sätt måste du implementera en `deconstruct()`-metod; vi har utökat dokumentationen för anpassade fält med [instruktioner om hur du implementerar den här metoden](/sv/6.1/howto/custom-model-fields/#custom-field-deconstruct-method).

Kravet på att alla fältargument ska vara [serialiserbara](/sv/6.1/topics/migrations/#migration-serializing) innebär att alla anpassade klassinstanser som skickas till fältkonstruktörer - saker som anpassade Storage-subklasser, till exempel - måste ha en [deconstruct-metod definierad på dem också](/sv/6.1/topics/migrations/#custom-deconstruct-method), men Django tillhandahåller en praktisk klassdekorator som fungerar för de flesta applikationer.

### Ändringar i app-laddning

#### Uppstartssekvens

Django 1.7 laddar applikationskonfigurationer och modeller så snart den startar. Även om detta beteende är mer okomplicerat och tros vara mer robust, kan regressioner inte uteslutas. Se [Felsökning](/sv/6.1/ref/applications/#applications-troubleshooting) för lösningar på vissa problem som du kan stöta på.

#### Fristående skript

Om du använder Django i ett vanligt Python-skript - snarare än ett managementkommando - och du förlitar dig på miljövariabeln [`DJANGO_SETTINGS_MODULE`](/sv/6.1/topics/settings/#envvar-DJANGO_SETTINGS_MODULE), måste du nu uttryckligen initiera Django i början av ditt skript med:

```pycon
>>> import django
>>> django.setup()
```

Annars kommer du att få ett `AppRegistryNotReady` undantag.

#### WSGI-skript

Fram till Django 1.3 var det rekommenderade sättet att skapa en WSGI-applikation:

```
import django.core.handlers.wsgi

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

I Django 1.4 förbättrades stödet för WSGI och API:et ändrades till:

```
from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()
```

Om du fortfarande använder den förra stilen i ditt WSGI-skript måste du uppgradera till den senare, annars kommer du att få ett `AppRegistryNotReady`-undantag.

#### Konsistens i appregistret

Det är inte längre möjligt att ha flera installerade applikationer med samma etikett. I tidigare versioner av Django fungerade detta inte alltid korrekt, men det kraschade inte heller direkt.

Om du har två appar med samma etikett bör du skapa en [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig) för en av dem och åsidosätta dess [`label`](/sv/6.1/ref/applications/#django.apps.AppConfig.label) där. Du bör sedan justera din kod överallt där den refererar till denna applikation eller dess modeller med den gamla etiketten.

Det är inte längre möjligt att importera samma modell två gånger via olika sökvägar. Från och med Django 1.6 kan detta endast hända om du manuellt lägger till en katalog och en underkatalog på [`PYTHONPATH`](https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH). Se avsnittet om den nya projektlayouten i [1.4 versionsinformation](/sv/6.1/releases/1.4/) för migreringsinstruktioner.

Det bör du se till att göra:

- Alla modeller definieras i applikationer som är listade i [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS) eller har en explicit [`app_label`](/sv/6.1/ref/models/options/#django.db.models.Options.app_label).
- Modeller importeras inte som en bieffekt av att deras applikation laddas. Specifikt bör du inte importera modeller i rotmodulen för en applikation eller i den modul som definierar dess konfigurationsklass.

Django kommer att tillämpa dessa krav från och med version 1.9, efter en utfasningsperiod.

#### Underklassificering av AppCommand

Subklasser av [`AppCommand`](/sv/6.1/howto/custom-management-commands/#django.core.management.AppCommand) måste nu implementera en [`handle_app_config()`](/sv/6.1/howto/custom-management-commands/#django.core.management.AppCommand.handle_app_config)-metod istället för `handle_app()`. Denna metod tar emot en [`AppConfig`](/sv/6.1/ref/applications/#django.apps.AppConfig)-instans istället för en models-modul.

#### Introspekterande tillämpningar

Eftersom [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS) nu stöder programkonfigurationsklasser utöver programmoduler, bör du se över kod som har direkt åtkomst till denna inställning och använda appregistret ([`django.apps.apps`](/sv/6.1/ref/applications/#django.apps.apps)) istället.

Appregistret har bevarat vissa funktioner från den gamla appcachen. Även om appcachen var ett privat API kommer föråldrade metoder och argument att tas bort genom en standardväg för föråldring, med undantag för följande ändringar som träder i kraft omedelbart:

- `get_model` ger upphov till [`LookupError`](https://docs.python.org/3/library/exceptions.html#LookupError) istället för att returnera `None` när ingen modell hittas.
- Argumentet `only_installed` i `get_model` och `get_models` finns inte längre, inte heller argumentet `seed_cache` i `get_model`.

### Hanteringskommandon och ordning för [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS)

När flera applikationer tillhandahåller hanteringskommandon med samma namn, laddar Django kommandot från den applikation som kommer först i [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS). Tidigare versioner laddade kommandot från den applikation som kom sist.

Detta gör att upptäckten av hanteringskommandon är i linje med andra delar av Django som förlitar sig på ordningen för [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS), till exempel statiska filer, mallar och översättningar.

### `ValidationError` konstruktör och intern lagring

Beteendet för konstruktören `ValidationError` har ändrats när den tar emot en behållare med fel som argument (t.ex. en `list` eller en `ErrorList`):

- Den konverterar alla strängar den hittar till instanser av `ValidationError` innan den lägger till dem i sitt interna lager.
- Den lagrar inte den givna behållaren utan kopierar dess innehåll till sin egen interna lagring; tidigare lades själva behållaren till i `ValidationError`-instansen och användes som intern lagring.

Detta innebär att om du kommer åt `ValidationError` interna lagringsplatser, såsom `error_list`; `error_dict`; eller returvärdet av `update_error_dict()` kan du hitta instanser av `ValidationError` där du tidigare skulle ha hittat strängar.

Även om du direkt tilldelade returvärdet av `update_error_dict()` till `Form._errors` kan du oavsiktligt lägga till `list` instanser där `ErrorList` instanser förväntas. Detta är ett problem eftersom till skillnad från en enkel `list` vet en `ErrorList` hur den ska hantera instanser av `ValidationError`.

De flesta användningsfall som motiverade användning av dessa privata API:er täcks nu av den nyligen introducerade [`Form.add_error()`](/sv/6.1/ref/forms/api/#django.forms.Form.add_error)-metoden:

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

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

Om du behöver både Django \<= 1.6 och 1.7-kompatibilitet kan du inte använda [`Form.add_error()`](/sv/6.1/ref/forms/api/#django.forms.Form.add_error) eftersom det inte var tillgängligt före Django 1.7, men du kan använda följande lösning för att konvertera valfri `lista` till `ErrorList`:

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

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

### Beteendet hos `LocMemCache` när det gäller pickle-fel

En inkonsekvens fanns i tidigare versioner av Django angående hur pickle-fel hanteras av olika cache-backends. `django.core.cache.backends.locmem.LocMemCache` brukade misslyckas tyst när ett sådant fel inträffar, vilket är inkonsekvent med andra backends och leder till cache-specifika fel. Detta har åtgärdats i Django 1.7, se [#21200](https://code.djangoproject.com/ticket/21200) för mer information.

### Cache-nycklar genereras nu från förfrågningens absoluta URL

Tidigare versioner av Django genererade cache-nycklar med hjälp av en förfrågnings sökväg och frågesträng men inte schema eller värd. Om en Django-applikation betjänade flera underdomäner eller domäner kunde cache-nycklar kollidera. I Django 1.7 varierar cache-nycklarna med den absoluta URL:en för begäran, inklusive schema, värd, sökväg och frågesträng. Till exempel genereras URL-delen av en cache-nyckel nu från `https://www.example.com/path/to/?key=val` snarare än `/path/to/?key=val`. De cache-nycklar som genereras av Django 1.7 kommer att skilja sig från de nycklar som genereras av äldre versioner av Django. Efter uppgradering till Django 1.7 kommer den första begäran till en tidigare cachad URL att vara en cache-miss.

### Skicka `None` till `Manager.db_manager()`

I tidigare versioner av Django var det möjligt att använda `db_manager(using=None)` på en modellhanterarinstans för att få en hanterarinstans som använder standardroutingbeteende och åsidosätter all manuellt specificerad databasrouting. I Django 1.7 kommer ett värde på `None` som skickas till db\_manager att producera en router som *behåller* all manuellt tilldelad databasrouting - hanteraren kommer *inte* att återställas. Detta var nödvändigt för att lösa en inkonsekvens i hur routningsinformation kaskadkopplades över sammanfogningar. Se [#13724](https://code.djangoproject.com/ticket/13724) för mer detaljer.

### `pytz` kan behövas

Om ditt projekt hanterar datum före 1970 eller efter 2037 och Django ger upphov till ett [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError) när det möter dem, måste du installera [pytz](https://pypi.org/project/pytz/). Du kan påverkas av detta problem om du använder Djangos tidszonsrelaterade datumformat eller [`django.contrib.syndication`](/sv/6.1/ref/contrib/syndication/#module-django.contrib.syndication).

### metoderna `remove()` och `clear()` för relaterade förvaltare

Metoderna `remove()` och `clear()` för de relaterade hanterarna som skapats av `ForeignKey`, `GenericForeignKey` och `ManyToManyField` led av ett antal problem. Vissa operationer körde flera datamodifierande frågor utan att paketera dem i en transaktion, och vissa operationer respekterade inte standardfiltrering när den fanns (dvs. när standardhanteraren på den relaterade modellen implementerade en anpassad `get_queryset()`)).

Genom att åtgärda problemen infördes vissa ändringar som inte var kompatibla bakåt i tiden:

- Standardimplementeringen av `remove()` för `ForeignKey`-relaterade hanterare ändrades från en serie `Model.save()`-anrop till ett enda `QuerySet.update()`-anrop. Förändringen innebär att signalerna `pre_save` och `post_save` inte längre skickas. Du kan använda nyckelordsargumentet `bulk=False` för att återgå till det tidigare beteendet.
- Metoderna `remove()` och `clear()` för `GenericForeignKey` relaterade managers utför nu bulk delete. Metoden `Model.delete()` anropas inte längre på varje instans. Du kan använda nyckelordsargumentet `bulk=False` för att återgå till det tidigare beteendet.
- Metoderna `remove()` och `clear()` för `ManyToManyField` relaterade hanterare utför nästlade frågor när filtrering är inblandad, vilket kan vara ett problem eller inte beroende på din databas och dina data i sig. Se [this note](/sv/6.1/ref/models/querysets/#nested-queries-performance) för mer information.

### Strategi för omdirigering av admininloggning

Historiskt sett har Django-adminsidan skickat begäran från en obehörig eller oautentiserad användare direkt till inloggningsvyn, utan HTTP-omdirigering. I Django 1.7 ändrades detta beteende för att överensstämma med ett mer traditionellt arbetsflöde där alla obehöriga förfrågningar till en adminsida kommer att omdirigeras (med HTTP-statuskod 302) till inloggningssidan, med parametern `next` inställd på den refererande sökvägen. Användaren kommer att omdirigeras dit efter en lyckad inloggning.

Observera också att inloggningsformuläret för admin har uppdaterats så att det inte innehåller fältet `this_is_the_login_form` (nu oanvänt) och koden `ValidationError` har ställts in på den mer vanliga nyckeln `invalid_login`.

### `select_for_update()` kräver en transaktion

Historically, queries that use
[`select_for_update()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.select_for_update) could be
executed in autocommit mode, outside of a transaction. Before Django
1.6, Django’s automatic transactions mode allowed this to be used to
lock records until the next write operation. Django 1.6 introduced
database-level autocommit; since then, execution in such a context
voids the effect of `select_for_update()`. It is, therefore, assumed
now to be an error and raises an exception.

Denna ändring gjordes eftersom sådana fel kan orsakas av att inkludera en app som förväntar sig globala transaktioner (t.ex. `` ATOMIC_REQUESTS <DATABASE-ATOMIC_REQUESTS>` `` inställd på `True`), eller Djangos gamla autocommit-beteende, i ett projekt som körs utan dem; och vidare kan sådana fel manifestera sig som datakorruptionsbuggar. Det gjordes också i Django 1.6.3.

Denna ändring kan orsaka testfel om du använder `select_for_update()` i en testklass som är en underklass av [`TransactionTestCase`](/sv/6.1/topics/testing/tools/#django.test.TransactionTestCase) snarare än [`TestCase`](/sv/6.1/topics/testing/tools/#django.test.TestCase).

### Bidragande mellanprogram borttagna från standard `MIDDLEWARE_CLASSES`

Refaktorn [app-loading refactor](#app-loading-refactor-17-release-note) avförde användning av modeller från appar som inte är en del av inställningen [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS). Detta exponerade en inkompatibilitet mellan standardinställningen [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS) och `MIDDLEWARE_CLASSES` i de globala standardinställningarna (`django.conf.global_settings`). För att synkronisera dessa inställningar och förhindra deprecation-varningar när man gör saker som att testa återanvändbara appar med minimala inställningar, togs [`SessionMiddleware`](/sv/6.1/ref/middleware/#django.contrib.sessions.middleware.SessionMiddleware), [`AuthenticationMiddleware`](/sv/6.1/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware) och [`MessageMiddleware`](/sv/6.1/ref/middleware/#django.contrib.messages.middleware.MessageMiddleware) bort från standardinställningarna. Dessa klasser kommer fortfarande att ingå i de standardinställningar som genereras av [`startproject`](/sv/6.1/ref/django-admin/#django-admin-startproject). De flesta projekt kommer inte att påverkas av denna ändring, men om du inte tidigare har deklarerat `MIDDLEWARE_CLASSES` i dina projektinställningar och förlitat dig på den globala standardinställningen bör du se till att de nya standardinställningarna överensstämmer med ditt projekts behov. Du bör också kontrollera om det finns någon kod som har direkt åtkomst till `django.conf.global_settings.MIDDLEWARE_CLASSES`.

### Diverse

- The [`django.core.files.uploadhandler.FileUploadHandler.new_file()`](/sv/6.1/ref/files/uploads/#django.core.files.uploadhandler.FileUploadHandler.new_file)
  method is now passed an additional `content_type_extra` parameter. If you
  have a custom [`FileUploadHandler`](/sv/6.1/ref/files/uploads/#django.core.files.uploadhandler.FileUploadHandler)
  that implements `new_file()`, be sure it accepts this new parameter.
- [`ModelFormSet`](/sv/6.1/topics/forms/modelforms/#django.forms.models.BaseModelFormSet) raderar inte längre instanser när `save(commit=False)` anropas. Se [`can_delete`](/sv/6.1/topics/forms/formsets/#django.forms.formsets.BaseFormSet.can_delete) för instruktioner om hur du manuellt tar bort objekt från borttagna formulär.
- Laddning av tomma fixturer ger en `RuntimeWarning` istället för att ge upphov till [`CommandError`](/sv/6.1/howto/custom-management-commands/#django.core.management.CommandError).
- [`django.contrib.staticfiles.views.serve()`](/sv/6.1/ref/contrib/staticfiles/#django.contrib.staticfiles.views.serve) kommer nu att ge upphov till ett [`Http404`](/sv/6.1/topics/http/views/#django.http.Http404) undantag istället för [`ImproperlyConfigured`](/sv/6.1/ref/exceptions/#django.core.exceptions.ImproperlyConfigured) när [`DEBUG`](/sv/6.1/ref/settings/#std-setting-DEBUG) är `False`. Denna ändring tar bort behovet av att villkorligt lägga till vyn i din root URLconf, vilket i sin tur gör det säkert att vända på namnet. Den tar också bort möjligheten för besökare att generera falska HTTP 500-fel genom att begära statiska filer som inte finns eller som inte har samlats in ännu.
- Metoden [`django.db.models.Model.__eq__()`](/sv/6.1/ref/models/instances/#django.db.models.Model.__eq__) är nu definierad på ett sätt där instanser av en proxymodell och dess basmodell anses vara lika när primära nycklar matchar. Tidigare ansågs endast instanser av exakt samma klass vara lika vid matchning av primärnycklar.
- Metoden [`django.db.models.Model.__eq__()`](/sv/6.1/ref/models/instances/#django.db.models.Model.__eq__) har ändrats så att två `Model`-instanser utan primärnyckelvärden inte kommer att betraktas som lika (såvida de inte är samma instans).
- Metoden [`django.db.models.Model.__hash__()`](/sv/6.1/ref/models/instances/#django.db.models.Model.__hash__) kommer nu att ge upphov till `TypeError` när den anropas på en instans utan ett primärnyckelvärde. Detta görs för att undvika mutabla `__hash__`-värden i behållare.
- [`AutoField`](/sv/6.1/ref/models/fields/#django.db.models.AutoField)-kolumner i SQLite-databaser kommer nu att skapas med hjälp av alternativet `AUTOINCREMENT`, som garanterar monotona ökningar. Detta kommer att leda till att numreringsbeteendet för primärnycklar ändras i SQLite och blir konsekvent med de flesta andra SQL-databaser. Detta gäller endast för nyskapade tabeller. Om du har en databas som skapats med en äldre version av Django måste du migrera den för att dra nytta av den här funktionen. Du kan till exempel göra följande:

  1. Använd [`dumpdata`](/sv/6.1/ref/django-admin/#django-admin-dumpdata) för att spara dina data.
  2. Byt namn på den befintliga databasfilen (behåll den som säkerhetskopia).
  3. Kör [`migrate`](/sv/6.1/ref/django-admin/#django-admin-migrate) för att skapa det uppdaterade schemat.
  4. Använd [`loaddata`](/sv/6.1/ref/django-admin/#django-admin-loaddata) för att importera de fixturer som du exporterade i (1).
- `django.contrib.auth.models.AbstractUser` no longer defines a
  [`get_absolute_url()`](/sv/6.1/ref/models/instances/#django.db.models.Model.get_absolute_url) method. The old definition
  returned  `"/users/%s/" % urlquote(self.username)` which was arbitrary
  since applications may or may not define such a url in `urlpatterns`.
  Define a `get_absolute_url()` method on your own custom user object or use
  [`ABSOLUTE_URL_OVERRIDES`](/sv/6.1/ref/settings/#std-setting-ABSOLUTE_URL_OVERRIDES) if you want a URL for your user.
- Funktionaliteten för servering av statiska tillgångar i klassen [`django.test.LiveServerTestCase`](/sv/6.1/topics/testing/tools/#django.test.LiveServerTestCase) har förenklats: Nu kan den bara servera innehåll som redan finns i [`STATIC_ROOT`](/sv/6.1/ref/settings/#std-setting-STATIC_ROOT) när tester körs. Möjligheten att transparent servera alla statiska tillgångar (på samma sätt som man får med [`DEBUG = True`](/sv/6.1/ref/settings/#std-setting-DEBUG) vid utvecklingstid) har flyttats till en ny klass som lever i applikationen `staticfiles` (den som faktiskt ansvarar för en sådan funktion): [`django.contrib.staticfiles.testing.StaticLiveServerTestCase`](/sv/6.1/ref/contrib/staticfiles/#django.contrib.staticfiles.testing.StaticLiveServerTestCase). Med andra ord är `LiveServerTestCase` i sig mindre kraftfull men har samtidigt mindre magi.

  Skälet till detta är att ta bort beroendet av icke-contrib-kod på contrib-applikationer.
- Den gamla URI-syntaxen för cache (t.ex. `"locmem://"`) stöds inte längre. Den fungerade fortfarande, även om den inte var dokumenterad eller officiellt stödd. Om du fortfarande använder den, uppdatera till den nuvarande [`CACHES`](/sv/6.1/ref/settings/#std-setting-CACHES)-syntaxen.
- Standardordningen för `Form`-fält i händelse av arv har ändrats för att följa normal Python MRO. Fält upptäcks nu genom att iterera genom MRO i omvänd ordning, där den översta klassen kommer sist. Detta påverkar dig bara om du förlitade dig på standardfältordningen medan du hade fält definierade på både den aktuella klassen *och* på en överordnad `Form`.
- Argumentet `required` i [`SelectDateWidget`](/sv/6.1/ref/forms/widgets/#django.forms.SelectDateWidget) har tagits bort. Denna widget respekterar nu formulärfältets `is_required`-attribut som andra widgets.
- `Widget.is_hidden` är nu en skrivskyddad egenskap som får sitt värde genom att introspektera förekomsten av `input_type == 'hidden'`.
- [`select_related()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.select_related) kedjar nu på samma sätt som andra liknande anrop som `prefetch_related`. Det vill säga, `select_related('foo', 'bar')` är likvärdigt med `select_related('foo').select_related('bar')`. Tidigare skulle det senare ha varit likvärdigt med `select_related('bar')`.
- GeoDjango har inte längre stöd för GEOS \< 3.1.
- Metoden `init_connection_state` för databasbackends körs nu i autocommit-läge (om du inte ställer in [`AUTOCOMMIT`](/sv/6.1/ref/settings/#std-setting-DATABASE-AUTOCOMMIT) till `False`). Om du underhåller en anpassad databasbackend bör du kontrollera den metoden.
- Attributet `django.db.backends.BaseDatabaseFeatures.allows_primary_key_0` har bytt namn till `allows_auto_pk_0` för att bättre beskriva det. Det är `True` för alla databasbackends som ingår i Django utom MySQL som tillåter primära nycklar med värdet 0. Det förbjuder bara *autoincrement* primära nycklar med värde 0.
- Skuggning av modellfält som definieras i en överordnad modell har förbjudits eftersom detta skapar tvetydighet i det förväntade modellbeteendet. Dessutom resulterar kolliderande fält i modellens arvshierarki i ett systemkontrollfel. Om du t.ex. använder multi-inheritance måste du definiera anpassade primärnyckelfält i överordnade modeller, annars kommer standardfälten `id` att krocka. Se [Multipel arvsmassa](/sv/6.1/topics/db/models/#model-multiple-inheritance-topic) för mer information.
- `django.utils.translation.parse_accept_lang_header()` returnerar nu lokala med små bokstäver, istället för det fall som det tillhandahölls. Eftersom lokalspråk bör behandlas skiftlägesokänsligt gör detta att vi kan påskynda lokalspårningen.
- `django.utils.translation.get_language_from_path()` och `django.utils.translation.trans_real.get_supported_language_variant()` har nu inte längre ett `stödd` argument.
- Vyn `shortcut` i `django.contrib.contenttypes.views` stöder nu protokollrelativa webbadresser (t.ex. `//example.com`).
- [`GenericRelation`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericRelation) har nu stöd för ett valfritt argument `related_query_name`. Om du anger `related_query_name` läggs en relation från det relaterade objektet tillbaka till innehållstypen för filtrering, ordning och andra frågeoperationer.
- När du kör tester på PostgreSQL kommer [`USER`](/sv/6.1/ref/settings/#std-setting-USER) att behöva läsbehörighet till den inbyggda `postgres`-databasen. Detta är i stället för det tidigare beteendet att ansluta till den faktiska icke-testdatabasen.
- Som en del av [System check framework](/sv/6.1/ref/checks/), [fields, models, and model managers](/sv/6.1/topics/checks/#field-checking) implementerar alla en `check()` metod som är registrerad med check framework. Om du har en befintlig metod som heter `check()` på ett av dessa objekt, måste du byta namn på den.
- Som nämnts ovan i avsnittet ”Cache” i ”Mindre funktioner”, kommer en definition av argumentet [`TIMEOUT`](/sv/6.1/ref/settings/#std-setting-CACHES-TIMEOUT) i inställningen [`CACHES`](/sv/6.1/ref/settings/#std-setting-CACHES) som `None` att ställa in cache-nycklarna som ”non-expiring”. Tidigare, med memcache-backend, skulle en [`TIMEOUT`](/sv/6.1/ref/settings/#std-setting-CACHES-TIMEOUT) på `0` ställa in nycklar som inte upphör att gälla, men detta var inkonsekvent med set-and-expire-beteendet (dvs. ingen cachelagring) i `set("key", "value", timeout=0)`. Om du vill ha nycklar som inte löper ut, uppdatera dina inställningar så att du använder `None` istället för `0` eftersom den senare nu också anger set-and-expire i inställningarna.
- Hanteringskommandona `sql*` respekterar nu metoden `allow_migrate()` i [`DATABASE_ROUTERS`](/sv/6.1/ref/settings/#std-setting-DATABASE_ROUTERS). Om du har modeller som synkroniserats till databaser som inte är standarddatabaser, använd flaggan `--database` för att få SQL för dessa modeller (tidigare inkluderades de alltid i utdata).
- Avkodning av frågesträngen från webbadresser faller nu tillbaka till ISO-8859-1-kodningen när inmatningen inte är giltig UTF-8.
- Med tillägget av `django.contrib.auth.middleware.SessionAuthenticationMiddleware` till standardprojektmallen (endast före 1.7.2) måste en databas skapas innan du öppnar en sida med [`runserver`](/sv/6.1/ref/django-admin/#django-admin-runserver).
- Tillägget av argumentet `schemes` till `URLValidator` kommer att framstå som en bakåtkompatibel förändring om du tidigare använde ett anpassat reguljärt uttryck för att validera scheman. Alla scheman som inte listas i `schemes` kommer att misslyckas med valideringen, även om det reguljära uttrycket matchar den angivna URL:en.

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

### `django.core.cache.get_cache`

`django.core.cache.get_cache` har ersatts av [`django.core.cache.caches`](/sv/6.1/topics/cache/#django.core.cache.caches).

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

`django.utils.dictconfig` och `django.utils.importlib` var kopior av [`logging.config`](https://docs.python.org/3/library/logging.config.html#module-logging.config) respektive [`importlib`](https://docs.python.org/3/library/importlib.html#module-importlib) som tillhandahölls för Python-versioner före 2.7. De har blivit föråldrade.

### `django.utils.module_loading.import_by_path`

Den nuvarande funktionen `django.utils.module_loading.import_by_path` fångar upp `AttributeError`, `ImportError` och `ValueError` undantag och återställer [`ImproperlyConfigured`](/sv/6.1/ref/exceptions/#django.core.exceptions.ImproperlyConfigured). Sådan undantagsmaskering gör det onödigt svårt att diagnostisera problem med cirkulär import, eftersom det får det att se ut som om problemet kommer inifrån Django. Det har utgått till förmån för [`import_string()`](/sv/6.1/ref/utils/#django.utils.module_loading.import_string).

### `django.utils.tzinfo`

`django.utils.tzinfo` tillhandahöll två [`tzinfo`](https://docs.python.org/3/library/datetime.html#datetime.tzinfo)-underklasser, `LocalTimezone` och `FixedOffset`. De har utgått till förmån för mer korrekta alternativ som tillhandahålls av [`django.utils.timezone`](/sv/6.1/ref/utils/#module-django.utils.timezone), [`django.utils.timezone.get_default_timezone()`](/sv/6.1/ref/utils/#django.utils.timezone.get_default_timezone) och [`django.utils.timezone.get_fixed_timezone()`](/sv/6.1/ref/utils/#django.utils.timezone.get_fixed_timezone).

### `django.utils.unittest`

`django.utils.unittest` gav enhetlig tillgång till `unittest2`-biblioteket på alla Python-versioner. Eftersom `unittest2` blev standardbibliotekets [`unittest`](https://docs.python.org/3/library/unittest.html#module-unittest)-modul i Python 2.7, och Django 1.7 tappar stöd för äldre Python-versioner, är denna modul inte användbar längre. Den har blivit avskriven. Använd [`unittest`](https://docs.python.org/3/library/unittest.html#module-unittest) istället.

### `django.utils.datastrukturer.SortedDict`

Eftersom [`OrderedDict`](https://docs.python.org/3/library/collections.html#collections.OrderedDict) lades till i standardbiblioteket i Python 2.7, behövs inte längre `SortedDict` och har utgått.

De två ytterligare, föråldrade metoderna som tillhandahålls av `SortedDict` (`insert()` och `value_for_index()`) har tagits bort. Om du förlitade dig på dessa metoder för att ändra strukturer som formulärfält, bör du nu behandla dessa `OrderedDict` som oföränderliga objekt och åsidosätta dem för att ändra deras innehåll.

Till exempel kanske du vill åsidosätta `MyFormClass.base_fields` (även om detta attribut inte anses vara ett offentligt API) för att ändra ordningen på fält för alla `MyFormClass`-instanser; eller på liknande sätt kan du åsidosätta `self.fields` inifrån `MyFormClass.__init__()`, för att ändra fälten för en viss formulärinstans. Till exempel (från Django själv):

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

### Anpassad SQL-plats för modellpaket

Tidigare, om modeller organiserades i ett paket (`myapp/models/`) snarare än bara `myapp/models.py`, skulle Django leta efter inledande SQL-data i `myapp/models/sql/`. Denna bugg har åtgärdats så att Django söker i `myapp/sql/` som dokumenterat. Efter att detta problem åtgärdades lades migreringar till som avregistrerar initial SQL-data. Även om denna ändring fortfarande existerar är avskrivningen irrelevant eftersom hela funktionen kommer att tas bort i Django 1.9.

### Omorganisering av `django.contrib.sites`

`django.contrib.sites` ger reducerad funktionalitet när den inte finns i [`INSTALLED_APPS`](/sv/6.1/ref/settings/#std-setting-INSTALLED_APPS). App-loading refactor lägger till några begränsningar i den situationen. Som en följd av detta flyttades två objekt och de gamla platserna är föråldrade:

- [`RequestSite`](/sv/6.1/ref/contrib/sites/#django.contrib.sites.requests.RequestSite) finns nu i `django.contrib.sites.requests`.
- [`get_current_site()`](/sv/6.1/ref/contrib/sites/#django.contrib.sites.shortcuts.get_current_site) finns nu i `django.contrib.sites.shortcuts`.

### attributet `declared_fieldsets` för `ModelAdmin`

`ModelAdmin.declared_fieldsets` har blivit föråldrat. Trots att det är ett privat API kommer det att gå igenom en vanlig deprecation-väg. Detta attribut användes mest av metoder som kringgick `ModelAdmin.get_fieldsets()` men detta ansågs vara en bugg och har åtgärdats.

### Omorganisering av `django.contrib.contenttypes`

Eftersom `django.contrib.contenttypes.generic` definierade både admin- och modellrelaterade objekt, kunde en import av denna modul utlösa oväntade sidoeffekter. Som en följd av detta delades dess innehåll upp i [`contenttypes`](/sv/6.1/ref/contrib/contenttypes/#module-django.contrib.contenttypes) undermoduler och modulen `django.contrib.contenttypes.generic` är avskriven:

- [`GenericForeignKey`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericForeignKey) och [`GenericRelation`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.fields.GenericRelation) finns nu i [`fields`](/sv/6.1/ref/contrib/contenttypes/#module-django.contrib.contenttypes.fields).
- [`BaseGenericInlineFormSet`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.BaseGenericInlineFormSet) och [`generic_inlineformset_factory()`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.forms.generic_inlineformset_factory) finns nu i [`forms`](/sv/6.1/ref/contrib/contenttypes/#module-django.contrib.contenttypes.forms).
- [`GenericInlineModelAdmin`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericInlineModelAdmin), [`GenericStackedInline`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericStackedInline) och [`GenericTabularInline`](/sv/6.1/ref/contrib/contenttypes/#django.contrib.contenttypes.admin.GenericTabularInline) finns nu i [`admin`](/sv/6.1/ref/contrib/contenttypes/#module-django.contrib.contenttypes.admin).

### `syncdb`

Kommandot `syncdb` har utgått till förmån för det nya kommandot `` migrate` ``. `migrate` tar samma argument som `syncdb` brukade göra plus några till, så det är säkert att bara ändra namnet du anropar och inget annat.

### modulerna `util` byter namn till `utils`

Följande instanser av `util.py` i Djangos kodbas har bytt namn till `utils.py` i ett försök att förena alla util- och utils-referenser:

- `django.contrib.admin.util`
- `django.contrib.gis.db.backends.util`
- `django.db.backends.util`
- `django.forms.util`

### metoden `get_formsets` för `ModelAdmin`

`ModelAdmin.get_formsets` har utgått till förmån för den nya ``get_formsets_with_inlines`()``, för att bättre hantera fallet att selektivt visa inlines på en `ModelAdmin`.

### `IPAddressField`

Fälten `django.db.models.IPAddressField` och `django.forms.IPAddressField` har utgått till förmån för [`django.db.models.GenericIPAddressField`](/sv/6.1/ref/models/fields/#django.db.models.GenericIPAddressField) och [`django.forms.GenericIPAddressField`](/sv/6.1/ref/forms/fields/#django.forms.GenericIPAddressField).

### metoden `BaseMemcachedCache._get_memcache_timeout`

Metoden `BaseMemcachedCache._get_memcache_timeout()` har bytt namn till `get_backend_timeout()`. Trots att det är ett privat API kommer det att gå igenom den normala utfasningen.

### Alternativ för serialisering av naturliga nycklar

Alternativen `--natural` och `-n` för [`dumpdata`](/sv/6.1/ref/django-admin/#django-admin-dumpdata) har utgått. Använd [`dumpdata --natural-foreign`](/sv/6.1/ref/django-admin/#cmdoption-dumpdata-natural-foreign) istället.

På samma sätt har argumentet `use_natural_keys` för `serializers.serialize()` utgått. Använd `use_natural_foreign_keys` istället.

### Sammanslagning av argumenten `POST` och `GET` till `WSGIRequest.REQUEST`

Det var redan starkt rekommenderat att du använder `GET` och `POST` istället för `REQUEST`, eftersom de förra är mer explicita. Egenskapen `REQUEST` är föråldrad och kommer att tas bort i Django 1.9.

### klassen `django.utils.datastructures.MergeDict`

`MergeDict` finns främst för att stödja sammanslagning av `POST` och `GET` argument till en `REQUEST` egenskap på `WSGIRequest`. För att slå samman ordböcker, använd `dict.update()` istället. Klassen `MergeDict` är föråldrad och kommer att tas bort i Django 1.9.

### Språkkoderna `zh-cn`, `zh-tw` och `fy-nl`

De språkkoder som för närvarande används för förenklad kinesiska `zh-cn`, traditionell kinesiska `zh-tw` och (väst)fransyska `fy-nl` är föråldrade och bör ersättas av språkkoderna `zh-hans`, `zh-hant` respektive `fy`. Om du använder dessa språkkoder bör du byta namn på locale-katalogerna och uppdatera dina inställningar så att de återspeglar dessa ändringar. De föråldrade språkkoderna kommer att tas bort i Django 1.9.

### funktionen `django.utils.functional.memoize`

Funktionen `memoize` är föråldrad och bör ersättas av dekoratorn `functools.lru_cache` (tillgänglig från Python 3.2 och framåt).

Django levererar en backport av denna dekorator för äldre Python-versioner och den finns tillgänglig på `django.utils.lru_cache.lru_cache`. Den föråldrade funktionen kommer att tas bort i Django 1.9.

### Geografiska webbplatskartor

Google har dragit tillbaka stödet för Geo Sitemaps-formatet. Därför är Djangos stöd för Geo Sitemaps utdaterat och kommer att tas bort i Django 1.8.

### Skicka anropsbara argument till queryset-metoder

Kallbara argument för querysets var en odokumenterad funktion som var opålitlig. Den har utrangerats och kommer att tas bort i Django 1.9.

Kallbara argument utvärderades när en queryset konstruerades i stället för när den utvärderades, vilket innebar att den här funktionen inte gav någon fördel jämfört med att utvärdera argumenten innan de skickades till queryset och skapade förvirring om att argumenten kunde ha utvärderats vid query-tidpunkten.

### inställning `ADMIN_FOR`

Funktionen `ADMIN_FOR`, som är en del av admindocs, har tagits bort. Du kan ta bort inställningen från din konfiguration när det passar dig.

### `SplitDateTimeWidget` med `DateTimeField`

stöd för `SplitDateTimeWidget` i [`DateTimeField`](/sv/6.1/ref/forms/fields/#django.forms.DateTimeField) är föråldrat, använd `SplitDateTimeWidget` med [`SplitDateTimeField`](/sv/6.1/ref/forms/fields/#django.forms.SplitDateTimeField) istället.

### `validera`

Hanteringskommandot `validate` är utdaterat till förmån för kommandot [`check`](/sv/6.1/ref/django-admin/#django-admin-check).

### `django.core.management.BaseCommand`

flaggan `requires_model_validation` har tagits bort till förmån för den nya flaggan `requires_system_checks`. Om den senare flaggan saknas används värdet för den förra flaggan. Att definiera både `requires_system_checks` och `requires_model_validation` resulterar i ett fel.

Metoden `check()` har ersatt den gamla metoden `validate()`.

### validerare för `ModelAdmin`

Attributen `ModelAdmin.validator_class` och `default_validator_class` är avförda till förmån för det nya attributet `checks_class`.

Metoden `ModelAdmin.validate()` är föråldrad till förmån för `ModelAdmin.check()`.

Modulen `django.contrib.admin.validation` är föråldrad.

### `django.db.backends.databasvalidering.validate_field`

Denna metod har utgått till förmån för den nya metoden `check_field`. Funktionaliteten som krävs av `check_field()` är samma som den som tillhandahålls av `validate_field()`, men utdataformatet är annorlunda. Tredjeparts databasbackends som behöver denna funktionalitet bör tillhandahålla en implementation av `check_field()`.

### Laddar `ssi` och `url` malltaggar från `future` bibliotek

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

### `django.utils.text.javascript_quote`

`javascript_quote()` var en odokumenterad funktion som fanns i `django.utils.text`. Den användes internt i vyn `javascript_catalog()` vars implementation ändrades till att använda `json.dumps()` istället. Om du förlitar dig på denna funktion för att tillhandahålla säker utdata från opålitliga strängar, bör du använda `django.utils.html.escapejs` eller [`escapejs`](/sv/6.1/ref/templates/builtins/#std-templatefilter-escapejs) mallfiltret. Om allt du behöver är att generera giltiga JavaScript-strängar kan du helt enkelt använda `json.dumps()`.

### `fix_ampersands` utils-metod och mallfilter

Metoden `django.utils.html.fix_ampersands` och mallfiltret `fix_ampersands` är föråldrade, eftersom escapingen av ampersands redan tas om hand av Djangos standard HTML-escapingfunktioner. Att kombinera detta med `fix_ampersands` skulle antingen resultera i dubbel escaping eller, om utdata antas vara säker, en risk för att införa XSS-sårbarheter. Tillsammans med `fix_ampersands` är `django.utils.html.clean_html` utfasad, en odokumenterad funktion som anropar `fix_ampersands`. Eftersom detta är en accelererad deprecation kommer `fix_ampersands` och `clean_html` att tas bort i Django 1.8.

### Omorganisering av testinställningar för databaser

Alla databasinställningar med prefixet `TEST_` har utgått till förmån för poster i en [`TEST`](/sv/6.1/ref/settings/#std-setting-DATABASE-TEST)-ordbok i databasinställningarna. De gamla inställningarna kommer att stödjas fram till Django 1.9. För bakåtkompatibilitet med äldre versioner av Django kan du definiera båda versionerna av inställningarna så länge de matchar.

### Stöd för FastCGI

FastCGI-stöd via hanteringskommandot `runfcgi` kommer att tas bort i Django 1.9. Distribuera ditt projekt med hjälp av WSGI.

### Flyttade objekt i `contrib.sites`

Efter app-loading refactor behövde två objekt i `django.contrib.sites.models` flyttas eftersom de måste vara tillgängliga utan att importera `django.contrib.sites.models` när `django.contrib.sites` inte är installerat. Importera `RequestSite` från `django.contrib.sites.requests` och `get_current_site()` från `django.contrib.sites.shortcuts`. De gamla importplatserna kommer att fungera fram till Django 1.9.

### `django.forms.forms.get_declared_fields()`

Django använder inte längre denna funktion internt. Även om det är ett privat API kommer det att gå igenom den normala utfasningscykeln.

### API:er för privata sökfrågor

Privata API:er `django.db.models.sql.where.WhereNode.make_atom()` och `django.db.models.sql.where.Constraint` är utfasade till förmån för den nya [custom lookups API](/sv/6.1/ref/models/lookups/).

## Funktioner borttagna i 1.7

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

- `django.utils.simplejson` är borttagen.
- `django.utils.itercompat.product` har tagits bort.
- INSTALLED\_APPS och TEMPLATE\_DIRS korrigeras inte längre från en vanlig sträng till en tupel.
- [`HttpResponse`](/sv/6.1/ref/request-response/#django.http.HttpResponse), [`SimpleTemplateResponse`](/sv/6.1/ref/template-response/#django.template.response.SimpleTemplateResponse), [`TemplateResponse`](/sv/6.1/ref/template-response/#django.template.response.TemplateResponse), `render_to_response()`, [`index()`](/sv/6.1/ref/contrib/sitemaps/#django.contrib.sitemaps.views.index), och [`sitemap()`](/sv/6.1/ref/contrib/sitemaps/#django.contrib.sitemaps.views.sitemap) tar inte längre ett `mimetype` argument
- [`HttpResponse`](/sv/6.1/ref/request-response/#django.http.HttpResponse) konsumerar omedelbart sitt innehåll om det är en iterator.
- Inställningen `AUTH_PROFILE_MODULE` och metoden `get_profile()` i User-modellen har tagits bort.
- Ledningskommandot `cleanup` har tagits bort.
- Skriptet `daily_cleanup.py` har tagits bort.
- [`select_related()`](/sv/6.1/ref/models/querysets/#django.db.models.query.QuerySet.select_related) har inte längre ett `djup` nyckelordsargument.
- Funktionerna `get_warnings_state()`/`restore_warnings_state()` från [`django.test.utils`](/sv/6.1/topics/testing/advanced/#module-django.test.utils) och `save_warnings_state()`/ `restore_warnings_state()` [django.test.\*TestCase](/sv/6.1/topics/testing/tools/#django-testcase-subclasses) tas bort.
- Metoden `check_for_test_cookie` i [`AuthenticationForm`](/sv/6.1/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm) har tagits bort.
- Den version av `django.contrib.auth.views.password_reset_confirm()` som stöder base36-kodade användar-ID (`django.contrib.auth.views.password_reset_confirm_uidb36`) tas bort.
- Mix-in `django.utils.encoding.StrAndUnicode` tas bort.