# Django 5.2.8 documentation

# Django-inställningar

En Django-inställningsfil innehåller all konfiguration av din Django-installation. I detta dokument förklaras hur inställningar fungerar och vilka inställningar som finns tillgängliga.

## Grunderna

En inställningsfil är bara en Python-modul med variabler på modulnivå.

Här är några exempel på inställningar:

    ALLOWED_HOSTS = ["www.example.com"]
    DEBUG = False
    DEFAULT_FROM_EMAIL = "webmaster@example.com"

Observera

Om du ställer in `DEBUG` på `False` måste du också ställa in `ALLOWED_HOSTS` på rätt sätt.

Eftersom en inställningsfil är en Python-modul gäller följande:

- Det tillåter inte syntaxfel i Python.

- Den kan tilldela inställningar dynamiskt med hjälp av normal Python-syntax. Till exempel:

      MY_SETTING = [str(i) for i in range(30)]

- Den kan importera värden från andra inställningsfiler.

## Beteckna inställningarna

DJANGO_SETTINGS_MODULE

När du använder Django måste du tala om vilka inställningar du använder. Detta gör du genom att använda miljövariabeln `DJANGO_SETTINGS_MODULE`.

The value of `DJANGO_SETTINGS_MODULE` should be in Python path syntax, e.g. `mysite.settings`. Note that the settings module should be on the Python `sys.path`.

### Verktyget `django-admin`

När du använder django-admin kan du antingen ställa in miljövariabeln en gång, eller uttryckligen skicka in inställningsmodulen varje gång du kör verktyget.

Exempel (Unix Bash-skal):

    export DJANGO_SETTINGS_MODULE=mysite.settings
    django-admin runserver

Exempel (Windows-skal):

    set DJANGO_SETTINGS_MODULE=mysite.settings
    django-admin runserver

Använd kommandoradsargumentet `--settings` för att ange inställningarna manuellt:

    django-admin runserver --settings=mysite.settings

### På servern (`mod_wsgi`)

I din live-servermiljö måste du tala om för din WSGI-applikation vilken inställningsfil som ska användas. Gör det med `os.environ`:

    import os

    os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"

Läs Django mod_wsgi documentation för mer information och andra vanliga element i en Django WSGI-applikation.

## Standardinställningar

En Django-inställningsfil behöver inte definiera några inställningar om den inte behöver det. Varje inställning har ett förnuftigt standardvärde. Dessa standardvärden finns i modulen django/conf/global_settings.py.

Här är den algoritm som Django använder för att sammanställa inställningar:

- Ladda inställningar från `global_settings.py`.

- Ladda inställningar från den angivna inställningsfilen och åsidosätt de globala inställningarna vid behov.

Observera att en inställningsfil inte bör importera från `global_settings`, eftersom det är överflödigt.

### Se vilka inställningar du har ändrat

Kommandot `python manage.py diffsettings` visar skillnader mellan den aktuella inställningsfilen och Djangos standardinställningar.

Mer information finns i `diffsettings`-dokumentationen.

## Använda inställningar i Python-kod

I dina Django-appar kan du använda inställningar genom att importera objektet `django.conf.settings`. Exempel:

    from django.conf import settings

    if settings.DEBUG:
        # Do something
        ...

Observera att `django.conf.settings` inte är en modul - det är ett objekt. Så det är inte möjligt att importera enskilda inställningar:

    from django.conf.settings import DEBUG  # This won't work.

Observera också att din kod inte ska importera från varken `global_settings` eller din egen inställningsfil. `django.conf.settings` abstraherar begreppen standardinställningar och platsspecifika inställningar; det presenterar ett enda gränssnitt. Det frikopplar också koden som använder inställningar från platsen för dina inställningar.

## Ändra inställningar under körning

Du bör inte ändra inställningarna i dina program under körning. Gör till exempel inte så här i en vy:

    from django.conf import settings

    settings.DEBUG = True  # Don't do this!

Den enda plats där du bör tilldela inställningar är i en inställningsfil.

## Säkerhet

Eftersom en inställningsfil innehåller känslig information, t.ex. databasens lösenord, bör du göra allt du kan för att begränsa åtkomsten till den. Ändra t.ex. filbehörigheterna så att endast du och webbserverns användare kan läsa den. Detta är särskilt viktigt i en miljö med delat värdskap.

## Tillgängliga inställningar

För en fullständig lista över tillgängliga inställningar, se inställningsreferens.

## Skapa dina egna inställningar

Det finns inget som hindrar dig från att skapa dina egna inställningar för dina egna Django-appar, men följ dessa riktlinjer:

- Alla namn på inställningarna måste vara versaler.

- Uppfinn inte en redan existerande miljö på nytt.

För inställningar som är sekvenser använder Django själv listor, men detta är bara en konvention.

## Använda inställningar utan att ställa in `DJANGO_SETTINGS_MODULE`

I vissa fall kanske du vill kringgå miljövariabeln `DJANGO_SETTINGS_MODULE`. Om du till exempel använder mallsystemet i sig självt, vill du förmodligen inte behöva ställa in en miljövariabel som pekar på en inställningsmodul.

I dessa fall kan du konfigurera Djangos inställningar manuellt. Detta gör du genom att anropa:

django.conf.settings.configure(default_settings, **settings)

Exempel:

    from django.conf import settings

    settings.configure(DEBUG=True)

Skicka `configure()` så många nyckelordsargument som du vill, där varje nyckelordsargument representerar en inställning och dess värde. Varje argumentnamn ska vara versalt och ha samma namn som de inställningar som beskrivs ovan. Om en viss inställning inte skickas till `configure()` och behövs vid ett senare tillfälle, kommer Django att använda standardinställningsvärdet.

Att konfigurera Django på det här sättet är oftast nödvändigt - och rekommenderas faktiskt - när du använder en del av ramverket i en större applikation.

Följaktligen kommer Django inte att göra några ändringar i processmiljövariablerna när de konfigureras via `settings.configure()` (se dokumentationen av `TIME_ZONE` för varför detta normalt skulle inträffa). Det förutsätts att du redan har full kontroll över din miljö i dessa fall.

### Anpassade standardinställningar

Om du vill att standardvärdena ska komma från någon annanstans än `django.conf.global_settings`, kan du skicka in en modul eller klass som tillhandahåller standardinställningarna som `default_settings`-argument (eller som det första positionsargumentet) i anropet till `configure()`.

I det här exemplet hämtas standardinställningarna från `myapp_defaults`, och inställningen `DEBUG`` sätts till `True`, oavsett dess värde i `myapp_defaults`:

    from django.conf import settings
    from myapp import myapp_defaults

    settings.configure(default_settings=myapp_defaults, DEBUG=True)

Följande exempel, som använder `myapp_defaults` som ett positionellt argument, är likvärdigt:

    settings.configure(myapp_defaults, DEBUG=True)

Normalt sett behöver du inte åsidosätta standardinställningarna på detta sätt. Djangos standardvärden är tillräckligt tama för att du säkert kan använda dem. Tänk på att om du skickar in en ny standardmodul, ersätter den helt och hållet Djangos standardinställningar, så du måste ange ett värde för varje möjlig inställning som kan användas i den kod du importerar. Kolla in `django.conf.settings.global_settings` för den fullständiga listan.

### Antingen krävs `configure()` eller `DJANGO_SETTINGS_MODULE`

Om du inte ställer in miljövariabeln `DJANGO_SETTINGS_MODULE` måste du anropa `configure()` någon gång innan du använder någon kod som läser inställningar.

Om du inte ställer in `DJANGO_SETTINGS_MODULE` och inte anropar `configure()`, kommer Django att göra ett `ImportError` undantag första gången en inställning nås.

Om du ställer in `DJANGO_SETTINGS_MODULE`, kommer åt inställningsvärden på något sätt, därefter anropar `configure()`, kommer Django att ge ett `RuntimeError` som indikerar att inställningarna redan har konfigurerats. Det finns en egenskap för detta ändamål:

django.conf.settings.configured

Till exempel:

    from django.conf import settings

    if not settings.configured:
        settings.configure(myapp_defaults, DEBUG=True)

Det är också ett fel att anropa `configure()` mer än en gång, eller att anropa `configure()` efter att någon inställning har använts.

Det kokar ner till detta: Använd exakt en av antingen `configure()` eller `DJANGO_SETTINGS_MODULE`. Inte både och, och inte varken eller.

### Anrop av `django.setup()` krävs för ”fristående” Django-användning

Om du använder komponenter i Django ”fristående” - till exempel skriver ett Python-skript som laddar några Django-mallar och renderar dem, eller använder ORM för att hämta data - finns det ytterligare ett steg du behöver utöver att konfigurera inställningar.

After you’ve either set `DJANGO_SETTINGS_MODULE` or called `configure()`, you’ll need to call `django.setup()` to load your settings and populate Django’s application registry. For example:

    import django
    from django.conf import settings
    from myapp import myapp_defaults

    settings.configure(default_settings=myapp_defaults, DEBUG=True)
    django.setup()

    # Now this script or any imported module can use any part of Django it needs.
    from myapp import models

Observera att anrop av `django.setup()` endast är nödvändigt om din kod verkligen är fristående. När den anropas av din webbserver, eller genom django-admin, kommer Django att hantera detta åt dig.

`django.setup()` får bara anropas en gång.

Undvik därför att lägga återanvändbar applikationslogik i fristående skript så att du måste importera från skriptet någon annanstans i din applikation. Om du inte kan undvika det, lägg anropet till `django.setup()` inuti ett `if`-block:

    if __name__ == "__main__":
        import django

        django.setup()

Se även

Inställningsreferensen

  Innehåller den fullständiga listan över inställningar för core- och contrib-appar.