Symphony.

Not sure if its probably the right thing to call it that! I've been using jit for a while and have no problem at all on some websites.

Recently I've been working on a project and jit was working absolutely fine however all of a sudden all images are marked by browsers as broken. However I still see the correct image when I check the manifest/cache folder (cleared this up to be sure). So it seems like either something with the headers or the encoding. Note I am using 1.14 last version compatible with 2.2.5.

The file is also successfully transferred with a 200 and the size of the files seems to make complete sense as well.

Permissions. I get that every time I deploy to a new server.

The original image needs read permissions, and the cache needs read and write permissions.

Doubt its permissions... all this is happening both on my local XAMPP environment and the dev server. The cache files are being created. So its not problems with write/read permissions.

The problem seems with the submission of files; if I open up the images in the cache (Even from a browser) these appear properly however through jit the browsers are cpomplaining that the image is invalid

It reads the following

The image “http://website.com/image/1/100/0//images/trainers/trainer-name.png” cannot be displayed because it contains errors.

http://website.com/image/1/100/0//images/trainers/trainer-name.png

Isn't there a double / ?

good point should work anyway though. I tried various combinations. Even if I tried http://website.com/image/0/images/trainers/trainer-name.png which is the unedited version its still the same result a blank on the front-end. all other instances create a cache file which still exists and I can locate this through the file system.

What happens when you try and open up the image from it's workspace path in the browser?

Does manifest/logs/main have anything enlightening to add? My problems with JIT images not displaying have almost always included some error messages along the way.

Image from workspace path works perfectly - only issue is when images are passed through jit; and nothing in the logs. the return code is 200 so deemed as valid. The browser just thinks the image is broken

When you say broken, what exactly is the browser returning?

So I copied the image URL from the page and pasted it into the Navigation Bar.

Chrome & IE return a blank page with the broken image icon. HTTP code 200 and file transferred over 10kb

Firefox returns the following message instead of the image

The image “http://website.com/image/1/100/0/images/trainers/trainer-name.png” cannot be displayed because it contains errors.

Now if on Chrome I right clicked on the broken image and saved it to desktop. Windows Photo Viewer returns the following error

Windows Photo Viewer can't open this picture because the file appears damaged, corrupted, or is too large.

Could I be missing some library on the PHP side of things to make this work or possibly some image headers are being lost on transfer? As the generated cache file is fine... its on transfer through the Apache server that it seems to become corrupted.

So went a step further and opened up the image properties of the cache file and the one I get through jit on my browser. The one that I saved from my browser has missing image Dimensions & Bit Depth... so I assume there's something wrong with the image headers... though I don't really have an idea of what I should be looking for.

It sounds like an issue with the GD library in PHP, although I'm not sure.

Fixed going to put a bug report in... seems all it required was an ob_clean() function prior to the header outputs....

Hm, peculiar... Can you post the image you're trying to resize here?

Phoque - tried with loads of images - so its not a single image issue.

This guy had the same issue with a similar technique. Its something to do with the header outputs; his blog explains it much better.

@unglien I'm having the same issue but I'm not sure where should I put the fix. Could you please explain it a little bit?

thank you!

Well this is strange.

I've just had the "The image [...] cannot be displayed because it contains an error" problem for the first time after setting up locally with a new dev environment, but it's with JIT 1.18 which includes ob_clean() at the beginning of the renderOutputHeaders method.

If I comment out ob_clean(), images are successfully loaded. :-S

My new dev environment is using PHP 5.4 (FastCGI/FPM) whereas I was previously using PHP 5.3 (FastCGI/FPM), and I'm wondering if that's what makes the difference. But I would have thought more would have had this problem either before or after ob_clean() was added if that were the case.

As reported by Firefox, with ob_clean the size of my test image response is 38.5 KB. Without, it's 38.7 KB. I wonder what that .2 KB that's being cleared that either enables or disables (depending on some as-yet-unidentified difference) the image to load in-browser might be...

Response headers with and without are reported as being the same.

@gunglien, did you have this problem in PHP 5.3, and does JIT with ob_clean still work for you in PHP 5.4+? I see from your pull request info you were using Apache. I'm using Hiawatha.

I assume others have successfully been running JIT 1.18+ on PHP 5.4?

@iltrico and anyone else who needs to add/remove ob_clean, you can see the inserted line here.

Can you log this on the JIT repo please?

To follow from github, I have an out-of-the-box ubuntu (well, linuxmint) configuration. I am now also updating a photo web, and all runs fine. Sorry, I'm no help with this, but just to note this.

Issue reported.

I'm finding that using ob_end_clean() seems not to stop JIT working for me, so maybe this is an alternative that would also work for @gunglien. But as far as I understand, neither should be necessary.

@juro, thanks. :)