Symphony.

@stuartgpalmer According to http://getsymphony.com/learn/concepts/view/jit-image-manipulation/ there is no mode '/4'. "Crop to fill" is mode /2. So: /image/2/w/h/p/e/path.

I believe it should, therefore, be: <img src="{$root}/image/2/200/50/4/0/{logo-image/@path}/{logo-image/filename}" alt="{title}" /> (I added Position [4] and Not External [0])

UPDATE just saw John's comment and realized you're refering to some magic mode that's not yet in the docs (?) Anyway, try adding all correct parameters...

I was referring to the JIT Readme on Github which describes a fourth mode "resize to fit".

Has anyone used this? If so, can you see anything wrong with my code?

Thanks :-)

Stu, what is it actually doing, if anything?

Hi John. Thanks for caring :-)

When I use mode 4 I get broken images and the error:

Image /workspace/4/200/50/uploads/sponsor_logos/stimmtag-4ec12f8928630.png could not be found.

To recap, I'm using this code:

<img src="{$root}/image/4/200/50/{logo-image/@path}/{logo-image/filename}" alt="{title}" />

I've just tried it on my local install and it's working fine. Did you make sure you updated the extension to the latest version?

Sorry guys, I was on 1.12. I have upgraded to 1.14 and it works fine. Thanks for your help.

@Fazal, @davidhund, you may be interested in the Data Source: RESS extension I have just released to be used in conjunction with JIT.

I have an in-progress Symphony site being served by the hiawatha webserver (which seems to be working well in general), and am finding that JIT images are loading properly on the first page load but not on a subsequent visit/soft reload.

Different browsers/platforms behave differently, but Chromium in Ubuntu for example doesn't display the images on the second visit to the page.

I think the difference/problem is that the Content-Type response header is not set on the second/cached visit, whereas on the first visit it is.

Initial page load response headers

Cache-Control:public
Connection:keep-alive
Content-Type:image/jpeg   # missing from second page load / soft refresh
Date:Wed, 14 Dec 2011 20:10:10 GMT
ETag:"ff2ac5c9a2f1ebc15dcf9399c8df3d5f"
Last-Modified:Sun, 25 Sep 2011 21:50:08 GMT
Server:Hiawatha v7.8.2
Transfer-Encoding:chunked

Second page load/soft refresh response headers

Cache-Control:public
Connection:keep-alive
Date:Wed, 14 Dec 2011 20:11:25 GMT
ETag:"ff2ac5c9a2f1ebc15dcf9399c8df3d5f"
Last-Modified:Sun, 25 Sep 2011 21:50:08 GMT
Server:Hiawatha v7.8.2
Transfer-Encoding:chunked

Images served by hiawatha that are not JIT images display okay, and have the Content-Type response header set.

If this is the issue, is it an issue with JIT or hiawatha? The same site and its images work okay in Apache, but perhaps this is an update to JIT that could be made to cover more webservers?

That is interesting. As far as I understand, the relevant thing is in the extension's /lib/image.php file. If you look at the lines around line 198, you see that all JIT does is send a 304 Not Modified header if the browser's request "matches".

So the question is: Would it be good to add the content-type here as well? Honestly I don't know what the HTTP specs say in this case. I have never read those specs (although I know that it would actually help, sometimes...) :-)

For your usecase you may try to add the following line before the 304 line:

header('Content-Type: ' . image_type_to_mime_type($type));

Does that help? (It would be great if you could make some browser tests on this.)

Anyway I suggest to file an issue an GitHub, so we can discuss it over there. Would you please do that?

Thanks a lot for the helpful information Michael. I'll try that and create an issue at Github tomorrow.

I finally twigged the relevance of the 304 header not being set. (The status for these cached JIT images was showing in Chromium as 200 when it should have been 304.)

Some searching revealed that it's a server API issue and not a webserver issue. Because I'm using FastCGI, the 304 status header needs to be header('Status: 304 Not Modified'); instead of header('HTTP/1.1 304 Not Modified');.

The Content-Type header is not required to show the cached images once the 304 status header is correctly sent.

I'll post info/links and an idea for a possible solution in a Github issue.

CGI / Apache module issue logged.

Hello!

I just tried to update to the latest version of JIT but when Im trying to save my list of trusted sites in preferences, the trusted sites textarea remains blank after the save (i.e., the list doesn't get saved). Any idea of what this is caused by?

Thanks

the trusted sites textarea remains blank after the save (i.e., the list doesn't get saved). Any idea of what this is caused by

Check that the file has write permissions.

Is it extension.driver.php?

All files in the JIT-folder has 644, as all other extensions seems to have.

Oh sorry, I mean

/manifest/jit-trusted-sites

This file should be created when you save the form. If it's not there, check permissions on /manifest and then perhaps try creating the file by hand.

Creating the file by hand seemed to do the trick. Thanks alot!

I had a thought just now while playing with JIT parameters: a malicious person could very easily directly view the image URL and replace the image dimensions with large numbers. If they then repeatedly hit their revised URL, I think that could cause denial of service issues due to the memory involved in resizing and the associated bandwidth.

What would be a good way of preventing that?

I thought there were JIT Recipies in the pipeline that would help prevent this kind of activity?

Aha, thanks. The recipes sound good.