--- title: "Django 1.9 versionsinformation" version: 6.0 locale: sv source: https://docs.djangoproject.com/sv/6.0/releases/1.9/ canonical: https://djangodocs.dev/sv/6.0/releases/1.9/ --- # Django 1.9 versionsinformation *1 december 2015* Välkommen till Django 1.9! Dessa versionsinformation täcker de [nya funktionerna](#whats-new-1-9), samt några [bakåtkompatibla ändringar](#backwards-incompatible-1-9) som du vill vara medveten om när du uppgraderar från Django 1.8 eller äldre versioner. Vi har [ta bort några funktioner](#removed-features-1-9) som har nått slutet av sin utfasningscykel, och vi har [startat utfasningsprocessen för vissa funktioner](#deprecated-features-1-9). Se guiden [Så här uppgraderar du Django till en nyare version](/sv/6.0/howto/upgrade-version/) om du ska uppdatera ett befintligt projekt. ## Kompatibilitet med Python Django 1.9 kräver Python 2.7, 3.4 eller 3.5. Vi rekommenderar **starkt** och stöder endast officiellt den senaste versionen av varje serie. Django 1.8-serien är den sista som stöder Python 3.2 och 3.3. ## Vad är nytt i Django 1.9 ### Utföra åtgärder efter en transaktionspassning Den nya [`on_commit()`](/sv/6.0/topics/db/transactions/#django.db.transaction.on_commit)-hook gör det möjligt att utföra åtgärder efter att en databastransaktion har genomförts. Detta är användbart för uppgifter som att skicka e-postmeddelanden, skapa köade uppgifter eller inaktivera cacheminnen. Denna funktionalitet från paketet [django-transaction-hooks](https://pypi.org/project/django-transaction-hooks/) har integrerats i Django. ### Validering av lösenord Django erbjuder nu validering av lösenord för att förhindra att användare använder svaga lösenord. Valideringen är integrerad i de medföljande formulären för lösenordsändring och återställning och är enkel att integrera i annan kod. Valideringen utförs av en eller flera validerare, som konfigureras i den nya inställningen [`AUTH_PASSWORD_VALIDATORS`](/sv/6.0/ref/settings/#std-setting-AUTH_PASSWORD_VALIDATORS). Fyra validerare ingår i Django, som kan genomdriva en minimilängd, jämföra lösenordet med användarens attribut som namn, säkerställa att lösenord inte är helt numeriska eller kontrollera mot en medföljande lista över vanliga lösenord. Du kan kombinera flera validerare, och vissa validerare har anpassade konfigurationsalternativ. Du kan t.ex. välja att tillhandahålla en anpassad lista över vanliga lösenord. Varje validerare innehåller en hjälptext som förklarar dess krav för användaren. Som standard utförs ingen validering och alla lösenord accepteras, så om du inte ställer in [`AUTH_PASSWORD_VALIDATORS`](/sv/6.0/ref/settings/#std-setting-AUTH_PASSWORD_VALIDATORS) kommer du inte att se någon förändring. I nya projekt som skapas med standardmallen [`startproject`](/sv/6.0/ref/django-admin/#django-admin-startproject) aktiveras en enkel uppsättning validerare. För att aktivera grundläggande validering i de auth-formulär som ingår i ditt projekt kan du till exempel ställa in: ``` AUTH_PASSWORD_VALIDATORS = [ { "NAME": "django.contrib.auth.password_validation.UserAttributeSimilarityValidator", }, { "NAME": "django.contrib.auth.password_validation.MinimumLengthValidator", }, { "NAME": "django.contrib.auth.password_validation.CommonPasswordValidator", }, { "NAME": "django.contrib.auth.password_validation.NumericPasswordValidator", }, ] ``` Se [Validering av lösenord](/sv/6.0/topics/auth/passwords/#password-validation) för mer information. ### Behörighetsmixins för klassbaserade vyer Django levereras nu med mixinerna [`AccessMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.AccessMixin), [`LoginRequiredMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.LoginRequiredMixin), [`PermissionRequiredMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.PermissionRequiredMixin), och [`UserPassesTestMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin) för att tillhandahålla funktionaliteten i `django.contrib.auth.decorators` för klassbaserade vyer. Dessa mixins har hämtats från, eller är åtminstone inspirerade av, projektet [django-braces](https://django-braces.readthedocs.io/en/latest/index.html). Det finns dock några skillnader mellan Djangos och `django-braces` implementering: - Attributet [`raise_exception`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.AccessMixin.raise_exception) kan endast vara `True` eller `False`. Egna undantag eller callables stöds inte. - Metoden [`handle_no_permission()`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.AccessMixin.handle_no_permission) tar inte ett `request` argument. Den aktuella begäran finns tillgänglig i `self.request`. - Den anpassade `test_func()` av [`UserPassesTestMixin`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin) tar inte ett `user` argument. Den aktuella användaren finns tillgänglig i `self.request.user`. - Attributet [`permission_required`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.PermissionRequiredMixin) stöder en sträng (som definierar en behörighet) eller en lista/tupel av strängar (som definierar flera behörigheter) som måste uppfyllas för att ge åtkomst. - Det nya attributet [`permission_denied_message`](/sv/6.0/topics/auth/default/#django.contrib.auth.mixins.AccessMixin.permission_denied_message) gör det möjligt att skicka ett meddelande till undantaget `PermissionDenied`. ### Ny styling för `contrib.admin` Administratören har en modern, platt design med nya SVG-ikoner som ser perfekta ut på HiDPI-skärmar. Den ger fortfarande en fullt fungerande upplevelse till [YUI:s A-grade](https://github.com/yui/yui3/wiki/Graded-Browser-Support) webbläsare. Äldre webbläsare kan uppleva varierande nivåer av graciös nedbrytning. ### Kör tester parallellt Kommandot [`test`](/sv/6.0/ref/django-admin/#django-admin-test) stöder nu alternativet [`--parallel`](/sv/6.0/ref/django-admin/#cmdoption-test-parallel) för att köra ett projekts tester i flera processer parallellt. Varje process får sin egen databas. Du måste se till att olika testfall inte får tillgång till samma resurser. Exempelvis bör testfall som rör filsystemet skapa en tillfällig katalog för eget bruk. Detta alternativ är aktiverat som standard för Djangos egen testsvit som tillhandahålls: - operativsystemet stöder det (alla utom Windows) - databasens backend stöder det (alla inbyggda backends utom Oracle) ### Mindre funktioner #### [`django.contrib.admin`](/sv/6.0/ref/contrib/admin/#module-django.contrib.admin) - Admin-vyer har nu attributen `model_admin` eller `admin_site`. - URL:en för adminändringsvyn har ändrats (var `/admin////` som standard och är nu `/admin////change/`). Detta bör inte påverka din applikation om du inte har hårdkodade administratörsadresser. I så fall ska du ersätta dessa länkar med [reversing admin URLs](/sv/6.0/ref/contrib/admin/#admin-reverse-urls) istället. Observera att den gamla webbadressen fortfarande omdirigeras till den nya för bakåtkompatibilitet, men den kan tas bort i en framtida version. - [`ModelAdmin.get_list_select_related()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_list_select_related) lades till för att tillåta ändring av `select_related()`-värdena som används i admins changelist-fråga baserat på begäran. - Kontextvariabeln `available_apps`, som listar tillgängliga applikationer för den aktuella användaren, har lagts till i metoden [`AdminSite.each_context()`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.AdminSite.each_context). - [`AdminSite.empty_value_display`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.AdminSite.empty_value_display) och [`ModelAdmin.empty_value_display`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin.empty_value_display) lades till för att åsidosätta visningen av tomma värden i adminändringslistan. Du kan också anpassa värdet för varje fält. - Lagt till jQuery-händelser [när ett inline-formulär läggs till eller tas bort](/sv/6.0/ref/contrib/admin/javascript/#admin-javascript-inline-form-events) på sidan för ändringsformulär. - Tidsväljarwidgeten innehåller ett alternativ ”6 p.m.” för att konsekvent ha fördefinierade alternativ var 6:e timme. - JavaScript slug-generering stöder nu rumänska tecken. #### [`django.contrib.admindocs`](/sv/6.0/ref/contrib/admin/admindocs/#module-django.contrib.admindocs) - I modellavsnittet i `admindocs` beskrivs nu även metoder som tar argument, istället för att ignorera dem. #### [`django.contrib.auth`](/sv/6.0/topics/auth/#module-django.contrib.auth) - Standardantalet iterationer för PBKDF2-lösenordshasher har ökats med 20%. Denna bakåtkompatibla ändring kommer inte att påverka användare som har underklassat `django.contrib.auth.hashers.PBKDF2PasswordHasher` för att ändra standardvärdet. - `BCryptSHA256PasswordHasher` kommer nu att uppdatera lösenord om dess `rounds` attribut ändras. - `AbstractBaseUser` och `BaseUserManager` flyttades till en ny `django.contrib.auth.base_user`-modul så att de kan importeras utan att inkludera `django.contrib.auth` i [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-INSTALLED_APPS) (att göra det gav upphov till en varning om föråldring i äldre versioner och stöds inte längre i Django 1.9). - The permission argument of [`permission_required()`](/sv/6.0/topics/auth/default/#django.contrib.auth.decorators.permission_required) accepts all kinds of iterables, not only list and tuples. - Den nya [`PersistentRemoteUserMiddleware`](/sv/6.0/ref/middleware/#django.contrib.auth.middleware.PersistentRemoteUserMiddleware) gör det möjligt att använda `REMOTE_USER` för inställningar där rubriken endast fylls i på inloggningssidor istället för varje begäran i sessionen. - Vyn `django.contrib.auth.views.password_reset()` accepterar en `extra_email_context` parameter. #### [`django.contrib.contenttypes`](/sv/6.0/ref/contrib/contenttypes/#module-django.contrib.contenttypes) - Det är nu möjligt att använda [`order_with_respect_to`](/sv/6.0/ref/models/options/#django.db.models.Options.order_with_respect_to) med en `GenericForeignKey`. #### [`django.contrib.gis`](/sv/6.0/ref/contrib/gis/#module-django.contrib.gis) - Alla `GeoQuerySet`-metoder har utgått och ersatts av [ekvivalenta databasfunktioner](/sv/6.0/ref/contrib/gis/functions/). Så snart de äldre metoderna har ersatts i din kod bör du till och med kunna ta bort den speciella `GeoManager` från dina GIS-aktiverade klasser. - GDAL-gränssnittet stöder nu instansiering av filbaserade och minnesbaserade [GDALRaster-objekt](/sv/6.0/ref/contrib/gis/gdal/#raster-data-source-objects) från rådata. Setters för rasteregenskaper som projektion eller pixelvärden har lagts till. - För PostGIS-användare tillåter den nya [`RasterField`](/sv/6.0/ref/contrib/gis/model-api/#django.contrib.gis.db.models.RasterField) [lagring av GDALRaster-objekt](/sv/6.0/ref/contrib/gis/db-api/#creating-and-saving-raster-models). Den stöder automatisk skapande av rumsliga index och återprojektion när en modell sparas. Den stöder ännu inte rumsliga frågor. - Den nya [`GDALRaster.warp()`](/sv/6.0/ref/contrib/gis/gdal/#django.contrib.gis.gdal.GDALRaster.warp)-metoden gör det möjligt att warpa en raster genom att ange målrasteregenskaper som ursprung, bredd, höjd eller pixelstorlek (bland andra). - Den nya [`GDALRaster.transform()`](/sv/6.0/ref/contrib/gis/gdal/#django.contrib.gis.gdal.GDALRaster.transform)-metoden gör det möjligt att omvandla ett raster till ett annat rumsligt referenssystem genom att ange ett mål `srid`. - Den nya [`GeoIP2`](/sv/6.0/ref/contrib/gis/geoip2/#django.contrib.gis.geoip2.GeoIP2)-klassen gör det möjligt att använda MaxMinds GeoLite2-databaser som inkluderar stöd för IPv6-adresser. - Standardversionen av OpenLayers-biblioteket som ingår i widgetar har uppdaterats från 2.13 till 2.13.1. #### [`django.contrib.postgres`](/sv/6.0/ref/contrib/postgres/#module-django.contrib.postgres) - Lagt till stöd för [`rangefield.contained_by`](/sv/6.0/ref/contrib/postgres/fields/#std-fieldlookup-rangefield.contained_by) lookup för vissa inbyggda fält som motsvarar intervallfälten. - Lade till `django.contrib.postgres.fields.JSONField`. - Lagt till [PostgreSQL-specifika aggregeringsfunktioner](/sv/6.0/ref/contrib/postgres/aggregates/). - Lagt till databasfunktionen [`TransactionNow`](/sv/6.0/ref/contrib/postgres/functions/#django.contrib.postgres.functions.TransactionNow). #### [`django.contrib.sessions`](/sv/6.0/topics/http/sessions/#module-django.contrib.sessions) - Sessionsmodellen och klasserna `SessionStore` för backends `db` och `cached_db` har omarbetats så att en anpassad databas-sessionsbackend kan bygga vidare på dem. Se [Utökning av databasstödda sessionsmotorer](/sv/6.0/topics/http/sessions/#extending-database-backed-session-engines) för mer information. #### [`django.contrib.sites`](/sv/6.0/ref/contrib/sites/#module-django.contrib.sites) - [`get_current_site()`](/sv/6.0/ref/contrib/sites/#django.contrib.sites.shortcuts.get_current_site) hanterar nu fallet där `request.get_host()` returnerar `domän:port`, t.ex. `example.com:80`. Om sökningen misslyckas på grund av att värden inte matchar en post i databasen och värden har en port, tas porten bort och sökningen görs om med endast domändelen. #### [`django.contrib.syndication`](/sv/6.0/ref/contrib/syndication/#module-django.contrib.syndication) - Stöd för flera bilagor per flödesobjekt har lagts till. Om flera inneslutningar definieras i ett RSS-flöde uppstår ett undantag eftersom RSS-flöden, till skillnad från Atom-flöden, inte stöder flera inneslutningar per flödesobjekt. #### Cache - `django.core.cache.backends.base.BaseCache` har nu en `get_or_set()` metod. - [`django.views.decorators.cache.never_cache()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.never_cache) skickar nu mer övertygande rubriker (lagt till `no-cache, no-store, must-revalidate` till `Cache-Control`) för att bättre förhindra cachelagring. Detta lades också till i Django 1.8.8. #### CSRF - Namnet på begäranhuvudet som används för CSRF-autentisering kan anpassas med [`CSRF_HEADER_NAME`](/sv/6.0/ref/settings/#std-setting-CSRF_HEADER_NAME). - CSRF-refererhuvudet valideras nu mot inställningen [`CSRF_COOKIE_DOMAIN`](/sv/6.0/ref/settings/#std-setting-CSRF_COOKIE_DOMAIN) om den är inställd. Se [Hur det fungerar](/sv/6.0/ref/csrf/#how-csrf-works) för detaljer. - Den nya inställningen [`CSRF_TRUSTED_ORIGINS`](/sv/6.0/ref/settings/#std-setting-CSRF_TRUSTED_ORIGINS) ger ett sätt att tillåta osäkra förfrågningar (t.ex. `POST`) över HTTPS. #### Databas backends - PostgreSQL backend (`django.db.backends.postgresql_psycopg2`) är också tillgänglig som `django.db.backends.postgresql`. Det gamla namnet kommer att fortsätta att vara tillgängligt för bakåtkompatibilitet. #### Fil delning - [`Storage.get_valid_name()`](/sv/6.0/ref/files/storage/#django.core.files.storage.Storage.get_valid_name) anropas nu när [`upload_to`](/sv/6.0/ref/models/fields/#django.db.models.FileField.upload_to) är en callable. - [`File`](/sv/6.0/ref/files/file/#django.core.files.File) har nu metoden `seekable()` när Python 3 används. #### Formulär - [`ModelForm`](/sv/6.0/topics/forms/modelforms/#django.forms.ModelForm) accepterar det nya `Meta`-alternativet `field_classes` för att anpassa typen av fält. Se [Åsidosätta standardfälten](/sv/6.0/topics/forms/modelforms/#modelforms-overriding-default-fields) för mer information. - Du kan nu ange i vilken ordning formulärfälten ska återges med attributet [`field_order`](/sv/6.0/ref/forms/api/#django.forms.Form.field_order), konstruktörsargumentet `field_order` eller metoden [`order_fields()`](/sv/6.0/ref/forms/api/#django.forms.Form.order_fields). - Ett formulärprefix kan anges i en formulärklass, inte bara när ett formulär instansieras. Se [Prefix för former](/sv/6.0/ref/forms/api/#form-prefix) för mer information. - Du kan nu [specificera nyckelordsargument](/sv/6.0/topics/forms/formsets/#custom-formset-form-kwargs) som du vill skicka till konstruktören av formulär i en formuläruppsättning. - [`SlugField`](/sv/6.0/ref/forms/fields/#django.forms.SlugField) accepterar nu ett [`allow_unicode`](/sv/6.0/ref/forms/fields/#django.forms.SlugField.allow_unicode)-argument för att tillåta Unicode-tecken i slugs. - [`CharField`](/sv/6.0/ref/forms/fields/#django.forms.CharField) now accepts a [`strip`](/sv/6.0/ref/forms/fields/#django.forms.CharField.strip) argument to strip input data of leading and trailing whitespace. As this defaults to `True` this is different behavior from previous releases. - Formulärfält har nu stöd för argumentet [`disabled`](/sv/6.0/ref/forms/fields/#django.forms.Field.disabled), vilket gör att fältwidgeten kan visas inaktiverad i webbläsare. - It’s now possible to customize bound fields by overriding a field’s [`get_bound_field()`](/sv/6.0/ref/forms/fields/#django.forms.Field.get_bound_field) method. #### Generiska åsikter - Klassbaserade vyer som genereras med `as_view()` har nu attributen `view_class` och `view_initkwargs`. - [`method_decorator()`](/sv/6.0/ref/utils/#django.utils.decorators.method_decorator) kan nu användas med en lista eller tupel av dekoratorer. Det kan också användas för att [dekorera klasser istället för metoder](/sv/6.0/topics/class-based-views/intro/#id1). #### Internationalisering - Vyn [`django.views.i18n.set_language()`](/sv/6.0/topics/i18n/translation/#django.views.i18n.set_language) omdirigerar nu korrekt till [översatta webbadresser](/sv/6.0/topics/i18n/translation/#url-internationalization), när det finns tillgängligt. - Vyn `django.views.i18n.javascript_catalog()` fungerar nu korrekt om den används flera gånger med olika konfigurationer på samma sida. - Funktionen [`django.utils.timezone.make_aware()`](/sv/6.0/ref/utils/#django.utils.timezone.make_aware) har fått ett `is_dst`-argument för att hjälpa till att lösa tvetydiga tider under DST-övergångar. - Du kan nu använda lokalvarianter som stöds av gettext. Dessa används vanligtvis för språk som kan skrivas med olika skript, t.ex. latin och kyrilliska (t.ex. `be@latin`). - Lade till vyn `django.views.i18n.json_catalog()` för att hjälpa till att bygga ett anpassat i18n-bibliotek på klientsidan på Django-översättningar. Den returnerar ett JSON-objekt som innehåller en översättningskatalog, formateringsinställningar och en pluralregel. - Lade till attributet `name_translated` till objektet som returneras av [`get_language_info`](/sv/6.0/topics/i18n/translation/#std-templatetag-get_language_info) malltaggen. Lade också till ett motsvarande mallfilter: [`language_name_translated`](/sv/6.0/topics/i18n/translation/#std-templatefilter-language_name_translated). - Du kan nu köra [`compilemessages`](/sv/6.0/ref/django-admin/#django-admin-compilemessages) från rotkatalogen i ditt projekt och den kommer att hitta alla appmeddelandefiler som skapades av [`makemessages`](/sv/6.0/ref/django-admin/#django-admin-makemessages). - [`makemessages`](/sv/6.0/ref/django-admin/#django-admin-makemessages) anropar nu `xgettext` en gång per lokalkatalog istället för en gång per översättningsbar fil. Detta snabbar upp byggandet av lokaliseringar. - [`blocktrans`](/sv/6.0/topics/i18n/translation/#std-templatetag-blocktrans) stöder tilldelning av dess utdata till en variabel med hjälp av `asvar`. - Två nya språk finns nu tillgängliga: Colombiansk spanska och skotsk gaeliska. #### Kommandon för hantering - Med det nya kommandot [`sendtestemail`](/sv/6.0/ref/django-admin/#django-admin-sendtestemail) kan du skicka ett testmejl för att enkelt bekräfta att det fungerar att skicka e-post via Django. - För att öka läsbarheten i SQL-koden som genereras av [`sqlmigrate`](/sv/6.0/ref/django-admin/#django-admin-sqlmigrate), föregås SQL-koden som genereras för varje migreringsoperation av en beskrivning av operationen. - Utdata från kommandot [`dumpdata`](/sv/6.0/ref/django-admin/#django-admin-dumpdata) är nu deterministiskt ordnad. När alternativet `--output` anges visas dessutom en förloppsindikator i terminalen. - Kommandot [`createcachetable`](/sv/6.0/ref/django-admin/#django-admin-createcachetable) har nu en `--dry-run` flagga för att skriva ut SQL istället för att köra den. - Kommandot [`startapp`](/sv/6.0/ref/django-admin/#django-admin-startapp) skapar en fil med namnet `apps.py`. Eftersom det inte använder `default_app_config` ([ett avrått API](/sv/6.0/ref/applications/#configuring-applications-ref)), måste du ange appkonfigurationens sökväg, t.ex. `'polls.apps.PollsConfig'`, i [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-INSTALLED_APPS) för att den ska användas (istället för bara `'polls'`). - När du använder PostgreSQL-backend kan kommandot [`dbshell`](/sv/6.0/ref/django-admin/#django-admin-dbshell) ansluta till databasen med lösenordet från din inställningsfil (istället för att kräva att det anges manuellt). - Paketet `django` kan köras som ett skript, t.ex. `python -m django`, vilket kommer att bete sig på samma sätt som `django-admin`. - Hanteringskommandon som har alternativet `--noinput` tar nu också `--no-input` som ett alias för det alternativet. #### Migreringar - Initiala migreringar markeras nu med ett klassattribut [`initial = True`](/sv/6.0/topics/migrations/#django.db.migrations.Migration.initial) vilket gör att [`migrate --fake-initial`](/sv/6.0/ref/django-admin/#cmdoption-migrate-fake-initial) lättare kan upptäcka initiala migreringar. - Lagt till stöd för serialisering av `functools.partial` och `LazyObject` instanser. - När man anger `None` som värde i [`MIGRATION_MODULES`](/sv/6.0/ref/settings/#std-setting-MIGRATION_MODULES), kommer Django att betrakta appen som en app utan migreringar. - Vid tillämpning av migreringar beräknar nu steget ”Rendering av modelltillstånd”, som visas när migrate körs med verbosity 2 eller högre, endast tillstånden för de migreringar som redan har tillämpats. Modelltillstånden för migreringar som tillämpas genereras på begäran, vilket drastiskt minskar mängden minne som krävs. Denna förbättring är dock inte tillgänglig när migreringar inte tillämpas och kräver därför fortfarande förberäkning och lagring av de mellanliggande migreringstillstånden. Denna förbättring kräver också att Django inte längre stöder blandade migreringsplaner. Blandade planer består av en lista med migreringar där vissa tillämpas och andra inte tillämpas. Detta stöddes aldrig officiellt och det fanns aldrig något offentligt API som stödde detta beteende. - Kommandot [`squashmigrations`](/sv/6.0/ref/django-admin/#django-admin-squashmigrations) har nu stöd för att ange den startmigrering från vilken migreringar kommer att krossas. #### Modeller - [`QuerySet.bulk_create()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create) fungerar nu på proxymodeller. - Databaskonfigurationen har fått ett alternativ [`TIME_ZONE`](/sv/6.0/ref/settings/#std-setting-DATABASE-TIME_ZONE) för interaktion med databaser som lagrar datatider i lokal tid och inte stöder tidszoner när [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är `True`. - Lade till metoden [`RelatedManager.set()`](/sv/6.0/ref/models/relations/#django.db.models.fields.related.RelatedManager.set) till de relaterade hanterare som skapats av `ForeignKey`, `GenericForeignKey` och `ManyToManyField`. - Metoden [`add()`](/sv/6.0/ref/models/relations/#django.db.models.fields.related.RelatedManager.add) på en omvänd främmande nyckel har nu en `bulk`-parameter för att tillåta körning av en fråga oavsett antalet objekt som läggs till snarare än en fråga per objekt. - Lade till parametern `keep_parents` till [`Model.delete()`](/sv/6.0/ref/models/instances/#django.db.models.Model.delete) för att tillåta radering av endast ett barns data i en modell som använder arv med flera tabeller. - [`Model.delete()`](/sv/6.0/ref/models/instances/#django.db.models.Model.delete) och [`QuerySet.delete()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.delete) returnerar antalet objekt som raderats. - Lagt till en systemkontroll för att förhindra att både `Meta.ordering` och `order_with_respect_to` definieras på samma modell. - [`Datum och tid`](/sv/6.0/ref/models/querysets/#std-fieldlookup-year)-uppslag kan kedjas med andra uppslag (t.ex. [`exact`](/sv/6.0/ref/models/querysets/#std-fieldlookup-exact), [`gt`](/sv/6.0/ref/models/querysets/#std-fieldlookup-gt), [`lt`](/sv/6.0/ref/models/querysets/#std-fieldlookup-lt) etc.). Till exempel: `Entry.objects.filter(pub_date__month__gt=6)`. - Tidsuppslag (timme, minut, sekund) stöds nu av [`TimeField`](/sv/6.0/ref/models/fields/#django.db.models.TimeField) för alla databasbackends. Stöd för andra backends än SQLite lades till men var odokumenterat i Django 1.7. - Du kan ange parametern `output_field` för aggregatet [`Avg`](/sv/6.0/ref/models/querysets/#django.db.models.Avg) för att aggregera över icke-numeriska kolumner, t.ex. `DurationField`. - Lade till [`date`](/sv/6.0/ref/models/querysets/#std-fieldlookup-date) lookup till [`DateTimeField`](/sv/6.0/ref/models/fields/#django.db.models.DateTimeField) för att göra det möjligt att fråga fältet med endast datumdelen. - Lagt till databasfunktionerna [`Greatest`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Greatest) och [`Least`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Least). - Lagt till databasfunktionen [`Now`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Now), som returnerar aktuellt datum och tid. - [`Transform`](/sv/6.0/ref/models/lookups/#django.db.models.Transform) är nu en underklass till [Func()](/sv/6.0/ref/models/expressions/#func-expressions) vilket gör att `Transform` kan användas på höger sida av ett uttryck, precis som vanliga `Func`. Detta gör det möjligt att registrera vissa databasfunktioner som [`Length`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Length), [`Lower`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Lower) och [`Upper`](/sv/6.0/ref/models/database-functions/#django.db.models.functions.Upper) som transformationer. - [`SlugField`](/sv/6.0/ref/models/fields/#django.db.models.SlugField) accepterar nu ett [`allow_unicode`](/sv/6.0/ref/models/fields/#django.db.models.SlugField.allow_unicode)-argument för att tillåta Unicode-tecken i slugs. - Lagt till stöd för att referera till annoteringar i `QuerySet.distinct()`. - `connection.queries` visar frågor med substituerade parametrar på SQLite. - [Query expressions](/sv/6.0/ref/models/expressions/) kan nu användas när du skapar nya modellinstanser med `save()`, `create()` och `bulk_create()`. #### Förfrågningar och svar - Om inte [`HttpResponse.reason_phrase`](/sv/6.0/ref/request-response/#django.http.HttpResponse.reason_phrase) uttryckligen anges, bestäms det nu av det aktuella värdet på [`HttpResponse.status_code`](/sv/6.0/ref/request-response/#django.http.HttpResponse.status_code). Om du ändrar värdet på `status_code` utanför konstruktören ändras också värdet på `reason_phrase`. - Felsökningsvyn visar nu detaljer om kedjade undantag i Python 3. - Standardvyerna för 40x-fel accepterar nu en andra positionell parameter, det undantag som utlöste vyn. - Felhanterare för vyer stöder nu [`TemplateResponse`](/sv/6.0/ref/template-response/#django.template.response.TemplateResponse), som ofta används med klassbaserade vyer. - Undantag som uppstår i `render()`-metoden skickas nu till `process_exception()`-metoden i varje middleware. - Middleware för begäran kan nu ställa in [`HttpRequest.urlconf`](/sv/6.0/ref/request-response/#django.http.HttpRequest.urlconf) till `None` för att återställa alla ändringar som gjorts av tidigare middleware och återgå till att använda [`ROOT_URLCONF`](/sv/6.0/ref/settings/#std-setting-ROOT_URLCONF). - Kontrollen [`DISALLOWED_USER_AGENTS`](/sv/6.0/ref/settings/#std-setting-DISALLOWED_USER_AGENTS) i [`CommonMiddleware`](/sv/6.0/ref/middleware/#django.middleware.common.CommonMiddleware) ger nu upphov till ett [`PermissionDenied`](/sv/6.0/ref/exceptions/#django.core.exceptions.PermissionDenied) undantag i stället för att returnera ett [`HttpResponseForbidden`](/sv/6.0/ref/request-response/#django.http.HttpResponseForbidden) så att [`handler403`](/sv/6.0/ref/urls/#django.conf.urls.handler403) anropas. - Added [`HttpRequest.get_port()`](/sv/6.0/ref/request-response/#django.http.HttpRequest.get_port) to fetch the originating port of the request. - Lade till parametern `json_dumps_params` till [`JsonResponse`](/sv/6.0/ref/request-response/#django.http.JsonResponse) för att tillåta att nyckelordsargument skickas till anropet `json.dumps()` som används för att generera svaret. - Klassen:~django.middleware.common.BrokenLinkEmailsMiddleware ignorerar nu 404:or när referensen är lika med den begärda URL:en. För att kringgå kontrollen av tomma referenser som redan implementerats, sätter vissa webbrobotar referensen till den begärda URL:en. #### Mallar - Malltaggar som skapats med hjälpen [`simple_tag()`](/sv/6.0/howto/custom-template-tags/#django.template.Library.simple_tag) kan nu lagra resultat i en mallvariabel genom att använda argumentet `as`. - Lagt till en [`Context.setdefault()`](/sv/6.0/ref/templates/api/#django.template.Context.setdefault) metod. - Loggern [django.template](/sv/6.0/ref/logging/#django-template-logger) har lagts till och innehåller följande meddelanden: - Ett meddelande på `DEBUG`-nivå för saknade kontextvariabler. - Ett meddelande på `WARNING`-nivå för undantag som inte fångats upp och som uppstår under renderingen av en `{% include %}` när felsökningsläget är av (användbart eftersom `{% include %}` tystar undantaget och returnerar en tom sträng). - Malltaggen [`firstof`](/sv/6.0/ref/templates/builtins/#std-templatetag-firstof) stöder lagring av utdata i en variabel med hjälp av ’as’. - [`Context.update()`](/sv/6.0/ref/templates/api/#django.template.Context.update) kan nu användas som en kontexthanterare. - Djangos mallladdare kan nu utöka mallar rekursivt. - Felsökningssidans mall postmortem innehåller nu utdata från varje motor som är installerad. - [Debug page integration](/sv/6.0/howto/custom-template-backend/#template-debug-integration) för anpassade mallmotorer har lagts till. - Backend [`DjangoTemplates`](/sv/6.0/topics/templates/#django.template.backends.django.DjangoTemplates) har fått möjlighet att registrera bibliotek och builtins explicit genom mallens [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-TEMPLATES-OPTIONS). - Filtren `timesince` och `timeuntil` förbättrades för att hantera skottår när de ges stora tidsspann. - Taggen `include` cachelagrar nu parsade mallobjekt under mallrendering, vilket påskyndar återanvändning på platser som for-loopar. #### Tester - Lade till [`json()`](/sv/6.0/topics/testing/tools/#django.test.Response.json)-metoden för att testa klientsvar för att ge tillgång till svarskroppen som JSON. - Added the [`force_login()`](/sv/6.0/topics/testing/tools/#django.test.Client.force_login) method to the test client. Use this method to simulate the effect of a user logging into the site while skipping the authentication and verification steps of [`login()`](/sv/6.0/topics/testing/tools/#django.test.Client.login). #### URL:er - Lookaround-assertions med reguljära uttryck tillåts nu i URL-mönster. - Applikationens namnrymd kan nu anges med hjälp av attributet `app_name` på den inkluderade modulen eller objektet. Det kan också ställas in genom att skicka en 2-tupel av (\, \) som första argument till `include()`. - Systemkontroller har lagts till för vanliga fel i URL-mönster. #### Validerare - Lagt till [`django.core.validators.int_list_validator()`](/sv/6.0/ref/validators/#django.core.validators.int_list_validator) för att generera validerare av strängar som innehåller heltal separerade med ett anpassat tecken. - [`EmailValidator`](/sv/6.0/ref/validators/#django.core.validators.EmailValidator) begränsar nu längden på domännamnsetiketter till 63 tecken enligt [**RFC 1034**](https://datatracker.ietf.org/doc/html/rfc1034.html). - Lagt till [`validate_unicode_slug()`](/sv/6.0/ref/validators/#django.core.validators.validate_unicode_slug) för att validera slugs som kan innehålla Unicode-tecken. ## Bakåtkompatibla ändringar i 1.9 > **Warning** > > Utöver de ändringar som beskrivs i det här avsnittet bör du granska [Funktioner borttagna i 1.9](#removed-features-1-9) för de funktioner som har nått slutet av sin föråldringscykel och därför har tagits bort. Om du inte har uppdaterat din kod inom utfasningscykeln för en viss funktion kan borttagningen av den framstå som en bakåtkompatibel ändring. ### Databas backend API - Ett par nya tester förlitar sig på backendets förmåga att introspektera kolumnstandarder (returnerar resultatet som `Field.default`). Du kan ställa in databasfunktionen `can_introspect_default` till `False` om din backend inte implementerar detta. Du kanske vill granska implementeringen på de backends som Django inkluderar som referens ([#24245](https://code.djangoproject.com/ticket/24245)). - Det är inte lämpligt att registrera en global adapter eller konverterare på DB-API-modulens nivå för att hantera tidszonsinformation för [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime)-värden som skickas som frågeparametrar eller returneras som frågeresultat i databaser som inte stöder tidszoner. Det kan komma i konflikt med andra bibliotek. Det rekommenderade sättet att lägga till en tidszon i [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime)-värden som hämtas från databasen är att registrera en omvandlare för `DateTimeField` i `DatabaseOperations.get_db_converters()`. Databasfunktionen `needs_datetime_string_cast` togs bort. Databasbackends som ställer in den måste registrera en konverterare istället, enligt förklaringen ovan. - Metoderna `DatabaseOperations.value_to_db_()` döptes om till `adapt_field_value()` för att spegla metoderna `convert_field_value()`. - För att använda den nya `date`-uppslagningen kan tredjepartsdatabasbackends behöva implementera metoden `DatabaseOperations.datetime_cast_date_sql()`. - Metoden `DatabaseOperations.time_extract_sql()` har lagts till. Den anropar den befintliga metoden `date_extract_sql()`. Denna metod åsidosätts av SQLite-backend för att lägga till tidsuppslagningar (timme, minut, sekund) till [`TimeField`](/sv/6.0/ref/models/fields/#django.db.models.TimeField), och kan behövas av tredjeparts databasbackend. - Metoden `DatabaseOperations.datetime_cast_sql()` (inte att förväxla med `DatabaseOperations.datetime_cast_date_sql()` som nämns ovan) har tagits bort. Denna metod användes för att formatera datum på Oracle långt före 1.0, men har inte åsidosatts av någon kärnbackend på flera år och har inte anropats någonstans i Djangos kod eller tester. - För att stödja parallellisering av tester måste du implementera metoden `DatabaseCreation._clone_test_db()` och ställa in `DatabaseFeatures.can_clone_databases = True`. Du kan behöva justera `DatabaseCreation.get_test_db_clone_settings()`. ### Standardinställningar som var tupler är nu listor Standardinställningarna i `django.conf.global_settings` var en kombination av listor och tupler. Alla inställningar som tidigare var tupler är nu listor. ### attributet `is_usable` på mallladdare har tagits bort Djangos mallladdare krävde tidigare att ett `is_usable`-attribut skulle definieras. Om en laddare konfigurerades i mallinställningarna och detta attribut var `False`, skulle laddaren ignoreras i tysthet. I praktiken användes detta endast av ägglastaren för att upptäcka om `setuptools` var installerat. Attributet `is_usable` är nu borttaget och ägglastaren misslyckas istället vid körning om `setuptools` inte är installerat. ### Relaterat set direkttilldelning Direkt tilldelning av relaterade objekt i ORM brukade utföra en `clear()` följt av ett anrop till `add()`. Detta orsakade onödigt stora dataförändringar och förhindrade användning av [`m2m_changed`](/sv/6.0/ref/signals/#django.db.models.signals.m2m_changed)-signalen för att spåra enskilda ändringar i många-till-många-relationer. Direkt tilldelning förlitar sig nu på den nya [`set()`](/sv/6.0/ref/models/relations/#django.db.models.fields.related.RelatedManager.set)-metoden på relaterade chefer som som standard endast behandlar ändringar mellan den befintliga relaterade uppsättningen och den som nyligen tilldelats. Det tidigare beteendet kan återställas genom att ersätta direkt tilldelning med ett anrop till `set()` med nyckelordsargumentet `clear=True`. `ModelForm`, och därmed `ModelAdmin`, förlitar sig internt på direkt tilldelning för många-till-många relationer och som en konsekvens av detta används nu det nya beteendet. ### Filsystembaserade mallladdare fångar upp mer specifika undantag Vid användning av [`filesystem.Loader`](/sv/6.0/ref/templates/api/#django.template.loaders.filesystem.Loader) eller [`app_directories.Loader`](/sv/6.0/ref/templates/api/#django.template.loaders.app_directories.Loader) gav tidigare versioner av Django felmeddelandet [`TemplateDoesNotExist`](/sv/6.0/topics/templates/#django.template.TemplateDoesNotExist) om en mallkälla fanns men var oläslig. Detta kunde hända under många omständigheter, till exempel om Django inte hade behörighet att öppna filen, eller om mallkällan var en katalog. Nu tystnar Django bara undantaget om mallkällan inte finns. Alla andra situationer resulterar i att det ursprungliga `IOError` tas upp. ### HTTP-omdirigeringar tvingas inte längre till absoluta URI:er Relativa omdirigeringar konverteras inte längre till absoluta URI:er. [**RFC 2616**](https://datatracker.ietf.org/doc/html/rfc2616.html) krävde att rubriken `Location` i omdirigeringssvar skulle vara en absolut URI, men den har ersatts av [**RFC 7231**](https://datatracker.ietf.org/doc/html/rfc7231.html) som tillåter relativa URI:er i `Location`, vilket är ett erkännande av den faktiska praxisen hos användaragenter, som nästan alla stöder dem. Följaktligen bör de förväntade webbadresserna som skickas till `assertRedirects` i allmänhet inte längre innehålla schema- och domändelen av webbadresserna. Till exempel bör `self.assertRedirects(response, 'http://testserver/some-url/')` ersättas med `self.assertRedirects(response, '/some-url/')` (såvida inte omdirigeringen specifikt innehöll en absolut URL). I det sällsynta fallet att du behöver det gamla beteendet (upptäckt med en gammal version av Apache med `mod_scgi` som tolkar en relativ omdirigering som en ”intern omdirigering”) kan du återställa det genom att skriva en anpassad middleware: ``` class LocationHeaderFix(object): def process_response(self, request, response): if "Location" in response: response["Location"] = request.build_absolute_uri(response["Location"]) return response ``` ### Slopat stöd för PostgreSQL 9.0 Uppströmsstöd för PostgreSQL 9.0 slutade i september 2015. Som en följd av detta ställer Django 1.9 9.1 som den minsta PostgreSQL-versionen som den officiellt stöder. ### Upphört stöd för Oracle 11.1 Uppströmsstödet för Oracle 11.1 upphörde i augusti 2015. Som en följd av detta anger Django 1.9 11.2 som den lägsta Oracle-versionen som den officiellt stöder. ### Bulkbeteende för `add()`-metoden för relaterade chefer För att förbättra prestanda ändrades `add()`-metoderna för de relaterade hanterarna som skapats av `ForeignKey` och `GenericForeignKey` från en serie `Model.save()`-anrop till ett enda `QuerySet.update()`-anrop. Ä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. ### Mallarna `LoaderOrigin` och `StringOrigin` har tagits bort I tidigare versioner av Django, när en mallmotor initialiserades med debug som `True`, ställdes en instans av `django.template.loader.LoaderOrigin` eller `django.template.base.StringOrigin` in som ursprungsattribut på mallobjektet. Dessa klasser har kombinerats till [`Origin`](/sv/6.0/ref/templates/api/#django.template.base.Origin) och är nu alltid inställda oavsett inställningen för felsökning av motorn. För en minimal nivå av bakåtkompatibilitet kommer de gamla klassnamnen att behållas som alias till den nya klassen `Origin` fram till Django 2.0. ### Ändringar av standardkonfigurationen för loggning För att göra det enklare att skriva anpassade loggningskonfigurationer definierar Djangos standardloggningskonfiguration inte längre `django.request` och `django.security` loggers. Istället definieras en enda `django`-logger, filtrerad på `INFO`-nivå, med två hanterare: - `console`: filtreras på `INFO`-nivå och är endast aktiv om `DEBUG=True`. - `mail_admins`: filtreras på `ERROR`-nivå och är endast aktiv om `DEBUG=False`. Om du inte åsidosätter Djangos standardloggning bör du se minimala förändringar i beteendet, men du kanske ser en del ny loggning till konsolen `runserver`, till exempel. Om du åsidosätter Djangos standardloggning bör du kontrollera hur din konfiguration smälter samman med de nya standardinställningarna. ### `HttpRequest` detaljer i felrapportering Det var överflödigt att visa alla detaljer om [`HttpRequest`](/sv/6.0/ref/request-response/#django.http.HttpRequest) varje gång den dök upp som en stack frame-variabel i HTML-versionen av felsökningssidan och felmeddelandet. Således kommer HTTP-begäran nu att visa samma standardrepresentation som andra variabler (`repr(request)`). Som ett resultat av detta togs metoden `ExceptionReporterFilter.get_request_repr()` och den odokumenterade funktionen `django.http.build_request_repr()` bort. Innehållet i textversionen av e-postmeddelandet ändrades för att ge en spårning med samma struktur som vid AJAX-förfrågningar. Spårningsinformationen återges med metoden `ExceptionReporter.get_traceback_text()`. ### Borttagning av tidszonmedvetna globala adaptrar och omvandlare för datatider Django registrerar inte längre globala adaptrar och omvandlare för att hantera tidszonsinformation på [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime)-värden som skickas till databasen som frågeparametrar eller läses från databasen i frågeresultat. Denna ändring påverkar projekt som uppfyller alla följande villkor: - Inställningen [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är `True`. - Databasen är SQLite, MySQL, Oracle eller en tredjepartsdatabas som inte stöder tidszoner. Om du är osäker kan du kontrollera värdet på `connection.features.supports_timezones`. - Koden ställer frågor till databasen utanför ORM, vanligtvis med `cursor.execute(sql, params)`. Om du skickar medvetna [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime)-parametrar till sådana frågor bör du omvandla dem till naiva datatider i UTC: ``` from django.utils import timezone param = timezone.make_naive(param, timezone.utc) ``` Om du inte gör det kommer konverteringen att utföras som i tidigare versioner (med en deprecation-varning) fram till och med Django 1.11. Django 2.0 kommer inte att utföra någon konvertering, vilket kan leda till datakorruption. Om du läser [`datetime`](https://docs.python.org/3/library/datetime.html#datetime.datetime)-värden från resultaten kommer de att vara naiva i stället för medvetna. Du kan kompensera på följande sätt: ``` from django.utils import timezone value = timezone.make_aware(value, timezone.utc) ``` Du behöver inte något av detta om du frågar databasen via ORM, även om du använder [`raw()`](/sv/6.0/ref/models/querysets/#django.db.models.query.QuerySet.raw) frågor. ORM tar hand om hanteringen av tidszoninformation. ### Moduler för malltaggar importeras när mallar konfigureras Backend [`DjangoTemplates`](/sv/6.0/topics/templates/#django.template.backends.django.DjangoTemplates) utför nu upptäckt på installerade malltaggmoduler när den instansieras. Denna uppdatering gör det möjligt att tillhandahålla bibliotek uttryckligen via nyckeln `'libraries'` i [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-TEMPLATES-OPTIONS) när man definierar en [`DjangoTemplates`](/sv/6.0/topics/templates/#django.template.backends.django.DjangoTemplates)-backend. Import- eller syntaxfel i malltaggmoduler misslyckas nu tidigt vid instantiering snarare än när en mall med en [`{% load %}`](/sv/6.0/ref/templates/builtins/#std-templatetag-load)-tagg först kompileras. ### `django.template.base.add_to_builtins()` tas bort Även om det var ett privat API, använde projekt ofta `add_to_builtins()` för att göra malltaggar och filter tillgängliga utan att använda [`{% load %}`](/sv/6.0/ref/templates/builtins/#std-templatetag-load)-taggen. Detta API har formaliserats. Projekt bör nu definiera inbyggda bibliotek via nyckeln `'builtins'` i [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-TEMPLATES-OPTIONS) när de definierar en [`DjangoTemplates`](/sv/6.0/topics/templates/#django.template.backends.django.DjangoTemplates)-backend. ### `simple_tag` omsluter nu taggutdata i `conditional_escape` I allmänhet autoescaper inte malltaggar sitt innehåll, och detta beteende är [dokumenterat](/sv/6.0/howto/custom-template-tags/#tags-auto-escaping). För taggar som [`inclusion_tag`](/sv/6.0/howto/custom-template-tags/#django.template.Library.inclusion_tag) är detta inte ett problem eftersom den inkluderade mallen kommer att utföra autoescaping. För `assignment_tag()` kommer utdata att escapas när den används som en variabel i mallen. För de avsedda användningsfallen för [`simple_tag`](/sv/6.0/howto/custom-template-tags/#django.template.Library.simple_tag) är det dock mycket lätt att få felaktig HTML och eventuellt en XSS-exploatering. Till exempel: ``` @register.simple_tag(takes_context=True) def greeting(context): return "Hello {0}!".format(context["request"].user.first_name) ``` I äldre versioner av Django kommer detta att vara ett XSS-problem eftersom `user.first_name` inte är escaped. I Django 1.9 är detta åtgärdat: om mallkontexten har `autoescape=True` inställt (standard), kommer `simple_tag` att omsluta utdata från taggfunktionen med [`conditional_escape()`](/sv/6.0/ref/utils/#django.utils.html.conditional_escape). För att åtgärda dina `simple_tag` är det bäst att tillämpa följande metoder: - All kod som genererar HTML bör använda antingen mallsystemet eller [`format_html()`](/sv/6.0/ref/utils/#django.utils.html.format_html). - Om utdata från en `simple_tag` behöver escapas, använd [`escape()`](/sv/6.0/ref/utils/#django.utils.html.escape) eller [`conditional_escape()`](/sv/6.0/ref/utils/#django.utils.html.conditional_escape). - Om du är helt säker på att du matar ut HTML från en betrodd källa (t.ex. ett CMS-fält som lagrar HTML som matats in av administratörer) kan du markera det som sådant med [`mark_safe()`](/sv/6.0/ref/utils/#django.utils.safestring.mark_safe). Taggar som följer dessa regler kommer att vara korrekta och säkra oavsett om de körs på Django 1.9+ eller tidigare. ### `Paginator.page_range` [`Paginator.page_range`](/sv/6.0/ref/paginator/#django.core.paginator.Paginator.page_range) är nu en iterator istället för en lista. I versioner av Django tidigare än 1.8 returnerade `Paginator.page_range` en `list` i Python 2 och en `range` i Python 3. Django 1.8 returnerade konsekvent en lista, men en iterator är mer effektiv. Befintlig kod som är beroende av `list`-specifika funktioner, t.ex. indexering, kan överföras genom att omvandla iteratorn till en `list` med hjälp av `list()`. ### Implicit `QuerySet` `__in` lookup borttagen I tidigare versioner kunde frågor som: ``` Model.objects.filter(related_id=RelatedModel.objects.all()) ``` skulle implicit konverteras till: ``` Model.objects.filter(related_id__in=RelatedModel.objects.all()) ``` vilket resulterar i SQL som `"related_id IN (SELECT id FROM ...)"`. Denna implicita `__in` sker inte längre så ”IN” SQL är nu ”=”, och om underfrågan returnerar flera resultat kommer åtminstone vissa databaser att ge ett felmeddelande. ### stöd för webbläsaren `contrib.admin` Administratören stöder inte längre Internet Explorer 8 och lägre, eftersom dessa webbläsare har nått slutet av livscykeln. CSS och bilder för att stödja Internet Explorer 6 och 7 har tagits bort. PNG- och GIF-ikoner har ersatts med SVG-ikoner, som inte stöds av Internet Explorer 8 och tidigare. Biblioteket jQuery som är inbäddat i admin har uppgraderats från version 1.11.2 till 2.1.4. jQuery 2.x har samma API som jQuery 1.x, men stöder inte Internet Explorer 6, 7 eller 8, vilket ger bättre prestanda och mindre filstorlek. Om du behöver stöd för IE8 och även måste använda den senaste versionen av Django kan du åsidosätta administratörens kopia av jQuery med din egen genom att skapa en Django-applikation med den här strukturen: ```text app/static/admin/js/vendor/ jquery.js jquery.min.js ``` ### `SyntaxError` vid installation av Django `setuptools` 5.5.x När du installerar Django 1.9 eller 1.9.1 med `setuptools` 5.5.x, kommer du att se: ```shell Compiling django/conf/app_template/apps.py ... File "django/conf/app_template/apps.py", line 4 class {{ camel_case_app_name }}Config(AppConfig): ^ SyntaxError: invalid syntax Compiling django/conf/app_template/models.py ... File "django/conf/app_template/models.py", line 1 {{ unicode_literals }}from django.db import models ^ SyntaxError: invalid syntax ``` Det är säkert att ignorera dessa fel (Django kommer fortfarande att installeras bra), men du kan undvika dem genom att uppgradera `setuptools` till en nyare version. Om du använder pip kan du uppgradera pip med `python -m pip install -U pip` vilket också kommer att uppgradera `setuptools`. Detta är löst i senare versioner av Django enligt beskrivningen i [Django 1.9.2 versionsinformation](/sv/6.0/releases/1.9.2/). ### Diverse - De statiska jQuery-filerna i `contrib.admin` har flyttats till en `vendor/jquery`-underkatalog. - Den text som visas för null-kolumner i cellerna i admin-ändringslistan `list_display` har ändrats från `(None)` (eller dess översatta motsvarighet) till `-` (ett streck). - `django.http.responses.REASON_PHRASES` och `django.core.handlers.wsgi.STATUS_CODE_TEXT` har tagits bort. Använd Pythons standardbibliotek i stället: [`http.client.responses`](https://docs.python.org/3/library/http.client.html#http.client.responses) för Python 3 och [httplib.responses](https://docs.python.org/2/library/httplib.html#httplib.responses) för Python 2. - `ValuesQuerySet` och `ValuesListQuerySet` har tagits bort. - Mallen `admin/base.html` ställer inte längre in `window.__admin_media_prefix__` eller `window.__admin_utc_offset__`. Bildreferenser i JavaScript som använde det värdet för att konstruera absoluta webbadresser har flyttats till CSS för enklare anpassning. UTC-offset lagras i ett dataattribut i taggen ``. - valideringen av `CommaSeparatedIntegerField` har förfinats för att förbjuda värden som `','`, `',1'` och `'1,,2'`. - Formulärinitialisering flyttades från metoden [`ProcessFormView.get()`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.ProcessFormView.get) till den nya metoden [`FormMixin.get_context_data()`](/sv/6.0/ref/class-based-views/mixins-editing/#django.views.generic.edit.FormMixin.get_context_data). Detta kan vara inkompatibelt bakåt om du har åsidosatt metoden `get_context_data()` utan att anropa `super()`. - Stöd för PostGIS 1.5 har tagits bort. - Fältet `django.contrib.sites.models.Site.domain` ändrades till att vara [`unique`](/sv/6.0/ref/models/fields/#django.db.models.Field.unique). - För att genomdriva testisolering tillåts inte databasfrågor som standard i [`SimpleTestCase`](/sv/6.0/topics/testing/tools/#django.test.SimpleTestCase)-tester längre. Du kan inaktivera detta beteende genom att ställa in klassattributet `allow_database_queries` till `True` på din testklass. - `ResolverMatch.app_name` har ändrats så att den innehåller hela sökvägen till namnrymden om det finns nästlade namnrymder. För konsekvens med `ResolverMatch.namespace` är det tomma värdet nu en tom sträng istället för `None`. - Av säkerhetsskäl måste sessionsnycklar bestå av minst 8 tecken. - Den privata funktionen `django.utils.functional.total_ordering()` har tagits bort. Den innehöll en lösning för ett fel i `functools.total_ordering()` i Python-versioner äldre än 2.7.3. - XML-serialisering (antingen via [`dumpdata`](/sv/6.0/ref/django-admin/#django-admin-dumpdata) eller syndikeringsramverket) brukade mata ut alla tecken som den mottog. Om innehållet som skall serialiseras innehåller kontrolltecken som inte är tillåtna i XML 1.0-standarden, kommer serialiseringen att misslyckas med ett [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError). - [`CharField`](/sv/6.0/ref/forms/fields/#django.forms.CharField) tar nu bort inledande och avslutande blanksteg som standard. Detta kan inaktiveras genom att ställa in det nya [`strip`](/sv/6.0/ref/forms/fields/#django.forms.CharField.strip)-argumentet till `False`. - Malltext som översätts och använder två eller flera procenttecken i följd, t.ex. `"%%"`, kan få ett nytt `msgid` efter att `makemessages` körts (troligen kommer översättningen att markeras som luddig). Det nya `msgid` kommer att markeras med `"#, python-format"`. - Om varken [`request.current_app`](/sv/6.0/ref/request-response/#django.http.HttpRequest.current_app) eller [`Context.current_app`](/sv/6.0/ref/templates/api/#django.template.Context) är inställda, kommer malltaggen [`url`](/sv/6.0/ref/templates/builtins/#std-templatetag-url) nu att använda namnrymden för den aktuella begäran. Ställ in `request.current_app` till `None` om du inte vill använda en namnrymdshint. - Inställningen [`SILENCED_SYSTEM_CHECKS`](/sv/6.0/ref/settings/#std-setting-SILENCED_SYSTEM_CHECKS) tystar nu meddelanden på alla nivåer. Tidigare skrevs meddelanden på `ERROR`-nivå eller högre ut till konsolen. - Fältet `FlatPage.enable_comments` är borttaget från `FlatPageAdmin` eftersom det inte används av applikationen. Om ditt projekt eller en tredjepartsapplikation använder det, [skapa en anpassad ModelAdmin](/sv/6.0/ref/contrib/flatpages/#flatpages-admin) för att lägga till det igen. - Returvärdet för [`setup_databases()`](/sv/6.0/topics/testing/advanced/#django.test.runner.DiscoverRunner.setup_databases) och det första argumentet för [`teardown_databases()`](/sv/6.0/topics/testing/advanced/#django.test.runner.DiscoverRunner.teardown_databases) ändrades. De brukade vara `(old_names, mirrors)`-tupler. Nu är de bara det första objektet, `old_names`. - Som standard försöker [`LiveServerTestCase`](/sv/6.0/topics/testing/tools/#django.test.LiveServerTestCase) att hitta en tillgänglig port i intervallet 8081-8179 istället för att bara försöka med port 8081. - Systemkontrollerna för [`ModelAdmin`](/sv/6.0/ref/contrib/admin/#django.contrib.admin.ModelAdmin) kontrollerar nu instanser istället för klasser. - Det privata API:et för att tillämpa blandade migreringsplaner har tagits bort av prestandaskäl. Blandade planer består av en lista med migreringar där vissa tillämpas och andra inte tillämpas. - Deskriptorklasserna för relaterade modellobjekt i `django.db.models.fields.related` (privat API) flyttas från modulen `related` till `related_descriptors` och byter namn enligt följande: - `ReverseSingleRelatedObjectDescriptor` är `ForwardManyToOneDescriptor` - `SingleRelatedObjectDescriptor` är `ReverseOneToOneDescriptor` - `ForeignRelatedObjectsDescriptor` är `ReverseManyToOneDescriptor` - `MångaRelateradeObjektDeskriptor` är `MångaTillMångaDeskriptor` - Om du implementerar en anpassad [`handler404`](/sv/6.0/ref/urls/#django.conf.urls.handler404)-vy måste den returnera ett svar med en HTTP 404-statuskod. Använd [`HttpResponseNotFound`](/sv/6.0/ref/request-response/#django.http.HttpResponseNotFound) eller skicka `status=404` till [`HttpResponse`](/sv/6.0/ref/request-response/#django.http.HttpResponse). Annars kommer [`APPEND_SLASH`](/sv/6.0/ref/settings/#std-setting-APPEND_SLASH) inte att fungera korrekt med `DEBUG=False`. ## Funktioner som inte längre är aktuella i 1.9 ### `tilldelning_tag()` Django 1.4 lade till hjälpen `assignment_tag` för att underlätta skapandet av malltaggar som lagrar resultat i en mallvariabel. Hjälpen [`simple_tag()`](/sv/6.0/howto/custom-template-tags/#django.template.Library.simple_tag) har fått samma förmåga, vilket gör `assignment_tag` föråldrad. Taggar som använder `assignment_tag` bör uppdateras till att använda `simple_tag`. ### `{% cycle %}` syntax med kommaseparerade argument Taggen [`cycle`](/sv/6.0/ref/templates/builtins/#std-templatetag-cycle) har stöd för en gammal syntax från tidigare Django-versioner: ```html+django {% cycle row1,row2,row3 %} ``` Dess parsning orsakade buggar med den nuvarande syntaxen, så stöd för den gamla syntaxen kommer att tas bort i Django 1.10 efter en påskyndad avskrivning. ### `ForeignKey` och `OneToOneField` `on_delete` argument För att öka medvetenheten om cascading model deletion kommer argumentet `on_delete` för `ForeignKey` och `OneToOneField` att krävas i Django 2.0. Uppdatera modeller och befintliga migreringar så att argumentet anges explicit. Eftersom standard är `models.CASCADE`, lägg till `on_delete=models.CASCADE` till alla `ForeignKey` och `OneToOneField` som inte använder ett annat alternativ. Du kan också skicka det som det andra positionella argumentet om du inte bryr dig om kompatibilitet med äldre versioner av Django. ### `Field.rel` ändringar `Field.rel` och dess metoder och attribut har ändrats för att matcha API:et för relaterade fält. Attributet `Field.rel` har bytt namn till `remote_field` och många av dess metoder och attribut har antingen ändrats eller bytt namn. Syftet med dessa ändringar är att tillhandahålla ett dokumenterat API för relationsfält. ### anpassade metoder för `GeoManager` och `GeoQuerySet` Alla anpassade `GeoQuerySet`-metoder (`area()`, `distance()`, `gml()`, …) har ersatts av motsvarande geografiska uttryck i annoteringar (se under nya funktioner). Därför är behovet av att ställa in en anpassad `GeoManager` till GIS-aktiverade modeller nu föråldrat. Så snart din kod inte anropar någon av de föråldrade metoderna kan du helt enkelt ta bort raderna `objects = GeoManager()` från dina modeller. ### API:erna för mallladdare har ändrats Djangos mallladdare har uppdaterats för att tillåta rekursiv förlängning av mallar. Denna förändring krävde ett nytt API för mallladdare. De gamla metoderna `load_template()` och `load_template_sources()` är nu föråldrade. Detaljer om det nya API:et finns [i dokumentationen för mallladdaren](/sv/6.0/ref/templates/api/#custom-template-loaders). ### Överlämnar en 3-tupel eller ett `app_name` till `include()` Instansnamnrymdsdelen av att skicka en tupel som ett argument till `include()` har ersatts med att skicka argumentet `namespace` till `include()`. Till exempel: ``` polls_patterns = [ url(...), ] urlpatterns = [ url(r"^polls/", include((polls_patterns, "polls", "author-polls"))), ] ``` blir: ``` polls_patterns = ( [ url(...), ], "polls", ) # 'polls' is the app_name urlpatterns = [ url(r"^polls/", include(polls_patterns, namespace="author-polls")), ] ``` Argumentet `app_name` till `include()` har ersatts med att skicka en 2-tupel (som ovan), eller att skicka ett objekt eller en modul med ett `app_name`-attribut (som nedan). Om `app_name` anges på det här nya sättet behövs inte längre argumentet `namespace`. Det kommer som standard att motsvara värdet för `app_name`. Till exempel ändras URL-mönstren i handledningen från: *`mysite/urls.py`* ```python urlpatterns = [url(r"^polls/", include("polls.urls", namespace="polls")), ...] ``` till: *`mysite/urls.py`* ```python urlpatterns = [ url(r"^polls/", include("polls.urls")), # 'namespace="polls"' removed ..., ] ``` *`polls/urls.py`* ```python app_name = "polls" # added urlpatterns = [...] ``` Denna ändring innebär också att det gamla sättet att inkludera en `AdminSite`-instans är föråldrat. Skicka istället `admin.site.urls` direkt till `django.conf.urls.url()`: *`urls.py`* ```python from django.conf.urls import url from django.contrib import admin urlpatterns = [ url(r"^admin/", admin.site.urls), ] ``` ### URL-applikationens namnrymd krävs om man anger en instansnamnrymd Tidigare kunde en instansnamnrymd utan en applikationsnamnrymd tjäna samma syfte som applikationsnamnrymden, men det var omöjligt att vända på mönstret om det fanns en applikationsnamnrymd med samma namn. Inkluderingar som anger ett instansnamnområde kräver att den inkluderade URLconf anger ett applikationsnamnområde. ### parameter för `aktuell_app` till `contrib.auth`-vyer Alla vyer i `django.contrib.auth.views` har följande struktur: ```text def view(request, ..., current_app=None, ...): ... if current_app is not None: request.current_app = current_app return TemplateResponse(request, template_name, context) ``` Från och med Django 1.8 ställs `current_app` in på `request`-objektet. För konsekvensens skull kommer dessa vyer att kräva att den som anropar ställer in `current_app` på `request` istället för att skicka det i ett separat argument. ### `django.contrib.gis.geoip` Modulen [`django.contrib.gis.geoip2`](/sv/6.0/ref/contrib/gis/geoip2/#module-django.contrib.gis.geoip2) ersätter `django.contrib.gis.geoip`. Den nya modulen tillhandahåller ett liknande API förutom att den inte tillhandahåller de äldre GeoIP-Python API-kompatibilitetsmetoderna. ### Diverse - Argumentet `weak` till `django.dispatch.signals.Signal.disconnect()` har utgått eftersom det inte har någon effekt. - Metoden `check_aggregate_support()` i `django.db.backends.base.BaseDatabaseOperations` har blivit föråldrad och kommer att tas bort i Django 2.0. Den mer allmänna `check_expression_support()` bör användas istället. - `django.forms.extras` är föråldrad. Du kan hitta [`SelectDateWidget`](/sv/6.0/ref/forms/widgets/#django.forms.SelectDateWidget) i `django.forms.widgets` (eller helt enkelt `django.forms`) istället. - Privat API `django.db.models.fields.add_lazy_relation()` är föråldrat. - Dekoratorn `django.contrib.auth.tests.utils.skipIfCustomUser()` är föråldrad. Med testupptäcktsändringarna i Django 1.6 körs inte längre testerna för `django.contrib`-appar som en del av användarens projekt. Därför behövs inte längre dekoratorn `@skipIfCustomUser` för att dekorera tester i `django.contrib.auth`. - Om du har anpassat några [felshanterare](/sv/6.0/ref/views/#error-views), är vynsignaturerna med endast en requestparameter föråldrade. Vyerna bör nu också acceptera en andra `exception` positionell parameter. - Attributen `django.utils.feedgenerator.Atom1Feed.mime_type` och `django.utils.feedgenerator.RssFeed.mime_type` är föråldrade till förmån för `content_type`. - [`Signer`](/sv/6.0/topics/signing/#django.core.signing.Signer) ger nu en varning om en ogiltig separator används. Detta kommer att bli ett undantag i Django 1.10. - `django.db.models.Field._get_val_from_obj()` är föråldrad till förmån för `Field.value_from_object()`. - `django.template.loaders.eggs.Loader` är föråldrad eftersom det inte rekommenderas att distribuera applikationer som ägg. - Nyckelordsargumentet `callable_obj` till `SimpleTestCase.assertRaisesMessage()` är föråldrat. Skicka istället den anropsbara som ett positionellt argument. - Attributet `allow_tags` på metoder för `ModelAdmin` har utgått. Använd [`format_html()`](/sv/6.0/ref/utils/#django.utils.html.format_html), [`format_html_join()`](/sv/6.0/ref/utils/#django.utils.html.format_html_join), eller [`mark_safe()`](/sv/6.0/ref/utils/#django.utils.safestring.mark_safe) när du konstruerar metodens returvärde istället. - Nyckelordsargumentet `enclosure` till `SyndicationFeed.add_item()` är föråldrat. Använd det nya `enclosures` argumentet som accepterar en lista med `Enclosure` objekt istället för ett enda. - Aliasen `django.template.loader.LoaderOrigin` och `django.template.base.StringOrigin` för `django.template.base.Origin` är föråldrade. ## Funktioner borttagna i 1.9 Dessa funktioner har nått slutet av sin utfasningscykel och tas bort i Django 1.9. Se [Funktioner som inte längre är aktuella i 1.7](/sv/6.0/releases/1.7/#deprecated-features-1-7) för detaljer, inklusive hur man tar bort användningen av dessa funktioner. - `django.utils.dictconfig` har tagits bort. - `django.utils.importlib` är borttagen. - `django.utils.tzinfo` har tagits bort. - `django.utils.unittest` har tagits bort. - Kommandot `syncdb` har tagits bort. - `django.db.models.signals.pre_syncdb` och `django.db.models.signals.post_syncdb` tas bort. - Stöd för `allow_syncdb` på databasroutrar har tagits bort. - Automatisk synkronisering av appar utan migreringar har tagits bort. Migreringar är obligatoriska för alla appar om du inte anger alternativet [`migrate --run-syncdb`](/sv/6.0/ref/django-admin/#cmdoption-migrate-run-syncdb). - SQL-hanteringskommandona för appar utan migreringar, `sql`, `sqlall`, `sqlclear`, `sqldropindexes` och `sqlindexes`, har tagits bort. - Stöd för automatisk laddning av `initial_data`-fixturer och inledande SQL-data har tagits bort. - Alla modeller måste definieras i en installerad applikation eller deklarera en explicit [`app_label`](/sv/6.0/ref/models/options/#django.db.models.Options.app_label). Dessutom är det inte möjligt att importera dem innan deras applikation har laddats. I synnerhet är det inte möjligt att importera modeller inuti rotpaketet för en applikation. - Modellen och formuläret `IPAddressField` tas bort. Ett stub-fält finns kvar för kompatibilitet med historiska migreringar. - `AppCommand.handle_app()` stöds inte längre. - `RequestSite` och `get_current_site()` är inte längre importerbara från `django.contrib.sites.models`. - FastCGI-stöd via hanteringskommandot `runfcgi` har tagits bort. - `django.utils.datastructures.SortedDict` tas bort. - `ModelAdmin.declared_fieldsets` har tagits bort. - Modulerna `util` som gav bakåtkompatibilitet har tagits bort: - `django.contrib.admin.util` - `django.contrib.gis.db.backends.util` - `django.db.backends.util` - `django.forms.util` - `ModelAdmin.get_formsets` har tagits bort. - De bakåtkompatibla shims som infördes för att byta namn på metoden `BaseMemcachedCache._get_memcache_timeout()` till `get_backend_timeout()` har tagits bort. - Alternativen `--natural` och `-n` för [`dumpdata`](/sv/6.0/ref/django-admin/#django-admin-dumpdata) har tagits bort. - Argumentet `use_natural_keys` för `serializers.serialize()` har tagits bort. - Det privata API:et `django.forms.forms.get_declared_fields()` har tagits bort. - Möjligheten att använda en `SplitDateTimeWidget` med `DateTimeField` har tagits bort. - Egenskapen `WSGIRequest.REQUEST` tas bort. - Klassen `django.utils.datastructures.MergeDict` är borttagen. - Språkkoderna `zh-cn` och `zh-tw` har tagits bort. - Den interna `django.utils.functional.memoize()` tas bort. - `django.core.cache.get_cache` är borttagen. - `django.db.models.loading` är borttagen. - Det är inte längre möjligt att skicka anropsbara argument till querysets. - `BaseCommand.requires_model_validation` tas bort till förmån för `requires_system_checks`. Admin-validatorer ersätts av admin-kontroller. - Attributen `ModelAdmin.validator_class` och `default_validator_class` tas bort. - `ModelAdmin.validate()` har tagits bort. - `django.db.backends.DatabaseValidation.validate_field` tas bort till förmån för metoden `check_field`. - Ledningskommandot `validate` har tagits bort. - `django.utils.module_loading.import_by_path` tas bort till förmån för `django.utils.module_loading.import_string`. - `ssi` och `url` malltaggar är borttagna från `future` malltaggsbiblioteket. - `django.utils.text.javascript_quote()` har tagits bort. - Databasens testinställningar som självständiga poster i databasinställningarna, med prefixet `TEST_`, stöds inte längre. - Alternativet `cache_choices` till [`ModelChoiceField`](/sv/6.0/ref/forms/fields/#django.forms.ModelChoiceField) och [`ModelMultipleChoiceField`](/sv/6.0/ref/forms/fields/#django.forms.ModelMultipleChoiceField) har tagits bort. - Standardvärdet för attributet [`RedirectView.permanent`](/sv/6.0/ref/class-based-views/base/#django.views.generic.base.RedirectView.permanent) har ändrats från `True` till `False`. - `django.contrib.sitemaps.FlatPageSitemap` tas bort till förmån för `django.contrib.flatpages.sitemaps.FlatPageSitemap`. - Privat API `django.test.utils.TestTemplateLoader` tas bort. - Modulen `django.contrib.contenttypes.generic` har tagits bort.