カタログキャッシュイメージの問題を再生成する

Magento 1.9.2.4からMagento 2.1.6への移行プロセスを行っています。移行が完了したら、M1のメディアフォルダーをpub / media M2に移動します。

問題は、カタログ/キャッシュフォルダーに画像の一部が生成されないことです

たとえば、以下の画像は404 not foundになります

pub/media/catalog/product/cache/f9c7fbe9b524c081a3ccf800cbd963eb/m/s/msj006c-red_2.jpg
pub/media/catalog/product/cache/75eed2686e01eb22cb4050b2f40ddf97/m/s/msj006c-red_2.jpg
pub/media/catalog/product/cache/f9c7fbe9b524c081a3ccf800cbd963eb/m/s/msj006c-red_2.jpg

カタログキャッシュフォルダーを削除してページを再度読み込むだけですが、壊れたイメージになります。

私のページには50％の壊れた画像があります

この問題を解決するための回避策を共有できますか？

image resizeコマンドを使用して、必要なすべてのサイズ変更を事前に生成してください。

php bin/magento catalog:image:resize

このコマンドは、テーマXMLで定義されているすべての画像サイズを取得し、正しいフォルダーに画像を事前生成します。

詳細については、コマンドのドキュメントhttp://devdocs.magento.com/guides/v2.1/frontend-dev-guide/themes/theme-images.htmlを確認することもできます

私もこの問題を抱えており、上記のコマンドラインイメージの生成でさえ機能しませんでした。Magento はサムネイルが作成された情報をキャッシュしているようで、標準のMagentoキャッシュクリーニング（コマンドラインまたは管理パネルの両方）でさえ、この情報をキャッシュから削除しません。

すべてのキャッシュディレクトリのコンテンツを手動で削除し、それが役立ちました：

rm -Rf var/cache/*
rm -Rf var/page_cache/*

.. 等々。その後、画像のサムネイルは、サイトの閲覧中に適切に「オンデマンド」で生成されるはずです。

これとまったく同じ問題がありましたが、Magento 2.3.2

私にとっては、間違ったキャッシュハッシュパスを持つ製品のサムネイル画像でした。製品とカテゴリの画像は正しいが、サムのURLは正しくなく、標準のMagento画像のプレースホルダーが表示されていました。

カスタムテーマを使用していました。

SHH "php bin / magento catalog：images：resize"を使用している場合-何が起きていましたか？画像は、カスタムテーマetc / view.xmlファイルではなく、Lumaテーマetc / view.xmlを使用して生成されていました。

問題。Lumaテーマとは異なるサイズの画像を使用するブラウザでカスタムテーマを表示すると、Magentoは画像を見つけることができず、404エラーを表示します。

修正。

Replace Luma themes etc/view.xml with my custom theme etc/view.xml
Using SHH run "php bin/magento catalog:images:resize

これを修正する方法を見つけるのに1週間かかりましたが、今ではすべて正常に動作します。

使用しているテーマの構成を確認し、ソースストアの構成がターゲットの構成と同じであることを確認してください。これを参照できます：https : //devdocs.magento.com/guides/v2.3/frontend-dev-guide/themes/theme-images.html

次に実行します：

php bin / magento catalog：images：resize

これが役立つかどうか教えてください！

2019年11月20日の回答：

コマンドによってイメージキャッシュを再生成することは、多くの製品を持っている一部のWebサイトでは多くの時間がかかるため、すべての実行可能なソリューションではありません。また、CLIからキャッシュイメージを生成する場合、それが機能するなどのいくつかの問題に直面しました。その時点で管理者から画像をフラッシュしたり、キャッシュされた画像を手動で削除すると、ページの読み込み時にキャッシュ画像が再度生成されないため、再生成コマンドを何度も実行する必要があります。私の観点では、最適なソリューションはページの読み込み時に画像キャッシュを生成することです。

デフォルトフロー

デフォルトのMagentoフローは、イメージ（メディア）を読み込むときは常に、pub / get.phpへのリクエストを常に通過し、イメージが存在するかどうかを確認します。存在しない場合は、新しいキャッシュイメージが生成されます。存在する場合、そのパスを返します。そのため、デフォルトでは、画像はページの読み込み時に生成されます。

以下のファイルでこのパススルーロジックを確認できます

pub/media/.htaccess以下のためのApacheサーバ

RewriteRule .* ../get.php [L]
.............................
.............................

nginx.conf.sample以下のためのnginxのサーバー

location /media/ {
    try_files $uri $uri/ /get.php$is_args$args;
    .......................................
    .......................................

このロジックが機能しているかどうかを確認する方法は？

echo "test";exit;pub / get.phpの先頭に入れて、キャッシュされたメディアURLをロードすると、テストを出力するはずです。それ以外の場合は、サーバー構成に問題があります。

私にとっては、カタログキャッシュディレクトリ（rm -rf pub / media / catalog / product / cache / *）を削除した後、ページを読み込むと新しいキャッシュイメージが生成されず、404ページが見つかりません。また、get.phpには到達しません。次に、フォルダーの多くが、フォルダーの755やファイルの644とは異なる不正なアクセス許可を持っていることに気付きました。適切な許可を設定すると、正常に機能します。

私はそれが何らかのアイデアを与えることを願っています。