Django-Speicher erkennt keine geänderten statischen Dateien

7

Ich benutze Django-Speicher und Amazon S3 für meine statischen Dateien. Nach der Dokumentation lege ich diese Einstellungen in meine settings.py

%Vor%

Und als ich das erste Mal mit collect static gearbeitet habe, hat alles korrekt funktioniert und meine statischen Dateien wurden in meinen s3-Bucket hochgeladen.

Nachdem jedoch Änderungen an meinen statischen Dateien vorgenommen wurden und python manage.py collectstatic ausgeführt wurde, wird dies trotz der Tatsache, dass statische Dateien geändert wurden, ausgegeben.

%Vor%

Wenn ich jedoch die geänderte statische Datei umbenenne, wird die geänderte statische Datei korrekt in meinen s3-Bucket kopiert.

Warum lädt der Django-Speicher meine geänderten statischen Dateien nicht hoch? Gibt es ein Konfigurationsproblem oder ist das Problem tiefer?

    
bab 06.07.2013, 22:59
quelle

4 Antworten

13

collectstatic überspringt Dateien, wenn die "Ziel" -Datei "jünger" als die Quelldatei ist. Scheint wie amazon S3 Speicher gibt falsches Datum für Ihre Datei zurück.

Sie könnten [code] [1] untersuchen und Server-Antworten debuggen. Vielleicht gibt es ein Problem mit der Zeitzone.

Oder Sie könnten einfach --clear Argument an Collectstatic übergeben, so dass alle Dateien auf S3 gelöscht werden, bevor Sie

sammeln     
imposeren 10.07.2013, 07:13
quelle
5

Ссылка

Von readme.txt: Benutzerdefinierter Verwaltungsbefehl, der die MD5-Summe und das Etag von S3 vergleicht und, wenn beide identisch sind, die Dateikopie überspringt. Das macht das Sammeln statisch VIEL schneller wenn Sie git als Quellcodeverwaltungssystem verwenden, das Zeitstempel aktualisiert.

    
yeaske 15.07.2013 14:15
quelle
2

Erstellen Sie eine Einstellungsdatei nur für collectstatic sync mit dieser Konfiguration:

%Vor%

Führen Sie collectstatic mit einer bestimmten Einstellung mit dieser Zeile aus:

%Vor%     
Karl Zillner 16.05.2017 16:05
quelle
0

Diese Frage ist ein wenig alt, aber für den Fall, dass es jemandem in der Zukunft hilft, dachte ich, ich würde meine Erfahrung teilen. Nach dem Ratschlag in anderen Threads bestätigte ich, dass dies in der Tat durch einen Unterschied in der Zeitzone verursacht wurde. Meine Django-Zeit war nicht falsch, wurde aber auf EST und S3 auf GMT eingestellt. Beim Testen bin ich zu den Django-Speichern 1.1.5 zurückgekehrt, die scheinbar kollektiv arbeiten. Teilweise aufgrund persönlicher Vorlieben war ich nicht bereit, a) drei Versionen von Django-Speichern zurückzusetzen und mögliche Fehlerbehebungen zu verlieren oder b) Zeitzonen für Komponenten meines Projekts zu ändern, was im Wesentlichen auf eine Bequemlichkeitsfunktion hinausläuft (wenn auch eine wichtige ein).

Ich habe ein kurzes Skript geschrieben, um die gleiche Aufgabe wie Collectstatic ohne die oben genannten Änderungen zu erledigen. Es muss für Ihre App ein wenig modifiziert werden, sollte aber für Standardfälle funktionieren, wenn es auf App-Ebene platziert wird und "static_dirs" durch die Namen der Apps Ihres Projekts ersetzt wird. Es wird über Terminal mit 'python whatever_you_call_it.py -e environment_name (setzen Sie dies auf Ihren aws-Bucket).

%Vor%     
RyCSmith 30.01.2016 06:15
quelle