Invalid JPEG Marker causes Panel to crash

It took me a little while that it was a faulty JPG (invalid markers) that made the Panel crash (Kirby 2.5.7)

get_resource_type() expects parameter 1 to be resource, null given



abeautifulsite\SimpleImage __destruct

– this is the log in Debug mode. In non-Debug mode, the panel just freezes, so your’re unable to save / exit / delete the faulty files.

I am not sure if this qualifies as ‘bug’ (it’s the JPGs that are faulty after all), that’s why I am posting it here. But it would to be great – especially for clients – to get a warning, (e.g. “invalid file”), instead of the whole panel just crashing.

Does the jpg work fine in graphics programs? Does it work ok with things like imageoptim?

Im not sure how easy it would be to setup, but does it work with Simple Image outside of Kirby? (this is what kirby uses to process the images.)

Also, is your server up to date, because SimpleImage depends on the common GD library.

What exactly was wrong with the image? I take it that the file was uploaded after all, but that trying to create a thumb from it caused the Panel to crash.

Thanks for your feedback. I just tested, and the files seem to work fine with imageoptim – however, I can’t open them with Photoshop (Error message). I’ve also tried running a mogrify command, and get the following errors:

mogrify: profile 'icc': 'CMYK': invalid ICC profile color space 'ardhamatsyendrasana.png' @ warning/png.c/MagickPNGWarningHandler/1709.


mogrify: Unknown Adobe color transform code 2 'janushirshasana-2.jpg' @ warning/jpeg.c/JPEGWarningHandler/365.

I probably won’t go through the hassle of setting up Simle Image locally, as it’s really just about 3 faulty images in my case; I just thought I’d report it to the forum, as the bug causes a nasty crash of the panel.

I created an issue on GitHub. Don’t know if this can be fixed in the Panel though or if this is something that needs to be fixed in the SimpleImage class.

What happens if you try to resize such an image in a frontend template?

Thanks for creating the issue on GitHub.

When I try to output these images with a frontend template, I’m basically getting the exact same error as in the panel:

Whoops\Exception\ErrorException thrown with message "get_resource_type() expects parameter 1 to be resource, null given"

#2 Whoops\Exception\ErrorException in /Users/ld/Documents/git/
#1 get_resource_type in /Users/ld/Documents/git/
#0 abeautifulsite\SimpleImage:__destruct in [internal]:0

– this is in Debug Mode; if I disable the Debug mode, all images are displayed, but the faulty ones are not resized, as opposed to other “non-faulty” JPGs.

That is the result I expected. Somehow Kirby/the Panel seems to accept the image (that’s why it is uploaded without error) but the SimpleImage class doesn’t.

As a work around, If you can get the image to open in a graphics program, save it as RGB and try again with Kirby. I see you tried Photoshop but give Gimp or Affinity Photo a try. ImageOptim seemed to like it, so maybe try the result of imageoptim in Kirby rather then the source file.

Ive had issues my self with CMYK images in general (not with Kirby, but in general the common libraries used by most CMS system can get a bit funny with CMYK images).

Feel free to send me your source file, i’m happy to have a mess with it.

The problem is that this does not help the editor because there is very little he/she can do if the Panel crashes (especially when without access to the file system to remove the file).

Well sure, but in the absence of the issue being fixed, I cant think of another way around it.

@anteante Where did the image come from? Is this a stock photo? Can you get the image in RGB in the first place? Most stock image services offer multiple formats and sizes.

You might be able to use a panel hook to convert the image to RGB on upload by talking to GD directly, rather then through SimpleImage.

I agree with @texnixe – I myself can find ways to fix a corrupted image, but that’s not an option for the client / editor, who thinks he “broke” the CMS. It’s not a big deal for those three images, I can convert them for the client; but it would be great to have a future proof fallback (e.g. an explcit error code “Invalid file” or “unable to process file”) if that happens again.

Of course, I agree with @texnixe too - clients need to see whats going on rather then it just freezing up.

I think your best bet is as I suggested… try a panel hook that converts the image to RGB on upload. This i think is the path of least resistance for clients.

I don’t think this will work because the hook is called after the event, by then, the Panel probably will already have crashed by trying to create the thumb.

Hmm thats annoying.

@anteante I was just googling around and found this plugin. It might fix your image on upload in the same way that ImageOptim was happy to do so. Ive got a hunch that it talks straight to GD, without simple image but i’m not sure. Worth a shot i guess. I think a minor tweak to it will have it save as RGB.

Well, it’s worth a try after all. Maybe the event actually does hit before the thumb is created in the sidebar or file view.

Hey @jimbobrjames thanks a lot for the hint towards this plugin … this might be a good solution, will try this out later!

@anteante No problem. Let us know how it goes.

@anteante Could you please send me the faulty file for testing? I can’t reproduce this with a completely invalid file (in my case a PDF that I renamed to .jpg), so it looks like it needs to be a JPG that is basically valid but not completely valid.