По всей вероятности, ваша проблема в том, что вы использовали абсолютные URL как в STATIC_ROOT
, так и STATICFILES_DIRS
.
Если вы хотите включить абсолютные URL-адреса для каждого статического каталога (это похоже на взлом, но это нормально, так как вы должны использовать staticfiles_urlpatterns()
только в разработке), тогда вы можете решить эту проблему, просто установив STATIC_ROOT = ''
.
Редактировать : Похоже, это была не единственная ошибка. Кроме того, если вы посмотрите на результаты отладки, вы заметите что-то странное в 404 - оно исходит от /images/img03.jpg
. Если вы помните, вы пытались добавить {{ STATIC_URL }}
к этому, так что это должно было быть /static/images/img03.jpg
.
Это потому, что при использовании render_to_response
вы никогда не пропускаете никакого контекста (поэтому шаблон никогда не имеет доступа к STATIC_URL
- он думает, что он пуст (поэтому вы не видели /static/
как часть URL изображения. Всякий раз, когда вы хотите использовать ЛЮБОЙ контекст, вы ДОЛЖНЫ передать его шаблону. В этом случае вам следует использовать [RequestContext]
.
Поэтому вы должны убедиться, что добавили django.core.context_processors.static
к TEMPLATE_CONTEXT_PROCESSORS
в settings.py . Вы должны использовать render_to_response
следующим образом:
def index(request):
return render_to_response('test.html', context_instance=RequestContext(request))
Ниже приводится объяснение того, что такое контекстные процессоры :
В settings.py у вас будет что-то вроде:
TEMPLATE_CONTEXT_PROCESSORS = (
'constant_context_processor.constants',
'django.core.context_processors.static',
'django.contrib.auth.context_processors.auth',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
'django.core.context_processors.media',
'django.core.context_processors.request', )
Важной частью здесь является то, что у вас есть django.core.context_processors.static
. В Django контекстный процессор - это функция, которая возвращает контекстный запрос. Например, в моих проектах Django я часто использую следующий фрагмент кода:
constant_context_processor.py
import settings
def constants(request):
return {
'CONSTANTS': settings.CONSTANTS,
}
(Вы заметите, что выше в settings.py я использовал constant_context_processor.constants
в качестве одного из процессоров контекста). Это позволяет мне определять константы в settings.py и использовать их в моих шаблонах, например, как {{ CONSTANTS.favicon_url }}
.
Как видите, преимущество для контекстных процессоров и использования RequestContext
заключается в том, что контекст, который вам обычно нужен в ваших шаблонах, добавляется автоматически, поэтому вам не нужно вручную заполнять словарь вашего контекста в каждом представлении. Django знает, что есть определенные переменные, к которым вы обычно хотите получить доступ в своих шаблонах, поэтому они делают их доступными через свои контекстные процессоры (так, например, django.core.context_processors.request предоставит вам доступ к данному запросу, его GET и POST параметры и все виды метаданных из шаблона, что часто полезно, если, скажем, вы изменяете содержимое на основе параметров GET).
В вашем случае вы не хотели использовать много контекста, но вы хотели использовать немного ({{ STATIC_URL }}
), поэтому вам нужно было как минимум django.core.context_processors.static.