Django-compressor: 404 para archivos comprimidos en CACHE

Creado en 7 may. 2017 · 6Comentarios · Fuente: django-compressor/django-compressor

No puedo acceder a los archivos creados por django-compressor. Se crea en staticfiles/CACHE/ , pero cuando cargo la página dice:

GET https://site.com/de/static/CACHE/css/5e257aa688ab.css/ 404 (Not Found)
GET https://site.com/de/static/CACHE/js/3f1c59956fa3.js/ 404 (Not Found)

Nota: El enlace original se redirige a la página 404, de ahí el /de/ en la URL. En el código fuente, los siguientes bloques son correctos:

<link rel="stylesheet" href="/static/CACHE/css/5e257aa688ab.css" type="text/css" />
<script type="text/javascript" src="/static/CACHE/js/3f1c59956fa3.js"></script>

Vale la pena señalar que uso django-sekizai y el posprocesador correspondiente compressor.contrib.sekizai.compress .

Mi configuración:

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

COMPRESS_STORAGE = 'compressor.storage.GzipCompressorFileStorage'
COMPRESS_URL = STATIC_URL
COMPRESS_ENABLED = True

STATIC_ROOT = '/app/staticfiles/'  # usually computed, ends up here
STATIC_URL = '/static/'

STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
    # Django-Bower
    'compressor.finders.CompressorFinder',
)

Etiquetas de plantilla:

{% render_block "css" postprocessor "compressor.contrib.sekizai.compress" %}
{% render_block "js" postprocessor "compressor.contrib.sekizai.compress" %}

¿Alguien me puede ayudar? Estoy atascado con esto durante 3 días e incontables horas...

Fuente

oesah

Comentario más útil

@oesah , gracias por esto. Estoy teniendo exactamente el mismo problema. Me doy cuenta de que esto no es un problema del compresor y que este hilo ahora está cerrado, pero si ha comenzado esta discusión sobre el ruido blanco, ¿podría publicar un enlace? ¡Pasé algunas horas tratando de resolver este problema y este hilo fue un salvavidas!

zengoma en 1 dic. 2017

👍5

Todos 6 comentarios

Cuando habilito el compresor localmente, ¡funciona perfectamente! Es solo en el servidor, que no puede encontrar los archivos en la carpeta CACHE, todo lo demás que encuentra.

oesah en 8 may. 2017

Ok, otro hallazgo: supongo que el problema surge debido a la combinación de sekizai + whitenoise + compresor. Whitenoise Docs dice que "_Por razones de rendimiento y seguridad, WhiteNoise no busca nuevos archivos después del inicio (a menos que use el modo DEBUG de Django). Como tal, todos los archivos estáticos deben generarse con anticipación. Si está usando Django Compressor, esto puede ser realizado usando su función de compresión fuera de línea._" Entonces, Sekizai los comprime en tiempo real (la compresión fuera de línea no está disponible debido a la naturaleza de sekizai), cada vez que un usuario abre una página. Whitenoise no vuelve a buscar, por lo que asume que el archivo no existe. Cuando reinicio Django después de abrir una página y crear los archivos, funciona. Pero si voy a otra página, tengo que volver a hacer el mismo proceso (abrir página y reiniciar). Entonces los encuentra correctamente...

¿Alguna idea de cómo arreglarlo? Mi próxima prueba será no usar sekizai con el posprocesador de compresión, pero me encantaría una solución que funcione con sekizai y solicitudes estáticas en tiempo real.

oesah en 8 may. 2017

Entonces terminé modificando whitenoise.django.DjangoWhiteNoise y cambié

    self.autorefresh = settings.DEBUG
    self.use_finders = settings.DEBUG

    self.autorefresh = True
    self.use_finders = True

Y ahora funciona. Sin tener en cuenta los problemas de rendimiento (que aún no noté, por el contrario, Google Page Speed Insight me da un punto más con la actualización automática habilitada), ¿cuáles son los problemas de seguridad? ¿Puedo eludir esos? Sería increíble si whitenoise también pudiera manejar estáticas creadas en tiempo real (como django-compressor CACHE).

Espero que mis aportes ayuden a alguien más a tropezar con esto.

oesah en 9 may. 2017

Hola,

Este no es un problema del compresor, pertenece a stackoverflow o similar (o quizás al foro de soporte de whitenoise)