Symphony.

Images dynamically resized by the JIT extensions can be cached on the server. But is there a way to let the images be cached by the browser as well.

Wait, their not?

Wait, their not?

Judging from the flashing/reloading of images all the time: I don’t think so.

Actually Symphony sends hardcore-no-caching-http-headers for everything it is generating (pages and images). Maybe one day the team thinks about making this configurable… But most of the time those headers are welcome to me. (Additionally I use the Datestamp Helper extension to control caching of JacaScript files, for example.)

Actually Symphony sends hardcore-no-caching-http-headers for everything it is generating (pages and images).

Yuck on the images not caching part. That seems a little bit wasteful.

Well, yes and no. If authors are using a CMS, they tend to replace images by new versions with the same filename, for example. But they won’t understand that in this case many browsers would still show the old (cached) version until it “expires”. (Theoretically, the “Etag” HTTP-header would solve this – if the browser accepted this help… In my tests it didn’t work very well.)

So if I had to choose, I’d vote for “not caching”. But, yes, maybe someone will make it configurable for each upload field in the future. (This would mean changes to the JIT extension and to the upload field.)

I think the second factor to this problem arises from JIT always sending Last-Modified: now(). That way the browser will always throw away anything it has in its cache and reload the image as it must be brand new.

Maybe for starters setting it to the time the original image has actually been modified on the server would help improve image load behaviour a little bit.

Doing that would probably be gentle on the problem michael-e mentioned: Replacing an existing file on the server with a new one will simply change the Last-Modified header, encouraging (but not forcing) the browsers to reload it.

The next step would be to teach JIT to answer with 304 Not Modified headers.

Oh and I still think it was a horrible design decision to not cache external images.

Granted, one could spam the /manifest/cache/ directory with thumbs of images from other servers in the funniest dimensions and cropping modes. But this can be done with local files too. And of course there is the problem of not knowing when an image has been modified on the external server. But come on, that’s a tradeoff one has to make when using images from other servers. Additionally, this could be prevented by a simple separate “don’t cache external images” config setting.

On the other hand you have unreliable loading times and traffic even before the transformation has been done at all. Loading a single thumbs from an external site always takes a couple of seconds(!) on my server.

Maybe for starters setting it to the time the original image has actually been modified on the server would help improve image load behaviour a little bit.

The next step would be to teach JIT to answer with 304 Not Modified headers.

Seems that there is room for optimization. (Of course, that’s nothing for a minor – bugfix – release of Symphony.)

Oh and I still think it was a horrible design decision to not cache external images.

Yes, for fast loading you will need to import those images using import scripts and cronjobs. At least that’s what I have done, for example with a flickr stream.

And of course there is the problem of not knowing when an image has been modified on the external server.

I think we could rely on some HTTP headers. But at the moment I don’t know if Symphony’s gateway class is capable of that. With cURL you can do this rather easily.

I’ve been searching the core for hours now to find where the images are set to “not cache”.

Any help on where I can hack caching into the core? (I’m on windows, so searching in files doesn’t actually work..)

Thanks.

I have not found this either. There are some headers built in /extensions/jit_image_manipulation/lib/class.image.php, but – strange – changing them had no effect when I tried it.

Maybe Alistair can help.

There are some headers built in /extensions/jit_image_manipulation/lib/class.image.php, but – strange – changing them had no effect when I tried it.

There is a conditional return statement in the second line of code in the renderOutputHeaders function. Maybe you put your headers after the statement. But I wasn’t lucky modifying the headers there either.

Tricky.

Alistair?

Phew, I thought it was just me..;)

Phew, I thought it was just me..;)

Nope. I have failed as well. :-)

Something is very strange here. Room for improvement, perhaps.

Yes, I was thinking of improving JIT to include the things mentioned here, but this has stopped me in my tracks..

There is a conditional return statement in the second line of code in the renderOutputHeaders function. Maybe you put your headers after the statement. But I wasn’t lucky modifying the headers there either.

I was able to change Last-Modified accordingly to last file modification, just before the if statement you mentioned.

Any more on this chaps? This is a bug that has annoyed me for some time and I’ve never looked into a resolution. It’d be great to nail this for 2.0.8…

Is it a bug or a feature? (Symphony sends everything using all those “no-cache” headers.)

There’s always the “unwanted caching” case. You overwrite an image file in the backend, and some browsers might stick to the old version. So if you change JIT’s behaviour, developers will have to prohibit aggressive caching themselves (for example by using the Unique File Upload extension, which helps by generating a new filename).

So if you change JIT’s behaviour, developers will have to prohibit aggressive caching themselves (for example by using the Unique File Upload extension, which helps by generating a new filename).

Could the cache TTL be configurable? Or by passing another parameter (0 or 1) in the JIT URL to say whether you want the output to set cache headers or not.