LiipImagineBundleを使用して、アップロードした画像からフィルタリングされた画像を作成しています。バンドルの現在の構成は次のとおりです。元のサイズのため元の画像とフィルタリングされた画像を同じフォルダに保存します。 - LiipImagineBundle
web_root\{subdirectory}\{type}_{filename_md5_hash}.jpeg
タイプはどちらかs
かo
:
liip_imagine:
resolvers:
default:
web_path: ~
filter_sets:
cache: ~
my_filter:
filters:
relative_resize: { heighten: 66 }
私の目標は次のようなディレクトリ構造を作成することです。サブディレクトリはアップロード日から作成されます。
LiipImagineBundleは、フィルタリングされた画像をweb_root\my_filter\{subdirecory}\{type}_{filename_md5_hash}.jpeg
に保存するという問題があります。
my_filter
のURLの部分はどうやって省略できますか?アップロードされた各画像とフィルタリングされた画像が同じ最終フォルダに保存される必要があります。
私は専門家ではなく、私は役に立たないように多くの研究を行いました。この設定では、フィルタ全体または個々のフィルタのキャッシュのWebパスを変更することができますが、最終的なURLには常にフィルタ名が表示されます。
お手数をおかけします。
このソリューションではキャッシュをまったく使用しないため、長期的にはパフォーマンスの問題が発生する可能性があります。また、実行時に常にフィルタリングされたファイルを生成し、キャッシュされたファイルを使用しないため、サブディレクトリにファイルを保存する理由はわかりません。しかしそれに加えて、私はこれがうまくいくことに同意します。これは私が提案したものよりも最適ではなくクリーンですが、それは仕事です。 – Terenoth
@テレノス、ありがとうございました。私は正直なところ、「なぜ長期的にはパフォーマンスの問題があるのか」を理解していません。私は実行時にフィルタリングされたファイルを生成しません。私がやっているのは、ファイルをアップロードしている間にフィルタリングされた画像を作成することです(コントローラのuploadAction内にあります)。 liipImagineBundleのデフォルトフォルダとは別のフォルダに 'キャッシュ 'します。あなたの説明は非常に高く評価されています。 –
あなたのコードは表示アクションであり、アップロードアクションではないと思いました。その場合、実際にはパフォーマンスの問題はありません。私はLiipImagineBundleを実際には必要としないが、LiipImagineのキャッシュとフィルタ機能を実際に使用していないので、自分自身を想像してみてください。あなたは 'liip_imagine.data.manager'と' liip_imagine.filter.manager'を呼び出すことなく、アップロードされたバイナリを取得し、Imagine関数を適用して新しいファイルを保存することができます。しかし、物事が働く限り、あなたは行くのが良いです:) – Terenoth