# Django 6.0.5 documentation

# `django-admin` och `manage.py`

`django-admin` är Djangos kommandoradsverktyg för administrativa uppgifter. Detta dokument beskriver allt det kan göra.

Dessutom skapas `manage.py` automatiskt i varje Django-projekt. Den gör samma sak som `django-admin` men ställer också in miljövariabeln `DJANGO_SETTINGS_MODULE` så att den pekar på ditt projekts `settings.py`-fil.

Skriptet `django-admin` bör finnas på din systemsökväg om du installerade Django via `pip`. Om det inte finns i din sökväg, se till att du har aktiverat din virtuella miljö.

När du arbetar med ett enda Django-projekt är det i allmänhet lättare att använda `manage.py` än `django-admin`. Om du behöver växla mellan flera Django-inställningsfiler, använd `django-admin` med `DJANGO_SETTINGS_MODULE` eller kommandoradsalternativet `--settings`.

I kommandoradsexemplen i det här dokumentet används `django-admin` för att vara konsekvent, men alla exempel kan lika gärna använda `manage.py` eller `python -m django`.

## Användning

/ 

    $ django-admin <command> [options]
    $ manage.py <command> [options]
    $ python -m django <command> [options]

    ...\> django-admin <command> [options]
    ...\> manage.py <command> [options]
    ...\> py -m django <command> [options]

`command` ska vara ett av de kommandon som listas i detta dokument. `options`, som är valfritt, ska vara noll eller flera av de alternativ som finns tillgängliga för det angivna kommandot.

### Få hjälp under körtiden

django-admin help

Kör `django-admin help` för att visa användningsinformation och en lista över de kommandon som tillhandahålls av varje program.

Kör `django-admin help --commands` för att visa en lista över alla tillgängliga kommandon.

Kör `django-admin help <command>` för att visa en beskrivning av det angivna kommandot och en lista över dess tillgängliga alternativ.

### Appens namn

Många kommandon tar emot en lista med ”appnamn” Ett ”appnamn” är basnamnet på det paket som innehåller dina modeller. Om din `INSTALLED_APPS` till exempel innehåller strängen `'mysite.blog'`, är appnamnet `blog`.

### Fastställande av version

django-admin version

Kör `django-admin version` för att visa den aktuella Django-versionen.

Utdata följer det schema som beskrivs i PEP 440:

    1.4.dev17026
    1.4a1
    1.4

### Visning av debug-utdata

Använd `--verbosity`, där det stöds, för att ange mängden meddelande- och felsökningsinformation som `django-admin` skriver ut till konsolen.

## Tillgängliga kommandon

### `kontroll`

django-admin check [app_label [app_label ...]]

Använder systemkontrollramverket för att inspektera hela Django-projektet för vanliga problem.

Som standard kommer alla appar att kontrolleras. Du kan kontrollera en delmängd av appar genom att ange en lista med appetiketter som argument:

    django-admin check auth admin myapp

--tag TAGS, -t TAGS

Ramverket för systemkontroller utför många olika typer av kontroller som är kategoriserade med taggar. Du kan använda dessa taggar för att begränsa de kontroller som utförs till att bara omfatta kontroller i en viss kategori. Om du t.ex. bara vill utföra kontroller av modeller och kompatibilitet kör du:

    django-admin check --tag models --tag compatibility

--database DATABASE

Anger den databas där kontroller som kräver databasåtkomst ska utföras:

    django-admin check --database default --database other

Som standard kommer dessa kontroller inte att köras.

--list-tags

Visar en lista över alla tillgängliga taggar.

--deploy

Aktiverar några ytterligare kontroller som endast är relevanta i en distributionsinställning.

Du kan använda detta alternativ i din lokala utvecklingsmiljö, men eftersom din lokala inställningsmodul för utveckling kanske inte har många av dina produktionsinställningar, kommer du förmodligen att vilja rikta kommandot `check` mot en annan inställningsmodul, antingen genom att ange miljövariabeln `DJANGO_SETTINGS_MODULE` eller genom att ange alternativet `--settings`:

    django-admin check --deploy --settings=production_settings

Eller så kan du köra det direkt på en produktions- eller staging-distribution för att verifiera att rätt inställningar används (genom att utelämna `--settings`). Du kan till och med göra det till en del av din integrationstestsvit.

--fail-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}

Anger den meddelandenivå som gör att kommandot avslutas med en status som inte är noll. Standard är `ERROR`.

### `compilemessages`

django-admin compilemessages

Kompilerar `.po`-filer skapade av `makemessages` till `.mo`-filer för användning med det inbyggda gettext-stödet. Se Internationalisering och lokalisering.

--locale LOCALE, -l LOCALE

Anger den eller de lokala språkversioner som ska bearbetas. Om inget anges bearbetas alla lokala språk.

--exclude EXCLUDE, -x EXCLUDE

Anger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.

--use-fuzzy, -f

Inkluderar fuzzy translations i kompilerade filer.

Exempel på användning:

    django-admin compilemessages --locale=pt_BR
    django-admin compilemessages --locale=pt_BR --locale=fr -f
    django-admin compilemessages -l pt_BR
    django-admin compilemessages -l pt_BR -l fr --use-fuzzy
    django-admin compilemessages --exclude=pt_BR
    django-admin compilemessages --exclude=pt_BR --exclude=fr
    django-admin compilemessages -x pt_BR
    django-admin compilemessages -x pt_BR -x fr

--ignore PATTERN, -i PATTERN

Ignorerar kataloger som matchar det angivna `glob`-stilmönstret. Använd flera gånger för att ignorera fler.

Exempel på användning:

    django-admin compilemessages --ignore=cache --ignore=outdated/*/locale

### `createcachetable`

django-admin createcachetable

Skapar cachetabellerna för användning med databasens cache-backend med hjälp av informationen från din inställningsfil. Se Djangos ramverk för cache för mer information.

--database DATABASE

Anger den databas i vilken cachetabellen/-tabellerna ska skapas. Standardvärdet är `default`.

--dry-run

Skriver ut den SQL som ska köras utan att faktiskt köra den, så att du kan anpassa den eller använda migreringsramverket.

### `dbshell`

django-admin dbshell

Kör kommandoradsklienten för den databasmotor som anges i inställningen `ENGINE`, med de anslutningsparametrar som anges i inställningarna `USER`, `PASSWORD`, etc.

- För PostgreSQL kör detta kommandoradsklienten `` psql``.

- För MySQL körs kommandoradsklienten `mysql`.

- För SQLite körs kommandoradsklienten `sqlite3`.

- För Oracle körs kommandoradsklienten `sqlplus`.

Detta kommando förutsätter att programmen finns i din `PATH` så att ett anrop till programnamnet (`psql`, `mysql`, `sqlite3`, `sqlplus`) hittar programmet på rätt plats. Det finns inget sätt att ange platsen för programmet manuellt.

--database DATABASE

Anger den databas där ett skal ska öppnas. Standardvärdet är `default`.

-- ARGUMENTS

Alla argument som följer en `` —`` avdelare kommer att vidarebefordras till den underliggande kommandoradsklienten. Till exempel:, med PostgreSQL kan du använda kommandot `` psql`` kommandots `` c`` flagga för att köra en rå SQL-fråga direkt:

/ 

    $ django-admin dbshell -- -c 'select current_user'
     current_user
    --------------
     postgres
    (1 row)

    ...\> django-admin dbshell -- -c 'select current_user'
     current_user
    --------------
     postgres
    (1 row)

På MySQL/MariaDB kan du göra detta med kommandot `mysql` flagga `-e`:

/ 

    $ django-admin dbshell -- -e "select user()"
    +----------------------+
    | user()               |
    +----------------------+
    | djangonaut@localhost |
    +----------------------+

    ...\> django-admin dbshell -- -e "select user()"
    +----------------------+
    | user()               |
    +----------------------+
    | djangonaut@localhost |
    +----------------------+

Observera

Tänk på att inte alla alternativ som anges i `OPTIONS`-delen av din databaskonfiguration i `DATABASES` skickas till kommandoradsklienten, t.ex. `'isolation_level'`.

### `differensinställningar`

django-admin diffsettings

Visar skillnader mellan den aktuella inställningsfilen och Djangos standardinställningar (eller en annan inställningsfil som anges av `--default`).

Inställningar som inte finns med i standardinställningarna följs av `"###"`. Standardinställningarna definierar till exempel inte `ROOT_URLCONF`, så `ROOT_URLCONF` följs av `"###"` i utdata från `diffsettings`.

--all

Visar alla inställningar, även om de har Djangos standardvärde. Sådana inställningar inleds med `"###"`.

--default MODULE

Den inställningsmodul som de aktuella inställningarna ska jämföras med. Lämna tom för att jämföra mot Djangos standardinställningar.

--output {hash,unified}

Anger utdataformat. Tillgängliga värden är `hash` och `unified`. `hash` är standardläget som visar utdata enligt beskrivningen ovan. `unified` visar utdata som liknar `diff -u`. Standardinställningar inleds med ett minustecken, följt av den ändrade inställningen som inleds med ett plustecken.

### `Dumpdata`

django-admin dumpdata [app_label[.ModelName] [app_label[.ModelName] ...]]

Skickar ut alla data i databasen som är kopplade till de namngivna programmen till standardutdata.

Om inget applikationsnamn anges kommer alla installerade applikationer att dumpas.

Utdata från `dumpdata` kan användas som indata för `loaddata`.

När resultatet av `dumpdata` sparas som en fil kan den fungera som en fixtur för tester eller som en initial data.

Observera att `dumpdata` använder standardhanteraren i modellen för att välja vilka poster som ska dumpas. Om du använder en custom manager som standardhanterare och den filtrerar några av de tillgängliga posterna, kommer inte alla objekt att dumpas.

--all, -a

Använder Djangos bashanterare och dumpar poster som annars skulle kunna filtreras eller ändras av en anpassad hanterare.

--format FORMAT

Anger serialiseringsformatet för utdata. Standardvärdet är JSON. Format som stöds listas i Format för serialisering.

--indent INDENT

Anger antalet indragningsutrymmen som ska användas i utdata. Standardvärdet är `None` som visar alla data på en enda rad.

--exclude EXCLUDE, -e EXCLUDE

Förhindrar att specifika program eller modeller (anges i form av `app_label.ModelName`) dumpas. Om du anger ett modellnamn är det bara den modellen som utesluts, inte hela programmet. Du kan också blanda programnamn och modellnamn.

Om du vill utesluta flera program, skicka `--exclude` mer än en gång:

    django-admin dumpdata --exclude=auth --exclude=contenttypes

--database DATABASE

Anger den databas från vilken data ska dumpas. Standardvärdet är `default`.

--natural-foreign

Använder modellmetoden `natural_key()` för att serialisera alla foreign key och many-to-many-relationer till objekt av den typ som definierar metoden. Om du dumpar `contrib.auth` `Permission`-objekt eller `contrib.contenttypes` `ContentType`-objekt bör du förmodligen använda den här flaggan. Se natural keys-dokumentationen för mer information om detta och nästa alternativ.

--natural-primary

Utelämnar primärnyckeln i de serialiserade data för detta objekt eftersom den kan beräknas under deserialiseringen.

--pks PRIMARY_KEYS

Skickar endast ut de objekt som anges i en kommaseparerad lista med primärnycklar. Detta är endast tillgängligt vid dumpning av en modell. Som standard matas alla poster i modellen ut.

--output OUTPUT, -o OUTPUT

Anger en fil som de serialiserade data ska skrivas till. Som standard går data till standardutdata.

När detta alternativ är inställt och `--verbosity` är större än 0 (standard), visas en förloppsindikator i terminalen.

#### Komprimering av fixturer

Utdatafilen kan komprimeras med något av formaten `bz2`, `gz`, `lzma` eller `xz` genom att avsluta filnamnet med motsvarande tillägg. Till exempel:, för att mata ut data som en komprimerad JSON-fil:

    django-admin dumpdata -o mydata.json.gz

### `spola`

django-admin flush

Tar bort alla data från databasen och kör om alla postsynkroniseringshanterare. Tabellen över vilka migreringar som har tillämpats rensas inte.

Om du hellre vill starta från en tom databas och köra alla migreringar på nytt bör du ta bort och återskapa databasen och sedan köra `migrate` istället.

--noinput, --no-input

Undertrycker alla användarinstruktioner.

--database DATABASE

Anger vilken databas som ska rensas. Standardvärdet är `default`.

### `inspectdb`

django-admin inspectdb [table [table ...]]

Introspekterar databastabellerna i databasen som pekas ut av inställningen `NAME` och matar ut en Django-modellmodul (en `models.py`-fil) till standardutdata.

Du kan välja vilka tabeller eller vyer som ska inspekteras genom att ange deras namn som argument. Om inga argument anges skapas modeller för vyer endast om alternativet `--include-views` används. Modeller för partitionstabeller skapas på PostgreSQL om alternativet `--include-partitions` används.

Använd detta om du har en äldre databas som du vill använda Django med. Skriptet kommer att inspektera databasen och skapa en modell för varje tabell i den.

Som du kanske förväntar dig kommer de skapade modellerna att ha ett attribut för varje fält i tabellen. Observera att `inspectdb` har några specialfall i sin fältnamnsutmatning:

- Om `inspectdb` inte kan mappa en kolumns typ till en modellfälttyp, kommer den att använda `TextField` och infoga Python-kommentaren `'Denna fälttyp är en gissning.'` bredvid fältet i den genererade modellen. De fält som identifieras kan bero på appar som listas i `INSTALLED_APPS`. Till exempel: lägger `django.contrib.postgres` till igenkänning för flera PostgreSQL-specifika fälttyper.

- Om databasens kolumnnamn är ett reserverat Python-ord (som `'pass'`, `'class'` eller `'for'`), kommer `inspectdb` att lägga till `'_field'` till attributnamnet. Om en tabell till exempel har kolumnen `'for'`, kommer den genererade modellen att ha fältet `'for_field'`, med attributet `db_column` inställt på `'for'`. `inspectdb` kommer att infoga Python-kommentaren `'Fältet döptes om eftersom det var ett reserverat Python-ord.'` bredvid fältet.

Den här funktionen är tänkt som en genväg, inte som en slutgiltig modellgenerering. När du har kört den bör du själv titta igenom de genererade modellerna för att göra anpassningar. Framför allt behöver du ändra modellernas ordning så att modeller som hänvisar till andra modeller får rätt ordning.

Django skapar inte standardvärden för databaser när en `default` anges för ett modellfält. På samma sätt översätts inte databasstandardvärden till standardvärden för modellfält eller upptäcks på något sätt av `inspectdb`.

Som standard skapar `inspectdb` ohanterade modeller. Det vill säga, `managed = False` i modellens `Meta`-klass säger till Django att inte hantera varje tabells skapande, modifiering och radering. Om du vill tillåta Django att hantera tabellens livscykel måste du ändra alternativet `managed` till `True` (eller ta bort det eftersom `True` är dess standardvärde).

#### Databasspecifika anteckningar

##### Oracle

- Modeller skapas för materialiserade vyer om `--include-views` används.

##### PostgreSQL

- Modeller skapas för utländska tabeller.

- Modeller skapas för materialiserade vyer om `--include-views` används.

- Modeller skapas för partitionstabeller om `--include-partitions` används.

--database DATABASE

Anger vilken databas som ska introspekteras. Standardvärdet är `default`.

--include-partitions

Om detta alternativ anges skapas även modeller för partitioner.

Endast stöd för PostgreSQL är implementerat.

--include-views

Om detta alternativ anges skapas även modeller för databasvyer.

### `Ladda data`

django-admin loaddata fixture [fixture ...]

Söker efter och laddar innehållet i den namngivna fixture i databasen.

--database DATABASE

Anger den databas som data ska laddas till. Standardvärdet är `default`.

--ignorenonexistent, -i

Ignorerar fält och modeller som kan ha tagits bort sedan fixturen ursprungligen skapades.

--app APP_LABEL

Anger en enda app att leta efter fixturer i istället för att leta i alla appar.

--format FORMAT

Anger serialiseringsformat (t.ex. `json` eller `xml`) för fixturer läs från stdin.

--exclude EXCLUDE, -e EXCLUDE

Utesluter laddning av fixturerna från de angivna applikationerna och/eller modellerna (i form av `app_label` eller `app_label.ModelName`). Använd alternativet flera gånger för att utesluta mer än en app eller modell.

#### Laddar fixturer från `stdin`

Du kan använda ett bindestreck som fixturnamn för att ladda inmatning från `sys.stdin`. Till exempel:

    django-admin loaddata --format=json -

Vid läsning från `stdin` krävs alternativet `--format` för att ange serialiseringsformat för indata (t.ex. `json` eller `xml`).

Att ladda från `stdin` är användbart med omdirigeringar av standardinmatning och -utmatning. Till exempel:

    django-admin dumpdata --format=json --database=test app_label.ModelName | django-admin loaddata --format=json --database=prod -

Kommandot `dumpdata` kan användas för att generera indata för `loaddata`.

Se även

Mer information om fixturer finns i ämnet Fixturer.

### `makemessages`

django-admin makemessages

Går igenom hela källträdet i den aktuella katalogen och drar ut alla strängar som är markerade för översättning. Den skapar (eller uppdaterar) en meddelandefil i katalogen conf/locale (i Django-trädet) eller locale (för projekt och program). När du har gjort ändringar i meddelandefilerna måste du kompilera dem med `compilemessages` för användning med det inbyggda gettext-stödet. Se i18n documentation för mer information.

Det här kommandot kräver inga konfigurerade inställningar. Men när inställningarna inte är konfigurerade kan kommandot inte ignorera katalogerna `MEDIA_ROOT` och `STATIC_ROOT` eller inkludera `LOCALE_PATHS`.

--all, -a

Uppdaterar meddelandefilerna för alla tillgängliga språk.

--extension EXTENSIONS, -e EXTENSIONS

Anger en lista med filändelser som ska undersökas (standard: `html`, `txt`, `py` eller `js` om `--domain` är `djangojs`).

Exempel på användning:

    django-admin makemessages --locale=de --extension xhtml

Separera flera tillägg med kommatecken eller använd `-e` eller `--extension` flera gånger:

    django-admin makemessages --locale=de --extension=html,txt --extension xml

--locale LOCALE, -l LOCALE

Anger den eller de locale(s) som ska bearbetas.

--exclude EXCLUDE, -x EXCLUDE

Anger den eller de lokala språkversioner som ska undantas från bearbetning. Om inget anges utesluts inga lokala språk.

Exempel på användning:

    django-admin makemessages --locale=pt_BR
    django-admin makemessages --locale=pt_BR --locale=fr
    django-admin makemessages -l pt_BR
    django-admin makemessages -l pt_BR -l fr
    django-admin makemessages --exclude=pt_BR
    django-admin makemessages --exclude=pt_BR --exclude=fr
    django-admin makemessages -x pt_BR
    django-admin makemessages -x pt_BR -x fr

--domain DOMAIN, -d DOMAIN

Anger domänen för meddelandefilerna. Alternativ som stöds är:

- `django` för alla `*.py`, `*.html` och `*.txt`-filer (standard)

- `djangojs` för `*.js`-filer

--symlinks, -s

Följer symlinks till kataloger när du letar efter nya översättningssträngar.

Exempel på användning:

    django-admin makemessages --locale=de --symlinks

--ignore PATTERN, -i PATTERN

Ignorerar filer eller kataloger som matchar det angivna `glob`-stilmönstret. Använd flera gånger för att ignorera fler.

Dessa mönster används som standard: `'CVS'`, `'.*'`, `'*~'`, `'*.pyc'`.

Exempel på användning:

    django-admin makemessages --locale=en_US --ignore=apps/* --ignore=secret/*.html

--no-default-ignore

Inaktiverar standardvärdena för `--ignore`.

--no-wrap

Avaktiverar uppdelning av långa meddelanderader i flera rader i språkfiler.

--no-location

Undertrycker skrivning av ”`#: filnamn:rad`”-kommentarrader i språkfiler. Om du använder detta alternativ blir det svårare för tekniskt skickliga översättare att förstå varje meddelandes sammanhang.

--add-location [{full,file,never}]

Styr `#: filnamn:rad` kommentarrader i språkfiler. Om alternativet är:

- `full` (standard om den inte anges): raderna innehåller både filnamn och radnummer.

- `file`: radnumret utelämnas.

- `never`: raderna undertrycks (samma som `--no-location`).

Kräver `gettext` 0.19 eller nyare.

--no-obsolete

Tar bort föråldrade meddelandesträngar från filerna `.po`.

--keep-pot

Förhindrar att de temporära `.pot`-filerna som genereras innan `.po`-filen skapas raderas. Detta är användbart vid felsökning av fel som kan förhindra att de slutliga språkfilerna skapas.

Se även

Se Anpassa kommandot ”Makemessages för instruktioner om hur du anpassar de nyckelord som `makemessages` skickar till `xgettext`.

### `makemigreringar`

django-admin makemigrations [app_label [app_label ...]]

Skapar nya migreringar baserat på de ändringar som upptäcks i dina modeller. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.

Om du anger ett eller flera appnamn som argument begränsas de migreringar som skapas till den eller de angivna apparna och eventuella beroenden som behövs (t.ex. tabellen i andra änden av en `ForeignKey`).

Om du vill lägga till migreringar i en app som inte har en katalog med namnet `migrations` kör du `makemigrations` med appens `app_label`.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 3.

--empty

Skriver ut en tom migrering för de angivna apparna, för manuell redigering. Detta är för avancerade användare och bör inte användas om du inte är bekant med migreringsformatet, migreringsåtgärderna och beroendena mellan dina migreringar.

--dry-run

Visar vilka migreringar som skulle göras utan att några migreringsfiler faktiskt skrivs till disken. Om du använder detta alternativ tillsammans med `--verbosity 3` visas även de fullständiga migreringsfiler som skulle skrivas.

--merge

Gör det möjligt att åtgärda migrationskonflikter.

--name NAME, -n NAME

Tillåter namngivning av genererade migreringar istället för att använda ett genererat namn. Namnet måste vara en giltig Python identifierare.

--no-header

Generera migreringsfiler utan Django-version och tidsstämpelhuvud.

--check

Gör att `makemigrations` avslutas med en status som inte är noll när modelländringar utan migreringar upptäcks. Innebär `--dry-run`.

--scriptable

Omdirigerar loggutdata och inmatningsfrågor till `stderr` och skriver endast sökvägar för genererade migreringsfiler till `stdout`.

--update

Sammanfogar modelländringar till den senaste migreringen och optimerar de resulterande operationerna.

Den uppdaterade migreringen kommer att ha ett genererat namn. För att bevara det tidigare namnet, ställ in det med `--name`.

### `migrera`

django-admin migrate [app_label] [migration_name]

Synkroniserar databastillståndet med den aktuella uppsättningen modeller och migreringar. Migreringar, deras förhållande till appar med mera behandlas ingående i dokumentationen om migreringar.

Kommandot fungerar på olika sätt beroende på vilka argument som anges:

- Inga argument: Alla appar har alla sina migreringar körda.

- `<app_label>`: Den angivna appen får sina migreringar körda, fram till den senaste migreringen. Detta kan innebära att andra appars migreringar också körs, på grund av beroenden.

- `<app_label> <migrationname>`: För databasschemat till ett tillstånd där den namngivna migreringen tillämpas, men inga senare migreringar i samma app tillämpas. Detta kan innebära att migreringar inte tillämpas om du tidigare har migrerat förbi den namngivna migreringen. Du kan använda ett prefix för migreringsnamnet, t.ex. `0001`, så länge det är unikt för det angivna appnamnet. Använd namnet `zero` för att migrera hela vägen tillbaka, dvs. för att återställa alla tillämpade migreringar för en app.

Varning

När migreringar tas bort kommer alla beroende migreringar också att tas bort, oavsett `<app_label>`. Du kan använda `--plan` för att kontrollera vilka migreringar som inte kommer att tillämpas.

--database DATABASE

Anger den databas som ska migreras. Standardvärdet är `default`.

--fake

Markerar migreringarna upp till målet (enligt reglerna ovan) som tillämpade, men utan att faktiskt köra SQL för att ändra ditt databasschema.

Detta är avsett för avancerade användare som vill manipulera det aktuella migreringstillståndet direkt om de manuellt tillämpar ändringar; varnas för att användning av `--fake` riskerar att sätta migreringstillståndstabellen i ett tillstånd där manuell återställning kommer att krävas för att migreringarna ska fungera korrekt.

--fake-initial

Tillåter Django att hoppa över en apps första migrering om alla databastabeller med namnen på alla modeller som skapats av alla `CreateModel`-operationer i den migreringen redan finns. Det här alternativet är avsett att användas när migreringar körs för första gången mot en databas som inte tidigare använde migreringar. Det här alternativet kontrollerar dock inte att databasschemat matchar utöver matchande tabellnamn och är därför bara säkert att använda om du är säker på att ditt befintliga schema matchar det som registreras i din första migrering.

--plan

Visar de migreringsåtgärder som kommer att utföras för det angivna kommandot `migrate`.

--run-syncdb

Gör det möjligt att skapa tabeller för appar utan migreringar. Även om detta inte rekommenderas är migreringsramverket ibland för långsamt i stora projekt med hundratals modeller.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Ett exempel är en fråga om att ta bort inaktuella innehållstyper.

--check

Gör att `migrate` avslutas med en status som inte är noll när oanvända migreringar upptäcks.

--prune

Raderar icke-existerande migreringar från tabellen `django_migrations`. Detta är användbart när migreringsfiler som ersatts av en krossad migrering har tagits bort. Se Minska antalet migreringar för mer information.

### `optimera migreringen`

django-admin optimizemigration app_label migration_name

Optimerar åtgärderna för den namngivna migreringen och åsidosätter den befintliga filen. Om migreringen innehåller funktioner som måste kopieras manuellt skapar kommandot en ny migreringsfil med suffixet `_optimized` som är avsedd att ersätta den namngivna migreringen.

--check

Gör att `optimizemigration` avslutas med en status som inte är noll när en migrering kan optimeras.

### `runserver`

django-admin runserver [addrport]

Startar en lättviktig webbserver för utveckling på den lokala maskinen. Som standard körs servern på port 8000 på IP-adressen `127.0.0.1`. Du kan ange en IP-adress och ett portnummer explicit.

Om du kör det här skriptet som en användare med normala privilegier (rekommenderas) kanske du inte har tillgång till att starta en port på ett lågt portnummer. Låga portnummer är reserverade för superanvändaren (root).

Den här servern använder det WSGI-applikationsobjekt som anges i inställningen `WSGI_APPLICATION`.

Varning

ANVÄND INTE DENNA SERVER I EN PRODUKTIONSMILJÖ.

Denna lätta utvecklingsserver har inte genomgått säkerhetsgranskningar eller prestandatester och är därför olämplig för produktion. Att göra den här servern kapabel att hantera en produktionsmiljö ligger utanför Djangos omfattning.

Utvecklingsservern laddar automatiskt om Python-koden för varje begäran, efter behov. Du behöver inte starta om servern för att kodändringar ska träda i kraft. Vissa åtgärder, som att lägga till filer, utlöser dock inte en omstart, så du måste starta om servern i dessa fall.

Om du använder Linux eller MacOS och installerar både pywatchman och Watchman-tjänsten, kommer kernelsignaler att användas för att autoladda servern (i stället för att polla tidsstämplar för filändringar varje sekund). Detta ger bättre prestanda i stora projekt, minskad svarstid efter kodändringar, mer robust ändringsdetektering och minskad energianvändning. Django stöder `pywatchman` 1.2.0 och högre.

Stora kataloger med många filer kan orsaka prestandaproblem

När Watchman används i ett projekt som innehåller stora icke-Python-kataloger som `node_modules`, är det lämpligt att ignorera denna katalog för optimal prestanda. Se watchman documentation för information om hur du gör detta.

Timeout för vaktman

DJANGO_WATCHMAN_TIMEOUT

Standardtimeouten för `Watchman`-klienten är 5 sekunder. Du kan ändra den genom att ställa in miljövariabeln `DJANGO_WATCHMAN_TIMEOUT`.

När du startar servern, och varje gång du ändrar Python-kod medan servern körs, kommer ramverket för systemkontroll att kontrollera hela ditt Django-projekt för några vanliga fel (se kommandot `check`). Om några fel hittas kommer de att skrivas ut till standardutmatningen. Du kan använda alternativet `--skip-checks` för att hoppa över att köra systemkontroller.

Du kan köra så många samtidiga servrar som du vill, så länge de är på separata portar genom att köra `django-admin runserver` mer än en gång.

Observera att standard-IP-adressen, `127.0.0.1`, inte är tillgänglig från andra maskiner i nätverket. Om du vill att utvecklingsservern ska kunna ses av andra datorer i nätverket använder du dess egen IP-adress (t.ex. `192.168.2.1`), `0` (genväg för `0.0.0.0`), `0.0.0.0` eller `::` (med IPv6 aktiverat).

Du kan ange en IPv6-adress omgiven av parenteser (t.ex. `[200a::1]:8000`). Detta aktiverar automatiskt IPv6-stöd.

Ett värdnamn som endast innehåller ASCII-tecken kan också användas.

Om contrib-appen staticfiles är aktiverad (standard i nya projekt) kommer kommandot `runserver` att åsidosättas med sitt eget kommando runserver.

Loggning av varje begäran och svar från servern skickas till loggern django.server.

--noreload

Inaktiverar den automatiska omladdaren. Detta innebär att eventuella ändringar i Python-koden som du gör medan servern körs inte kommer att träda i kraft om de specifika Python-modulerna redan har laddats in i minnet.

--nothreading

Inaktiverar användning av trådning i utvecklingsservern. Servern är flertrådig som standard.

--ipv6, -6

Använder IPv6 för utvecklingsservern. Detta ändrar standard-IP-adressen från `127.0.0.1` till `::1`.

DJANGO_RUNSERVER_HIDE_WARNING

New in Django 5.2.

Som standard skrivs en varning ut till konsolen om att `runserver` inte är lämplig för produktion:

    WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
    For more information on production servers see: https://docs.djangoproject.com/en/|version|/howto/deployment/

Ställ in denna miljövariabel på `"true"` för att dölja denna varning.

#### Exempel på användning av olika portar och adresser

Port 8000 på IP-adress `127.0.0.1`:

    django-admin runserver

Port 8000 på IP-adress `1.2.3.4`:

    django-admin runserver 1.2.3.4:8000

Port 7000 på IP-adress `127.0.0.1`:

    django-admin runserver 7000

Port 7000 på IP-adress `1.2.3.4`:

    django-admin runserver 1.2.3.4:7000

Port 8000 på IPv6-adress `::1`:

    django-admin runserver -6

Port 7000 på IPv6-adress `::1`:

    django-admin runserver -6 7000

Port 7000 på IPv6-adressen `2001:0db8:1234:5678::9`:

    django-admin runserver [2001:0db8:1234:5678::9]:7000

Port 8000 på IPv4-adressen för värden `localhost`:

    django-admin runserver localhost:8000

Port 8000 på IPv6-adressen för värden `localhost`:

    django-admin runserver -6 localhost:8000

#### Servering av statiska filer med utvecklingsservern

Som standard serverar utvecklingsservern inte några statiska filer för din webbplats (t.ex. CSS-filer, bilder, saker under `MEDIA_URL` och så vidare). Om du vill konfigurera Django för att servera statiska media, läs Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS).

#### Tjänstgöring med ASGI under utveckling

Djangos kommando `runserver` tillhandahåller en WSGI-server. För att kunna köra under ASGI måste du använda en ASGI-server. Django Daphne-projektet tillhandahåller Integration med runserver som du kan använda.

### `sendtestemail`

django-admin sendtestemail [email [email ...]]

Skickar ett testmejl (för att bekräfta att det fungerar att skicka e-post via Django) till den eller de mottagare som anges. Till exempel:

    django-admin sendtestemail foo@example.com bar@example.com

Det finns ett par alternativ, och du kan använda vilken kombination som helst av dem tillsammans:

--managers

Skickar e-postmeddelanden till de e-postadresser som anges i `MANAGERS` med hjälp av `mail_managers()`.

--admins

Skickar e-postmeddelanden till de e-postadresser som anges i `ADMINS` med hjälp av `mail_admins()`.

### `shell`

django-admin shell

Startar den interaktiva Python-tolken.

All models from installed apps are automatically imported into the shell environment. Models from apps listed earlier in `INSTALLED_APPS` take precedence. The following common utilities are also imported:

    from django.db import connection, reset_queries, models
    from django.conf import settings
    from django.utils import timezone

For a `--verbosity` of 2 or higher, the automatically imported objects will be listed. To disable automatic importing entirely, use the `--no-imports` flag.

See the guide on customizing this behavior to add or remove automatic imports.

Changed in Django 5.2:

Automatisk import av modeller har lagts till.

Changed in Django 6.0:

Automatic imports of common utilities, such as `django.conf.settings`, were added.

--interface {ipython,bpython,python}, -i {ipython,bpython,python}

Anger vilket shell som ska användas. Som standard kommer Django att använda IPython eller bpython om något av dem är installerat. Om båda är installerade, ange vilket du vill ha så här:

IPython:

    django-admin shell -i ipython

bpython:

    django-admin shell -i bpython

Om du har ett ”rikt” skal installerat men vill tvinga fram användning av den ”vanliga” Python-tolken använder du `python` som gränssnittsnamn, så här:

    django-admin shell -i python

--no-startup

Inaktiverar läsning av startskriptet för den ”vanliga” Python-tolken. Som standard läses det skript som pekas ut av miljövariabeln `PYTHONSTARTUP` eller skriptet `~/.pythonrc.py`.

--no-imports

New in Django 5.2.

Avaktiverar automatisk import av modeller från `INSTALLED_APPS`.

--command COMMAND, -c COMMAND

Låter dig skicka ett kommando som en sträng för att exekvera det som Django, så här:

    django-admin shell --command="import django; print(django.__version__)"

Du kan också skicka in kod på standardinmatningen för att köra den. Till exempel:

    $ django-admin shell <<EOF
    > import django
    > print(django.__version__)
    > EOF

På Windows matas REPL ut på grund av begränsningar i implementeringen av `select.select()` på den plattformen.

### `visa migreringar`

django-admin showmigrations [app_label [app_label ...]]

Visar alla migreringar i ett projekt. Du kan välja ett av två format:

--list, -l

Visar alla appar som Django känner till, de migreringar som är tillgängliga för varje app och om varje migrering tillämpas eller inte (markerat med ett `[X]` bredvid migreringsnamnet). För en ``--verbosity` på 2 och högre visas även de tillämpade datatiderna.

Appar utan migreringar listas också, men har `(inga migreringar)` skrivet under sig.

Detta är standardutmatningsformatet.

--plan, -p

Visar den migreringsplan som Django kommer att följa för att tillämpa migreringar. Liksom `--list` markeras tillämpade migreringar med en `[X]`. För en `--verbosity` på 2 och högre kommer alla beroenden av en migrering också att visas.

`app_label` argumenten begränsar utdata, men beroenden av tillhandahållna appar kan också inkluderas.

--database DATABASE

Anger vilken databas som ska undersökas. Standardvärdet är `default`.

### `sqlflush`

django-admin sqlflush

Skriver ut de SQL-satser som skulle utföras för kommandot `flush`.

--database DATABASE

Anger den databas för vilken SQL ska skrivas ut. Standardvärdet är `default`.

### `sqlmigrate`

django-admin sqlmigrate app_label migration_name

Skriver ut SQL för den namngivna migreringen. Detta kräver en aktiv databasanslutning, som används för att lösa begränsningsnamn. Detta innebär att du måste generera SQL mot en kopia av den databas som du senare vill använda den på.

Observera att `sqlmigrate` inte färglägger sin utdata.

--backwards

Genererar SQL för att ta bort tillämpningen av migreringen. Som standard skapas SQL för att köra migreringen i framåtriktad riktning.

--database DATABASE

Anger den databas för vilken SQL ska genereras. Standardvärdet är `default`.

### `sqlsequencereset`

django-admin sqlsequencereset app_label [app_label ...]

Skriver ut SQL-satserna för återställning av sekvenser för det eller de angivna appnamnen.

Sekvenser är index som används av vissa databasmotorer för att spåra nästa tillgängliga nummer för automatiskt inkrementerade fält.

Använd detta kommando för att generera SQL som åtgärdar fall där en sekvens inte är synkroniserad med sina automatiskt inkrementerade fältdata.

--database DATABASE

Anger den databas för vilken SQL ska skrivas ut. Standardvärdet är `default`.

### `kvashmigreringar`

django-admin squashmigrations app_label [start_migration_name] migration_name

Pressar om möjligt ner migreringarna för `app_label` till och med `migration_name` till färre migreringar. De resulterande krossade migreringarna kan leva tillsammans med de okrossade på ett säkert sätt. För mer information, läs Minska antalet migreringar.

När `start_migration_name` anges kommer Django endast att inkludera migreringar som börjar från och med denna migrering. Detta hjälper till att mildra squashing-begränsningen av `RunPython` och `django.db.migrations.operations.RunSQL` migreringsoperationer.

--no-optimize

Inaktiverar optimeraren när du genererar en krossad migrering. Som standard kommer Django att försöka optimera operationerna i dina migreringar för att minska storleken på den resulterande filen. Använd det här alternativet om den här processen misslyckas eller skapar felaktiga migreringar, men skicka också in en Django-buggrapport om beteendet, eftersom optimering är tänkt att vara säker.

--noinput, --no-input

Undertrycker alla användarinstruktioner.

--squashed-name SQUASHED_NAME

Ställer in namnet på den krossade migreringen. Om det utelämnas baseras namnet på den första och den sista migreringen, med `_squashed_` däremellan.

--no-header

Generera en komprimerad migreringsfil utan Django-version och tidsstämpelhuvud.

### `startapp`

django-admin startapp name [directory]

Skapar en Django-appkatalogstruktur för det angivna appnamnet i den aktuella katalogen eller den angivna destinationen.

Som standard innehåller den nya katalogen en fil `models.py` och andra appmallfiler. Om endast appnamnet anges kommer appkatalogen att skapas i den aktuella arbetskatalogen.

If the optional destination is provided, Django will use that name instead. If the directory with the given name doesn’t exist, it will be created. You can use ’.’ to denote the current working directory.

Changed in Django 6.0:

Automatic creation of the destination directory was added.

Till exempel:

    django-admin startapp myapp /Users/jezdez/Code/myapp

--template TEMPLATE

Anger sökvägen till en katalog med en anpassad appmallfil, eller en sökväg till ett okomprimerat arkiv (`.tar`) eller ett komprimerat arkiv (`.tar.gz`, `.tar.bz2`, `.tar.xz`, `.tar.lzma`, `.tgz`, `.tbz2`, `.txz`, `.tlz`, `.zip`) som innehåller appmallfilerna.

Exempelvis skulle detta söka efter en appmall i den angivna katalogen när appen `myapp` skapas:

    django-admin startapp --template=/Users/jezdez/Code/my_app_template myapp

Django accepterar också webbadresser (`http`, `https`, `ftp`) till komprimerade arkiv med appmallfilerna och laddar ner och extraherar dem i farten.

Om du till exempel utnyttjar GitHubs funktion för att exponera repositories som zip-filer kan du använda en URL som:

    django-admin startapp --template=https://github.com/githubuser/django-app-template/archive/main.zip myapp

Varning

Mallar som tillhandahålls via `--template` används som de är. Skadliga eller dåligt konstruerade mallar kan medföra säkerhetsrisker eller oönskat beteende. Komprimerade arkiv kan också förbruka överdrivna resurser under extraheringen, vilket kan orsaka krascher eller hängningar.

Innehållet i mallarna bör kontrolleras noggrant före användning.

--extension EXTENSIONS, -e EXTENSIONS

Anger vilka filnamnstillägg i appmallen som ska återges med mallmotorn. Standardvärdet är `py`.

--name FILES, -n FILES

Anger vilka filer i appmallen (utöver de som matchar `--extension`) som ska återges med mallmotorn. Standardvärdet är en tom lista.

--exclude DIRECTORIES, -x DIRECTORIES

Anger vilka kataloger i appmallen som ska uteslutas, utöver `.git` och `__pycache__`. Om detta alternativ inte anges kommer kataloger som heter `__pycache__` eller börjar med `.` att uteslutas.

Den `template context` som används för alla matchande filer är:

- Alla alternativ som skickas till kommandot `startapp` (bland de alternativ som stöds av kommandot)

- `app_name` – appens namn som skickas till kommandot

- `app_directory` – den fullständiga sökvägen till den nyskapade appen

- `camel_case_app_name` – appens namn i camel case-format

- `docs_version` – version av dokumentationen: `'dev'` eller `'1.x'`

- `django_version` – versionen av Django, t.ex. `'2.0.3'`

Varning

När appens mallfiler renderas med Djangos mallmotor (som standard alla `*.py`-filer), kommer Django också att ersätta alla mallvariabler som finns. Om till exempel en av Python-filerna innehåller en docstring som förklarar en viss funktion relaterad till mallrendering, kan det resultera i ett felaktigt exempel.

För att komma runt detta problem kan du använda `templatetag` malltaggen för att ”undkomma” de olika delarna av mallsyntaxen.

För att tillåta Python-mallfiler som innehåller syntax för Djangos mallspråk och samtidigt förhindra att paketeringssystem försöker bytekompilera ogiltiga `*.py`-filer, kommer mallfiler som slutar med `.py-tpl` att döpas om till `.py`.

Varning

Innehållet i anpassade app- (eller projekt-) mallar bör alltid granskas före användning: Sådana mallar definierar kod som kommer att bli en del av ditt projekt, och det innebär att sådan kod kommer att vara lika betrodd som alla appar som du installerar eller kod som du skriver själv. Dessutom innebär även rendering av mallarna i praktiken att man exekverar kod som tillhandahölls som indata till hanteringskommandot. Djangos mallspråk kan ge bred tillgång till systemet, så se till att alla anpassade mallar du använder är värda ditt förtroende.

### `starta projekt`

django-admin startproject name [directory]

Skapar en Django-projektkatalogstruktur för det angivna projektnamnet i den aktuella katalogen eller den angivna destinationen.

Som standard innehåller den nya katalogen <django/conf/project_template>` `manage.py` och ett projektpaket (som innehåller en `settings.py` och andra filer).

Om endast projektnamnet anges kommer både projektkatalogen och projektpaketet att få namnet `<projectname>` och projektkatalogen kommer att skapas i den aktuella arbetskatalogen.

If the optional destination is provided, Django will use that name as the project directory, and create `manage.py` and the project package within it. If the directory with the given name doesn’t exist, it will be created. Use ’.’ to denote the current working directory.

Changed in Django 6.0:

Automatic creation of the destination directory was added.

Till exempel:

    django-admin startproject myproject /Users/jezdez/Code/myproject_repo

--template TEMPLATE

Anger en katalog, filväg eller URL för en anpassad projektmall. Se dokumentationen för `startapp --template` för exempel och användning. Samma säkerhetsöverväganden som beskrivs för `startapp`-mallar gäller även här: skadliga eller dåligt konstruerade mallar kan medföra svagheter eller förbruka överdrivna resurser, och mallar bör granskas noggrant före användning.

--extension EXTENSIONS, -e EXTENSIONS

Anger vilka filnamnstillägg i projektmallen som ska återges med mallmotorn. Standardvärdet är `py`.

--name FILES, -n FILES

Anger vilka filer i projektmallen (utöver de som matchar `--extension`) som ska återges med mallmotorn. Standardvärdet är en tom lista.

--exclude DIRECTORIES, -x DIRECTORIES

Anger vilka kataloger i projektmallen som ska uteslutas, utöver `.git` och `__pycache__`. Om det här alternativet inte anges kommer kataloger som heter `__pycache__` eller börjar med `.` att uteslutas.

Den `template context` som används är:

- Alla alternativ som skickas till kommandot `startproject` (bland de alternativ som stöds av kommandot)

- `project_name` – projektnamnet som skickas till kommandot

- `project_directory` – den fullständiga sökvägen till det nyskapade projektet

- `secret_key` – en slumpmässig nyckel för inställningen :setting:`SECRET_KEY

- `docs_version` – version av dokumentationen: `'dev'` eller `'1.x'`

- `django_version` – versionen av Django, t.ex. `'2.0.3'`

Se även rendering warning och trusted code warning som nämns för `startapp`.

### `test`

django-admin test [test_label [test_label ...]]

Kör tester för alla installerade appar. Se Testning i Django för mer information.

--failfast

Stoppar testkörningen och rapporterar felet omedelbart efter att ett test misslyckats.

--testrunner TESTRUNNER

Styr den testkörningsklass som används för att köra tester. Detta värde åsidosätter det värde som anges av inställningen `TEST_RUNNER`.

--noinput, --no-input

Undertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.

#### Alternativ för testkörning

Kommandot `test` tar emot alternativ på uppdrag av det angivna `--testrunner`. Detta är alternativen för standardtestlöparen: `DiscoverRunner`.

--keepdb

Bevarar testdatabasen mellan testkörningar. Fördelen med detta är att man hoppar över både skapande och förstörande åtgärder, vilket kan minska tiden för testkörning avsevärt, särskilt i en stor testsvit. Om testdatabasen inte finns kommer den att skapas vid den första körningen och sedan bevaras för varje efterföljande körning. Om inte testinställningen `MIGRATE` är `False`, kommer alla oanvända migreringar också att tillämpas på testdatabasen innan testsviten körs.

--shuffle [SEED]

Slumpar ordningen på testerna innan de körs. Detta kan hjälpa till att upptäcka tester som inte är ordentligt isolerade. Den testordning som genereras av detta alternativ är en deterministisk funktion av det heltal som anges. Om inget seed anges väljs ett seed slumpmässigt och skrivs ut på konsolen. För att upprepa en viss testordning, skicka ett frö. Testordningarna som genereras av detta alternativ bevarar Djangos garantier för testordning. De håller också tester grupperade efter testfallsklass.

De blandade ordningarna har också en speciell konsistensegenskap som är användbar när man begränsar isoleringsfrågor. För ett givet frö och när en delmängd av testerna körs kommer den nya ordningen att vara den ursprungliga blandningen begränsad till den mindre uppsättningen. På samma sätt kommer ordningen på de ursprungliga testerna att vara densamma i den nya ordningen när du lägger till tester samtidigt som fröet förblir detsamma.

--reverse, -r

Sorterar testfall i motsatt exekveringsordning. Detta kan hjälpa till vid felsökning av bieffekter av tester som inte är ordentligt isolerade. Gruppering efter testklass bevaras när detta alternativ används. Detta kan användas tillsammans med `--shuffle` för att vända ordningen för ett visst frö.

--debug-mode

Sätter inställningen `DEBUG` till `True` innan tester körs. Detta kan hjälpa till att felsöka testfel.

--debug-sql, -d

Aktiverar SQL logging för misslyckade tester. Om `--verbosity` är `2`, kommer frågor i godkända tester också att matas ut.

--parallel [N]

DJANGO_TEST_PROCESSES

Kör tester i separata parallella processer. Eftersom moderna processorer har flera kärnor gör detta att testerna kan köras betydligt snabbare.

Using `--parallel` without a value, or with the value `auto`, runs one test process per core according to `multiprocessing.cpu_count()`. You can override this by passing the desired number of processes, e.g. `--parallel 4`, or by setting the `DJANGO_TEST_PROCESSES` environment variable.

Django distribuerar testfall - `unittest.TestCase` subclasses - till subprocesser. Om det finns färre testfallsklasser än konfigurerade processer, kommer Django att minska antalet processer i enlighet med detta.

Varje process får sin egen databas. Du måste se till att olika testfallsklasser inte får tillgång till samma resurser. Exempelvis bör testfallsklasser som använder filsystemet skapa en temporär katalog för eget bruk.

Observera

Om du har testklasser som inte kan köras parallellt kan du använda `SerializeMixin` för att köra dem sekventiellt. Se Tvinga fram sekventiell körning av testklasser.

Detta alternativ kräver tredjeparts `tblib`-paketet för att visa spårningar korrekt:

    $ python -m pip install tblib

Den här funktionen är inte tillgänglig i Windows. Den fungerar inte heller med Oracle-databasens backend.

Om du vill använda `pdb` när du felsöker tester måste du inaktivera parallellkörning (`--parallel=1`). Du kommer att se något i stil med `bdb.BdbQuit` om du inte gör det.

Varning

När testparallellisering är aktiverad och ett test misslyckas kan Django kanske inte visa spårningen av undantaget. Detta kan göra felsökningen svår. Om du stöter på detta problem, kör det berörda testet utan parallellisering för att se spårningen av felet.

Detta är en känd begränsning. Den uppstår på grund av behovet av att serialisera objekt för att kunna utbyta dem mellan processer. Se What can be pickled and unpickled? för detaljer.

--tag TAGS

Kör endast tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med `test --exclude-tag`.

Tester som inte laddas betraktas alltid som matchande.

--exclude-tag EXCLUDE_TAGS

Utesluter tester märkta med de angivna taggarna. Kan anges flera gånger och kombineras med `test --tag`.

-k TEST_NAME_PATTERNS

Kör testmetoder och klasser som matchar testnamnsmönster, på samma sätt som `unittests -k-alternativ`. Kan anges flera gånger.

--pdb

Startar en `pdb`-felsökare vid varje fel eller misslyckande i testet. Om du har det installerat används `ipdb` istället.

--buffer, -b

Slänger utdata (`stdout` och `stderr`) för godkända tester, på samma sätt som `unittests alternativ --buffer`.

--no-faulthandler

Django automatically calls `faulthandler.enable()` when starting the tests, which allows it to print a traceback if the interpreter crashes. Pass `--no-faulthandler` to disable this behavior.

--timing

Utmatning av tidsangivelser, inklusive databasinstallation och total körtid.

--durations N

Visar de N långsammaste testfallen (N=0 för alla).

### `testserver`

django-admin testserver [fixture [fixture ...]]

Kör en Django-utvecklingsserver (som i `runserver`) med data från den eller de angivna fixturerna.

Till exempel: detta kommando:

    django-admin testserver mydata.json

…skulle utföra följande steg:

1. Skapa en testdatabas, enligt beskrivningen i testdatabasen.

2. Fyller på testdatabasen med fixturdata från de angivna fixturerna. (För mer information om fixturer, se dokumentationen för `loaddata` ovan)

3. Kör Django-utvecklingsservern (som i `runserver`), riktad mot denna nyskapade testdatabas i stället för din produktionsdatabas.

Detta är användbart på flera olika sätt:

- När du skriver enhetstester av hur dina vyer fungerar med vissa fixturdata, kan du använda `testserver` för att interagera med vyerna i en webbläsare, manuellt.

- Let’s say you’re developing your Django application and have a ”pristine” copy of a database that you’d like to interact with. You can dump your database to a fixture (using the `dumpdata` command, explained above), then use `testserver` to run your web application with that data. With this arrangement, you have the flexibility of messing up your data in any way, knowing that whatever data changes you’re making are only being made to a test database.

Observera att den här servern inte automatiskt upptäcker ändringar i din Python-källkod (som `runserver` gör). Den upptäcker dock ändringar i mallar.

--addrport ADDRPORT

Anger en annan port, eller IP-adress och port, än standardvärdet `127.0.0.1:8000`. Detta värde följer exakt samma format och har exakt samma funktion som argumentet till kommandot `runserver`.

Exempel:

För att köra testservern på port 7000 med `fixture1` och `fixture2`:

    django-admin testserver --addrport 7000 fixture1 fixture2
    django-admin testserver fixture1 fixture2 --addrport 7000

(Ovanstående uttalanden är likvärdiga. Vi tar med båda för att visa att det inte spelar någon roll om alternativen kommer före eller efter fixturargumenten)

För att köra på 1.2.3.4:7000 med en `test` fixtur:

    django-admin testserver --addrport 1.2.3.4:7000 test

--noinput, --no-input

Undertrycker alla uppmaningar till användaren. En typisk uppmaning är en varning om att ta bort en befintlig testdatabas.

## Kommandon som tillhandahålls av applikationer

Vissa kommandon är endast tillgängliga när applikationen `django.contrib` som implementerar dem har `aktiverats`. Detta avsnitt beskriver dem grupperade efter deras applikation.

### `django.contrib.auth`

#### `byt lösenord`

django-admin changepassword [<username>]

Detta kommando är endast tillgängligt om Djangos autentiseringssystem (`django.contrib.auth`) är installerat.

Gör det möjligt att ändra en användares lösenord. Du uppmanas att ange ett nytt lösenord två gånger för den aktuella användaren. Om inmatningarna är identiska blir detta omedelbart det nya lösenordet. Om du inte anger någon användare kommer kommandot att försöka ändra lösenordet för den användare vars användarnamn matchar den aktuella användaren.

--database DATABASE

Anger vilken databas som ska användas för att söka efter användaren. Standardvärdet är `default`.

Exempel på användning:

    django-admin changepassword ringo

#### `skapa superanvändare`

django-admin createsuperuser

DJANGO_SUPERUSER_PASSWORD

Detta kommando är endast tillgängligt om Djangos autentiseringssystem (`django.contrib.auth`) är installerat.

Skapar ett superanvändarkonto (en användare som har alla behörigheter). Detta är användbart om du behöver skapa ett första superanvändarkonto eller om du behöver generera superanvändarkonton för dina webbplatser på ett programmatiskt sätt.

När kommandot körs interaktivt kommer det att fråga efter ett lösenord för det nya superanvändarkontot. När kommandot körs icke-interaktivt kan du ange ett lösenord genom att ange miljövariabeln `DJANGO_SUPERUSER_PASSWORD`. Annars anges inget lösenord och superanvändarkontot kan inte logga in förrän ett lösenord har angetts manuellt för det.

I icke-interaktivt läge faller `USERNAME_FIELD` och obligatoriska fält (listade i `REQUIRED_FIELDS`) tillbaka till miljövariablerna `DJANGO_SUPERUSER_<uppercase_field_name>`, såvida de inte åsidosätts av ett kommandoradsargument. Om du t.ex. vill tillhandahålla ett fält för e-post kan du använda miljövariabeln `DJANGO_SUPERUSER_EMAIL`.

--noinput, --no-input

Undertrycker alla användarinstruktioner. Om en undertryckt fråga inte kan lösas automatiskt avslutas kommandot med felkod 1.

--username USERNAME

--email EMAIL

Användarnamnet och e-postadressen för det nya kontot kan anges med argumenten `--username` och `--email` på kommandoraden. Om något av dessa inte anges kommer `createsuperuser` att fråga efter det när det körs interaktivt.

--database DATABASE

Anger den databas i vilken superuser-objektet ska sparas.

Du kan underklassa management-kommandot och åsidosätta `get_input_data()` om du vill anpassa datainmatning och validering. I källkoden finns mer information om den befintliga implementeringen och metodens parametrar. Det kan till exempel vara användbart om du har en `ForeignKey` i `REQUIRED_FIELDS` och vill tillåta att en instans skapas istället för att ange primärnyckeln för en befintlig instans.

### `django.contrib.contenttypes`

#### `ta bort_stale_innehållstyper`

django-admin remove_stale_contenttypes

Detta kommando är endast tillgängligt om Djangos contenttypes app (`django.contrib.contenttypes`) är installerat.

Raderar inaktuella innehållstyper (från borttagna modeller) i din databas. Alla objekt som är beroende av de borttagna innehållstyperna kommer också att raderas. En lista över borttagna objekt visas innan du bekräftar att det är okej att fortsätta med borttagningen.

--database DATABASE

Anger vilken databas som ska användas. Standardvärdet är `default`.

--include-stale-apps

Raderar inaktuella innehållstyper, inklusive innehåll från tidigare installerade appar som har tagits bort från `INSTALLED_APPS`. Standardvärde är `False`.

### `django.contrib.gis`

#### `ogrinspect`

Detta kommando är endast tillgängligt om GeoDjango (`django.contrib.gis`) är installerat.

Se dess `description` i GeoDjango-dokumentationen.

### `django.contrib.sessions`

#### `clearsessions`

django-admin clearsessions

Kan köras som ett cron-jobb eller direkt för att rensa bort utgångna sessioner.

### `django.contrib.staticfiles`

#### `samla statiskt`

Detta kommando är endast tillgängligt om applikationen för statiska filer (`django.contrib.staticfiles`) är installerad.

Se dess `description` i staticfiles dokumentation.

#### `findstatic`

Detta kommando är endast tillgängligt om applikationen för statiska filer (`django.contrib.staticfiles`) är installerad.

Se dess `description` i staticfiles dokumentation.

## Standardalternativ

Även om vissa kommandon kan tillåta egna anpassade alternativ, tillåter alla kommandon följande alternativ som standard:

--pythonpath PYTHONPATH

Adds the given filesystem path to the Python `sys.path` module attribute. If this isn’t provided, `django-admin` will use the `PYTHONPATH` environment variable.

Detta alternativ är onödigt i `manage.py`, eftersom det tar hand om att ställa in Python-sökvägen åt dig.

Exempel på användning:

    django-admin migrate --pythonpath='/home/djangoprojects/myproject'

--settings SETTINGS

Anger vilken inställningsmodul som ska användas. Inställningsmodulen bör vara i Python-paketsyntax, t.ex. `mysite.settings`. Om detta inte anges kommer `django-admin` att använda miljövariabeln `DJANGO_SETTINGS_MODULE`.

Detta alternativ är onödigt i `manage.py`, eftersom det använder `settings.py` från det aktuella projektet som standard.

Exempel på användning:

    django-admin migrate --settings=mysite.settings

--traceback

Visar en fullständig stackspårning när ett `CommandError` uppstår. Som standard kommer `django-admin` att visa ett felmeddelande när ett `CommandError` inträffar och en fullständig stack trace för alla andra undantag.

Detta alternativ ignoreras av `runserver`.

Exempel på användning:

    django-admin migrate --traceback

--verbosity {0,1,2,3}, -v {0,1,2,3}

Anger hur mycket meddelande- och felsökningsinformation som ett kommando ska skriva ut till konsolen.

- `0` betyder ingen utmatning.

- `1` betyder normal utmatning (standard).

- `2` betyder utförlig utdata.

- `3` betyder mycket utförlig utdata.

Detta alternativ ignoreras av `runserver`.

Exempel på användning:

    django-admin migrate --verbosity 2

--no-color

Disables colorized command output. Some commands format their output to be colorized. For example, errors will be printed to the console in red and SQL statements will be syntax highlighted.

Exempel på användning:

    django-admin runserver --no-color

--force-color

Tvingar fram färgläggning av kommandoutmatningen om den annars skulle vara inaktiverad, vilket diskuteras i Syntax färgläggning. Du kanske t.ex. vill skicka färgade utdata till ett annat kommando.

--skip-checks

Hoppar över att köra systemkontroller innan kommandot körs. Detta alternativ är endast tillgängligt om `requires_system_checks` inte är en tom lista eller tupel.

Exempel på användning:

    django-admin migrate --skip-checks

## Extra finesser

### Syntax färgläggning

DJANGO_COLORS

Kommandona `django-admin` / `manage.py` kommer att använda vackra färgkodade utdata om din terminal stöder ANSI-färgade utdata. Det kommer inte att använda färgkoderna om du skickar kommandots utdata till ett annat program om inte alternativet `--force-color` används.

#### Stöd för Windows

I Windows 10 tillåter programmet Windows Terminal, VS Code och PowerShell (där bearbetning i virtuell terminal är aktiverad) färgad utdata och stöds som standard.

Under Windows stöder inte den gamla inbyggda konsolen `cmd.exe` ANSI escape-sekvenser, så som standard finns det ingen färgutmatning. I detta fall behövs något av de två tredjepartsbiblioteken:

- Installera colorama, ett Python-paket som översätter ANSI-färgkoder till Windows API-anrop. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar. `colorama` kan installeras via pip:

      ...\> py -m pip install "colorama >= 0.4.6"

- Installera ANSICON, ett tredjepartsverktyg som gör det möjligt för `cmd.exe` att bearbeta ANSI-färgkoder. Django-kommandon kommer att upptäcka dess närvaro och använda dess tjänster för att färglägga utdata precis som på Unix-baserade plattformar.

Andra moderna terminalmiljöer på Windows, som stöder terminalfärger, men som inte automatiskt upptäcks som stödda av Django, kan ”fejka” installationen av `ANSICON` genom att ställa in lämplig miljövariabel, `ANSICON="on"`.

#### Anpassade färger

De färger som används för syntaxmarkering kan anpassas. Django levereras med tre färgpaletter:

- `dark`, lämplig för terminaler som visar vit text på svart bakgrund. Detta är standardpaletten.

- `light`, lämpar sig för terminaler som visar svart text på vit bakgrund.

- `nocolor`, som inaktiverar syntaxmarkering.

Du väljer en palett genom att ange en `DJANGO_COLORS`-miljövariabel som anger vilken palett du vill använda. Om du till exempel vill ange paletten `light` i ett Unix- eller OS/X BASH-skal, kör du följande vid kommandotolken:

    export DJANGO_COLORS="light"

Du kan också anpassa de färger som används. Django specificerar ett antal roller där färg används:

- `error` - Ett allvarligt fel.

- `notice` - Ett mindre fel.

- `uccess` - En framgång.

- `warning` - En varning.

- `sql_field` - Namnet på ett modellfält i SQL.

- `sql_coltype` - Typen av ett modellfält i SQL.

- `sql_keyword` - Ett SQL-nyckelord.

- `sql_table` - Namnet på en modell i SQL.

- `http_info` - Ett 1XX HTTP-informationssvar från servern.

- `http_success` - Ett 2XX HTTP Success-serversvar.

- `http_not_modified` - Ett 304 HTTP Not Modified-serversvar.

- `http_redirect` - Ett 3XX HTTP Redirect-serversvar annat än 304.

- `http_not_found` - Ett 404 HTTP Not Found-serversvar.

- `http_bad_request` - Ett 4XX HTTP Bad Request-serversvar annat än 404.

- `http_server_error` - Ett 5XX HTTP Server Error-svar.

- `migrate_heading` - En rubrik i ett kommando för migrationshantering.

- `migrate_label` - Ett namn på migreringen.

Var och en av dessa roller kan tilldelas en specifik förgrunds- och bakgrundsfärg från följande lista:

- `svart`

- ”röd

- `grön`

- `gult`

- `blått`

- `magenta`

- `cyan`

- `vit`

Var och en av dessa färger kan sedan ändras med hjälp av följande visningsalternativ:

- `fett`

- `underscore`

- `blink`

- `omvänd`

- ”dölja

En färgspecifikation följer något av följande mönster:

- `role=fg`

- `role=fg/bg`

- `roll=fg,option,option`

- `roll=fg/bg,option,option`

där `role` är namnet på en giltig färgroll, `fg` är förgrundsfärgen, `bg` är bakgrundsfärgen och varje `option` är ett av färgmodifieringsalternativen. Flera färgspecifikationer separeras sedan med ett semikolon. Till exempel:

    export DJANGO_COLORS="error=yellow/blue,blink;notice=magenta"

skulle ange att fel visas med blinkande gult på blått och meddelanden visas med magenta. Alla andra färgroller skulle lämnas ofärgade.

Färger kan också specificeras genom att utöka en baspalett. Om du anger ett palettnamn i en färgspecifikation laddas alla färger som impliceras av den paletten. Så här gör du:

    export DJANGO_COLORS="light;error=yellow/blue,blink;notice=magenta"

skulle ange användningen av alla färger i den ljusa färgpaletten, utom färgerna för fel och meddelanden som skulle åsidosättas enligt specifikationen.

### Bash-avslutning

Om du använder Bash-skalet, överväg att installera Django bash-kompletteringsscriptet, som finns i extras/django_bash_completion i Django-källdistributionen. Det möjliggör tabkomplettering av kommandon i `django-admin` och `manage.py`, så att du till exempel kan …

- Typ `django-admin`.

- Tryck på [TAB] för att se alla tillgängliga alternativ.

- Skriv `sql` och sedan [TAB] för att se alla tillgängliga alternativ vars namn börjar med `sql`.

Se Hur man skapar egna kommandon för django-admin för information om hur du lägger till anpassade åtgärder.

### Svart formatering

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

Om du har `black` globalt installerat, men inte vill att det ska användas för det aktuella projektet, kan du ange `PATH` explicit:

    PATH=path/to/venv/bin django-admin makemigrations

För kommandon som använder `stdout` kan du vid behov skicka utdata till `black`:

    django-admin inspectdb | black -

# Kör kommandon för hantering från din kod

django.core.management.call_command(name, *args, **options)

Om du vill anropa ett managementkommando från kod använder du `call_command()`.

`namn`

  namnet på kommandot som ska anropas eller ett kommando-objekt. Att skicka namnet är att föredra om inte objektet krävs för testning.

`*args`

  en lista med argument som accepteras av kommandot. Argumenten skickas till argumentparsern, så att du kan använda samma stil som på kommandoraden. Till exempel:, `call_command('flush', '--verbosity=0')`.

`**alternativ`

  namngivna alternativ som accepteras på kommandoraden. Alternativen skickas till kommandot utan att argumentparsern aktiveras, vilket innebär att du måste skicka rätt typ. Till exempel:, `call_command('flush', verbosity=0)` (noll måste vara ett heltal snarare än en sträng).

Exempel:

    from django.core import management
    from django.core.management.commands import loaddata

    management.call_command("flush", verbosity=0, interactive=False)
    management.call_command("loaddata", "test_data", verbosity=0)
    management.call_command(loaddata.Command(), "test_data", verbosity=0)

Observera att kommandoval som inte tar några argument skickas som nyckelord med `True` eller `False`, som du kan se med alternativet `interactive` ovan.

Namngivna argument kan skickas genom att använda någon av följande syntaxer:

    # Similar to the command line
    management.call_command("dumpdata", "--natural-foreign")

    # Named argument similar to the command line minus the initial dashes and
    # with internal dashes replaced by underscores
    management.call_command("dumpdata", natural_foreign=True)

    # `use_natural_foreign_keys` is the option destination variable
    management.call_command("dumpdata", use_natural_foreign_keys=True)

Vissa kommandoalternativ har olika namn när du använder `call_command()` istället för `django-admin` eller `manage.py`. Till exempel: översätts `django-admin createsuperuser --no-input` till `call_command('createsuperuser', interactive=False)`. För att hitta vilket nyckelordsargumentnamn som ska användas för `call_command()`, kontrollera kommandots källkod för `dest`-argumentet som skickas till `parser.add_argument()`.

Kommandoval som innehåller flera alternativ skickas till en lista:

    management.call_command("dumpdata", exclude=["contenttypes", "auth"])

Returvärdet för funktionen `call_command()` är detsamma som returvärdet för kommandots metod `handle()`.

## Omdirigering av utdata

Observera att du kan omdirigera standardutdata- och felströmmar eftersom alla kommandon stöder alternativen `stdout` och `stderr`. Du kan till exempel skriva:

    with open("/path/to/command_output", "w") as f:
        management.call_command("dumpdata", stdout=f)