# Django 6.0.5 documentation

# Django 4.1 versionsinformation

3 augusti 2022

Välkommen till Django 4.1!

Dessa versionsinformation täcker nya funktioner, samt några bakåtkompatibla ändringar som du vill vara medveten om när du uppgraderar från Django 4.0 eller tidigare. Vi har börjat utfasningsprocessen för vissa funktioner.

Se guiden Så här uppgraderar du Django till en nyare version om du ska uppdatera ett befintligt projekt.

## Kompatibilitet med Python

Django 4.1 stöder Python 3.8, 3.9, 3.10 och 3.11 (från och med 4.1.3). Vi rekommenderar starkt och stöder endast officiellt den senaste utgåvan av varje serie.

## Vad är nytt i Django 4.1

### Asynkrona hanterare för klassbaserade vyer

View-subklasser kan nu definiera asynkrona HTTP-metodhanterare:

    import asyncio
    from django.http import HttpResponse
    from django.views import View

    class AsyncView(View):
        async def get(self, request, *args, **kwargs):
            # Perform view logic using await.
            await asyncio.sleep(1)
            return HttpResponse("Hello async world!")

Se Asynkrona klassbaserade visningar för mer information.

### Asynkront ORM-gränssnitt

`QuerySet` tillhandahåller nu ett asynkront gränssnitt för alla dataåtkomstoperationer. Dessa namnges på samma sätt som de befintliga synkrona operationerna men med prefixet `a`, till exempel `acreate()`, `aget()`, och så vidare.

Det nya gränssnittet gör att du kan skriva asynkron kod utan att behöva linda in ORM-operationer i `sync_to_async()`:

    async for author in Author.objects.filter(name__startswith="A"):
        book = await author.books.afirst()

Observera att i detta skede förblir de underliggande databasoperationerna synkrona, med bidrag som pågår för att driva asynkront stöd ner i SQL-kompilatorn och integrera asynkrona databasdrivrutiner. Det nya asynkrona queryset-gränssnittet kapslar för närvarande in de nödvändiga `sync_to_async()`-operationerna åt dig och kommer att göra det möjligt för din kod att dra nytta av utvecklingen av ORM:s asynkrona stöd när det utvecklas.

Se Asynkrona förfrågningar för detaljer och begränsningar.

### Validering av begränsningar

begränsningarna `Check`, `unique` och `exclusion` som definieras i alternativet `Meta.constraints` kontrolleras nu under modellvalidering.

### Tillgänglighet för rendering av formulär

För att underlätta för användare med skärmläsare och andra tekniska hjälpmedel finns nya formulärmallar baserade på<div> tillgängliga från och med den här versionen. Dessa ger en mer tillgänglig navigering än de äldre mallarna och kan gruppera relaterade kontroller, t.ex. radiolistor, i fältuppsättningar på ett korrekt sätt.

De nya mallarna rekommenderas och kommer att bli standardrenderingsstilen för formulär när du skriver ut ett formulär, som `{{ form }}` i en mall, från Django 5.0.

För att göra det lättare att använda den nya utdatastilen kan standardformuläret och formulärmallarna nu konfigureras på projektnivå via inställningen `FORM_RENDERER`.

Se formavsnittet (nedan) för fullständig information.

### inställning `CSRF_COOKIE_MASKED`

Den nya övergångsinställningen `CSRF_COOKIE_MASKED` gör det möjligt att ange om CSRF-cookien ska maskeras.

`CsrfViewMiddleware` maskerar inte längre CSRF-cookien som den gör med CSRF-token i DOM. Om du uppgraderar flera instanser av samma projekt till Django 4.1 bör du ställa in `CSRF_COOKIE_MASKED` till `True` under övergången, för att möjliggöra kompatibilitet med de äldre versionerna av Django. När övergången till 4.1 är slutförd kan du sluta åsidosätta `CSRF_COOKIE_MASKED`.

Denna inställning är föråldrad från och med den här utgåvan och kommer att tas bort i Django 5.0.

### Mindre funktioner

#### `django.contrib.admin`

- CSS-variablerna för admin dark mode tillämpas nu i en separat stilmall och ett separat mallblock.

- ModelAdmin Lista Filter som tillhandahåller anpassade `FieldListFilter`-underklasser kan nu styra värdeseparatorn för frågesträngen när man filtrerar efter flera värden med hjälp av `__in`-uppslagningen.

- Admin `history view` är nu paginerad.

- Relaterade widgetomslag har nu en länk till objektets ändringsformulär.

- Metoden `AdminSite.get_app_list()` gör det nu möjligt att ändra ordningen på appar och modeller på adminindexsidan.

#### `django.contrib.auth`

- Standardantalet iterationer för PBKDF2-lösenordshashen ökas från 320.000 till 390.000.

- Metoden `RemoteUserBackend.configure_user()` gör det nu möjligt att synkronisera användarattribut med attribut i ett fjärrsystem, t.ex. en LDAP-katalog.

#### `django.contrib.gis`

- The new `GEOSGeometry.make_valid()` method allows converting invalid geometries to valid ones.

- Det nya argumentet `clone` för `GEOSGeometry.normalize()` gör det möjligt att skapa en normaliserad klon av geometrin.

#### `django.contrib.postgres`

- Den nya `BitXor()`-aggregatfunktionen returnerar ett `int` av det bitvisa `XOR` av alla icke-nullvärden.

- `SpGistIndex` stöder nu täckande index på PostgreSQL 14+.

- `ExclusionConstraint` stöder nu täckande uteslutningsbegränsningar med SP-GiST-index på PostgreSQL 14+.

- Det nya attributet `default_bounds` för `DateTimeRangeField` och `DecimalRangeField` gör det möjligt att ange gränser för list- och tuple-ingångar.

- `ExclusionConstraint` tillåter nu att operatörsklasser anges med uttrycket `OpClass()`.

#### `django.contrib.sitemaps`

- Standardmallen för sitemap-index `<sitemapindex>` inkluderar nu tidsstämpeln `<lastmod>` där den är tillgänglig, genom den nya `get_latest_lastmod()`-metoden. Anpassade indexmallar för webbplatskartor bör uppdateras för den justerade kontextvariabler.

#### `django.contrib.staticfiles`

- `ManifestStaticFilesStorage` ersätter nu sökvägar till CSS-källkartreferenser med deras hashade motsvarigheter.

#### Databas backends

- Tredjeparts databasbackends kan nu ange den lägsta version som krävs av databasen med hjälp av attributet `DatabaseFeatures.minimum_database_version` som är en tupel (t.ex. `(10, 0)` betyder ”10.0”). Om en minsta version anges måste backends också implementera `DatabaseWrapper.get_database_version()`, som returnerar en tupel av den aktuella databasversionen. Backendets metod `DatabaseWrapper.init_connection_state()` måste anropa `super()` för att kontrollen ska kunna köras.

#### Formulär

- Den standardmall som används för att rendera formulär när de kastas till en sträng, t.ex. i mallar som `{{form }}`, kan nu konfigureras på projektnivå genom att ställa in `form_template_name` på den klass som tillhandahålls för `FORM_RENDERER`.

  `Form.template_name` är nu en egenskap som överförs till renderingsprogrammet, men kan åsidosättas med ett strängvärde för att ange mallnamnet per formulärklass.

  På samma sätt kan standardmallen som används för att rendera formulär specificeras via det matchande `formset_template_name` renderer-attributet.

- Den nya formulärmallen `div.html`, som refererar till attributet `Form.template_name_div` och metoden `Form.as_div()`, renderar formulär med hjälp av HTML-elementen `<div>`.

  Denna nya utdatastil rekommenderas framför de befintliga stilarna `as_table()`, `as_p()` och `as_ul()`, eftersom mallen implementerar `<fieldset>` och `<legend>` för att gruppera relaterade indata och är lättare att navigera i för skärmläsaranvändare.

  Den div-baserade utskriften kommer att bli standardrenderingsstilen från Django 5.0.

- För att underlätta antagandet av den nya utdatastilen `<div>` finns två övergångsklasser för formulärrenderare tillgängliga: `django.forms.renderers.DjangoDivFormRenderer` och `django.forms.renderers.Jinja2DivFormRenderer`, för Django- respektive Jinja2-mallbackends.

  Du kan använda en av dessa via inställningen `FORM_RENDERER`. Till exempel:

      FORM_RENDERER = "django.forms.renderers.DjangoDivFormRenderer"

  När utdatastilen `<div>` är standard, från Django 5.0, kommer dessa övergångsrenderare att avskrivas, för borttagning i Django 6.0. Deklarationen `FORM_RENDERER` kan tas bort vid den tidpunkten.

- Om den nya utdatastilen `<div>` inte är lämplig för ditt projekt, bör du definiera en underklass för rendering som anger `form_template_name` och `formset_template_name` för den önskade stilen och ange `FORM_RENDERER` i enlighet med detta.

  Till exempel, för utdatastilen `<p>` som används av `as_p()`, skulle du definiera en formulärrenderare som sätter `form_template_name` till `"django/forms/p.html"` och `formset_template_name` till `"django/forms/formsets/p.html"`.

- Den nya `legend_tag()` tillåter rendering av fältetiketter i `<legend>` taggar via det nya `tag` argumentet i `label_tag()`.

- Det nya argumentet `edit_only` för `modelformset_factory()` och `inlineformset_factory()` gör det möjligt att förhindra att nya objekt skapas.

- Klassattributen `js` och `css` för Media tillåter nu användning av hashbara objekt, inte bara söksträngar, så länge som dessa objekt implementerar metoden `__html__()` (vanligtvis när de dekoreras med dekoratorn `html_safe()`).

- De nya attributen `BoundField.use_fieldset` och `Widget.use_fieldset` hjälper till att identifiera widgets där indata ska grupperas i en `<fieldset>` med en `<legend>`.

- Argumentet Felmeddelanden för `BaseFormSet` gör det nu möjligt att anpassa felmeddelanden för ogiltigt antal formulär genom att skicka nycklarna `'too_few_forms'` och `'too_many_forms'`.

- `IntegerField`, `FloatField` och `DecimalField` accepterar nu valfritt ett `step_size`-argument. Detta används för att ställa in HTML-attributet `step` och valideras när formuläret skickas in.

#### Internationalisering

- Funktionen `i18n_patterns()` stöder nu språk med både skript och regioner.

#### Kommandon för hantering

- `makemigrations --no-input` loggar nu standardsvar och anledningar till varför migreringar inte kan skapas.

- Det nya alternativet `makemigrations --scriptable` omdirigerar loggutdata och inmatningsfrågor till `stderr` och skriver endast sökvägar till genererade migreringsfiler till `stdout`.

- Det nya alternativet `migrate --prune` gör det möjligt att ta bort icke-existerande migreringar från tabellen `django_migrations`.

- Python-filer som skapats av `startproject`, `startapp`, `optimizemigration`, `makemigrations` och `squashmigrations` formateras nu med kommandot `black` om det finns i din `PATH`.

- Det nya kommandot `optimizemigration` gör det möjligt att optimera åtgärder för en migrering.

#### Migreringar

- Den nya `RenameIndex`-operationen gör det möjligt att byta namn på index som definieras i `Meta.indexes` eller `index_together`-alternativen.

- Autodetektorn för migreringar genererar nu `RenameIndex`-operationer i stället för `RemoveIndex` och `AddIndex`, när man byter namn på index som definieras i `Meta.indexes`.

- Migreringsautodetektorn genererar nu `RenameIndex`-operationer istället för `AlterIndexTogether` och `AddIndex`, när index som definieras i `Meta.index_together` flyttas till `Meta.indexes`.

#### Modeller

- Argumentet `order_by` i `Window`-uttrycket accepterar nu strängreferenser till fält och transformationer.

- Den nya inställningen `CONN_HEALTH_CHECKS` gör det möjligt att aktivera hälsokontroller för persistent database connections i syfte att minska antalet misslyckade förfrågningar, t.ex. efter omstart av databasservern.

- `QuerySet.bulk_create()` stöder nu uppdatering av fält när en radinsättning misslyckas med unikhetsbegränsningar. Detta stöds på MariaDB, MySQL, PostgreSQL och SQLite 3.24+.

- `QuerySet.iterator()` har nu stöd för prefetching av relaterade objekt så länge argumentet `chunk_size` anges. I äldre versioner gjordes ingen prefetching.

- `Q`-objekt och querysets kan nu kombineras med hjälp av `^` som operatorn exclusive or (`XOR`). `XOR` har inbyggt stöd i MariaDB och MySQL. För databaser som inte stöder `XOR` kommer frågan att konverteras till en motsvarighet med hjälp av `AND`, `OR` och `NOT`.

- Det nya attributet Field.non_db_attrs gör det möjligt att anpassa attribut för fält som inte påverkar en kolumndefinition.

- På PostgreSQL skapas nu `AutoField`, `BigAutoField` och `SmallAutoField` som identitetskolumner snarare än seriella kolumner med sekvenser.

#### Förfrågningar och svar

- `HttpResponse.set_cookie()` stöder nu `timedelta`-objekt för argumentet `max_age`.

#### Säkerhet

- Den nya inställningen `SECRET_KEY_FALLBACKS` gör det möjligt att ange en lista med värden för rotation av hemliga nycklar.

- Inställningen `SECURE_PROXY_SSL_HEADER` stöder nu en kommaseparerad lista med protokoll i rubrikvärdet.

#### Signaler

- Signalerna `pre_delete` och `post_delete` skickar nu ut raderingens `ursprung`.

#### Mallar

- HTML-elementets `<script>``id`-attribut krävs inte längre när `json_script`-mallfiltret paketeras.

- `cached template loader` är nu aktiverad under utveckling, när `DEBUG` är `True`, och `OPTIONS['loaders']` inte är specificerad. Du kan ange `OPTIONS['loaders']` för att åsidosätta detta, om det behövs.

#### Tester

- `DiscoverRunner` stöder nu parallella tester på macOS, Windows och alla andra system där standardstartmetoden för `multiprocessing` är `spawn`.

- Ett nästlat atomic block som markerats som hållbart i `django.test.TestCase` ger nu upphov till ett `RuntimeError`, på samma sätt som utanför tester.

- `SimpleTestCase.assertFormError()` och `assertFormsetError()` har nu stöd för att skicka ett formulär/formset-objekt direkt.

#### URL:er

- Det nya attributet `ResolverMatch.captured_kwargs` lagrar de nyckelordsargument som fångats upp, såsom de tolkats från URL:en.

- Det nya attributet `ResolverMatch.extra_kwargs` lagrar de ytterligare nyckelordsargument som skickas till vyfunktionen.

#### Verktyg

- `SimpleLazyObject` stöder nu additionsoperationer.

- `mark_safe()` bevarar nu lata objekt.

#### Validerare

- Den nya `StepValueValidator` kontrollerar om ett värde är en integrerad multipel av en given stegstorlek. Denna nya validator används för det nya `step_size`-argumentet som läggs till i formulärfält som representerar numeriska värden.

## Bakåtkompatibla ändringar i 4.1

### Databas backend API

I det här avsnittet beskrivs ändringar som kan behövas i tredjeparts databasbackends.

- `BaseDatabaseFeatures.has_case_insensitive_like` ändras från `True` till `False` för att återspegla beteendet hos de flesta databaser.

- `DatabaseIntrospection.get_key_columns()` har tagits bort. Använd `DatabaseIntrospection.get_relations()` istället.

- metoden `DatabaseOperations.ignore_conflicts_suffix_sql()` ersätts av `DatabaseOperations.on_conflict_suffix_sql()` som accepterar argumenten `fields`, `on_conflict`, `update_fields` och `unique_fields`.

- Argumentet `ignore_conflicts` i metoden `DatabaseOperations.insert_statement()` ersätts av `on_conflict` som accepterar `django.db.models.constants.OnConflict`.

- `DatabaseOperations._convert_field_to_tz()` ersätts av `DatabaseOperations._convert_sql_to_tz()` som accepterar argumenten `sql`, `params` och `tzname`.

- Flera datum- och tidsmetoder i `DatabaseOperations` tar nu `sql` och `params` argument istället för `field_name` och returnerar 2-tupel som innehåller SQL och parametrarna som ska interpoleras i SQL. De ändrade metoderna har dessa nya signaturer:

  - `DatabaseOperations.date_extract_sql(lookup_type, sql, params)`

  - `DatabaseOperations.datetime_extract_sql(lookup_type, sql, params, tzname)`

  - `DatabaseOperations.time_extract_sql(lookup_type, sql, params)`

  - `DatabaseOperations.date_trunc_sql(lookup_type, sql, params, tzname=None)`

  - `DatabaseOperations.datetime_trunc_sql(self, lookup_type, sql, params, tzname)`

  - `DatabaseOperations.time_trunc_sql(lookup_type, sql, params, tzname=None)`

  - `DatabaseOperations.datetime_cast_date_sql(sql, params, tzname)`

  - `DatabaseOperations.datetime_cast_time_sql(sql, params, tzname)`

### `django.contrib.gis`

- Stöd för GDAL 2.1 har tagits bort.

- Stöd för PostGIS 2.4 har tagits bort.

### Slopat stöd för PostgreSQL 10

Uppströmsstöd för PostgreSQL 10 slutar i november 2022. Django 4.1 stöder PostgreSQL 11 och högre.

### Borttaget stöd för MariaDB 10.2

Uppströmsstöd för MariaDB 10.2 upphör i maj 2022. Django 4.1 stöder MariaDB 10.3 och senare.

### Sökningar i administratörens ändringslista som omfattar ändringar i relationer med flera värden

Sökningar i adminändringslistan med flera söktermer tillämpas nu i ett enda anrop till `filter()`, snarare än i sekventiella `filter()`-anrop.

För flervärdesrelationer innebär detta att rader från den relaterade modellen måste matcha alla termer snarare än någon term. Om till exempel `search_fields` är inställt på `['child__name', 'child__age']` och en användare söker efter `'Jamal 17'`, kommer rader med föräldrar endast att returneras om det finns en relation till ett 17-årigt barn som heter Jamal, i stället för att även returnera föräldrar som bara har ett yngre eller äldre barn som heter Jamal utöver någon annan 17-åring.

Se ämnet Spänner över flervärdiga relationer för mer diskussion om denna skillnad. I Django 4.0 och tidigare följde `get_search_results()` den andra exempelfrågan, men detta odokumenterade beteende ledde till frågor med alltför många sammanfogningar.

### Omvända ändringar av främmande nycklar för osparade modellinstanser

För att förenhetliga beteendet med många-till-många-relationer för osparade modellinstanser, ger en omvänd främmande nyckel nu upphov till `ValueError` när man anropar `related managers` för osparade objekt.

### Diverse

- Relaterade hanterare för `ForeignKey`, `ManyToManyField` och `GenericRelation` cachelagras nu på den `Model`-instans som de tillhör. Denna ändring återställdes i Django 4.1.2.

- `DiscoverRunner` now returns a non-zero error code for unexpected successes from tests marked with `unittest.expectedFailure()`.

- `CsrfViewMiddleware` maskerar inte längre CSRF-cookien som den gör med CSRF-token i DOM.

- `CsrfViewMiddleware` använder nu `request.META['CSRF_COOKIE']` för att lagra den omaskerade CSRF-hemligheten istället för en maskerad version. Detta är ett odokumenterat, privat API.

- Attributen `ModelAdmin.actions` och `inlines` är nu standard för en tom tupel snarare än en tom lista för att motverka oavsiktlig mutation.

- Attributet `type="text/css"` ingår inte längre i `<link>` taggar för CSS form media.

- javaScript-händelserna `formset:added` och `formset:removed` är nu rena JavaScript-händelser och är inte beroende av jQuery. Se Inline-formulärhändelser för mer detaljer om förändringen.

- Argumentet `exc_info` i den odokumenterade funktionen `django.utils.log.log_response()` ersätts av `exception`.

- Argumentet `size` i den odokumenterade funktionen `django.views.static.was_modified_since()` har tagits bort.

- Användargränssnittet för inloggning av administratörer använder nu `POST`-förfrågningar.

- Den odokumenterade egenskapen `InlineAdminFormSet.non_form_errors` ersätts av metoden `non_form_errors()`. Detta är i överensstämmelse med `BaseFormSet`.

- Enligt above, är den cachade mallladdaren nu aktiverad i utveckling. Du kan ange `OPTIONS['loaders']` för att åsidosätta detta, om det behövs.

- Den odokumenterade mixen `django.contrib.auth.views.SuccessURLAllowedHostsMixin` ersätts av `RedirectURLMixin`.

- `BaseConstraint` subclasses måste implementera `validate()` method för att tillåta att dessa begränsningar används för validering.

- De odokumenterade `URLResolver._is_callback()`, `URLResolver._callback_strs` och `URLPattern.lookup_str()` flyttas till `django.contrib.admindocs.utils`.

- Metoden `Model.full_clean()` konverterar nu ett `exclude`-värde till ett `set`. Det är också att föredra att skicka ett `exclude`-värde som ett `set` till metoderna `Model.clean_fields()`, `Model.full_clean()`, `Model.validate_unique()`, och `Model.validate_constraints()`.

- Den lägsta versionen av `asgiref` som stöds har ökats från 3.4.1 till 3.5.2.

- Kombinerade uttryck använder inte längre det felbenägna beteendet att gissa `output_field` när argumenttyperna matchar. Som en följd av detta kan upplösningen av ett `output_field` för databasfunktioner och kombinerade uttryck nu krascha med blandade typer. Du måste uttryckligen ange `output_field` i sådana fall.

- Kommandot `makemessages` ändrar inte längre `.po`-filer när de är uppdaterade. I äldre versioner uppdaterades alltid `POT-Creation-Date`.

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

### Logga ut via GET

Logging out via `GET` requests to the `built-in logout view` is deprecated. Use `POST` requests instead.

Om du vill behålla användarupplevelsen av en HTML-länk kan du använda ett formulär som är utformat så att det ser ut som en länk:

    <form id="logout-form" method="post" action="{% url 'admin:logout' %}">
      {% csrf_token %}
      <button type="submit">{% translate "Log out" %}</button>
    </form>

    #logout-form {
      display: inline;
    }
    #logout-form button {
      background: none;
      border: none;
      cursor: pointer;
      padding: 0;
      text-decoration: underline;
    }

### Diverse

- Kontexten för sitemap index mallar av en platt lista över webbadresser är föråldrad. Anpassade sitemap indexmallar bör uppdateras för den justerade context variables, som förväntar sig en lista av objekt med `location` och valfria `lastmod` attribut.

- övergångsinställningen `CSRF_COOKIE_MASKED` är föråldrad.

- Argumentet `name` i `django.utils.functional.cached_property()` är föråldrat eftersom det är onödigt från och med Python 3.6.

- Argumentet `opclasses` i `django.contrib.postgres.constraints.ExclusionConstraint` är föråldrat till förmån för användning av `OpClass()` i `ExclusionConstraint.expressions`. För att använda det måste du lägga till `'django.contrib.postgres'` i din `INSTALLED_APPS`.

  När du har gjort den här ändringen kommer `makemigrations` att generera en ny migrering med två åtgärder: `RemoveConstraint` och `AddConstraint`. Eftersom denna ändring inte har någon effekt på databasschemat kan operationen `SeparateDatabaseAndState` användas för att bara uppdatera migreringstillståndet utan att köra någon SQL. Flytta de genererade operationerna till argumentet `state_operations` i `SeparateDatabaseAndState`. Till exempel:

      class Migration(migrations.Migration):
          ...

          operations = [
              migrations.SeparateDatabaseAndState(
                  database_operations=[],
                  state_operations=[
                      migrations.RemoveConstraint(...),
                      migrations.AddConstraint(...),
                  ],
              ),
          ]

- Den odokumenterade möjligheten att skicka `errors=None` till `SimpleTestCase.assertFormError()` och `assertFormsetError()` är föråldrad. Använd `errors=[]` istället.

- `django.contrib.sessions.serializers.PickleSerializer` är föråldrad på grund av risken för exekvering av fjärrkod.

- Användningen av `QuerySet.iterator()` på en queryset som hämtar relaterade objekt utan att ange argumentet `chunk_size` är föråldrad. I äldre versioner gjordes ingen förhämtning. Om man anger ett värde för `chunk_size` innebär det att man vill ha den extra fråga per chunk som behövs för att göra prefetch.

- Att skicka osparade modellinstanser till relaterade filter är föråldrat. I Django 5.0 kommer undantaget att tas upp.

- `created=True` läggs till i signaturen för `RemoteUserBackend.configure_user()`. Stöd för subklasser av `RemoteUserBackend` som inte accepterar detta argument är föråldrat.

- Aliaset `django.utils.timezone.utc` till `datetime.timezone.utc`` är föråldrat. Använd `datetime.timezone.utc` direkt.

- Att skicka ett svarsobjekt och ett namn på formulär/formset till `SimpleTestCase.assertFormError()` och `assertFormsetError()` är föråldrat. Använd:

      assertFormError(response.context["form_name"], ...)
      assertFormsetError(response.context["formset_name"], ...)

  eller skicka formuläret/formset-objektet direkt istället.

- Den odokumenterade `django.contrib.gis.admin.OpenLayersWidget` är föråldrad.

- `django.contrib.auth.hashers.CryptPasswordHasher` är föråldrad.

- Möjligheten att skicka `nulls_first=False` eller `nulls_last=False` till metoderna `Expression.asc()` och `Expression.desc()` och uttrycket `OrderBy` är föråldrad. Använd `None` istället.

- Mallarna `"django/forms/default.html"` och `"django/forms/formsets/default.html"` som är en proxy till de tabellbaserade mallarna är föråldrade. Använd den specifika mallen istället.

- Den odokumenterade metoden `LogoutView.get_next_page()` har bytt namn till `get_success_url()`.

## Funktioner borttagna i 4.1

Dessa funktioner har nått slutet av sin utfasningscykel och tas bort i Django 4.1.

Se Funktioner som inte längre är aktuella i 3.2 för detaljer om dessa ändringar, inklusive hur man tar bort användningen av dessa funktioner.

- Stöd för att tilldela objekt som inte stöder skapande av djupa kopior med `copy.deepcopy()` till klassattribut i `TestCase.setUpTestData()` har tagits bort.

- Stöd för att använda ett boolean-värde i `BaseCommand.requires_system_checks` har tagits bort.

- Argumentet `whitelist` och attributet `domain_whitelist` i `django.core.validators.EmailValidator` har tagits bort.

- Programkonfigurationsvariabeln `default_app_config` tas bort.

- `TransactionTestCase.assertQuerysetEqual()` anropar inte längre `repr()` på en queryset när den jämförs med strängvärden.

- Backend `django.core.cache.backends.memcached.MemcachedCache` har tagits bort.

- Stöd för formatet före Django 3.2 för meddelanden som används av `django.contrib.messages.storage.cookie.CookieStorage` tas bort.