2012-02-06 17 views
6

Los medios se encuentran actualmente en mi máquina de desarrollo local.Django no puede encontrar mis archivos de medios (en el servidor de desarrollo)

Mi MEDIA_ROOT, MEDIA_URL, ADMIN_MEDIA_PREFIX y se especifican a continuación:

MEDIA_ROOT = os.path.join(os.path.dirname(__file__), "media") 
MEDIA_URL = '/media/' 
SITE_URL = 'http://localhost:80' 
ADMIN_MEDIA_PREFIX = '/media/admin/' 

No hay una carpeta 'admin', pero que no debe hacer una diferencia no creo. En el archivo urls.py que tengo:

(r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}), 

Estoy en una pérdida en cuanto a lo que debo hacer para que funcione. [Estoy tratando de aprender django y estoy trabajando con un proyecto existente que es bastante peludo]

Respuesta

7

Está mezclando y combinando el manejo de archivos estáticos pre y post Django 1.3. Originalmente, todos los archivos estáticos se publicaron desde MEDIA_URL, pero Django 1.3 introdujo el paquete contrib staticfiles y las configuraciones asociadas STATIC_ROOT y STATIC_URL. django.views.static.serve utiliza la nueva aplicación staticfiles, que no ha configurado.

Suponiendo que ejecuta Django 1.3, primero, tendrá que agregar 'archivos estáticos' a su INSTALLED_APPS. Luego, deberá definir STATIC_ROOT y STATIC_URL. La ubicación estándar es un directorio de nivel de raíz de proyecto denominado "estático".

También tendrá que añadir el procesador staticfiles contexto de la plantilla:

TEMPLATE_CONTEXT_PROCESSORS = (
    ... 
    'django.core.context_processors.static', 
) 

Esto hará que la variable STATIC_URL disponible en sus plantillas, lo que puede hacer referencia a los recursos con algo como {{ STATIC_URL }}css/style.css

Todos sus recursos estáticos también deberán ir a un directorio de nivel (s) de aplicación llamado "estático". El directorio "estático" del nivel de raíz del proyecto real nunca se usa directamente. Es simplemente el lugar donde el comando de administración collectstatic vacia todos sus recursos estáticos para usar en producción.

Si desea recursos estáticos de todo el proyecto (no ligada a ninguna aplicación en particular), tendrá un directorio totalmente independiente (es decir, no el mismo que MEDIA_ROOToSTATIC_ROOT). Tiendo a usar uno llamado "activos". A continuación, tendrá que decirle a Django que mirar en aquí para recursos estáticos, así como con el ajuste STATICFILES_DIRS:

STATICFILES_DIRS = (
    os.path.join(os.path.dirname(__file__), 'assets'), # or whatever you named it 
) 

MEDIA_ROOT/MEDIA_URL están ahora sólo se utiliza para la carga de usuarios (por ejemplo, cualquier archivo creado a través de FileField s y s ImageField , por lo que aún se necesita, pero no se va a almacenar cada vez manualmente nada allí.

al llegar a la producción, su servidor web tendrá que servir tanto MEDIA_ROOT y STATIC_ROOT en MEDIA_URL y STATIC_URL, respectivamente. también necesitará ejecutar:

$ python manage.py collectstatic 

Para hacer que Django compile todos sus archivos estáticos en el directorio especificado por STATIC_ROOT.

+0

Uf, debería haber recordado que estaba trabajando en el 1,3 cuando el código es de 1.2, ¿hay alguna forma de que no tenga que cambiar demasiado en el código 1.2 para poder usar ese directorio sin ningún problema? ¿O sería mejor para mí degradar a django 1.2? – StanM

+0

Hay algunas otras configuraciones, como 'BASES DE DATOS 'que pueden darle advertencias de depreciación o pueden necesitar modificaciones para compatibilidad con Django 1.3, pero hay relativamente pocos cambios obligatorios en general. Personalmente, recomendaría seguir con 1.3 y hacer que la aplicación funcione. El ligero trabajo potencialmente involucrado en hacer que funcione es ampliamente superado por los beneficios de cosas como archivos estáticos, vistas basadas en clases, etiquetas de plantilla mejoradas, etc. Además, hará que sea más fácil saltar finalmente a 1.4, que será casi una necesidad tener la liberación de lo que he visto. –

4

En servidor de desarrollo, esta página puede ayudarlo. https://docs.djangoproject.com/en/1.2/howto/static-files/

Mediante la adición de código de seguimiento a urls.py:

if settings.DEBUG: 
    urlpatterns += patterns('', 
     (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/media'}), 
    ) 
0

con Python Django 1.7 Solía ​​

if settings.DEBUG: 
     urlpatterns = patterns('', 
      (r'^$', 'blenderx3d.first_step.views.index'), 
      (r'^media/(?P<path>.*)$','django.contrib.staticfiles.views.serve'),) 
6

trabajos con Django 1.8 a 1.11:

from django.conf import settings 
from django.conf.urls.static import static 

urlpatterns = [ 
    # ... the rest of your URLconf goes here ... 
] 

if settings.DEBUG: 
    urlpatterns += static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) 

https://docs.djangoproject.com/en/1.11/howto/static-files/#serving-files-uploaded-by-a-user-during-development

nota de que la documentación de Django afirma que esto es

no es adecuado para su uso en producción

(obviamente a menos que utilice if settings.DEBUG: parte)

+0

Esto está documentado aquí https://docs.djangoproject.com/en/1.10/howto/static-files/#serving-files-uploaded-by-a-user-during-development, y al menos a partir de 1.10, no necesita el bit 'if settings.DEBUG:'. Aún necesitará configurar de forma condicional 'MEDIA_URL' y' MEDIA_ROOT' en función de si se encuentra en modo de depuración. –

Cuestiones relacionadas