Django-compressor: CACHEの圧縮ファイルの場合は404

作成日 2017年05月07日  ·  6コメント  ·  ソース: django-compressor/django-compressor

django-compressorで作成されたファイルにアクセスできません。 staticfiles/CACHE/で作成されますが、ページを読み込むと次のように表示されます。

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)

注:元のリンクは404ページにリダイレクトされるため、URLの/de/になります。 ソースコードでは、次のブロックが正しいです。

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

django-sekizaiとそれに応じたポストプロセッサcompressor.contrib.sekizai.compressを使用していることは注目に値します。

私の設定:

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',
)

テンプレートタグ:

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

誰かが私を助けることができますか? 私はこれで3日間、数え切れないほどの時間で立ち往生しています...

最も参考になるコメント

@oesah 、ありがとう。 私はまったく同じ問題を抱えています。 これはコンプレッサーの問題ではなく、このスレッドは現在閉じられていることを認識していますが、ホワイトノイズに関するこのディスカッションを開始した場合は、リンクを投稿してください。 私はこの問題を解決するために数時間を費やしました、そしてこのスレッドは命の恩人でした!

全てのコメント6件

ローカルでコンプレッサーを有効にすると、完全に機能します。 サーバー上にあるだけで、CACHEフォルダー内のファイル、その他すべてのファイルを見つけることができません。

別の発見です。問題は、セキザイ+ホワイトノイズ+コンプレッサーの組み合わせが原因で発生すると思います。 Whitenoise Docsによると、「パフォーマンスとセキュリティ上の理由から、WhiteNoiseは起動後に新しいファイルをチェックしません(Django DEBUGモードを使用している場合を除く)。そのため、すべての静的ファイルを事前に生成する必要があります。DjangoCompressorを使用している場合は、次のようになります。オフライン圧縮機能を使用して実行されます。_ "したがって、Sekizaiは、ユーザーがページを開くたびに、リアルタイムでそれらを圧縮します(sekizaiの性質上、オフライン圧縮は使用できません)。 ホワイトノイズは再度検索しないため、ファイルが存在しないと想定します。 ページを開いてファイルが作成された後にDjangoを再起動すると、動作します。 ただし、別のページに移動した場合は、同じプロセスを再度実行する必要があります(ページを開いて再起動します)。 次に、それらを適切に検出します...

それを修正する方法はありますか? 次のテストは、圧縮ポストプロセッサでsekizaiを使用しないことですが、sekizaiとリアルタイムの静的リクエストで機能するソリューションが欲しいです。

そのため、 whitenoise.django.DjangoWhiteNoiseを変更して変更しました

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

    self.autorefresh = True
    self.use_finders = True

そして今、それは機能します。 パフォーマンスの問題(私はまだ気づいていませんでしたが、逆に、Google Page Speed Insightは自動更新を有効にしてもう1つのポイントを与えてくれます。)を無視すると、セキュリティの問題は何ですか? それらを回避できますか? ホワイトノイズがリアルタイムで作成された静力学(django-compressor CACHEなど)も処理できる場合、それはamazinになります。

私の入力が他の誰かがこれにつまずくのを助けることを願っています。

こんにちは、

これはコンプレッサーの問題ではありません。これはstackoverflowまたは同様のもの(またはおそらくホワイトノイズサポートフォーラム)に属します

ええ、私はその結論に到達しました:)ホワイトノイズから人々に尋ねます。 ありがとう

@oesah 、ありがとう。 私はまったく同じ問題を抱えています。 これはコンプレッサーの問題ではなく、このスレッドは現在閉じられていることを認識していますが、ホワイトノイズに関するこのディスカッションを開始した場合は、リンクを投稿してください。 私はこの問題を解決するために数時間を費やしました、そしてこのスレッドは命の恩人でした!

このページは役に立ちましたか?
0 / 5 - 0 評価