Differenza tra STATIC_URL statico e STATIC_ROOT su Django


127

Sono confuso static roote voglio chiarire le cose.

Per servire file statici in Django, dovrebbe essere presente quanto segue in settings.pye urls.py:

import os
PROJECT_DIR=os.path.dirname(__file__)

1. Percorso assoluto della directory in cui raccogliere i file statici

STATIC_ROOT= os.path.join(PROJECT_DIR,'static_media/')

2. Prefisso URL per file statici

STATIC_URL = '/static/'

3. Percorsi aggiuntivi per i file statici

STATICFILES_DIRS = ( os.path.join(PROJECT_DIR,'static/'),)

... e nelle urls.pyseguenti righe:

from django.contrib.staticfiles.urls import staticfiles_urlpatterns
urlpatterns += patterns('', (
    r'^static/(?P<path>.*)$',
    'django.views.static.serve',
    {'document_root': settings.STATIC_ROOT}
))

4. Usiamo anche python manage.py collectstatic

Domande:

  1. Qualcuno potrebbe spiegarmi il flusso di lavoro: come dovrebbero essere fatte le cose idealmente. A partire da ora, copio / incollo gli snippet di codice sopra nelle posizioni designate e continuo a creare nuovi file nella directory statica e funziona. Nel mio settings.STATIC_ROOT, invece, ho indicato una directory diversa.

  2. Sarebbe fantastico se qualcuno potesse spiegare il flusso di lavoro di ciascuna impostazione: come vengono raccolti e gestiti i file e quale sarebbe una buona pratica da seguire.

Grazie.


Potresti chiarire cosa intendi per "spiegare il flusso di lavoro"? anche i tuoi schemi di URL dovrebbero essere condizionati se stai sviluppando nella parte 3. puoi farlo aggiungendo che if settings.DEBUG:django non è molto bravo a servire media statici, questo dovrebbe essere lasciato a un vero server web.
dm03514

Ciao @ user993563 non riesco nemmeno a trovare la soluzione in diversi forum quello che voglio. ma le tue domande lo spiegano chiaramente grazie amico ... ottimo lavoro ...
Mohideen bin Mohammed

Buona spiegazione, grazie
Ajay Kumar

Risposte:


89

STATIC_ROOT

Il percorso assoluto della directory in cui ./manage.py collectstaticraccoglierà i file statici per la distribuzione. Esempio:STATIC_ROOT="/var/www/example.com/static/"

ora il comando ./manage.py collectstaticcopierà tutti i file statici (cioè nella cartella statica nelle tue app, i file statici in tutti i percorsi) nella directory/var/www/example.com/static/ . ora devi solo servire questa directory su apache o nginx..etc.

STATIC_URL

Di URLcui STATIC_ROOTvengono serviti i file statici nella directory (da Apache o nginx..etc). Esempio: /static/ohttp://static.example.com/

Se imposti STATIC_URL = 'http://static.example.com/', devi servire la STATIC_ROOTcartella (cioè "/var/www/example.com/static/") tramite apache o nginx all'URL 'http://static.example.com/'(in modo da poter fare riferimento al file statico '/var/www/example.com/static/jquery.js'con 'http://static.example.com/jquery.js')

Ora nei tuoi django-templates, puoi segnalarlo tramite:

{% load static %}
<script src="{% static "jquery.js" %}"></script>

che renderà:

<script src="http://static.example.com/jquery.js"></script>

1
Qual è la differenza tra il tuo esempio e questo: href = "{% static" jquery.js "%}"
Utente

8
@macdonjo sia {{ STATIC_URL }}jquery.jse {% static "jquery.js" %}sono uguali. cioè torneranno entrambi /static/jquery.js. Le versioni più recenti di django consigliano di usare {% static "jquery.js" %}, ma è necessario caricare il templatetag, ad es {% load staticfiles %}. nella versione precedente di Django consiglia{{STATIC_URL}}
suhailvs

Vedo. Stavo cercando di trovare un bug che causava il caricamento della maggior parte dei modelli del mio foglio di stile tranne una pagina. L'ho cambiato in staticmetodo anziché in STATIC_URLmetodo e il bug era scomparso. Buona chiamata ai suggerimenti basati sulle versioni.
Utente

37

STATICFILES_DIRS: Puoi conservare qui i file statici per il tuo progetto, ad esempio quelli usati dai tuoi modelli.

STATIC_ROOT: lascia questo vuoto, quando lo fai manage.py collectstatic, cercherà tutti i file statici sul tuo sistema e li sposterà qui. Il tuo file server statico dovrebbe essere mappato a questa cartella ovunque si trovi. Controllalo dopo aver eseguito collectstatic e troverai la struttura di directory che django ha costruito.

--------Modificare----------------

Come sottolineato da @DarkCygnus, STATIC_ROOT dovrebbe puntare a una directory del tuo filesystem, la cartella dovrebbe essere vuota poiché verrà popolata da Django.

STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

o

STATIC_ROOT = '/opt/web/project/static_files'

-------- Fine modifica -----------------

STATIC_URL: "/ static /" di solito va bene, è solo un prefisso per i file statici.


2
Qui, il collegamento alla gestione dei file statici in 1.3 docs.djangoproject.com/en/1.3/howto/static-files
keni

2
STATICFILES_DIRSdovrebbe servire come directory aggiuntive per i file statici. Se metti tutti i tuoi css / js / immagini nella cartella APP_NAME / static / APP_NAME, non è necessario specificare STATICFILES_DIRS.
laike9m

Grazie per la risposta, riguardo al lasciare vuoto STATIC_ROOT, in realtà ho dovuto specificarlo in settings.py(facendo STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')) prima di eseguire il comando collectstatic .
DarkCygnus

Hmm, posso vedere con quanta facilità questo può essere fuorviante. Quello che voglio dire lasciandolo vuoto è che di solito è vuoto, senza file al suo interno. Aggiornerò la risposta per rimuovere la confusione.
keni

2

Tutte le risposte di cui sopra sono utili ma nessuna ha risolto il mio problema. Nel mio file di produzione, il mio STATIC_URL erahttps://<URL>/static e ho usato lo stesso STATIC_URL nel mio file dev settings.py.

Ciò causa un errore silenzioso in django / conf / urls / static.py.

Il test elif not settings.DEBUG or '://' in prefix: preleva il "//" nell'URL e non aggiunge il pattern URL statico, senza che vengano trovati file statici.

Sarebbe utile se Django emettesse un messaggio di errore in cui si afferma che non è possibile utilizzare un http(s)://conDEBUG = True

Ho dovuto cambiare STATIC_URL in "/ static /"

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.