By looking at the timthumb.php that is included in the JIG distribution (4.1.1), apparently it will not process webp (but it’s unclear to me what is the expected behavior when webp’s are fed to it. by what I see on my website, the overall result seems to be the broken images)

protected function processImageAndWriteToCache($localImage){
    $sData = getimagesize($localImage);
    $origType = $sData[2];
    $mimeType = $sData['mime'];

$this->debug(3, "Mime type of image is $mimeType");
if(! preg_match('/^image\/(?:gif|jpg|jpeg|png)$/i', $mimeType)){
    return $this->error("The image being resized is not a valid gif, jpg or png.");
}

If you know what you are doing you don’t need TimThumb, so keep it disabled. The best is always to serve up “handcrafted” images. Not sure how WP handles webp or if it offers a fallback, but if you disable TT, JIG will just use what WP has as thumbnail for an image. You should make sure to use a row height + deviation value in the grids that don’t exceed the height of the thumbnails you have, to avoid upscaling.

Hi Firsh, thanks, understood. To understand better how to improve the thumbnails in case there is the need, what format does timthumb output for JIG and do you pass anything dynamic to it?

It outputs at a compressed JPG, but I plan to change how the thumbnail system works. Not sure if I can ever get rid of TT completely, but I want to support cloud-based image resizer/CDN services. In my personal use (not the demo site) I let WP create the thumbs and serve them from S3+CloudFront, no TT at all. But this way the Retina functionality is lost. So I’ll likely add a setting to define another WP-based thumbnail for the 2x resolution. Less optimal than cloud resizers – those are the real alternative but I understand I can’t make those default since they are paid options.

With a filter you can influence WordPress’ JPG compression too. It’s a setting in JIG’s TimThumb. Not sure about webp, haven’t investigated that yet.

Understood, thanks for the clarifications. I have tried to quickly patch TT for webP but no real luck yet at least on my installation (but I have trouble debugging there because of some server config). Here is the gist with the modified timthumb if you want to use it as a base. I modified line 507 and 840-843: https://gist.github.com/mbariola/27104111aec6377e4e90cd8ff77e1d76

Do you think we could drop IE11 and just use webp without fallback to legacy formats? I’m definitely interested in supporting that natively so thanks for the changed code, I’ll play with it. Seems too easy to achive this with those few lines.

Fix this:

} else {
} else if(

There is also something related to formats on 1182: protected function openImage

Thanks for the bug heads up. Yes I now can see the logs and I see that I need to fix something else in TT too, maybe the bit you pointed out. Well, IE in general has a 0,71% market share as of last statistics I have read, so yes. It’s been sunsetted by MS too. The only places where IE is still going strong are where a different browser cannot be downloaded, thinking places with really old computers and / or no admin privileges. I worked at a school where some PCs still ran Win XP, but they did have firefox installed.

I would say it is time to bring webP on and if you really want to cover all bases, leave room a hook or an option for retrocompatibility.

On a different matter, I am having trouble trying to debug JIG on my website. The default-language gallery works now (TT off): https://dev.syrian-heritage.org/gallery/ but the other languages do not show any picture anymore. https://dev.syrian-heritage.org/de/bilder-2/ I am sure that something went wrong with the import – together with the multi language quirks – but I do not see where. Is there a way to have a better insight of what JIG is trying to load, maybe both in php and in the browser JS … some way to write what image (ID, filepath) is trying to load so that I can figure out where the issue is? WP(ML) is rather unhelpful, it just says “WPML makes an attachment object per each language, but it reuses the same file”. I’m looking in the object metadata right now …

Ok, I’ll bring webp then Regarding WPML here is my guide: https://justifiedgrid.com/support/faq/how-to-translate-galleries-with-wpml-and-justified-image-grid/

You can check the IDs if you view source. JIG uses the media library IDs for lightbox deeplinking so they are in the source, search for the string jig-contentID- and you’ll see.

with TT off, it appears it is using the “medium” resolution for the webp, 1024×667 instead of a smaller size (thumbnail is 150×150, too small, but there are other intermediate sizes), so pics do show up but it takes quite a long time to show.

oh, one thing re webp, it has only become native in wp since last 5.8 release! You can still use it by adding a plugin like webp converter for media which works splendidly but does not touch the original pictures which are still in the media library. So, in this case, this might be the main point to consider when making webp the default choice for JIG

Seems to work fine, are you using any privacy extensions or adblocker? Are you logged in to FB on that browser?

No I’m not logged in to FB on this browser (Chrome) and neither using any privacy extensions. But I get the sad face icon as here – https://bit.ly/2SYM6E0

Hi, I tried and see what you mean. When logged out, there are no like buttons. Not just on JIG, anywhere else, on random blogs. Maybe not sad face, but they seem to be missing (just empty space). Do you experience the same thing on other sites? Unless you are logged in, there is no like button.

Yes, I’m getting pretty much what you just summarised. Do you have any idea why this might be happening?

I can only guess, maybe due to privacy laws, Facebook is not supposed to track you (with the like buttons) unles you gave consent. You do that by creating the account, and can perform the tracking while you are logged in.

On a technical side, I was checking blogs that use the iframe way of embedding, if you find a site where the button works even while logged out, I can investigate, maybe they use the non-iframe way. If that is the case I could change it in JIG.

Another thing I could think of, is that FB prefers that you supply an APP ID when generating the like button. Historically it has worked without one, but for various purposes they want to you have an app. To have a verified app is an ordeal and I doubt they would require people to have apps for such a simple thing as a like button.

Generally I see a move towards not using their official button but just a “share button image” (without a counter). That may show no social proof, but it is faster in every way, causes no 3rd party tracking of your visitors, and less prone to errors from a 3rd party (FB itself), when evaluating a site.

Also the mobile version works fine. It’s just the desktop version that’s the problem. So not even sure where I should start troubleshooting.

Please send me a link to where this happens. Does it also happen on my site for you? https://justifiedgrid.com/lightboxes/photoswipe/#!jig%5B1%5D/ML/8952

Thanks for responding. I sent the URL via PM. I checked out that link and yours works fine!