How to make Apache work or how I implement the creation of thumbnails of images in my projects
Hello, habrovchane.
Being engaged in the creation of various Internet projects is already a decent time, often was simply outraged by one fact - not all elements of the system bear the same load. I have always been of the opinion that every element of the system, be it an interpreter of one or another language for a site, or a database, or even an HTTP server itself, should take the maximum possible load in order to alleviate the fate of the other elements of the system. And the applications for their projects have always tried to unload as much as possible.
Now I would like to share my experience in how to “puzzle” Apache when creating Thumbnails.
With the “alterations” of sites with different variants of miniaturization of images, I have been faced for a long time and have always been very disappointed in their design. Practically all the solutions consisted in the work of the scripts and already the scripts searched for sources for miniaturization and generated headers if one was not found. And when I saw the implementation of miniatures in CMS MODX through phpThumbOf, I even cried involuntarily.
')
It so happened that I had to do an online store on the above mentioned CMS. The problem, to be honest, is not the easiest, but the most sensitive point was the generation of miniatures. Goods and images to them are unloaded from 1C and there is no question about optimization and standardization with respect to images, as you probably already understand. In this regard, in most cases, 1C can be called in one word - “garbage”. Everyone shoves there as can and pulls from where it turns out. One way or another, there are lots of product images. Also, in addition to images of goods, there should be a lot of others - photos for various actions, events ... But what can we say - there should be a lot of images.
Since the prospect of using the system phpThumbOf did not appeal to me, since the generation of thumbnails during page generation was too wild, and cleaning the thumbnails during the next exchange of data with 1C would become a problem, I began to search for a solution that matches my concept “everyone should work”.
The idea was simple:
I’ll skip the miniaturizer implementation in PHP, since It's not about him, but I'll share the concept myself. I think it is useful to many.
So, the first step: storing images and thumbnails in the presence of multiple source conversion rules.
We have a folder on the site in which all the images are. Let it be the “images” folder. In this folder there are many subdirectories with pictures on various subjects.
Create a subdirectory for storing thumbnails. Let it be the thumb directory.
Inside this directory will be subdirectories with thumbnails. Each subdirectory corresponds to a specific transformation rule for the original image. Let it be subdirectories "a, b, c, d". Each of them will contain images from the “images” catalog and below, passed through a miniaturizer using the general transformation rule.
Thus, for the image "/images/folder1/image1.jpg" after the transformation with the pattern "a" there will be a miniature "/images/thumb/a/folder1/image1.jpg".
Step two: add the miniaturizer itself.
I just put the script with the call miniaturizer in the image folder. Let it be "/images/thumb.php". Although no one bothers to place it anywhere. The main thing is not to forget to reflect this in “.htaccess” in RewriteBase and RewriteRule.
And at the end: give a kick to the Apache server.
Create a file "/images/.htaccess" with the following content:
With such content we make Apache think a little whether to launch a miniaturizer or not.
The server will first check if there is a requested image at all. If not, then check if it is a thumbnail request. If it should be a thumbnail, then it should check whether there is a source for the requested thumbnail. If the source code exists, then it starts the miniaturizer.
False at any stage of the test runs the standard server logic. Those. if the requested image is - he gives it away; if it is not a thumbnail request or there is no source for the requested thumbnail, then Apache will return status 404 “not found”.
Thus, we have implemented access to thumbnails and the script to create them, and without having to invoke one. Also, such a storage system removes the inconvenience associated with clearing the thumbnail cache.
Now let's complicate the task for the server.
Suppose I have a SVG image “/images/svgs/logo.svg” and in the cache I want to have a thumbnail in PNG format.
According to the above scheme, Apache simply will not find the source for “/images/thumb/b/svgs/logo.png”, since The server is looking for a source with the same extension.
You can make Apache think more:
Now, before sending our thumbnail request to the script, Apache will try to find the source for the requested thumbnail in a different format. He will simply iterate over all possible extensions for this file and if he did not find a match, again he will return 404 “not found” to us.
Now, when launching the miniaturizer, we only need to check the presence of the variable “REDIRECT_URL” to make sure that this is a redirect, and not a direct launch of the script. The rest of the miniaturizer already knows that the source is. Yes, and where to put the result of his work, he already knows, and where to get the source. All in the same environment variable "REDIRECT_URL".
It is very easy to reset the cache - specify the source folder for which you want to clear the cache, the program will load the names of the templates and clear the cache for each transformation template. You can also clean only for one pattern. And to update the cache when exchanging with 1C, we simply check the checksums of the existing image and the incoming one, and if there is a discrepancy, we replace the source code and clean all its thumbnails.
Being engaged in the creation of various Internet projects is already a decent time, often was simply outraged by one fact - not all elements of the system bear the same load. I have always been of the opinion that every element of the system, be it an interpreter of one or another language for a site, or a database, or even an HTTP server itself, should take the maximum possible load in order to alleviate the fate of the other elements of the system. And the applications for their projects have always tried to unload as much as possible.
Now I would like to share my experience in how to “puzzle” Apache when creating Thumbnails.
With the “alterations” of sites with different variants of miniaturization of images, I have been faced for a long time and have always been very disappointed in their design. Practically all the solutions consisted in the work of the scripts and already the scripts searched for sources for miniaturization and generated headers if one was not found. And when I saw the implementation of miniatures in CMS MODX through phpThumbOf, I even cried involuntarily.
')
It so happened that I had to do an online store on the above mentioned CMS. The problem, to be honest, is not the easiest, but the most sensitive point was the generation of miniatures. Goods and images to them are unloaded from 1C and there is no question about optimization and standardization with respect to images, as you probably already understand. In this regard, in most cases, 1C can be called in one word - “garbage”. Everyone shoves there as can and pulls from where it turns out. One way or another, there are lots of product images. Also, in addition to images of goods, there should be a lot of others - photos for various actions, events ... But what can we say - there should be a lot of images.
Since the prospect of using the system phpThumbOf did not appeal to me, since the generation of thumbnails during page generation was too wild, and cleaning the thumbnails during the next exchange of data with 1C would become a problem, I began to search for a solution that matches my concept “everyone should work”.
The idea was simple:
- remove the miniaturizer from the CMS in order not to overload the interpreter with unnecessary and often unnecessary code;
- to have in the minimizer not one, but a multitude of transformation rules, and load them according to a mask;
- do not use idle miniaturizer, i.e. Do not try to determine in it: whether there is a miniature or its source, or not;
- transfer part of the work of the miniaturizer to the Apache server via .htaccess;
- and make miniatures created on demand, and not always forced.
I’ll skip the miniaturizer implementation in PHP, since It's not about him, but I'll share the concept myself. I think it is useful to many.
So, the first step: storing images and thumbnails in the presence of multiple source conversion rules.
We have a folder on the site in which all the images are. Let it be the “images” folder. In this folder there are many subdirectories with pictures on various subjects.
Create a subdirectory for storing thumbnails. Let it be the thumb directory.
Inside this directory will be subdirectories with thumbnails. Each subdirectory corresponds to a specific transformation rule for the original image. Let it be subdirectories "a, b, c, d". Each of them will contain images from the “images” catalog and below, passed through a miniaturizer using the general transformation rule.
Thus, for the image "/images/folder1/image1.jpg" after the transformation with the pattern "a" there will be a miniature "/images/thumb/a/folder1/image1.jpg".
Step two: add the miniaturizer itself.
I just put the script with the call miniaturizer in the image folder. Let it be "/images/thumb.php". Although no one bothers to place it anywhere. The main thing is not to forget to reflect this in “.htaccess” in RewriteBase and RewriteRule.
And at the end: give a kick to the Apache server.
Create a file "/images/.htaccess" with the following content:
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] With such content we make Apache think a little whether to launch a miniaturizer or not.
The server will first check if there is a requested image at all. If not, then check if it is a thumbnail request. If it should be a thumbnail, then it should check whether there is a source for the requested thumbnail. If the source code exists, then it starts the miniaturizer.
False at any stage of the test runs the standard server logic. Those. if the requested image is - he gives it away; if it is not a thumbnail request or there is no source for the requested thumbnail, then Apache will return status 404 “not found”.
Thus, we have implemented access to thumbnails and the script to create them, and without having to invoke one. Also, such a storage system removes the inconvenience associated with clearing the thumbnail cache.
Now let's complicate the task for the server.
Suppose I have a SVG image “/images/svgs/logo.svg” and in the cache I want to have a thumbnail in PNG format.
According to the above scheme, Apache simply will not find the source for “/images/thumb/b/svgs/logo.png”, since The server is looking for a source with the same extension.
You can make Apache think more:
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] Now, before sending our thumbnail request to the script, Apache will try to find the source for the requested thumbnail in a different format. He will simply iterate over all possible extensions for this file and if he did not find a match, again he will return 404 “not found” to us.
Now, when launching the miniaturizer, we only need to check the presence of the variable “REDIRECT_URL” to make sure that this is a redirect, and not a direct launch of the script. The rest of the miniaturizer already knows that the source is. Yes, and where to put the result of his work, he already knows, and where to get the source. All in the same environment variable "REDIRECT_URL".
It is very easy to reset the cache - specify the source folder for which you want to clear the cache, the program will load the names of the templates and clear the cache for each transformation template. You can also clean only for one pattern. And to update the cache when exchanging with 1C, we simply check the checksums of the existing image and the incoming one, and if there is a discrepancy, we replace the source code and clean all its thumbnails.
Source: https://habr.com/ru/post/239501/
All Articles