Search the Community

I think this might be happening! I remember this happening to me when working with the webp hooks. https://processwire.com/blog/posts/webp-images-and-more/#webp-image-strategies-in-processwire $wire->addHookAfter('Pageimage::url', function($event) { static $n = 0; if(++$n === 1) $event->return = $event->object->webp()->url(); $n--; }); Word from Ryan on that post:

Does anyone know how to get the module to return webp images? see https://processwire.com/blog/posts/webp-images-in-pw/

Hi again, The reason I went for creating a hook generating image variations when uploading was to avoid the "reload the front-end page until you have all your variations generated", because each time I was getting this error "2006 MySQL server has gone away". But it kept happening, even with the splitted ajax calls. I do generate a lot of variations (3 sizes + webp variants for 10+ images per page), so I understand it takes a lot time for Imagick (and memory, both of which I increased) but I'm assuming it shouldn't impact MySQL, especially since the connection is supposed to be closed / recreated up to three times if you get this error. However, reading the code, I can see the connection is correctly closed but is it actually recreated on the next try ? It's obviously getting too technical to me, but my question would be: if a PDOStatement is executed and the connection is closed, does it try to reconnect by itself ? Or I am right assuming there is someting missing here ? Like a new call to the prepare() function, which then recreate the pdo ? It's mostly a question for @ryan but maybe someone else could tell me ? Many thanks in advance ! Edit: Github issue created

ok, well at the risk of hijacking this thread and turning it my dev process (hey, it is dev-talk anyway) ... I've created an app on Cloudways which is a skeleton project with the settings I nearly always end up using on a project. These are (more or less): Modules: AIOM TfaTopt Tracy Debugger TextformatterVideoEmbed TextformatterVideoEmbedOptions TextformatterTableWrapper there are more that probably could go on that list but I think pretty much every site I've done has those. Config tweaks: adding Markup Regions and webp, and disabling session fingerprinting when the site's in debug cos otherwise I keep getting logged out when testing in responsive design mode ... Templates: Basic site layout and then various things like pulling in meta tags / CSP etc, generating a nonce for inline scripts, password protecting the site whilst it's in debug mode. CSS gets pulled in either via AIOM or directly if the site is in debug. For CSS I generally have half a dozen files (definitions / grid / nav / typography and so on) that I've built up over the years but are mostly based on bits of other libraries eg we pretty much have the Bootstrap grid then there's adding a humans.txt file and tweaks to .htaccess (things like Strict-Transport-Security and ahem, X-Clacks-Overhead ). And there's a few application settings like disabling Varnish which never seems to work well for me on dynamic sites. What else ... oh yeah, a .vscode folder in the root of the project set to 400 so I don't accidently upload project settings (yeah that's happened). Now I can just clone that skeleton app in Cloudways and I'm off to a great start for a new project. Looks like cron jobs aren't cloned which is a shame because I have a cron job I normally use to dump database backups (which are easier to roll back than the default Cloudways backups) but that's easy enough to add. And it would be nice to be able to prompt me to change the PW admin user login as well when I log into the cloned site so I don't end up resusing passwords. I'll have a think about that. I'm sure this will save me time going forward - best get on with the sites I was supposed to be building today though....

Hello everybody, in order not to hijack the Wishlist & Roadmap thread, here is an extra thread about my current webP problem where I need your help. More precisely, it's about a strange phenomenon in the creation of images. - I have an Image Field, where I can upload an image. - Then I save the page with the image and call up the internet address in the frontend. - PW now generates a webP image for me. => HOWEVER this picture is unfortunately "empty".... More details see in this article here: https://processwire.com/talk/topic/14236-webp-support/?do=findComment&comment=208142 Help where is my error? Is it PW? is it the GD version I use? Thanks Ralf

I remember this issue, which could be related: make the fallback optional if pagefile->url is smaller than webp · Issue #903 · processwire/processwire-issues (github.com)

Hello everybody, i am currently working on a project where i want to implement the webp support in the code (<picture>...). But what I'm already busy with all this weekend, that PW for whatever reason doesn't always generate a webp image? In the first screenshot (which is reproducible) no webp image is generated. But if I edit this original picture and change parts of it, then make a jpg out of it and upload it, it works. Unfortunately, this is not only the case with this picture, but with other pictures this has already happened to me on Friday ? Help what could be the reason for this? ----------- The server specification from my hosting provider ProcessWire 3.0.165 PHP version 7.4.10 gd module version 2.1.1 WebP Support - enabled imagick module version 3.4.4 but NO entry in the supported formats! (that's why I did not enable IMagick Image Sizer)

Hey, so we all know about SEO and the importance of performance. Basically we do it, because if no one finds the website we just built, it´s frustrating. We all try to write clean markup, css and js code and most might have a webpack/gulp/whatever pipeline to minimize css&js. But when thinking about it, optimizing your pipeline might save you a few (hundreds) of kb, compared to loading an image with 1 mb that´s literally nothing and frankly just ridiculous. Don´t get me wrong, frontend pipelines are great and should be used, but let´s shift your "I will optimize the shit out of that 3 css lines" focus to something different: try to serve images as fast as possible, this is where the performance boost really happens. I´m no pro on processwire so far, but I built a very easy to use picture element, which some of you could find interesting: 1. the picture comes with 3 different sizes: one for mobile (keep in mind the double dpi, therefore width of 828px), one for tablet and one for desktop 2. the picture generates a webp version and the original file extension as a fallback 3. the filesize of each element is rendered within the "data" attribute 4. lazy loading(sooo important!!!) is done via the native 'loading="lazy"' attribute. Please try it out and see the difference ? I posted this so others can easily optimize their images, but I would also like to hear your suggestions in making it better. Maybe you could decrease the rendering time or maybe you have some easy improvements. Please let me know. Greetings from Austria! <picture> <source data="<?php echo($oElement->repeater_image->width(828)->webp->filesize);?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(828)->filesize) ?>" media="(max-width: 414px)" srcset="<?php echo($oElement->repeater_image->width(828)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->width(767)->webp->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->webp->url) ?> 2x" type="image/webp"> <source data="<?php echo($oElement->repeater_image->width(767)->filesize) ?>" media="(min-width: 415) and (max-width: 767px)" srcset="<?php echo($oElement->repeater_image->width(767)->url) ?> 2x" type="image/<?php echo($oElement->repeater_image->ext)?>"> <source data="<?php echo($oElement->repeater_image->webp->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->webp->url) ?>" type="image/webp"> <source data="<?php echo($oElement->repeater_image->filesize) ?>" media="(min-width: 768px)" srcset="<?php echo($oElement->repeater_image->url) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> <img data="<?php echo($oElement->repeater_image->filesize) ?>" class="img-fluid" loading="lazy" src="<?php echo($oElement->repeater_image->url) ?>" alt="<?php echo($oElement->repeater_image->description) ?>" type="image/<?php echo($oElement->repeater_image->ext)?>"> </picture>

Or it's working I guess but just not for one image with jpg extension weird the webp is in the files folder for the page with it

$wire->addHookAfter('Pageimage::url', function(HookEvent $event) { static $n = 0; $image = $event->object; if(++$n === 1 && in_array($image->ext, [ 'jpeg', 'jpg', 'png' ])) { $event->return = $image->webp()->url(); } $n--; }); [https://processwire.com/blog/posts/webp-images-on-an-existing-site/] This works great unless shown by $page->images->getRandom(); ?

For anyone interested in using Cloudflare CDN and a processwire webp output strategy:

Repost from Autosmush topic: In regards to .webp if anyone should be interested: If you're using Cloudflare free plan, it doesn't matter anyway. Cloudflare free plan doesn't support HTTP vary header so this : – Will NOT do anything useful. Because Cloudflare will serve your webp version NO MATTER WHAT. Which means that Safari on Mac and all iOS devices will not show any pictures... ? Source: https://community.cloudflare.com/t/cloudflare-cdn-cache-to-support-http-vary-header/160802 , https://community.cloudflare.com/t/cloudflare-displays-broken-images-on-my-website/183212/13

Update in regards to webp if anyone should be interested: If you're using Cloudflare free plan, it doesn't matter anyway. Cloudflare free plan doesn't support HTTP vary header so this : – Will NOT do anything useful. Because Cloudflare will serve your webp version NO MATTER WHAT. Which means that Safari on Mac and all iOS devices will not show any pictures... ? Source: https://community.cloudflare.com/t/cloudflare-cdn-cache-to-support-http-vary-header/160802 , https://community.cloudflare.com/t/cloudflare-displays-broken-images-on-my-website/183212/13

Hi! So.. If I follow this https://processwire.com/blog/posts/webp-images-and-more/ Strategy 2: Then all images where I call them using: img->width(x)->url I get a fine working .webp version. But on all images that I call using img->url It doesn't work. I get a 404 saying: https://mydomain.com/site/assets/files/xxxx/image-file-name.-autosmush.webp doesn't exist. And that's true. The automatic webp generation seems to generate a .webp verison for every size version of the image, except the one called image-file-name.-autosmush.png, meaning it looks like this in my versions overview of an image file: I guess it's supposed to still work even though I'm not calling a specific size trough the API? right? I tried this: – But that doesn't seem to do anything... Best, Jonatan.

While looking for apng - which has very good support now: https://caniuse.com/?search=apng (contrary to mng) - for a possible solution for slideshows conversions for a future Joomla! to ProcessWire migration (using css grid and possibly also flexbox), I've just stumbled upon FLIF: https://flif.info/animation.html "14% smaller than lossless WebP, 22% smaller than lossless BPG," Etc. https://github.com/UprootLabs/poly-flif

Its coming in Safari and iOS-Safari https://caniuse.com/?search=webp%20image versions 14 TP and 14

Thanks Horst - been following this a little lately - definitely keen because WebP just doesn't seem worth the effort given the often limited size reduction and lack of Safari support.

Do you have enabled the Imagemagick rendering engine in PW? You also may set strictly use the webp variation, also if the jpeg or png source is smaller in filesize. This is not often the case, but its possible. site/config.php: $config->webpOptions = array_merge($config->webpOptions, [ 'quality' => 84, 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) 'useSrcUrlOnSize' => false, // Fallback to source file URL when webp file is larger than source? 'useSrcUrlOnFail' => true // Fallback to source file URL when webp file fails for some reason? ]);

Hi, Locally I'm using Processwire 3.0.164 on MAMP 4.1.0. with ImageMagick 6.8.9. The phpinfo lists WEBP under ImageMagick supported format. Nonetheless, ->webp->url is returning a JPG-URL for any image. Why is that?

I can replicate here. There must be something wrong with the image, as it opens in FF and other deskop image viewers on windows. I recreated webp from your original jpg (using online jpg to webp converter) and this time Chronme shows the image. I have no idea what could be wrong, possible Chrome issue?

Good day! I got a strange issue with webp images on one server. The same image works fine on Firefox and does not show (though blinks for a momдnent when trying to open it) in Chrome. I did regenerate it without luck. Then installed Imagick sizer, regenerated - same thing. Same code works fine on local machine, generating images readable in both browsers (or serving them in correct way), so must be a server issue. But what could it be? Example image used on this page. Please help!

Okay, issue created: https://github.com/processwire/processwire-issues/issues/1209 As a quick fix I will re-upload my affected non-transparent PNGs with JPGs. Another possible workaround on template level: if($image->width == $width) { $imgUrl = $image->webp->url; } else { $imgUrl = $image->width($width)->webp->url; }

Thanks for your reply! I just tried that and apparently it gives me the same png url filename.1280x0.png. As soon as I go 1 pixel up or down I get a webp URL.

Have you also tried this: $page->image->width(1280)->webp()->url

Hey, I'm trying to completely switch over to WebP and noticed some strange behaviour. Let's say I upload a PNG in Processwire of size 1280x800. $page->image->url ➝ correct URL (filename.webp) $page->image->width(800)->url ➝ correct URL (filename.800x0.webp) $page->image->width(1280)->url ➝ wrong URL (filename.1280x0.png), webp file is not generated $page->image->width(1280)->url(false) ➝ correct URL (filename.1280x0.webp) but webp file is not generated So: When I request a size that equals the original file, no WebP conversion is happening (no webp file is created, although a new PNG is generated (...1280x0.png)). When I use url(false), I get the expected URL but still the file is not generated. Also interesting: this issue is only occuring with PNG, not JPG. My Configuration: $config->imageSizerOptions('webpAdd', true); $config->imageSizerOptions('defaultGamma', -1); GD Pageimage::url Hook from here Also tried to output width(1280)->webp->url, it makes no difference I checked that the PNG version is not smaller in filesize (PNG=450KB, WebP (from other tool)=60KB) Tested with Processwire 3.0.148 and 3.0.160 dev I think this post is about the same issue and where I got the url(false) from. Setting 'useSrcUrlOnFail' => false inside $config->webpOptions results in correct output URL (filename.1280x0.webp), but still the file is not generated. So maybe the webp conversion fails? Apparently I see zero webp logs in logs/image-resizer.txt "Don't use resize" seems like a solution here but this is a generic approach in my code, sometimes uploaded images are simply already in the correct size. Any ideas how to fix this and always get dem sweet sweet WebP images? Or did I find a bug? Maybe @horst has an idea what the cause of this phenomenon could be? ?