さまざまなインターネットプロジェクトの作成にかなりの時間を費やしていたため、彼は1つの事実にしばしば激怒しました。システムのすべての要素が同じ負荷をかけるわけではありません。 私は、システムの他の要素の運命を促進するために、サイトのあらゆる言語のインタープリター、データベース、またはHTTPサーバー自体であっても、システムのすべての要素が最大限の負荷をかけるべきであると常に考えてきました。 そして、プロジェクトのアプリケーション自体は常に可能な限りアンロードしようとしました。
画像（サムネイル）のサムネイルを作成するときにApacheを「パズル」する方法に関する私の経験を共有したいと思います。
長い間、画像をサムネイル化するためのさまざまなオプションを備えたサイトを「手直し」するとき、私は偶然出会い、そのデザインに常に非常に失望しました。 ほぼすべてのソリューションはスクリプトで構成されており、スクリプトは、小型化のソースと、見つからない場合は生成されたヘッダーを既に探していました。 そして、phpThumbOfを介してCMS MODXでサムネイルの実装を見たとき、私は思わず泣きさえしました。
たまたま、前述のCMSでオンラインストアを行う必要がありました。 正直なところ、タスクは単純なものではありませんが、最も繊細な瞬間はミニチュアの生成でした。 製品とイメージは1Cからアンロードされ、おそらく既に理解しているように、イメージに関する最適化と標準化の問題はありません。 この点で、ほとんどの場合、1Cは「ゴミ」という1つの単語と呼ぶことができます。 誰もができる限りそこに押し込み、それがどこから来たのかを引き出します。 いずれにせよ、商品のイメージがあり、それらの多くがあります。 また、商品の画像に加えて、他にもたくさんあるはずです-さまざまなプロモーション、イベントの写真...私が言えること-多くの画像があるはずです。
システムphpThumbOfを使用する見込みは私には魅力的ではなかったので、ページ生成中のサムネイル生成はあまりにも乱暴であり、1Cとの次のデータ交換中にサムネイルをクリーンアップすることは問題になるため、「誰でも動作する」というコンセプトに合うソリューションを探し始めました。
アイデアの本質はシンプルでした：
- インタプリタに冗長でしばしば不必要なコードで過負荷にならないように、CMSからミニチュアライザーを削除します。
- ミニチュライザーに1つではなく、多くの変換ルールを用意し、マスクでロードします。
- ミニチュアライザーのアイドルを使用しないでください。 その中で決定しようとしないでください：ミニチュアまたはそのソースがあるかどうか。
- .htaccessを介してミニチュアライザー操作の一部をApacheサーバーに転送します。
- 必要に応じてミニチュアを作成し、常に強制的に作成するわけではありません。
PHP自体のミニチュアライザーの実装はスキップします。 それは彼に関するものではありませんが、コンセプト自体は共有します。 多くの人に役立つと思います。
そのため、最初のステップは、ソースコードを変換するための多くのルールの存在下で画像とサムネイルを保存することです。
すべての画像が配置されているサイトにフォルダーがあります。 それを「画像」フォルダにします。 このフォルダには、さまざまなトピックの写真を含む多くのサブディレクトリがあります。
サムネイルを保存するためのサブディレクトリを作成します。 親指のディレクトリにしましょう。
このディレクトリ内には、サムネイルのあるサブディレクトリがあります。 各サブディレクトリは、元の画像を変換するための特定のルールに対応しています。 サブディレクトリ「a、b、c、d」とします。 それぞれには、「イメージ」カタログ以下のイメージが含まれ、一般的な変換ルールを使用してミニチュアライザーを通過します。
したがって、テンプレート「a」による変換後の画像「/images/folder1/image1.jpg」については、サムネイル「/images/thumb/a/folder1/image1.jpg」があります。
ステップ2：ミニチュアライザー自体を追加します。
画像フォルダーにミニチュアライザー付きのスクリプトを配置しました。 「/images/thumb.php」にします。 誰もそれをどこに置いても気にしませんが。 主なことは、これをRewriteBaseおよびRewriteRuleの「.htaccess」に反映することを忘れないことです。
最後に 、Apacheサーバーを起動します。
次の内容でファイル「/images/.htaccess」を作成します。
RewriteEngine On RewriteBase /images/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} ^/([^/]+)/thumb/([^/]+)(/.+)?/(.+)\.(jpe?g|png|gif|svgz?|tiff?)$ RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.%5 –f RewriteRule ^(.*)$ thumb.php [L,QSA]
このコンテンツを使用して、Apacheにミニチュアライザーを起動するかどうかについて少し考えさせます。
サーバーは最初に、要求されたイメージがあるかどうかを確認します。 そうでない場合は、これがサムネイルリクエストかどうかを確認します。 サムネイルにする必要がある場合は、要求されたサムネイルのソースがあるかどうかを確認する必要があります。 ソースが存在する場合、ミニチュアライザーを起動します。
チェックのどの段階でも、標準サーバーロジックが実行されます。 つまり 要求された画像が-彼がそれを配った場合 サムネイル要求ではない場合、または要求されたサムネイルのソースがない場合、Apacheは404 "not found"ステータスを返します。
したがって、サムネイルとそれらを作成するスクリプトへのアクセスを実装し、追加の呼び出しは行いませんでした。 また、そのようなストレージシステムは、サムネイルキャッシュのクリーニングに関連する不便さを取り除きます。
サーバーのタスクを複雑にしましょう。
SVGイメージ "/images/svgs/logo.svg"があり、キャッシュにPNG形式のサムネイルが必要だとします。
上記のスキームによれば、Apacheは単に「/images/thumb/b/svgs/logo.png」のソースを見つけられません。 サーバーは同じ拡張子を持つソースを探しています。
Apacheにもっと考えさせることができます：
RewriteEngine On RewriteBase /images/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_URI} ^/([^/]+)/thumb/([^/]+)(/.+)?/(.+)\.(jpe?g|png|gif|svgz?|tiff?)$ RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.jpg -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.jpeg -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.tif -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.tiff -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.gif -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.bmp -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.png -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.svg -f [OR] RewriteCond %{DOCUMENT_ROOT}/%1%3/%4.svgz -f RewriteRule ^(.*)$ thumb.php [L,QSA]
さて、サムネイル要求をスクリプトに送信する前に、Apacheは要求されたサムネイルのソースを別の形式で見つけようとします。 このファイルで使用可能なすべての拡張子を単純にソートし、一致するものが見つからない場合は、404「not found」を返します。
さて、ミニチュアライザーを起動するときは、変数「REDIRECT_URL」の存在を確認して、これがリダイレクトであり、直接のスクリプト起動ではないことを確認する必要があります。 ミニチュアライザーの残りの部分は、ソースが確かであることをすでに知っています。 そして、彼はすでに自分の仕事の結果をどこに置くか、どこでソースを入手するかを知っています。 すべて同じ環境変数「REDIRECT_URL」にあります。
キャッシュのゼロ化は非常に簡単です。キャッシュをクリアするソースフォルダーを指定すると、プログラムはテンプレートの名前をロードし、各変換テンプレートのキャッシュをクリアします。 1つのパターンだけをきれいにすることもできます。 また、1Cと交換するときにキャッシュを更新するには、既存の画像と着信画像のチェックサムをチェックします。不一致がある場合は、ソースを置き換えて、すべてのサムネイルをクリアします。