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

*23 mars 2011*

Välkommen till Django 1.3!

Django 1.3 har nästan ett år på nacken och innehåller en hel del [nya funktioner](#whats-new-1-3) och massor av buggfixar och förbättringar av befintliga funktioner. Dessa versionsinformation täcker de nya funktionerna i 1.3, samt några [backwards-incompatible changes](#backwards-incompatible-changes-1-3) som du bör vara medveten om när du uppgraderar från Django 1.2 eller äldre versioner.

## Översikt

Django 1.3 har mestadels fokuserat på att lösa mindre, långvariga funktionsförfrågningar, men det har inte hindrat några ganska betydande nya funktioner från att landa, inklusive:

- Ett ramverk för att skriva [klassbaserade vyer](#class-based-views).
- Inbyggt stöd för [användning av Pythons loggningsfunktioner](#logging).
- Contrib stöd för [enkel hantering av statiska filer](#extended-static-files-handling).
- Djangos testramverk stöder nu (och levereras med en kopia av) [the unittest2 library](#unittest2-support).

När det är möjligt introduceras nya funktioner på ett bakåtkompatibelt sätt enligt [vår API-stabilitetspolicy](/sv/5.2/misc/api-stability/) policy. Som ett resultat av denna policy, Django 1.3 [börjar deprecieringsprocessen för vissa funktioner](#deprecated-features-1-3).

## Kompatibilitet med Python

Utgåvan av Django 1.2 var anmärkningsvärd för att ha den första förändringen i Djangos Python-kompatibilitetspolicy; före Django 1.2 stödde Django alla 2.x-versioner av Python från 2.3 och uppåt. Från och med Django 1.2 höjdes minimikravet till Python 2.4.

Django 1.3 fortsätter att stödja Python 2.4, men kommer att vara den sista Django-utgåveserien som gör det; från och med Django 1.4 kommer den minsta stödda Python-versionen att vara 2.5. Ett dokument som beskriver vår fullständiga tidslinje för utfasning av Python 2.x och övergång till Python 3.x kommer att publiceras strax efter lanseringen av Django 1.3.

## Vad är nytt i Django 1.3

### Klassbaserade åsikter

Django 1.3 lägger till ett ramverk som gör att du kan använda en klass som en vy. Detta innebär att du kan komponera en vy av en samling metoder som kan underklassas och åsidosättas för att tillhandahålla gemensamma vyer av data utan att behöva skriva för mycket kod.

Analoger till alla de gamla funktionsbaserade generiska vyerna har tagits fram, tillsammans med en helt generisk basklass för vyer som kan användas som grund för återanvändbara applikationer som enkelt kan utökas.

Se [dokumentationen om klassbaserade generiska vyer](/sv/5.2/topics/class-based-views/) för mer information. Det finns också ett dokument som hjälper dig att [konvertera dina funktionsbaserade generiska vyer till klassbaserade vyer](https://raw.githubusercontent.com/django/django/ea9dc9f4b03ae034c1dc080730422dda7a9c2e47/docs/topics/generic-views-migration.txt).

### Loggning

Django 1.3 lägger till stöd på ramnivå för Pythons modul `logging`.  Detta innebär att du nu enkelt kan konfigurera och kontrollera loggning som en del av ditt Django-projekt. Ett antal loggningshanterare och loggningsanrop har också lagts till i Djangos egen kod - framför allt hanteras felmeddelandena som skickas vid ett HTTP 500-serverfel nu som en loggningsaktivitet. Se [dokumentationen om Djangos loggningsgränssnitt](/sv/5.2/topics/logging/) för mer information.

### Utökad hantering av statiska filer

Django 1.3 levereras med en ny contrib-app - `django.contrib.staticfiles` \- för att hjälpa utvecklare att hantera de statiska mediefiler (bilder, CSS, JavaScript, etc.) som behövs för att rendera en komplett webbsida.

I tidigare versioner av Django var det vanligt att placera statiska tillgångar i [`MEDIA_ROOT`](/sv/5.2/ref/settings/#std-setting-MEDIA_ROOT) tillsammans med filer som laddats upp av användaren, och servera dem båda på [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL). En del av syftet med att introducera appen `staticfiles` är att göra det enklare att hålla statiska filer åtskilda från användaruppladdade filer. Statiska tillgångar bör nu placeras i underkatalogerna `static/` i dina appar eller i andra kataloger för statiska tillgångar som anges i [`STATICFILES_DIRS`](/sv/5.2/ref/settings/#std-setting-STATICFILES_DIRS), och kommer att serveras på [`STATIC_URL`](/sv/5.2/ref/settings/#std-setting-STATIC_URL).

Se [referensdokumentationen för appen](/sv/5.2/ref/contrib/staticfiles/) för mer information eller lär dig hur man [hanterar statiska filer](/sv/5.2/howto/static-files/).

### stöd för `unittest2`

Python 2.7 introducerade några stora förändringar i `unittest`-biblioteket och lade till några extremt användbara funktioner. För att säkerställa att alla Django-projekt kan dra nytta av dessa nya funktioner, levereras Django med en kopia av [unittest2](https://pypi.org/project/unittest2/), en kopia av Python 2.7 `unittest`-biblioteket, bakåtporterat för Python 2.4-kompatibilitet.

För att komma åt detta bibliotek tillhandahåller Django modulaliaset `django.utils.unittest`. Om du använder Python 2.7, eller om du har installerat `unittest2` lokalt, kommer Django att mappa aliaset till den installerade versionen av `unittest`-biblioteket. Annars kommer Django att använda sin egen medföljande version av `unittest2`.

För att utnyttja detta alias använder du helt enkelt:

```
from django.utils import unittest
```

där du historiskt sett skulle ha använt:

```
import unittest
```

Om du vill fortsätta att använda basbiblioteket `unittest` kan du göra det - du får bara inte tillgång till några av de nya fina `unittest2`-funktionerna.

### Hantering av transaktionskontext

Användare av Python 2.5 och senare kan nu använda transaktionshanteringsfunktioner som kontexthanterare. Till exempel:

```
with transaction.autocommit():
    ...
```

### Konfigurerbar delete-kaskad

[`ForeignKey`](/sv/5.2/ref/models/fields/#django.db.models.ForeignKey) och [`OneToOneField`](/sv/5.2/ref/models/fields/#django.db.models.OneToOneField) accepterar nu ett [`on_delete`](/sv/5.2/ref/models/fields/#django.db.models.ForeignKey.on_delete)-argument för att anpassa beteendet när det refererade objektet raderas. Tidigare var borttagningar alltid kaskad; tillgängliga alternativ inkluderar nu set null, set default, set to any value, protect, eller do nothing.

För mer information, se [`on_delete`](/sv/5.2/ref/models/fields/#django.db.models.ForeignKey.on_delete) dokumentation.

### Kontextuella markörer och kommentarer för översättningsbara strängar

För översättningssträngar med tvetydig innebörd kan du nu använda funktionen `pgettext` för att ange strängens sammanhang.

Och om du bara vill lägga till lite information för översättare kan du också lägga till särskilda översättarkommentarer i källan.

Mer information finns i [Kontextuella markörer](/sv/5.2/topics/i18n/translation/#contextual-markers) och [Kommentarer för översättare](/sv/5.2/topics/i18n/translation/#translator-comments).

### Förbättringar av inbyggda malltaggar

Ett antal förbättringar har gjorts av Djangos inbyggda malltaggar:

- Taggen [`include`](/sv/5.2/ref/templates/builtins/#std-templatetag-include) accepterar nu alternativet `with`, vilket gör att du kan ange kontextvariabler för den inkluderade mallen
- Taggen [`include`](/sv/5.2/ref/templates/builtins/#std-templatetag-include) accepterar nu alternativet `only`, vilket gör att du kan utesluta den aktuella kontexten från den inkluderade kontexten
- Med taggen [`with`](/sv/5.2/ref/templates/builtins/#std-templatetag-with) kan du nu definiera flera kontextvariabler i ett enda [`with`](/sv/5.2/ref/templates/builtins/#std-templatetag-with)-block.
- Taggen [`load`](/sv/5.2/ref/templates/builtins/#std-templatetag-load) accepterar nu argumentet `from`, vilket gör att du kan ladda en enskild tagg eller ett filter från ett bibliotek.

### MallSvar

Det kan ibland vara fördelaktigt att låta dekoratorer eller mellanprogram ändra ett svar *efter* att det har konstruerats av vyn. Du kanske t.ex. vill ändra den mall som används eller lägga in ytterligare data i kontexten.

Du kan dock inte (enkelt) ändra innehållet i en grundläggande [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse) efter att den har konstruerats. För att övervinna denna begränsning lägger Django 1.3 till en ny [`TemplateResponse`](/sv/5.2/ref/template-response/#django.template.response.TemplateResponse)-klass. Till skillnad från grundläggande [`HttpResponse`](/sv/5.2/ref/request-response/#django.http.HttpResponse)-objekt behåller [`TemplateResponse`](/sv/5.2/ref/template-response/#django.template.response.TemplateResponse)-objekt detaljerna i mallen och sammanhanget som tillhandahölls av vyn för att beräkna svaret. Det slutliga resultatet av svaret beräknas inte förrän det behövs, senare i svarsprocessen.

För mer information, se [dokumentation](/sv/5.2/ref/template-response/) om [`TemplateResponse`](/sv/5.2/ref/template-response/#django.template.response.TemplateResponse)-klassen.

### Cachelagring av ändringar

Django 1.3 introducerar flera förbättringar av Djangos infrastruktur för cachning.

För det första stöder Django nu flera namngivna cacher. På samma sätt som Django 1.2 införde stöd för flera databasanslutningar, kan du med Django 1.3 använda den nya inställningen [`CACHES`](/sv/5.2/ref/settings/#std-setting-CACHES) för att definiera flera namngivna cache-anslutningar.

För det andra har [versioning](/sv/5.2/topics/cache/#cache-versioning), [site-wide prefixing](/sv/5.2/topics/cache/#cache-key-prefixing) och [transformation](/sv/5.2/topics/cache/#cache-key-transformation) lagts till i cache-API:et.

För det tredje har [cache key creation](/sv/5.2/topics/cache/#using-vary-headers) uppdaterats för att ta hänsyn till frågesträngen på `GET`-förfrågningar.

Slutligen har stöd för [pylibmc](http://sendapatch.se/projects/pylibmc/) lagts till i memcached cache backend.

För mer information, se [dokumentation om cachelagring i Django](/sv/5.2/topics/cache/).

### Behörigheter för inaktiva användare

Om du tillhandahåller en anpassad auth-backend med `upports_inactive_user` inställd på `True`, kommer en inaktiv `User`-instans att kontrollera backend för behörigheter.  Detta är användbart för att ytterligare centralisera behörighetshanteringen. Se [authentication docs](/sv/5.2/topics/auth/) för mer information.

### GeoDjango

GeoDjango-testsviten ingår nu när man [kör Django-testsviten](/sv/5.2/internals/contributing/writing-code/unit-tests/#running-unit-tests) med `runtests.py` när man använder [spatial databas backends](/sv/5.2/ref/contrib/gis/db-api/#spatial-backends).

### [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL) och [`STATIC_URL`](/sv/5.2/ref/settings/#std-setting-STATIC_URL) måste sluta med ett snedstreck

Tidigare krävde inställningen [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL) bara ett efterföljande snedstreck om den innehöll ett suffix utöver domännamnet.

Ett efterföljande snedstreck är nu *krävt* för [`MEDIA_URL`](/sv/5.2/ref/settings/#std-setting-MEDIA_URL) och den nya [`STATIC_URL`](/sv/5.2/ref/settings/#std-setting-STATIC_URL)-inställningen så länge det inte är tomt. Detta säkerställer att det finns ett konsekvent sätt att kombinera sökvägar i mallar.

Projektinställningar som anger någon av de båda inställningarna utan ett efterföljande snedstreck kommer nu att ge upphov till en `PendingDeprecationWarning`.

I Django 1.4 kommer samma tillstånd att ge upphov till ett `DeprecationWarning`, och i Django 1.5 kommer det att ge upphov till ett `ImproperlyConfigured` undantag.

### Allt annat

Django [1.1](/sv/5.2/releases/1.1/) och [1.2](/sv/5.2/releases/1.2/) lade till många stora saker till Django, som stöd för flera databaser, modellvalidering och ett sessionsbaserat meddelanderamverk. Detta fokus på stora funktioner kom dock på bekostnad av många mindre funktioner.

För att kompensera för detta har fokus i utvecklingsprocessen för Django 1.3 legat på att lägga till många mindre, långvariga funktionsförfrågningar. Dessa inkluderar:

- Förbättrade verktyg för åtkomst till och manipulering av det aktuella [`Site`](/sv/5.2/ref/contrib/sites/#django.contrib.sites.models.Site)-objektet i [the sites framework](/sv/5.2/ref/contrib/sites/).
- En [`RequestFactory`](/sv/5.2/topics/testing/advanced/#django.test.RequestFactory) för att mocka förfrågningar i tester.
- Ett nytt testassertment – [`assertNumQueries()`](/sv/5.2/topics/testing/tools/#django.test.TransactionTestCase.assertNumQueries) – gör det enklare att testa databasaktiviteten som är associerad med en vy.
- Stöd för uppslagningar som sträcker sig över relationer i admins [`list_filter`](/sv/5.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_filter).
- Stöd för [HttpOnly](https://owasp.org/www-community/HttpOnly)-cookies.
- [`mail_admins()`](/sv/5.2/topics/email/#django.core.mail.mail_admins) och [`mail_managers()`](/sv/5.2/topics/email/#django.core.mail.mail_managers) stöder nu enkel bifogning av HTML-innehåll till meddelanden.
- [`EmailMessage`](/sv/5.2/topics/email/#django.core.mail.EmailMessage) har nu stöd för CC.
- Felmeddelanden innehåller nu mer av detaljerna och formateringen på debug-serverns felsida.
- [`simple_tag()`](/sv/5.2/howto/custom-template-tags/#django.template.Library.simple_tag) accepterar nu ett `takes_context` argument, vilket gör det enklare att skriva enkla malltaggar som kräver tillgång till mallkontext.
- En ny [`render()`](/sv/5.2/topics/http/shortcuts/#django.shortcuts.render) genväg – ett alternativ till `django.shortcuts.render_to_response()` som tillhandahåller en [`RequestContext`](/sv/5.2/ref/templates/api/#django.template.RequestContext) som standard.
- Stöd för att kombinera [`F uttryck`](/sv/5.2/ref/models/expressions/#django.db.models.F) med `timedelta` värden vid hämtning eller uppdatering av databasvärden.

## Bakåtkompatibla ändringar i 1.3

### CSRF-validering gäller nu för AJAX-förfrågningar

Före Django 1.2.5 undantog Djangos CSRF-förhindrande system AJAX-förfrågningar från CSRF-verifiering; på grund av [säkerhetsproblem](https://www.djangoproject.com/weblog/2011/feb/08/security/) som rapporterats till oss, är dock *alla* förfrågningar nu föremål för CSRF-verifiering. Se [Djangos CSRF-dokumentation](/sv/5.2/ref/csrf/) för detaljer om hur man hanterar CSRF-verifiering i AJAX-förfrågningar.

### Begränsade filter i administratörsgränssnittet

Före Django 1.2.5 tillät Djangos administrativa gränssnitt filtrering på alla modellfält eller relationer - inte bara de som anges i `list_filter` \- via manipulering av frågesträngar. På grund av säkerhetsproblem som rapporterats till oss måste dock argument för uppslagning av frågesträngar i admin vara för fält eller relationer som anges i `list_filter` eller `date_hierarchy`.

### Om du tar bort en modell raderas inte tillhörande filer

I tidigare Django-versioner, när en modellinstans som innehåller en [`FileField`](/sv/5.2/ref/models/fields/#django.db.models.FileField) raderades, tog [`FileField`](/sv/5.2/ref/models/fields/#django.db.models.FileField) på sig att också radera filen från backend-lagringen. Detta öppnade dörren för flera dataförlustscenarier, inklusive rullade transaktioner och fält på olika modeller som refererar till samma fil. I Django 1.3, när en modell raderas, kommer [`FileField`](/sv/5.2/ref/models/fields/#django.db.models.FileField) `delete()` metod inte att anropas. Om du behöver rensa bort föräldralösa filer måste du hantera det själv (t.ex. med ett anpassat hanteringskommando som kan köras manuellt eller schemaläggas för att köras regelbundet via t.ex. cron).

### PasswordInput standard renderingsbeteende

Formwidgeten [`PasswordInput`](/sv/5.2/ref/forms/widgets/#django.forms.PasswordInput), avsedd för användning med formulärfält som representerar lösenord, accepterar ett boolean nyckelordsargument `render_value` som anger om dess data ska skickas tillbaka till webbläsaren när ett inskickat formulär visas med fel. Före Django 1.3 var detta argument som standard `True`, vilket innebär att det inskickade lösenordet skulle skickas tillbaka till webbläsaren som en del av formuläret. Utvecklare som ville lägga till lite extra säkerhet genom att utesluta det värdet från det återvisade formuläret kunde instansiera en [`PasswordInput`](/sv/5.2/ref/forms/widgets/#django.forms.PasswordInput) som passerade `render_value=False` .

På grund av lösenordets känsliga natur tar dock Django 1.3 detta steg automatiskt; standardvärdet för `render_value` är nu `False`, och utvecklare som vill att lösenordsvärdet ska returneras till webbläsaren vid en inlämning med fel (det tidigare beteendet) måste nu uttryckligen ange detta. Till exempel:

```
class LoginForm(forms.Form):
    username = forms.CharField(max_length=100)
    password = forms.CharField(widget=forms.PasswordInput(render_value=True))
```

### Rensbar standardwidget för FileField

Django 1.3 innehåller nu en [`ClearableFileInput`](/sv/5.2/ref/forms/widgets/#django.forms.ClearableFileInput)-form widget utöver [`FileInput`](/sv/5.2/ref/forms/widgets/#django.forms.FileInput). `ClearableFileInput` renderas med en kryssruta för att rensa fältets värde (om fältet har ett värde och inte är obligatoriskt); `FileInput` tillhandahöll inget sätt att rensa en befintlig fil från en `FileField`.

`ClearableFileInput` är nu standardwidgeten för en `FileField`, så befintliga formulär som innehåller `FileField` utan att tilldela en anpassad widget måste ta hänsyn till den eventuella extra kryssrutan i den renderade formulärutmatningen.

Om du vill återgå till den tidigare renderingen (utan möjlighet att rensa `FileField`) använder du widgeten `FileInput` i stället för `ClearableFileInput`. Till exempel, i en `ModelForm` för en hypotetisk `Document` modell med en `FileField` med namnet `document`:

```
from django import forms
from myapp.models import Document

class DocumentForm(forms.ModelForm):
    class Meta:
        model = Document
        widgets = {"document": forms.FileInput}
```

### Nytt index på databasens sessionstabell

Före Django 1.3 hade den databastabell som användes av databasbackend för appen [sessions](/sv/5.2/topics/http/sessions/) inget index på kolumnen `expire_date`. Som ett resultat skulle datumbaserade frågor på sessionstabellen - till exempel den fråga som behövs för att rensa gamla sessioner - vara mycket långsam om det fanns många sessioner.

Om du har ett befintligt projekt som använder databasens sessionsbackend behöver du inte göra något för att anpassa dig till den här ändringen. Du kan dock få en betydande prestandaförbättring om du manuellt lägger till det nya indexet i sessionstabellen. Den SQL som lägger till indexet kan hittas genom att köra adminkommandot `sqlindexes`:

```shell
python manage.py sqlindexes sessions
```

### Inga fler fula ord

Django har historiskt tillhandahållit (och genomdrivit) en lista över svordomar. Kommentarsappen har tillämpat denna lista över svordomar och hindrat människor från att skicka in kommentarer som innehåller någon av dessa svordomar.

Tyvärr var den teknik som användes för att implementera denna lista över svordomar sorgligt naiv och utsatt för [Scunthorpe-problemet](https://en.wikipedia.org/wiki/Scunthorpe_problem). Att förbättra det inbyggda filtret för att åtgärda detta problem skulle kräva betydande insatser, och eftersom bearbetning av naturligt språk inte är den normala domänen för ett webbramverk har vi ”åtgärdat” problemet genom att göra listan över förbjudna ord till en tom lista.

Om du vill återställa det gamla beteendet lägger du helt enkelt till en `PROFANITIES_LIST`-inställning i din inställningsfil som innehåller de ord som du vill förbjuda (se [commit som implementerade den här ändringen](https://github.com/django/django/commit/edd767d2612d891a906268cf590571f541dd164f) om du vill se listan över ord som historiskt sett var förbjudna). Om det är viktigt för dig att undvika svordomar gör du dock klokt i att försöka hitta en bättre och mindre naiv lösning på problemet.

### Lokala smakförändringar

Django 1.3 introducerar följande bakåtkompatibla ändringar för lokala varianter:

- Kanada (ca) – Provinsen ”Newfoundland and Labrador” har fått sin provinskod uppdaterad till ”NL”, istället för den äldre ”NF”. Dessutom har Yukon Territory fått sin provinskod korrigerad till ”YT”, istället för ”YK”.
- Indonesien (id) – Provinsen ”Nanggroe Aceh Darussalam (NAD)” har tagits bort från provinslistan till förmån för den nya officiella beteckningen ”Aceh (ACE)”.
- United States of America (us) – Listan över ”states” som används av `USStateField` har utökats med postnummer för de väpnade styrkorna. Detta är bakåtkompatibelt om du förlitade dig på att `USStateField` inte inkluderade dem.

### Uppdateringar av FormSet

I Django 1.3 har `FormSet` skapande beteende ändrats något. Historiskt sett gjorde klassen ingen skillnad mellan att inte få data och att få en tom ordbok. Detta var inkonsekvent med beteendet i andra delar av ramverket. Från och med 1.3 om du skickar in en tom ordbok kommer `FormSet` att skapa ett `ValidationError`.

Till exempel med en `FormSet`:

```pycon
>>> class ArticleForm(Form):
...     title = CharField()
...     pub_date = DateField()
...
>>> ArticleFormSet = formset_factory(ArticleForm)
```

kommer följande kod att ge upphov till ett `ValidationError`:

```pycon
>>> ArticleFormSet({})
Traceback (most recent call last):
...
ValidationError: [u'ManagementForm data is missing or has been tampered with']
```

om du behöver instansiera en tom `FormSet`, skicka inte in data eller använd `None`:

```pycon
>>> formset = ArticleFormSet()
>>> formset = ArticleFormSet(data=None)
```

### Callables i mallar

Tidigare anropades en callable i en mall automatiskt som en del av variabelupplösningsprocessen endast om den hämtades via attributuppslagning. Detta var en inkonsekvens som kunde leda till ett förvirrande och ohjälpsamt beteende:

```pycon
>>> Template("{{ user.get_full_name }}").render(Context({"user": user}))
u'Joe Bloggs'
>>> Template("{{ full_name }}").render(Context({"full_name": user.get_full_name}))
u'<bound method User.get_full_name of <...
```

Detta har lösts i Django 1.3 - resultatet i båda fallen kommer att vara `u'Joe Bloggs`. Även om det tidigare beteendet inte var användbart för ett mallspråk som är utformat för webbdesigners, och aldrig avsiktligt stöddes, är det möjligt att vissa mallar kan brytas av denna ändring.

### Användning av anpassad SQL för att ladda initiala data i tester

Django tillhandahåller en anpassad SQL-hook som ett sätt att injicera egenhändigt utformad SQL i databassynkroniseringsprocessen. En av de möjliga användningarna för denna anpassade SQL är att infoga data i din databas. Om din anpassade SQL innehåller `INSERT`-satser kommer dessa infogningar att utföras varje gång din databas synkroniseras. Detta inkluderar synkronisering av alla testdatabaser som skapas när du kör en testsvit.

I samband med testningen av Django 1.3 upptäcktes dock att denna funktion aldrig har fungerat helt som utlovat. När du använder databasbackends som inte stöder transaktioner, eller när du använder ett TransactionTestCase, kommer data som har infogats med anpassad SQL inte att vara synliga under testprocessen.

Tyvärr fanns det inget sätt att åtgärda detta problem utan att införa en bakåtkompatibilitet. I stället för att lämna SQL-införda initialdata i ett osäkert tillstånd, tillämpar Django nu policyn att data som infogats av anpassad SQL *inte* kommer att vara synliga under testning.

Den här ändringen påverkar endast testprocessen. Du kan fortfarande använda anpassad SQL för att ladda data till din produktionsdatabas som en del av `syncdb`-processen. Om du vill att data ska finnas under testförhållanden bör du antingen infoga dem med [test fixtures](/sv/5.2/topics/testing/tools/#topics-testing-fixtures) eller med metoden `setUp()` i ditt testfall.

### Ändrad prioritet för laddning av översättningar

Arbete har gjorts för att förenkla, rationalisera och korrekt dokumentera den algoritm som används av Django vid körning för att bygga översättningar från de olika översättningar som finns på disken, nämligen:

För översättningsbara bokstäver som finns i Python-kod och mallar (`'django` gettext-domän):

- Prioriteringarna för översättningar som ingår i applikationer som listas i inställningen [`INSTALLED_APPS`](/sv/5.2/ref/settings/#std-setting-INSTALLED_APPS) ändrades. För att ge ett beteende som överensstämmer med andra delar av Django som också använder en sådan inställning (mallar, etc.) nu, när man bygger den översättning som kommer att göras tillgänglig, har de appar som listas först högre prioritet än de som listas senare.
- Nu är det möjligt att åsidosätta de översättningar som levereras med program genom att använda inställningen [`LOCALE_PATHS`](/sv/5.2/ref/settings/#std-setting-LOCALE_PATHS) vars översättningar nu har högre prioritet än översättningarna i [`INSTALLED_APPS`](/sv/5.2/ref/settings/#std-setting-INSTALLED_APPS)-program. Den relativa prioriteten mellan de värden som anges i denna inställning har också ändrats så att de sökvägar som anges först har högre prioritet än de som anges senare.
- Underkatalogen `locale` i katalogen som innehåller inställningarna, som vanligtvis sammanfaller med och är känd som *projektkatalogen*, kommer i den här utgåvan inte längre att användas som källa för översättningar. (Prioriteten för dessa översättningar ligger mellan översättningar av program och [`LOCALE_PATHS`](/sv/5.2/ref/settings/#std-setting-LOCALE_PATHS)). Se avsnittet [motsvarande borttagna funktioner](#loading-of-project-level-translations) i detta dokument.

För översättningsbara bokstäver som finns i JavaScript-kod (`'djangojs` gettext-domän):

- På samma sätt som översättningarna för `'django'`-domänen: Åsidosättande av översättningar som levereras med applikationer genom att använda inställningen [`LOCALE_PATHS`](/sv/5.2/ref/settings/#std-setting-LOCALE_PATHS) är nu möjligt även för denna domän. Dessa översättningar har högre prioritet än översättningarna av Python-paket som skickas till vyn `javascript_catalog()`. Sökvägar som listas först har högre prioritet än de som listas senare.
- Översättningar i underkatalogen `locale` i *projektkatalogen* har aldrig tagits med i beräkningen för JavaScript-översättningar och situationen är fortfarande densamma med tanke på att denna plats inte längre är aktuell.

### Transaktionshantering

När du använder hanterade transaktioner - det vill säga allt annat än standardautocommit-läget - är det viktigt när en transaktion markeras som ”dirty”. Dirty-transaktioner bekräftas av dekoratorn `commit_on_success` eller `django.middleware.transaction.TransactionMiddleware`, och `commit_manually` tvingar dem att stängas uttryckligen; rena transaktioner ”får ett pass”, vilket innebär att de vanligtvis rullas tillbaka i slutet av en begäran när anslutningen stängs.

Fram till Django 1.3 markerades transaktioner endast som smutsiga när Django var medveten om en modifierande operation som utfördes i dem; det vill säga antingen sparades någon modell, någon bulkuppdatering eller radering utfördes, eller så kallade användaren uttryckligen `transaction.set_dirty()`. I Django 1.3 markeras en transaktion som dirty när *någon* databasoperation utförs.

Som ett resultat av den här ändringen behöver du inte längre uttryckligen ange att en transaktion är smutsig när du kör rå SQL eller använder en datamodifierande `SELECT`. Du *behöver* dock uttryckligen stänga alla skrivskyddade transaktioner som hanteras med hjälp av `commit_manually()`. Till exempel:

```
@transaction.commit_manually
def my_view(request, name):
    obj = get_object_or_404(MyObject, name__iexact=name)
    return render_to_response("template", {"object": obj})
```

Före Django 1.3 skulle detta fungera utan fel. Men under Django 1.3 kommer detta att ge upphov till ett [`TransactionManagementError`](/sv/5.2/ref/exceptions/#django.db.transaction.TransactionManagementError) eftersom läsoperationen som hämtar `MyObject`-instansen lämnar transaktionen i ett smutsigt tillstånd.

### Ingen återställning av lösenord för inaktiva användare

Före Django 1.3 kunde inaktiva användare begära ett e-postmeddelande om återställning av lösenord och återställa sitt lösenord. I Django 1.3 kommer inaktiva användare att få samma meddelande som ett icke-existerande konto.

### Lösenordsåterställningsvyn accepterar nu `from_email`

Vyn `django.contrib.auth.views.password_reset()` accepterar nu en `from_email`-parameter, som skickas till `password_reset_form` `save()`-metoden som ett nyckelordsargument. Om du använder den här vyn med ett anpassat formulär för återställning av lösenord måste du se till att formulärets `save()`-metod accepterar det här nyckelordsargumentet.

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

Django 1.3 tar bort vissa funktioner från tidigare utgåvor. Dessa funktioner stöds fortfarande, men kommer gradvis att fasas ut under de kommande utgivningscyklerna.

Kod som utnyttjar någon av funktionerna nedan kommer att ge upphov till en `PendingDeprecationWarning` i Django 1.3. Denna varning är tyst som standard, men kan aktiveras med Pythons modul [`warnings`](https://docs.python.org/3/library/warnings.html#module-warnings) eller genom att köra Python med flaggan `-Wd` eller `-Wall`.

I Django 1.4 kommer dessa varningar att bli en `DeprecationWarning`, som *inte* är tyst. I Django 1.5 kommer stödet för dessa funktioner att tas bort helt och hållet.

> **See also**
>
> För mer information, se dokumentationen Djangos releaseprocess och vår [deprecation tidslinje](/sv/5.2/internals/deprecation/).

### stöd för `mod_python`

Biblioteket `mod_python` har inte haft en release sedan 2007 eller en commit sedan 2008. Styrelsen för Apache Foundation röstade för att ta bort `mod_python` från uppsättningen aktiva projekt i dess versionshanteringsarkiv och dess huvudutvecklare har flyttat alla sina ansträngningar till den lättare, smalare, stabilare och mer flexibla `mod_wsgi` backend.

Om du för närvarande använder begäranhanteraren `mod_python` bör du distribuera om dina Django-projekt med hjälp av en annan begäranhanterare. [mod\_wsgi](/sv/5.2/howto/deployment/wsgi/modwsgi/) är den begäranhanterare som rekommenderas av Django-projektet, men FastCGI stöds också. Stöd för `mod_python`-distribution kommer att tas bort i Django 1.5.

### Funktionsbaserade generiska vyer

Som ett resultat av införandet av klassbaserade generiska vyer har de funktionsbaserade generiska vyerna som tillhandahålls av Django utgått. Följande moduler och de vyer de innehåller har utgått:

- `django.views.generic.create_update`
- `django.views.generic.date_based` `django.views.generic.date_based`
- `django.views.generic.list_detail`
- `django.views.generic.simple`

### Testa attributet `template` för klientsvar

Djangos [test client](/sv/5.2/topics/testing/tools/#test-client) returnerar [`Response`](/sv/5.2/topics/testing/tools/#django.test.Response)-objekt annoterade med extra testinformation. I Django-versioner före 1.3 inkluderade detta ett `template`-attribut som innehöll information om mallar som användes för att generera svaret: antingen None, ett enda [`Template`](/sv/5.2/ref/templates/api/#django.template.Template)-objekt eller en lista över [`Template`](/sv/5.2/ref/templates/api/#django.template.Template)-objekt. Denna inkonsekvens i returvärden (ibland en lista, ibland inte) gjorde attributet svårt att arbeta med.

I Django 1.3 är attributet `template` avskrivet till förmån för ett nytt [`templates`](/sv/5.2/topics/testing/tools/#django.test.Response.templates)-attribut, som alltid är en lista, även om den bara har ett enda element eller inga element.

### `DjangoTestRunner`

Som ett resultat av införandet av stöd för `unittest2`, har funktionerna i `django.test.simple.DjangoTestRunner` (inklusive fail-fast och Ctrl-C testavslut) blivit överflödiga. Med tanke på denna redundans har `DjangoTestRunner` förvandlats till en tom platshållarklass och kommer att tas bort helt i Django 1.5.

### Ändringar av `url` och `ssi`

De flesta malltaggar tillåter dig att skicka in antingen konstanter eller variabler som argument - till exempel:

```html+django
{% extends "base.html" %}
```

kan du ange en basmall som en konstant, men om du har en kontextvariabel `templ` som innehåller värdet `base.html`:

```html+django
{% extends templ %}
```

är också lagligt.

På grund av en historisk tillfällighet är dock `url` och `ssi` olika. Dessa taggar använder den andra, citatlösa syntaxen, men tolkar argumentet som en konstant. Det innebär att det inte är möjligt att använda en kontextvariabel som mål för en `url`\- och `ssi`-tagg.

Django 1.3 markerar starten på processen att rätta till denna historiska olycka. Django 1.3 lägger till ett nytt mallbibliotek - `future` \- som tillhandahåller alternativa implementationer av malltaggarna `url` och `ssi`. Detta `future`-bibliotek implementerar ett beteende som gör hanteringen av det första argumentet konsekvent med hanteringen av alla andra variabler. Så, en befintlig mall som innehåller:

```html+django
{% url sample %}
```

bör ersättas med:

```html+django
{% load url from future %}
{% url 'sample' %}
```

De taggar som implementerar det gamla beteendet har utgått och i Django 1.5 kommer det gamla beteendet att ersättas med det nya beteendet. För att säkerställa kompatibilitet med framtida versioner av Django bör befintliga mallar ändras så att de använder de nya `future`-biblioteken och syntaxen.

### Ändringar av inloggningsmetoderna för administratören

I den tidigare versionen definierade admin-appen inloggningsmetoder på flera platser och ignorerade den nästan identiska implementeringen i den redan använda auth-appen. En bieffekt av denna duplicering var att ändringarna som gjordes i [r12634](https://github.com/django/django/commit/c8015052d935a99a5c8f96434b2d0cd16d8a4e14) för att stödja en bredare uppsättning tecken för användarnamn inte antogs.

Denna utgåva refaktoriserar admins inloggningsmekanism för att använda en underklass av [`AuthenticationForm`](/sv/5.2/topics/auth/default/#django.contrib.auth.forms.AuthenticationForm) istället för en manuell formulärvalidering. Den tidigare odokumenterade metoden `'django.contrib.admin.sites.AdminSite.display_login_form'` har tagits bort till förmån för ett nytt [`login_form`](/sv/5.2/ref/contrib/admin/#django.contrib.admin.AdminSite.login_form)-attribut.

### hanteringskommandona `reset` och `sqlreset`

Dessa kommandon har tagits ur bruk. Kommandona `flush` och `sqlflush` kan användas för att radera allt. Du kan också använda ALTER TABLE- eller DROP TABLE-satser manuellt.

### GeoDjango

- Den funktionsbaserade [`TEST_RUNNER`](/sv/5.2/ref/settings/#std-setting-TEST_RUNNER) som tidigare användes för att köra GeoDjango-testsviten, `django.contrib.gis.tests.run_gis_tests`, utrangerades för den klassbaserade löparen, `django.contrib.gis.tests.GeoDjangoTestSuiteRunner`.
- Tidigare kunde anrop av [`transform()`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.transform) inte göra någonting när GDAL inte var tillgängligt.  Nu genereras en [`GEOSException`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSException) på rätt sätt för att indikera eventuell felaktig applikationskod.  En varning utfärdas nu om [`transform()`](/sv/5.2/ref/contrib/gis/geos/#django.contrib.gis.geos.GEOSGeometry.transform) anropas när geometrins SRID är mindre än 0 eller `None`.

### `CZBirthNumberField.clean`

Tidigare accepterade detta fälts `clean()`-metod ett andra argument, kön, som gjorde det möjligt att göra starkare valideringskontroller, men eftersom detta argument aldrig faktiskt kunde skickas från Django-formulärsmaskineriet är det nu i väntan på avskrivning.

### `CompatCookie`

Tidigare exponerade `django.http` en odokumenterad `CompatCookie`-klass, som var en buggfixad omslag runt standardbibliotekets `SimpleCookie`. Eftersom korrigeringarna flyttas uppströms är detta nu föråldrat - du bör använda `from django.http import SimpleCookie` istället.

### Inläsning av översättningar på projektnivå

Denna utgåva av Django startar utfasningsprocessen för inkludering av översättningar som ligger under den så kallade *projektsökvägen* i översättningsbyggnadsprocessen som utförs vid körning. Inställningen [`LOCALE_PATHS`](/sv/5.2/ref/settings/#std-setting-LOCALE_PATHS) kan användas för samma uppgift genom att lägga till filsystemets sökväg till en `locale`-katalog som innehåller översättningar på projektnivå till värdet för den inställningen.

Motivering för detta beslut:

- Projektsökvägen\* har alltid varit ett löst definierat begrepp (den katalog som används för att hitta översättningar på projektnivå är faktiskt den katalog som innehåller inställningsmodulen) och det har skett en förändring i andra delar av ramverket så att den inte längre används som referens för placering av tillgångar under körning.
- Detektering av underkatalogen `locale` tenderar att misslyckas när distributionsscenariot är mer komplext än det grundläggande. t.ex. misslyckas det när inställningsmodulen är en katalog (ärende #10765).
- Det finns potentiella konstiga problem under utvecklings- och driftsättningstiden, som det faktum att underkatalogen `project_dir/locale/` kan generera falska felmeddelanden när projektkatalogen läggs till i Python-sökvägen (`manage.py runserver` gör detta) och sedan krockar med den liknamnade standardbiblioteksmodulen, detta är ett typiskt varningsmeddelande:

  ```pytb
  /usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory '/path/to/project/locale': missing __init__.py.
  import locale, copy, os, re, struct, sys
  ```
- Den här platsen ingick inte i översättningsskapandeprocessen för JavaScript-litteraler. Denna depreciering tar bort sådan inkonsekvens.

### `PermWrapper` flyttad till `django.contrib.auth.context_processors`

I Django 1.2 började vi processen med att ändra platsen för `auth` kontextprocessorn från `django.core.context_processors` till `django.contrib.auth.context_processors`. Stödklassen `PermWrapper` utelämnades dock av misstag från den migreringen. I Django 1.3 har klassen `PermWrapper` också flyttats till `django.contrib.auth.context_processors`, tillsammans med supportklassen `PermLookupDict`. De nya klasserna är funktionellt identiska med sina gamla versioner; endast modulens plats har ändrats.

### Borttagning av `XMLField`

När Django först släpptes inkluderade Django en `XMLField` som utförde automatisk XML-validering för alla fältinmatningar. Denna valideringsfunktion har dock inte utförts sedan introduktionen av `newforms`, före 1.0-utgåvan. Som ett resultat är `XMLField` som det för närvarande implementeras funktionellt oskiljbart från en enkel [`TextField`](/sv/5.2/ref/models/fields/#django.db.models.TextField).

Av denna anledning har Django 1.3 påskyndat utfasningen av `XMLField` \- istället för en utfasning i två releaser kommer `XMLField` att tas bort helt i Django 1.4.

Det är enkelt att uppdatera din kod för att tillgodose denna ändring - ersätt bara alla användningar av `XMLField` med `TextField` och ta bort nyckelordsargumentet `schema_path` (om det anges).