JIT Image Manipulation: Caching
This is an open discussion with 10 replies, filed under Extensions.
Search
/jit_image_manipulation/lib/image.php:
define_safe('CACHING', ($param->external == false && $settings['image']['cache'] == 1 ? true : false));
Looks like caching is only enabled if the image is internal and caching is enabled in the config. You could probably change this, and the condition on line 117, but I’d be interested to know why it’s been done this way.
I assumed if you whitelist your external server in the pref pane it works. So this is a tiny bug?
@nickdunn Interesting because to me caching external images seems a lot more important that caching internal images.
@newnomad Without adding it to the whitelist JIT wouldn’t accept any images from the server at all. It has nothing to do with caching.
There’s no caching for external images because you can’t detemine their modified time. I’ve been meaning to submit a patch to Github that would allow you to cache external images by setting a preference. Haven’t gotten around to it yet though.
You should be able to enable it manually by changing /lib/image.php
in the following way. Line 74:
define_safe('CACHING', ($settings['image']['cache'] == 1 ? true : false));
Line 116-131:
## Do cache checking stuff here if(CACHING === true){ $cache_file = sprintf('%s/%s_%s', CACHE, md5($_REQUEST['param'] . $quality), basename($image_path)); if($param->external == FALSE && @is_file($cache_file) && (@filemtime($cache_file) < @filemtime($image_path))){ unlink($cache_file); } elseif(is_file($cache_file)){ $image_path = $cache_file; @touch($cache_file); $param->mode = MODE_NONE; $param->external = FALSE; } }
Keep in mind that this means cached external images will never expire.
Unless they source picture is updated I assume?
Can’t we force expire them by adding a ?jitexpire to any url or something?
@Makenosound Doesn’t HTTP transmit the modified time? Simply check the headers from time to time.
I think there are some useful HTTP response headers:
Date:Tue, 01 Sep 2009 08:52:30 GMT Expires:Tue, 01 Sep 2009 08:57:30 GMT Last-Modified:Wed, 06 May 2009 11:30:22 GMT
The problem might be that not all servers send these headers. Some use ETags (an HTTP 1.1 feature) instead:
Date:Tue, 01 Sep 2009 08:57:34 GMT Etag:"100c9660-1446-6ed4d700"
And some use them all:
Date:Tue, 01 Sep 2009 09:00:54 GMT Etag:"5790-4722e611a0580" Expires:Tue, 01 Sep 2009 09:37:56 GMT Last-Modified:Fri, 28 Aug 2009 07:10:30 GMT
It might be an interesting project to enable JIT to check these headers and apply caching for external images as well. (AFAIK, it should be possible to request those headers only, without requesting the actual file.)
And these seem to be the corresponding request headers for modification time and ETag:
If-Modified-Since:Fri, 28 Aug 2009 07:10:30 GMT If-None-Match:"5790-4722e611a0580"
What about falling back to “save for x minutes” when there are no headers set?
Create an account or sign in to comment.
Is JIT Image Manipulation caching images from external servers at all?
No matter how often I have loaded them, manipulated images from external servers are always dead slow…