2

私は。。をしようとしていますRAILS_ENV=production run rake paperclip:refresh:thumbnails CLASS=Spree::Image

リモート サーバーの現在の Rails アプリ ディレクトリにあるので、過去にアップロードした画像を更新できます。

私は S3 を使用しています。AWS S3 バケットの個々の ID フォルダで製品の各画像を確認できるため、バケットは正しくセットアップされています。

しかし、上記のコマンドを実行するたびに、レーキが中止されると「No such key」エラーが発生します。

このコマンドはローカルで実行され、正常に動作します。(明らかに RAILS_ENV=production をローカルに指定していない場合)

4

2 に答える 2

3

コンソールを使用して同じ問題を解決し、エラーをスキップしました (古い/壊れた S3 アセット):

Spree::Image.all.each { |i| i.attachment.reprocess! rescue nil }
于 2014-09-04T16:16:10.713 に答える
3

わかりましたので、自分で答えるためにこの質問を書きました。質問が理にかなっていることを願っています。

明確にするために、同じ Rails アプリでの以前のテストで別の S3 キーを使用してアップロードしたのは古いイメージ (古い S3 キーに関連付けられた古い存在しないパス) であったため、この問題が発生しました。Rails Spree アプリケーションで S3 を動作させようとしていたときに、これを以前に行いました。

これを解決するために私がしたことは、次のコマンドを使用してリモート サーバーの Rails コンソールにアクセスすることでした。

$RAILS_ENV=production rails c

次に、すべての Spree:Images のリストを次のように並べ替えました。

$y Spree::Image.all(:order => 'attachment_updated_at')

'y' は、Spree:Image の情報を表示する yaml の良い方法で、もう少し人間味があります。

次に、各イメージの ID を調べたところ、AWS S3 バケット内のフォルダーと一致しない ID を持つイメージがかなりの数あることに気付きました。

私の場合、実際に S3 バケット内のフォルダーであった最小の ID 番号は「1078」だったので、これを実行しました。

$Spree::Image.where('id < ?', 1078).destroy_all

これにより、1077 以下の ID を持つ Spree::Image が削除されました。

最後に、Rails コンソールを閉じて、現在の Rails アプリ ディレクトリ内のリモート サーバーでこれを実行しました。(私の場合は /home/deployer/apps/potentialapp/current/ でした)

$RAILS_ENV=production rake paperclip:refresh:thumbnails CLASS=Spree::Image

これにより、Spree にアップロードした画像が再フォーマットされ、すべてがうまく機能するようになりました。

これが誰かを大きな頭痛の種から救うことを願っています。（ああ、テストに行くときはキャッシュを空にして、画像が実際にリロードされているかどうかを確認してください。昨夜の午前4時に泣きそうになりました。）

于 2013-05-30T19:23:21.070 に答える