How to get Apache to work or how do I implement image thumbnails in my projects
Hello, Khabrovites.
Being engaged in the creation of various Internet projects for a decent time, he was often simply outraged by one fact - not all elements of the system carry an equal load. I have always been of the opinion that every element of the system, whether it is an interpreter of one or another language for a site, or a database, or even the HTTP server itself, should take on the maximum possible load in order to facilitate the fate of other elements of the system. And the applications themselves for their projects have always tried to unload as much as possible.
Now I would like to share my experience on how to "puzzle" Apache when creating thumbnails of images (Thumbnails).
When "reworking" sites with various options for thumbnailing images for a long time I came across and was always very disappointed in their design. Almost all solutions consisted of scripts and scripts were already looking for sources for miniaturization and generated headers, if not found. And when I saw the implementation of thumbnails in CMS MODX via phpThumbOf, I involuntarily even wept.
It just so happened that I had to do an online store on the aforementioned CMS. The task, to be honest, is not from simple, but the most delicate moment was the generation of miniatures. Products and images are unloaded from 1C and there is no question of any optimization and standardization regarding images, as you probably already understand. In this regard, in most cases, 1C can be called one word - "garbage." Everyone shoves there as best he can and pulls where it comes from. One way or another, there are images of goods and there are many of them. Also, in addition to images of goods, there should be a lot of others - photos for various promotions, events ... What can I say - there should be many images.
Since the prospect of using system phpThumbOf did not appeal to me, since thumbnail generation during page generation was too wild, and brushing thumbnails during the next data exchange with 1C would become a problem, I started looking for a solution that fits my concept “everyone should work”.
The essence of the idea was simple:
I will skip the implementation of the miniaturizer in PHP itself, as it’s not about him, but I’ll share the concept itself. I think it will be useful to many.
So, the first step: storing images and thumbnails in the presence of many rules for converting source codes.
We have a folder on the site in which all the images are located. Let it be the “images” folder. In this folder there are many subdirectories with pictures on various topics.
Create a subdirectory for storing thumbnails in it. Let it be the thumb directory.
Inside this directory will be subdirectories with thumbnails. Each subdirectory corresponds to a specific rule for converting the original image. Let it be the subdirectories “a, b, c, d”. Each of them will contain images from the “images” catalog and below, passed through the miniaturizer using the general transformation rule.
Thus, for the image “/images/folder1/image1.jpg” after the conversion according to the template “a” there will be a thumbnail “/images/thumb/a/folder1/image1.jpg”.
Step two: add the miniaturizer itself.
I just put a script with a miniaturizer in the image folder. Let it be "/images/thumb.php". Although no one bothers to place it anywhere. The main thing to remember is to reflect this in “.htaccess” in RewriteBase and RewriteRule.
And in the end:give a kick to the Apache server.
Create the file “/images/.htaccess” with the following contents:
With this content, we get Apache to think a bit about whether to launch the miniaturizer or not.
The server will first check if there is a requested image at all. If this is not the case, then check to see if this is a thumbnail request. If it should be a thumbnail, then he should check if there is a source for the requested thumbnail. If the source exists, it starts the miniaturizer.
Lying at any stage of the check starts the standard server logic. Those. if the requested image is - he gives it away; if it is not a thumbnail request or if there is no source for the requested thumbnail, then Apache will return a 404 “not found” status.
Thus, we have implemented access to thumbnails and a script to create them, and without any extra call to it. Also, such a storage system removes the inconvenience associated with cleaning the thumbnail cache.
Now let's complicate the task for the server.
Suppose I have an SVG image "/images/svgs/logo.svg" and I want to have a thumbnail in PNG format in the cache.
According to the above scheme, Apache simply will not find the source for "/images/thumb/b/svgs/logo.png", because 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. It will simply sort through all possible extensions for this file and if it does not find a match, it will again return 404 “not found” to us.
Now, when starting the miniaturizer, we just need to check the presence of the variable “REDIRECT_URL” to make sure that this is a redirect, and not a direct script launch. The rest of the miniaturizer already knows for sure that the source is. And he already knows where to put the result of his work, and where to get the source. All in the same environment variable "REDIRECT_URL".
Zeroing the cache is very easy - specify the source folder for which you need 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 for just one pattern. And to update the cache during the exchange with 1C, we simply check the checksums of the existing image and the incoming one, and if there is a mismatch, we replace the source and clear all its thumbnails.
Being engaged in the creation of various Internet projects for a decent time, he was often simply outraged by one fact - not all elements of the system carry an equal load. I have always been of the opinion that every element of the system, whether it is an interpreter of one or another language for a site, or a database, or even the HTTP server itself, should take on the maximum possible load in order to facilitate the fate of other elements of the system. And the applications themselves for their projects have always tried to unload as much as possible.
Now I would like to share my experience on how to "puzzle" Apache when creating thumbnails of images (Thumbnails).
When "reworking" sites with various options for thumbnailing images for a long time I came across and was always very disappointed in their design. Almost all solutions consisted of scripts and scripts were already looking for sources for miniaturization and generated headers, if not found. And when I saw the implementation of thumbnails in CMS MODX via phpThumbOf, I involuntarily even wept.
It just so happened that I had to do an online store on the aforementioned CMS. The task, to be honest, is not from simple, but the most delicate moment was the generation of miniatures. Products and images are unloaded from 1C and there is no question of any optimization and standardization regarding images, as you probably already understand. In this regard, in most cases, 1C can be called one word - "garbage." Everyone shoves there as best he can and pulls where it comes from. One way or another, there are images of goods and there are many of them. Also, in addition to images of goods, there should be a lot of others - photos for various promotions, events ... What can I say - there should be many images.
Since the prospect of using system phpThumbOf did not appeal to me, since thumbnail generation during page generation was too wild, and brushing thumbnails during the next data exchange with 1C would become a problem, I started looking for a solution that fits my concept “everyone should work”.
The essence of the idea was simple:
- remove the miniaturizer from the CMS, so as not to overload the interpreter with redundant and often unnecessary code;
- to have not one, but many transformation rules in the miniturizer, and load them by mask;
- do not use the miniaturizer idle, i.e. Do not try to determine in it: is there a miniature or its source, or not;
- transfer part of the miniaturizer operation to the Apache server through .htaccess;
- and make miniatures created on demand, and not always forced.
I will skip the implementation of the miniaturizer in PHP itself, as it’s not about him, but I’ll share the concept itself. I think it will be useful to many.
So, the first step: storing images and thumbnails in the presence of many rules for converting source codes.
We have a folder on the site in which all the images are located. Let it be the “images” folder. In this folder there are many subdirectories with pictures on various topics.
Create a subdirectory for storing thumbnails in it. Let it be the thumb directory.
Inside this directory will be subdirectories with thumbnails. Each subdirectory corresponds to a specific rule for converting the original image. Let it be the subdirectories “a, b, c, d”. Each of them will contain images from the “images” catalog and below, passed through the miniaturizer using the general transformation rule.
Thus, for the image “/images/folder1/image1.jpg” after the conversion according to the template “a” there will be a thumbnail “/images/thumb/a/folder1/image1.jpg”.
Step two: add the miniaturizer itself.
I just put a script with a miniaturizer in the image folder. Let it be "/images/thumb.php". Although no one bothers to place it anywhere. The main thing to remember is to reflect this in “.htaccess” in RewriteBase and RewriteRule.
And in the end:give a kick to the Apache server.
Create the file “/images/.htaccess” with the following contents:
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 this content, we get Apache to think a bit about whether to launch the miniaturizer or not.
The server will first check if there is a requested image at all. If this is not the case, then check to see if this is a thumbnail request. If it should be a thumbnail, then he should check if there is a source for the requested thumbnail. If the source exists, it starts the miniaturizer.
Lying at any stage of the check starts the standard server logic. Those. if the requested image is - he gives it away; if it is not a thumbnail request or if there is no source for the requested thumbnail, then Apache will return a 404 “not found” status.
Thus, we have implemented access to thumbnails and a script to create them, and without any extra call to it. Also, such a storage system removes the inconvenience associated with cleaning the thumbnail cache.
Now let's complicate the task for the server.
Suppose I have an SVG image "/images/svgs/logo.svg" and I want to have a thumbnail in PNG format in the cache.
According to the above scheme, Apache simply will not find the source for "/images/thumb/b/svgs/logo.png", because 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. It will simply sort through all possible extensions for this file and if it does not find a match, it will again return 404 “not found” to us.
Now, when starting the miniaturizer, we just need to check the presence of the variable “REDIRECT_URL” to make sure that this is a redirect, and not a direct script launch. The rest of the miniaturizer already knows for sure that the source is. And he already knows where to put the result of his work, and where to get the source. All in the same environment variable "REDIRECT_URL".
Zeroing the cache is very easy - specify the source folder for which you need 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 for just one pattern. And to update the cache during the exchange with 1C, we simply check the checksums of the existing image and the incoming one, and if there is a mismatch, we replace the source and clear all its thumbnails.