Różnica między statycznymi STATIC_URL i STATIC_ROOT w Django


127

Jestem zdezorientowany static rooti chcę wszystko wyjaśnić.

Aby udostępniać pliki statyczne w Django, w settings.pyand urls.py:

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

1. Bezwzględna ścieżka do katalogu, w którym powinny być gromadzone pliki statyczne

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

2. Prefiks adresu URL dla plików statycznych

STATIC_URL = '/static/'

3. Dodatkowe lokalizacje dla plików statycznych

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

... i w urls.pynastępujących wierszach:

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

4. Używamy również python manage.py collectstatic

Pytania:

  1. Czy ktoś mógłby mi wyjaśnić przebieg pracy: jak najlepiej to zrobić. Na razie kopiuję / wklejam powyższe fragmenty kodu do wyznaczonych lokalizacji i kontynuuję tworzenie nowych plików w katalogu statycznym i działa. W moim settings.STATIC_ROOTjednak wskazałem na inny katalog.

  2. Byłoby wspaniale, gdyby ktoś mógł wyjaśnić przepływ pracy dla każdego ustawienia: w jaki sposób pliki są gromadzone i zarządzane oraz jakie dobre praktyki należy stosować.

Dzięki.


Czy mógłbyś wyjaśnić, co rozumiesz przez „wyjaśnienie przepływu pracy”? również wzorce adresów URL powinny być uzależnione od tego, czy tworzysz w części 3. możesz to zrobić dodając, że if settings.DEBUG:django nie jest zbyt dobre w obsłudze mediów statycznych, powinno to być pozostawione prawdziwemu serwerowi WWW.
dm03514

Cześć @ user993563, nie mogę nawet znaleźć rozwiązania na kilku forach, czego chcę. ale twoje pytania wyjaśniają to jasno, dzięki człowieku ... świetna robota ...
Mohideen bin Mohammed Stycznia

Dobre wyjaśnienie, dzięki
Ajay Kumar

Odpowiedzi:


90

STATIC_ROOT

Bezwzględna ścieżka do katalogu, w którym ./manage.py collectstaticbędą gromadzone pliki statyczne do wdrożenia. Przykład:STATIC_ROOT="/var/www/example.com/static/"

teraz polecenie ./manage.py collectstaticskopiuje wszystkie pliki statyczne (tj. w folderze statycznym w twoich aplikacjach, pliki statyczne we wszystkich ścieżkach) do katalogu /var/www/example.com/static/. teraz musisz tylko udostępniać ten katalog na Apache lub nginx..etc.

STATIC_URL

Z URLktórych STATIC_ROOTsą obsługiwane pliki statyczne w katalogu (przez Apache lub nginx..etc). Przykład: /static/lubhttp://static.example.com/

Jeśli ustawisz STATIC_URL = 'http://static.example.com/', musisz udostępniać STATIC_ROOTfolder (tj. "/var/www/example.com/static/") Przez apache lub nginx pod adresem url 'http://static.example.com/'(abyś mógł skierować plik statyczny za '/var/www/example.com/static/jquery.js'pomocą 'http://static.example.com/jquery.js')

Teraz w swoich szablonach django możesz polecić to przez:

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

który wyrenderuje:

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

1
Jaka jest różnica między twoim przykładem a tym: href = "{% static" jquery.js "%}"
Użytkownik

8
@macdonjo oba {{ STATIC_URL }}jquery.jsi {% static "jquery.js" %}są takie same. tj. oba powrócą /static/jquery.js. Nowsze wersje django są zalecane do używania {% static "jquery.js" %}, ale musisz załadować szablon templatetag, tj {% load staticfiles %}. w starszej wersji django poleca{{STATIC_URL}}
suhailvs

Widzę. Próbowałem znaleźć błąd, który powodował, że większość moich szablonów wczytywała mój arkusz stylów z wyjątkiem jednej strony. Zmieniłem to na staticmetodę zamiast STATIC_URLmetody i błąd zniknął. Dobre wezwanie do sugestii opartych na wersjach.
Użytkownik

37

STATICFILES_DIRS: Możesz zachować statyczne pliki swojego projektu tutaj, np. Te używane przez twoje szablony.

STATIC_ROOT: zostaw to puste, gdy to zrobisz manage.py collectstatic, wyszuka wszystkie pliki statyczne w twoim systemie i przeniesie je tutaj. Twój serwer plików statycznych powinien być mapowany na ten folder, gdziekolwiek się znajduje. Sprawdź to po uruchomieniu collectstatic, a znajdziesz strukturę katalogów zbudowaną przez django.

--------Edytować----------------

Jak wskazał @DarkCygnus, STATIC_ROOT powinien wskazywać katalog w twoim systemie plików, folder powinien być pusty, ponieważ zostanie zapełniony przez Django.

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

lub

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

-------- Zakończ edycję -----------------

STATIC_URL: „/ static /” jest zwykle w porządku, to tylko przedrostek dla plików statycznych.


2
Tutaj link do statycznego zarządzania plikami w 1.3 docs.djangoproject.com/en/1.3/howto/static-files
keni

2
STATICFILES_DIRSpowinny służyć jako dodatkowe katalogi dla plików statycznych.Jeśli umieścisz wszystkie swoje css / js / images w folderze APP_NAME / static / APP_NAME, nie ma potrzeby określania STATICFILES_DIRS.
laike9m

Dzięki za odpowiedź, o pozostawieniu pustego STATIC_ROOT, właściwie musiałem to określić w settings.py(robiąc STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')) przed uruchomieniem polecenia collectstatic .
DarkCygnus

Hmm, widzę, jak łatwo może to być mylące. Przez pozostawienie go pustego mam na myśli to, że zwykle zaczyna się pusty, bez żadnych plików. Zaktualizuję odpowiedź, aby usunąć zamieszanie.
keni

2

Wszystkie powyższe odpowiedzi są pomocne, ale żadna nie rozwiązała mojego problemu. W moim pliku produkcyjnym mój STATIC_URL był https://<URL>/statici użyłem tego samego STATIC_URL w moim pliku dev settings.py.

Powoduje to cichą awarię w django / conf / urls / static.py.

Test elif not settings.DEBUG or '://' in prefix: wykrywa „//” w adresie URL i nie dodaje statycznego wzorca adresu URL, przez co nie można znaleźć żadnych plików statycznych.

Byłoby dobrze, gdyby Django wypluł komunikat o błędzie informujący, że nie można użyć http(s)://withDEBUG = True

Musiałem zmienić STATIC_URL na „/ static /”

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.