Django-compressor: Offline-Komprimierungsfehler

Erstellt am 25. Sept. 2013 · 6Kommentare · Quelle: django-compressor/django-compressor

Ich habe eine Woche damit verbracht, dies zu debuggen (zwei verschiedene separate Wochen) und bin ziemlich frustriert. Ich glaube, ich habe fast jeden Artikel/Blogbeitrag/jede Ausgabe gelesen und weiß nicht, was ich tun soll. Ich habe sowohl einen Staging-Server als auch einen Produktionsserver (jeweils mit separaten s3-Buckets) und dies funktioniert beim Staging, aber nicht bei der Produktion, obwohl die Server (auf Heroku) und die Buckets identisch sind.

Ich habe es so gemacht, dass Komprimierungs-Tags nur in der untergeordneten Vorlage angezeigt werden. Ich habe alle Template-Tags aus den compress-Tags entfernt (z. B. if/else). Das heißt, ich habe mehr compress-Tags, sodass die if/else-Anweisungen außerhalb der compress-Tags stehen können.

Hat jemand irgendwo eine funktionierende Offline-Komprimierung in der Produktion eingerichtet, um sie sich anzusehen? Mit compress offline=False gibt es eine erhebliche zusätzliche Last auf dem Server, häufig eine zusätzliche Verzögerung von 300-500 ms, was sich offensichtlich nicht lohnt und den gesamten Zweck dieses Pakets zunichte macht.

Ich könnte wirklich etwas Hilfe gebrauchen, habe aber im Grunde keine Ahnung, was ich an dieser Stelle tun soll, weil es das gleiche Problem ist, über das Hunderte von Menschen in der Problemliste hier und in Blogbeiträgen an anderer Stelle lesen können, und es scheint keine wiederholbare Lösung zu geben vorgeschlagen - was ein großes Problem für etwas ist, das für die Leistung so entscheidend ist und das wahrscheinlich jede Django-Bereitstellung erfordert.

deployment

Quelle

dasloss

Hilfreichster Kommentar

In den letzten Tagen war ich damit beschäftigt, das gleiche Problem zu lösen, und hier ist, was die Lösung war, falls es jemandem hilft.

In einer der Vorlagen, bei der das Problem reproduzierbar war, habe ich Kontext verwendet. Während der Offline-Komprimierung gibt es keinen Zugriff auf den Kontext, deshalb werden der während der Offline-Komprimierung generierte Schlüssel und der aus dem Antwortzyklus offensichtlich unterschiedlich sein.

Versuchen Sie, die Teile von JavaScript, in denen Sie sich auf den Kontext verlassen, auf einen anderen Block zu isolieren, der sich außerhalb des compress-Tags befindet.

Hoffentlich hilft diese Information jemandem.

jordanjambazov am 18. Juli 2016

👍2

Alle 6 Kommentare

Dasselbe hier. Scheint, dass COMPRESS_OFFLINE von django_compressor mehr Probleme macht als löst. Ich kann es nicht zum Laufen bringen, weil ich solche Nachrichten erhalte:

OfflineGenerationError: You have offline compression enabled but key "%s" 
is missing from offline manifest. You may need to run "python manage.py compress".

shalakhin am 18. Okt. 2013

Ebenfalls :/

Die Offline-Komprimierung funktioniert nicht. Bekomme immer OfflineGenerationError.

neara am 19. Jan. 2014

Also habe ich sichergestellt, dass ich bei jeder Bereitstellung auf allen Webservern Folgendes ausführe

python manage.py compress --force
python manage.py collectstatic

Das sollte die manifest.json-Datei aktualisieren. Außerdem stelle ich sicher, dass der Name der Manifestdatei bei jedem Push anders ist. Fügen Sie beispielsweise eine Versionsnummer hinzu. manifest_%s.json
Ich verwende die neueste Git-Commit-Hash-ID für das Plugin %s. Während der Bereitstellung führt es also einen Git-Pull, eine Komprimierung, eine Collectstatic durch und erstellt neue minimierte/aggregierte CSS/JS mit einer neuen manifest.json-Datei.
Und dann starte ich Apache neu. Es sollte also alles glatt sein.

Außerdem habe ich dafür gesorgt, dass collectstatic nicht --clear aufruft, um alte statische/* Medien zu löschen.

Sinn ergeben?

sidmitra am 10. März 2014

👍1

ok ich habe genau das gleiche problem.
Jeder führt dies zuverlässig offline von S3 aus?

mattions am 11. Okt. 2014

bitte versuche:
http://stackoverflow.com/a/31545361/1359475

mateuspadua am 21. Juli 2015