# Django 6.0.5 documentation

# Appen ”statiska filer

`django.contrib.staticfiles` samlar statiska filer från alla dina applikationer (och alla andra platser du anger) till en enda plats som enkelt kan användas i produktionen.

Se även

För en introduktion till appen för statiska filer och några användningsexempel, se Hur man hanterar statiska filer (t.ex. bilder, JavaScript, CSS). För riktlinjer om hur du distribuerar statiska filer, se Så här distribuerar du statiska filer.

## Inställningar

Se staticfiles settings för information om följande inställningar:

- `STORAGES`

- `STATIC_ROOT`

- `STATIC_URL`

- `STATICFILES_DIRS`

- `STATICFILES_FINDERS`

## Kommandon för hantering

`django.contrib.staticfiles` exponerar tre hanteringskommandon.

### `samla statiskt`

django-admin collectstatic

Samlar de statiska filerna i `STATIC_ROOT`.

Duplicerade filnamn löses som standard på ett liknande sätt som mallupplösning fungerar: den fil som först hittas på en av de angivna platserna kommer att användas. Om du är förvirrad kan kommandot `findstatic` hjälpa dig att visa vilka filer som hittas.

Vid efterföljande körningar av `collectstatic` (om `STATIC_ROOT` inte är tom) kopieras filer endast om de har en ändrad tidsstämpel som är större än tidsstämpeln för filen i `STATIC_ROOT`. Om du tar bort ett program från `INSTALLED_APPS` är det därför en god idé att använda alternativet `collectstatic --clear` för att ta bort inaktuella statiska filer.

Filer söks med hjälp av `enabled finders`. Standardinställningen är att leta på alla platser som definieras i `STATICFILES_DIRS` och i katalogen `'static'` för appar som anges i `INSTALLED_APPS`.

Hanteringskommandot `collectstatic` anropar metoden `post_process()` för lagringsbackend `staticfiles` från `STORAGES` efter varje körning och skickar en lista över sökvägar som har hittats av hanteringskommandot. Den tar också emot alla kommandoradsalternativ för `collectstatic`. Detta används av `ManifestStaticFilesStorage` som standard.

Som standard får insamlade filer behörigheter från `FILE_UPLOAD_PERMISSIONS` och insamlade kataloger får behörigheter från `FILE_UPLOAD_DIRECTORY_PERMISSIONS`. Om du vill ha olika behörigheter för dessa filer och/eller kataloger kan du underklassa någon av static files storage classes och ange parametrarna `file_permissions_mode` respektive `directory_permissions_mode`. Till exempel:

    from django.contrib.staticfiles import storage

    class MyStaticFilesStorage(storage.StaticFilesStorage):
        def __init__(self, *args, **kwargs):
            kwargs["file_permissions_mode"] = 0o640
            kwargs["directory_permissions_mode"] = 0o760
            super().__init__(*args, **kwargs)

Ställ sedan in lagringsbackend för `staticfiles` i `STORAGES` till `'path.to.MyStaticFilesStorage'`.

Några vanligt förekommande alternativ är:

--noinput, --no-input

  Be INTE användaren om någon form av inmatning.

--ignore PATTERN, -i PATTERN

  Ignorera filer, kataloger eller sökvägar som matchar detta glob-liknande mönster. Använd flera gånger för att ignorera fler. När du anger en sökväg ska du alltid använda snedstreck, även i Windows.

--dry-run, -n

  Gör allt utom att modifiera filsystemet.

--clear, -c

  Rensa de befintliga filerna innan du försöker kopiera eller länka originalfilen.

--link, -l

  Skapa en symbolisk länk till varje fil i stället för att kopiera.

--no-post-process

  Anropa inte `post_process()`-metoden för den konfigurerade `staticfiles`-lagringsbackend från `STORAGES`.

--no-default-ignore

  Ignorera inte de vanliga privata glob-stilmönstren `'CVS'`, `'.*'` och `'*~'`.

En fullständig lista över alternativ finns i kommandots egen hjälpfunktion genom att köra:

/ 

    $ python manage.py collectstatic --help

    ...\> py manage.py collectstatic --help

#### Anpassa listan över ignorerade mönster

Standardlistan över ignorerade mönster, `['CVS', '.*', '*~']`, kan anpassas på ett mer beständigt sätt än att tillhandahålla kommandoposten `--ignore` vid varje `collectstatic`-inkallelse. Tillhandahåll en anpassad `AppConfig`-klass, åsidosätt attributet `ignore_patterns` för denna klass och ersätt `'django.contrib.staticfiles'` med klassens sökväg i din `INSTALLED_APPS`-inställning:

    from django.contrib.staticfiles.apps import StaticFilesConfig

    class MyStaticFilesConfig(StaticFilesConfig):
        ignore_patterns = [...]  # your custom ignore list

### `findstatic`

django-admin findstatic staticfile [staticfile ...]

Söker efter en eller flera relativa sökvägar med de aktiverade sökarna.

Till exempel:

/ 

    $ python manage.py findstatic css/base.css admin/js/core.js
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css
      /home/polls.com/core/static/css/base.css
    Found 'admin/js/core.js' here:
      /home/polls.com/src/django/contrib/admin/media/js/core.js

    ...\> py manage.py findstatic css\base.css admin\js\core.js
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css
      /home/polls.com/core/static/css/base.css
    Found 'admin/js/core.js' here:
      /home/polls.com/src/django/contrib/admin/media/js/core.js

findstatic --first

Som standard hittas alla matchande platser. Om du bara vill returnera den första matchningen för varje relativ sökväg använder du alternativet `--first`:

/ 

    $ python manage.py findstatic css/base.css --first
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css

    ...\> py manage.py findstatic css\base.css --first
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css

Detta är ett hjälpmedel för felsökning; det visar exakt vilken statisk fil som kommer att samlas in för en viss sökväg.

Genom att ställa in flaggan `--verbosity` till 0 kan du undertrycka den extra utmatningen och bara få sökvägsnamnen:

/ 

    $ python manage.py findstatic css/base.css --verbosity 0
    /home/special.polls.com/core/static/css/base.css
    /home/polls.com/core/static/css/base.css

    ...\> py manage.py findstatic css\base.css --verbosity 0
    /home/special.polls.com/core/static/css/base.css
    /home/polls.com/core/static/css/base.css

Om du däremot sätter flaggan `--verbosity` till 2 kan du få fram alla kataloger som genomsöktes:

/ 

    $ python manage.py findstatic css/base.css --verbosity 2
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css
      /home/polls.com/core/static/css/base.css
    Looking in the following locations:
      /home/special.polls.com/core/static
      /home/polls.com/core/static
      /some/other/path/static

    ...\> py manage.py findstatic css\base.css --verbosity 2
    Found 'css/base.css' here:
      /home/special.polls.com/core/static/css/base.css
      /home/polls.com/core/static/css/base.css
    Looking in the following locations:
      /home/special.polls.com/core/static
      /home/polls.com/core/static
      /some/other/path/static

### `runserver`

django-admin runserver [addrport]

Åsidosätter kärnkommandot `runserver` om appen `staticfiles` är `installed` och lägger till automatisk servering av statiska filer. Filservering körs inte genom `MIDDLEWARE`.

Kommandot lägger till dessa alternativ:

--nostatic

Använd alternativet `--nostatic` för att inaktivera servering av statiska filer med appen staticfiles helt och hållet. Det här alternativet är endast tillgängligt om appen staticfiles finns i projektets inställning `INSTALLED_APPS`.

Exempel på användning:

/ 

    $ django-admin runserver --nostatic

    ...\> django-admin runserver --nostatic

--insecure

Använd alternativet `--insecure` för att tvinga fram servering av statiska filer med appen staticfiles även om inställningen `DEBUG`` är `False`. Genom att använda detta godkänner du det faktum att det är grovt ineffektivt och förmodligen osäkert. Detta är endast avsett för lokal utveckling, bör aldrig användas i produktion och är endast tillgängligt om staticfiles-appen finns i ditt projekts `INSTALLED_APPS`-inställning.

`--insecure` fungerar inte med `ManifestStaticFilesStorage`.

Exempel på användning:

/ 

    $ django-admin runserver --insecure

    ...\> django-admin runserver --insecure

## Förråd

### `StaticFilesStorage`

class storage.StaticFilesStorage

En underklass av lagringsbackend `FileSystemStorage` som använder inställningen `STATIC_ROOT` som basplats för filsystemet och inställningen `STATIC_URL` som bas-URL.

storage.StaticFilesStorage.post_process(paths, **options)

Om den här metoden är definierad på en lagringsplats anropas den av kommandot `collectstatic` efter varje körning och får de lokala lagringsplatserna och sökvägarna till de filer som hittats som en ordbok, samt kommandoradsalternativen. Den ger tupler med tre värden: `original_path, processed_path, processed`. Sökvägsvärdena är strängar och `processed` är en boolean som anger om värdet har efterbearbetats eller inte, eller ett undantag om efterbearbetningen misslyckades.

Klassen:~django.contrib.staticfiles.storage.ManifestStaticFilesStorage använder detta bakom kulisserna för att ersätta sökvägarna med deras hashade motsvarigheter och uppdatera cacheminnet på lämpligt sätt.

### `ManifestStaticFilesStorage`

class storage.ManifestStaticFilesStorage

En underklass av `StaticFilesStorage` lagringsbackend som lagrar filnamnen som den hanterar genom att lägga till MD5-hashen av filens innehåll till filnamnet. Till exempel: skulle filen `css/styles.css` också sparas som `css/styles.55e7cbb9ba48.css`.

Syftet med denna lagring är att fortsätta servera de gamla filerna om vissa sidor fortfarande hänvisar till dessa filer, t.ex. för att de är cachade av dig eller en proxyserver från tredje part. Dessutom är det mycket användbart om du vill tillämpa far future Expires headers på de distribuerade filerna för att påskynda laddningstiden för efterföljande sidbesök.

Lagringsbackenden ersätter automatiskt sökvägarna som finns i de sparade filer som matchar andra sparade filer med sökvägen till den cachade kopian (med metoden `post_process()`). De reguljära uttryck som används för att hitta dessa sökvägar (`django.contrib.staticfiles.storage.HashedFilesMixin.patterns`) täcker:

- Regeln @import och uttalandet url() i Cascading Style Sheets.

- Source map-kommentarer i CSS- och JavaScript-filer.

Subclass `ManifestStaticFilesStorage` och sätt attributet `upport_js_module_import_aggregation` till `True`, om du vill använda de experimentella reguljära uttrycken för att täcka:

- modules import i JavaScript.

- Aggregatet modules aggregation i JavaScript.

Till exempel: filen `'css/styles.css'` med detta innehåll:

    @import url("../admin/css/base.css");

…skulle ersättas genom att anropa `url()`-metoden för lagringsbackend `ManifestStaticFilesStorage`, vilket i slutändan sparar en `'css/styles.55e7cbb9ba48.css'`-fil med följande innehåll:

    @import url("../admin/css/base.27e20196a850.css");

Användning av HTML-attributet `integrity` med lokala filer

När du använder det valfria attributet `integrity` inom taggar som `<script>` eller `<link>`, bör dess värde beräknas baserat på filerna när de serveras, inte som lagrade i filsystemet. Detta är särskilt viktigt eftersom deras kontrollsumma kan ha ändrats beroende på hur statiska filer samlas in (t.ex. när `collectstatic` används). För närvarande finns det inga färdiga verktyg tillgängliga för detta.

Du kan ändra platsen för manifestfilen genom att använda en anpassad underklass till `ManifestStaticFilesStorage` som anger argumentet `manifest_storage`. Till exempel:

    from django.conf import settings
    from django.contrib.staticfiles.storage import (
        ManifestStaticFilesStorage,
        StaticFilesStorage,
    )

    class MyManifestStaticFilesStorage(ManifestStaticFilesStorage):
        def __init__(self, *args, **kwargs):
            manifest_storage = StaticFilesStorage(location=settings.BASE_DIR)
            super().__init__(*args, manifest_storage=manifest_storage, **kwargs)

Referenser i kommentarer

`ManifestStaticFilesStorage` ignorerar inte sökvägar i uttalanden som är kommenterade. Denna kan krascha på de icke-existerande sökvägarna. Du bör kontrollera och eventuellt ta bort kommentarer.

storage.ManifestStaticFilesStorage.manifest_hash

Det här attributet ger en enda hash som ändras när en fil i manifestet ändras. Detta kan vara användbart för att kommunicera till SPA:er att tillgångarna på servern har ändrats (på grund av en ny distribution).

storage.ManifestStaticFilesStorage.max_post_process_passes

Eftersom statiska filer kan referera till andra statiska filer som behöver få sina sökvägar ersatta, kan det behövas flera omgångar för att ersätta sökvägar tills filhasharna konvergerar. För att förhindra en oändlig loop på grund av att hasharna inte konvergerar (t.ex. om `'foo.css'' refererar till ``'bar.css'' som refererar till ``'foo.css'') finns det ett maximalt antal genomgångar innan efterbehandlingen avbryts. I fall med ett stort antal referenser kan ett högre antal passeringar behövas. Öka det maximala antalet passeringar genom att underklassa ``ManifestStaticFilesStorage` och ställa in attributet `max_post_process_passes`. Standardvärdet är 5.

För att aktivera `ManifestStaticFilesStorage` måste du se till att följande krav är uppfyllda:

- lagringsbackend för `staticfiles` i `STORAGES` inställningen är inställd på `'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'`

- inställningen `DEBUG` är satt till `False`

- du har samlat in alla dina statiska filer med hjälp av hanteringskommandot `collectstatic`

Eftersom skapandet av MD5-hashen kan vara en prestandabörda för din webbplats under körning, kommer `staticfiles` automatiskt att lagra mappningen med hashade namn för alla bearbetade filer i en fil som heter `staticfiles.json`. Detta sker en gång när du kör hanteringskommandot `collectstatic`.

storage.ManifestStaticFilesStorage.manifest_strict

Om en fil inte hittas i manifestet `staticfiles.json` vid körning, uppstår ett `ValueError`. Detta beteende kan inaktiveras genom att underklassa `ManifestStaticFilesStorage` och ställa in attributet `manifest_strict` till `False` - icke-existerande sökvägar kommer att förbli oförändrade.

På grund av kravet på att köra `collectstatic`, bör denna lagring vanligtvis inte användas när du kör tester eftersom `collectstatic` inte körs som en del av den normala testinställningen. Under testning, se till att `staticfiles` lagringsbackend i `STORAGES`-inställningen är inställd på något annat som `'django.contrib.staticfiles.storage.StaticFilesStorage'` (standard).

storage.ManifestStaticFilesStorage.file_hash(name, content=None)

Den metod som används när man skapar det hashade namnet på en fil. Måste returnera en hash för det angivna filnamnet och innehållet. Som standard beräknas en MD5-hash från innehållets chunks som nämnts ovan. Du får gärna åsidosätta den här metoden för att använda din egen hashalgoritm.

### `ManifestFilesMixin`

class storage.ManifestFilesMixin

Använd denna mixin med en anpassad lagring för att lägga till MD5-hashen för filens innehåll till filnamnet på samma sätt som `ManifestStaticFilesStorage` gör.

## Finders Modul

`staticfiles` finders har ett `searched_locations` attribut som är en lista över katalogsökvägar som finders sökte i. Exempel på användning:

    from django.contrib.staticfiles import finders

    result = finders.find("css/base.css")
    searched_locations = finders.searched_locations

## Andra hjälpare

Det finns några andra hjälpmedel utanför `staticfiles`-appen för att arbeta med statiska filer:

- Kontextprocessorn `django.template.context_processors.static()` som lägger till `STATIC_URL` till varje mallkontext som återges med `RequestContext`-kontexter.

- Den inbyggda malltaggen `static` som tar en sökväg och url-joinar den med det statiska prefixet `STATIC_URL`. Om `django.contrib.staticfiles` är installerat, använder taggen `url()` metoden för `staticfiles` lagringsbackend från `STORAGES` istället.

- Den inbyggda malltaggen `get_static_prefix` som fyller en mallvariabel med det statiska prefixet `STATIC_URL` som kan användas som en variabel eller direkt.

- Den liknande malltaggen `get_media_prefix` som fungerar som `get_static_prefix` men använder `MEDIA_URL`.

- Nyckeln `staticfiles` i `django.core.files.storage.storages` innehåller en färdiginstallerad instans av lagringsbackend för staticfiles.

### Vy för utveckling av statiska filer

Verktygen för statiska filer är främst utformade för att hjälpa till med att få statiska filer framgångsrikt distribuerade i produktion. Detta innebär vanligtvis en separat, dedikerad statisk filserver, vilket är en hel del overhead att röra med när man utvecklar lokalt. Således levereras appen `staticfiles` med en snabb och smutsig hjälpvy som du kan använda för att servera filer lokalt under utveckling.

views.serve(request, path)

Denna vyfunktion serverar statiska filer under utveckling.

Varning

Denna vy fungerar endast om `DEBUG` är `True`.

Det beror på att den här vyn är grovt ineffektiv och förmodligen osäker. Den här vyn är endast avsedd för lokal utveckling och ska aldrig användas i produktion.

Observera

To guess the served files’ content types, this view relies on the `mimetypes` module from the Python standard library, which itself relies on the underlying platform’s map files. If you find that this view doesn’t return proper content types for certain files, it is most likely that the platform’s map files are incorrect or need to be updated. This can be achieved, for example, by installing or updating the `mailcap` package on a Red Hat distribution, `mime-support` on a Debian distribution, or by editing the keys under `HKEY_CLASSES_ROOT` in the Windows registry.

Den här vyn aktiveras automatiskt av `runserver` (med inställningen `DEBUG` inställd på `True`). Om du vill använda vyn med en annan lokal utvecklingsserver lägger du till följande stycke i slutet av konfigurationen för den primära URL:en:

    from django.conf import settings
    from django.contrib.staticfiles import views
    from django.urls import re_path

    if settings.DEBUG:
        urlpatterns += [
            re_path(r"^static/(?P<path>.*)$", views.serve),
        ]

Observera att början av mönstret (`r'^static/'`) ska vara din `STATIC_URL`-inställning.

Eftersom det här är lite krångligt finns det också en hjälpfunktion som gör det åt dig:

urls.staticfiles_urlpatterns()

Detta returnerar rätt URL-mönster för servering av statiska filer till din redan definierade mönsterlista. Använd det så här:

    from django.contrib.staticfiles.urls import staticfiles_urlpatterns

    # ... the rest of your URLconf here ...

    urlpatterns += staticfiles_urlpatterns()

Detta kommer att inspektera din `STATIC_URL`-inställning och koppla upp vyn för att servera statiska filer i enlighet därmed. Glöm inte att ställa in `STATICFILES_DIRS` på rätt sätt för att låta `django.contrib.staticfiles` veta var de ska leta efter filer utöver filer i appkataloger.

Varning

Denna hjälpfunktion fungerar endast om `DEBUG` är `True` och din `STATIC_URL`-inställning varken är tom eller en fullständig URL som `http://static.example.com/`.

Det beror på att den här vyn är grovt ineffektiv och förmodligen osäker. Den här vyn är endast avsedd för lokal utveckling och ska aldrig användas i produktion.

### Specialiserat testfall för att stödja ”live-testning

class testing.StaticLiveServerTestCase

Denna unittest TestCase-underklass utökar `django.test.LiveServerTestCase`.

Precis som sin förälder kan du använda den för att skriva tester som innebär att du kör koden under test och konsumerar den med testverktyg via HTTP (t.ex. Selenium, PhantomJS, etc.), varför det behövs att de statiska tillgångarna också publiceras.

Men med tanke på att den använder `django.contrib.staticfiles.views.serve()`-vyn som beskrivs ovan, kan den på ett transparent sätt lägga över de tillgångar som tillhandahålls av `staticfiles`-sökarna vid testkörningstiden. Detta innebär att du inte behöver köra `collectstatic` före eller som en del av din testkonfiguration.