Symphony.

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…

/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.

@newnomad: Using the hack above means they would never expire, regardless of whether the source changed/was removed.

@phoque: Not to my knowledge. Though more often than not I’m wrong about such things.

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?