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.