Search the Community

@Didjee I think this must be an issue with the core. But I'm not able to investigate further ATM. Maybe there is a possible workaround, or at least some (micro) optimization, with your code example, leaving out the subfile class(es) from the chain. If you have enabled the $config->webpOptions['useSrcExt'], you can globally enable the creation of webP variations in the base core image engines, directly when creating any jpeg or png variation, by setting $config->imageSizerOptions['webpAdd'] to true. But this can result into a lot of unwanted webP files from intermediate image variations (that are never shown to the front end, but only are variation steps in the building chain)! Therefore better globally leave this setting to false, but pass an individual options array into any image sizer method where appropriate (width(123, $options), height(123, $options), size(123, 456, $options)) with this enabled. Example: <?php // this create a jpeg AND a webp varition with 900px for the 2x parts $imageX2 = $page->image->getCrop('default')->width(900, ['webpAdd' => true]); // this reduces the 2x variation to the half size for 1x, (jpeg AND webp at once) $imageX1 = $imageX2->width(450, ['webpAdd' => true]); // now, as you have set $config->webpOptions['useSrcExt'] to true, // every webp variation simply has to get a trailing ".webp" to the jpeg URL: ?> <source type="image/webp" srcset="<?= $imageX1->url . '.webp' ?> 1x, <?= $imageX2->url . '.webp' ?> 2x"> <source type="image/jpeg" srcset="<?= $imageX1->url ?> 1x, <?= $imageX2->url; ?> 2x"> Given that the issue you encountered is located in the files / images sub module for webp, the auto refresh now should be working, as you use the older, (but clumpsy) method in the base imagesizer engine. Have not tested this for quite a few (master)versions, but hopefully it is still true. ? PS: De hartelijke groeten aan de naburige stad! ?

ProcessWire 3.0.165. PHP 7.2, 7.3 and 7.4 Tried webp like this but it slows down the pages for about 10 seconds and more. Tried cache, same result. <?= $page->images->eq(0)->size(500,300)->webp->url;

http://littlesvr.ca/apng/gif_apng_webp.html This guy put animated WebP to test with somehow disappointing results. Is the test flawed? What are your experiences?

For those who just want to let users upload WEBP format and are looking for a workaround, here is a simple module that converts WEBP to JPG on upload: I wonder though... how is it that the user acquired the WEBP image in the first place? Surely they didn't just pinch it off somebody else's website... 🤔

@horst @howdytom Hi, same here. I empty the variants list. Original formats gets deleted, webp files remains in the asset folder. In my case, wether the image field is placed in a RepeaterMatrix (v5, latest) or is a single PW Field. It makes no difference. This is a big drawback. In my current project there were a buch of files corrupted on creation (webp). Which causes strange behaviour in google chrome. Inspected this a couple of hours,- until i found out the webp files won't get deleted physically form the asset folder. And so never being recreated. Deleting them manually solves the problem. But iterating through all assets folders by hand i cannot afford. Get rid off them with a script seems the way to go... While debugging i tried out all possible execution markup and calls as i assumed somethings wrong with my integration/code. But this was not the case. All scenarios (s. below) works fine since it turned out the only problem were the remaining webp files. PW 3.0.192 dev, GD lib image sizer Engine. @horst If there is anything i can do to help further exploring the behaviour, please let me know. Excerpt: With $config->useWebP = true; , lazysizes <?php $options = array( 'upscale' => false, 'cropping' => 'center' ); $page_image_palm = $page->image_head->size(480, 640, $options); ?> <picture> <source class="" media="(max-width: 480px)" data-srcset="<?= $page_image_palm->url; ?>" alt=""> //... <img class=" lazyload" data-srcset="<?= $page_image_palm->url; ?>" alt=""> </picture> Excerpt: With $config->useWebP = false; / Markup with default API call like in https://processwire.com/blog/posts/webp-images-on-an-existing-site/ <picture> <source class="" srcset="<?= $page_image_palm->webp->url; ?>" type="image/webp"> <img class="" src="<?= $page_image_palm->url; ?>" alt=""> </picture> And some other calls in between...

ProcessWire offers a few solutions to manage WebP formats including the Class "TextformatterWebpImages", but there is no solution that works for me with CloudFlare. I'm trying to convert CKEditor all images output to WebP using the HTML <picture> Tag. By default CKEditor generates this code when adding an image <img alt="Jellyfish" class="align_center" width="625" src="/site/assets/files/2581/jellyfish-aas.625x0-is.jpg"> I can convert the CKEditor images to WebP adding the imageSizerOptions to the config.php $config->imageSizerOptions('webpAdd', true); But how to convert the output of all images inside CKEditor after "echo $page->textfield" to look like this: <picture> <source data-srcset="/site/assets/files/2581/jellyfish-aas.625x0-is.webp" type="image/webp" /> <img alt="Jellyfish" class="align_center" width="625" data-src="/site/assets/files/2581/jellyfish-aas.625x0-is.jpg"> </picture> This script works and can convert it function webp_picture_fix($content){ preg_match_all("/<img(.*?)class=('|\")(.*?)('|\")(.*?)src=('|\")(.*?)('|\")(.*?)>/i", $content, $images); $i = -1; if(isset($images)){ foreach ($images as $key) { $i++; if(strpos($images[3][$i], 'align_center') !== false){ $slika_ekstenzija = $images[7][$i]; $sewebp = preg_replace('/\\.[^.\\s]{3,4}$/', '', $slika_ekstenzija); $webp_slika_src = $sewebp.".webp"; $replacement = '<picture>'."\r\n".'<source data-srcset="'.$webp_slika_src.'" type="image/webp" />'."\r\n".'<img'.$images[1][$i].'class='.$images[2][$i].$images[3][$i].$images[4][$i].$images[5][$i].'data-src='.$images[6][$i].$images[7][$i].$images[8][$i].$images[9][$i].'>'."\r\n".'</picture>'; $content = str_replace($images[0][$i], $replacement, $content); } } } return $content; } but there are also errors PHP Notice: Undefined offset: 3 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 4 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 5 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 6 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 7 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 8 in /home/cg/root/4517254/main.php on line 18 PHP Notice: Undefined offset: 9 in /home/cg/root/4517254/main.php on line 18 Any suggestion on how to fix it or use a different approach to the problem?

Hi @elabx, Apologies it has taken a while to get back to you. From what I've been able to determine, the browser selects the first <source> in the list in the absence of media queries. In this case the webP version would always be selected as it comes first. I've added a couple of things that can help with the issue. The first is the ability to disable the render() extensions, falling back to the default Pageimage:render() method. This is done by passing $options as false. Here's an example, where if the webP image url isn't actually webP due to it being larger it uses the default render(). <?php echo $pageimages->each(function($pageimage) { return strpos($pageimage->webp()->url, '.webp') === false ? // If the webP url is not webp $pageimage->render(false) : // Disables the PageimageSource::render() extensions $pageimage->render(); }) The second is a similar option to the $config->webpOptions option 'useSrcUrlOnSize'. If this is enabled, the module checks to see if the webP url is actually webP (as in the example above) and if it is not (e.g. if it is a .jpg), then it disables webP for that image, which in turn disables the picture option: <?php echo $pageimage->render([ 'useSrcUrlOnSize' => true, ]); This takes the module to v 1.0.2, still in beta. Cheers, Chris

With method 2 htaccess should rewrite it from webp to jpg shouldn't it? Assuming that is what you're expecting it to do, I found the example htaccess code didn't work for me. But I found that the code below did work (of course YMMV). RewriteCond %{HTTP_ACCEPT} !image/webp RewriteRule (.+)\.webp$ $1.jpg [T=image/jpeg,E=REQUEST_image]

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

When creating image variations, is there a way to suppress the creation of the variations in the original image format and only create the webp format? I can currently see (in PW 3.0.210) that a call to $image->width($width)->webp first creates a variation in the original file format. Is this a necessity? I only really need the webp variations, and creating unnecessary variations is time-consuming and takes up disk space.

Hello, everyone, I have been experiencing an issues with PW ImageResizer. It usually works quite well but for images with lots of dark areas it seems to degrade the image. Looking through the forum and trying out different settings I came close to what I need but the colours are still off... Here is the issue: Original: Converted by ImageResizer to JPG and WebP (WebP is slightly worse): The settings I have are those: array('upscaling' => false, 'cropping' => false, 'quality' => 100, 'hidpiQuality' => 90, 'sharpening' => 'none', 'defaultGamma' => -1); I have also tried: – Changing the color space to RGB from sRGB in the ImageSizerEngineMagick.php but this didn't work as expected after I read more about it. – Converted successfully, without any loss in quality, with my local imageMagick. Probably it's a newer version? Anyways, my question is is this known issue, can something be done about it and if not—can I just use the original image and add a toggle switch on the client side?

Let me try.. perhaps I am not seeing the forest for the trees.. Given is this syntax for responsive images. <picture> <source sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.webp 200w, image.400x0.webp 400w, image.800x0.webp 800w, image.1200x0.webp 1200w, image.1600x0.webp 1600w, image.2000x0.webp 2000w" type="image/webp"> <img src="image.400x0.jpg" alt="A rubber duck" sizes="(min-width: 640px) 60vw, 100vw" srcset="image.200x0.jpg 200w, image.400x0.jpg 400w, image.800x0.jpg 800w, image.1200x0.jpg 1200w, image.1600x0.jpg 1600w, image.2000x0.jpg 2000w"> </picture> 1. In order to reach this I create an array for the srcset. If I go through the variations for each image on a page <?php $variations = $image->getVariations($options = ['info' => true]); the default thumbnail is included, not what I need or want. I create the variations that I want for the particular site and do so with particular ImageMagick commands when it comes to encoding and compression. If the default thumbnail is included in the srcset array with different ImageMagick commands it not only messes with the array (including an item that is not supposed to be there) but also "dilutes" the quality of the outcome. 2. Now would the default thumbnail always have the same filename 0x260 or 260x0 I could easily single this out of my srcset array. Since this is not the case I cannot use the default assets -> files - page ID folder to get all the images for that page and then create a srcset array from it. So this means, in order to be able to use the image field and have a nice UI for clients.. a) I need to work in a custom folder that only mirrors the original files uploaded regardless of the variations PW might or might not create b) in such a custom folder I need to create my exact srcset array as well as image variations I want/need without the default thumbnail c) such variations created in a custom folder need to adhere to the PW nomenclature so that they can be seen in the "Variations" UI of the image field d) while also making sure these variations are later copied over to the assets -> files - page ID folder in order for them to come up in the "Variations" UI of the image field. Well this also won't work since as soon as I copy my variations back over to the assets -> files - page ID folder they are mixed with the default thumbnail. This not only then gets included in the "Variations" UI of the image field but also leaves a sheer amount of duplicate content on the server. One "custom" folder inside the assets -> files - page ID folder that is used to create a clean srcset array and the default assets -> files - page ID folder that has all variations, including the default thumbnail as well as, like you said, more variations that modules added later on might or might not create. Especially this "might or might not" scenario is something I cannot support. Let's have a look at this way of creating a srcset array for jpg. <?php if ($page->images) { $variations = $page->images->getAllVariations(); echo '$variations'; dump($variations); // This however does not return more info on the single variation // So you need to go one level deeper foreach ($page->images as $image) { // ######################################################## // Make jpg srcset array ################################## // ######################################################## dump($image); $variations = $image->getVariations($options = ['info' => true]); dump($variations); usort($variations, function ($a, $b) use ($variations) { if ($a == $b) { return 0; } // Compare the values of the 'width' key to each other and sort them // Sort from largest to smallest > and from smallest to largest with < return $a['width'] > $b['width'] ? 1 : -1; }); echo '$variations'; dump($variations); // Remove first element from the $variations array. // http://php.net/manual/en/function.array-shift.php // That first element holds the default variation/thumbnail created by ProcessWire $removedDefaultThumb = array_shift($variations); // this will just output the first element/the removed element dump($removedDefaultThumb); // this will now hold all the custom created variations as needed/wanted without the default 0x260 dump($variations); $srcsetJpg = array(); foreach ($variations as $variation => $value) { array_push($srcsetJpg, $value['url'] . ' ' . $value['width'] . 'w'); } echo '$srcsetJpg'; dump($srcsetJpg); } Quite clear, if the default thumbnail a) is not the first element of the array, the srcset array is messed up b) is later replaced by another variation included through a module added later on, the srcset array is messed up c) does not have the 0x260 or 260x0 nomenclature (one could try and single it out through that), the srcset array is messed up Now, let's move over to the webp srcset array. 1. webp files cannot be created by PW at the moment, support for those is in the pipeline, however when that might surface is not clear. Sure there is Horst's patch one can use so that the webp file format is accepted by PW. 2. webp files or variations therefore need to be created in an external process. If this is to be automated for clients in the background one needs to hook the PW site up to something like this https://github.com/rosell-dk/webp-convert-cloud-service in order to first of all obtain webp files and their variations. 3. Since webp files are not supported by PW they also do not show up in the "Variations" UI of the image field. There is no way know to me at the moment to even include them there to have a nice visual representation of what variations for an image exist in fact. Sidekick, at the moment the "Variations" UI of the image field also does not sort the variations by width or height keys but by filename resulting in a list that is not ordered. 4. Let's assume somehow the webp files and their variations are created with an external service and this is automated for the client. This process needs to make sure that a) only ever the original jpg files uploaded in the assets -> files - page ID folder are converted and then copied (not moved) to the clean custom folder in order to get a clean webp srcset array from there b) the amount of webp variations exactly match the amount of jpg variations for that original jpg, but not in the assets -> files - page ID folder but inside the custom folder, as again the contents of the default folder might be touched/edited/overwritten by modules added later on that "might or might not" introduce further variations 5. Since neither the original jpg or its variations are added to the db and unfortunately the original jpg also does not have a key, i.e. "original", inside the result of getVariations($options = ['info' => true]) there is no clear way to obtain that original file and its variations to then be able to create the exact webp variations of those images. In short, at least to me, it appears that obtaining a clean way to show responsive images that use the above syntax is/will be quite some work if one wants a solid approach to this. Last not least, creating variations in the frontend times out, hooking into the process in the backend is fine, albeit I am also, at times, facing timeouts there when using large images. Telling the client to create "optimized for web variations" before uploading images is, at least for me, out of the equation. So yeah, perhaps all these points are a result of me not understanding how PW handles a proper responsive image workflow that results on the above responsive image syntax. If that is the case and you or anyone else here has a simple and solid solution, well that would be great!! I would really love to start coding up some nice websites with PW instead of dealing with how I can get past the stage of creating responsive images. And no, I don't really want to divert from the syntax for responsive images given above. https://caniuse.com/#feat=webp just being one of the many reasons. For what it's worth here is how ideally I like to go about making the webp srcset array for each image on a page.. <?php // ######################################################## // Make webp srcset array ################################# // ######################################################## // http://cheatsheet.processwire.com/page/built-in-fields-reference/page-id/ dump($page->id); $pageId = $page->id; // Then make the page specific assets/files/$pageId url out of it. $pageWebpBaseUrl = $config->urls->files . $pageId; dump($pageWebpBaseUrl); // => "/site/assets/files/1016" $pattern = '!.*' . $pageWebpBaseUrl . '!'; $replacement = $pageWebpBaseUrl; // Make an empty array that will hold our webp srcset. $srcsetWebp = array(); foreach (glob($pageAssetsFilesPath . '*.webp') as $filename) { echo '<pre>'; echo "$filename size " . filesize($filename) . "\n"; echo $filename; $filenameSize = getimagesize($filename); dump($filenameSize); // Looking at the dump you can see that the width of the image // is always at key/index [0] of the array. dump(getimagesize($filename)[0]); // Turn the filename into the url for the webp image $webpUrl = preg_replace($pattern, $replacement, $filename); dump($webpUrl); echo '</pre>'; array_push( $srcsetWebp, array( 'url' => $webpUrl, 'filename' => $filename, 'width' => $filenameSize[0], 'height' => $filenameSize[1], ) ); } dump($srcsetWebp); usort($srcsetWebp, function ($a, $b) use ($srcsetWebp) { if ($a == $b) { return 0; } // Compare the values of the 'width' key to each other and sort them // Sort from largest to smallest > and from smallest to largest with < return $a['width'] > $b['width'] ? 1 : -1; }); echo '$srcsetWebp'; dump($srcsetWebp);

Hi, after the update from the 3.0.123 to the 3.0.164 I have some problem: The website start to be really slow and the server often go in times out with error 500. The different in performance was about 5/6s of TTFB. I try a lot of different things to recover speed and no longer have the error. In the end we went back to the previous version and everything worked better. On the 3.0.164 version I notice this error that maybe they can help to understand the reason for the problem with the update: Analyzing the site with the help of the server provider we found that: the index page make a lot of executions, was 38737 in 1 day. This is to very much for the traffic that we have, in the same day our IP is run 23206 call, that look impossible. I'm not sure the problem is about those things, I also the server use nginx, maybe could be this. At moment we will keep using the 3.0.123 version, but I would like to make the upgrade to use the new API. Someone can help me to understand why the site has become slow? UPDATE I tried to load version 3.0.148, but still I notice a slowdown of the site. The TTFB grow from 2.8 to 6.3 Someone know if there is a way to use the webp format for version 3.0.123 as well?

hello jürgen, thanks a lot for your work! while getting 5 spam mails during the first 12 hours of having my form online (even using honey pot option) i decided to enable a captcha. but that doesn't show! PHP 8.1.22 processwire 3.0.224 frontendforms 3.1.45 phpinfo(): GD Support enabled GD headers Version 2.3.0 GD library Version 2.3.0 FreeType Support enabled FreeType Linkage with freetype GIF Read Support enabled GIF Create Support enabled JPEG Support enabled PNG Support enabled WBMP Support enabled XPM Support enabled XBM Support enabled WebP Support enabled BMP Support enabled TGA Read Support enabled Directive Local Value Master Value gd.jpeg_ignore_warning 1 1 the HTML output is: <div class="form-control captcha" id="contact-captcha-inputwrapper"> <div class="image-wrapper"> <img class="captcha" alt="Captcha" src="/captchaimage.php?formID=contact&amp;cat=text&amp;type=SimpleMathTextCaptcha" id="contact-captcha-image"></div> <div class="reload-link-wrapper"> <a class="reload" href="#" title="Click to load a new captcha" id="contact-reload-link" onclick="reloadCaptcha('contact-captcha-image', event)">Reload image</a> </div><input id="contact-captcha" name="contact-captcha" type="text" class="input" required=""> </div> any idea? edit: an error 500 is reported for captchaimage.php

Hi, what I'm doing is this: <picture> <source srcset="<?php echo $page->section_three->main_img->first()->size(396,710)->webp->url; ?>" type="image/webp"> <img class="p_absoulte pp_block" src="<?php echo $page->section_three->main_img->first()->size(396,710)->url; ?>" alt=""> </picture> and for some reason it sometimes becomes this: <picture> <source srcset="/site/assets/files/1057/sektion3_bild-1.396x710.png" type="image/webp"> <img class="p_absoulte pp_block" src="/site/assets/files/1057/sektion3_bild-1.396x710.png" alt=""> </picture> It seems to be related to ->size(). When I don't use ->size() the webp Url is correct. I'm using the image-field inside a Fieldset(Page). Could that be a problem too? I just increased the output size by 2px and voila the webp url comes up. I deleted all variations (webp variation is present in correct size) changed it back to the original size and again: a png url. I also tried to rename the image and load it up agian. ...same behavoir. Thanks in advance guys

@netcarver Using PW 3.0.210 and nothing special in .htaccess other than ProCache directives, https only and <IfModule mod_mime.c> AddType image/webp .webp </IfModule> Strange that it only happens on small images. No problem at all on larger image file sizes. I changed the default image quality from 90% to 100% in case that made the file invalid but no difference. All PHP image processing modules seem OK. As for ModSecurity, yes it's on a shared host that has ModSecurity. That's been a nightmare on many occasions for other things. I have the web host on speed dial. Good call to check that one.

$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(); ?

The core InputfieldImage does not support webp format.

What I've done so far, is a small implementation of webp-convert. Currently without a ProcessWire specific module or something, but that's planned. Just added a file called webp-on-demand.php in the ProcessWire root directory with following content: <?php // docs https://github.com/rosell-dk/webp-convert require 'webp/webp-on-demand-1.inc'; use WebPConvert\WebPConvert; $docRoot = rtrim($_SERVER["DOCUMENT_ROOT"], '/'); $requestUriNoQS = explode('?', $_SERVER['REQUEST_URI'])[0]; $source = $docRoot . urldecode($requestUriNoQS); $destination = $source . '.webp'; // Store the converted images besides the original images (other options are available!) $options = [ // Tell where to find the webp-convert-and-serve library, which will // be dynamically loaded, if need be. //'reconvert' => true, 'require-for-conversion' => 'webp/webp-on-demand-2.inc', 'quality' => 'auto', 'max-quality' => 75, 'fail' => 'serve-original' // see https://github.com/rosell-dk/webp-on-demand/blob/master/docs/api.md for more info ]; WebPConvert::convertAndServe($source, $destination, $options); Then in the folder webp the two on-demand files from here. After that I added following to the .htaccess: <IfModule mod_rewrite.c> RewriteEngine On # Redirect images to webp-on-demand.php (if browser supports webp) RewriteCond %{HTTP_ACCEPT} image/webp RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^(.*)\.(jpe?g|png)$ webp-on-demand.php [NC,L] </IfModule> AddType image/webp .webp And that's it. If the browser supports webp, all requests of .jpg and .png are redirectet to the webp-on-demand.php which desides if it needs to convert the image or serve the already converted one. A small caveat: the standard installation of Plesk has no webp support included, so on webservers with Plesk you either need to wait for their implementation or compile it yourself.

Hello, I was originally going to include this as part of my forthcoming AdminStyleChroma module but decided to roll it out as its own module. https://github.com/solonmedia/ImageColorThief Please check out the readme for a deeper explanation - but the short version here for now: This module adds two new methods to the Pageimage class, allowing you to extract the main dominant color or a palette of prevalent colors from an image. You can use the entire image to evaluate color dominance, or you can use a select swatch from the image based on inset rectangles from the edges, blocks at each corner, or a swatch centered on the focus point if you choose to use it. You can also select the granularity of the quantization to get more accurate color results. This is not an eyedropper algorithm - the colors are close approximates. Great if you have color schemes you'd like to coordinate with the headliner or seasonal images, or if you'd like to be able to sort a gallery of images by dominant color, etc. Looks real nice, for example if you are running a ken burns style image fade background and the images are sorted by a channel, etc. How to sort them? Ugh that's something I haven't tackled - yet: https://www.alanzucconi.com/2015/09/30/colour-sorting/ It works on JPG, GIF, PNG and WEBP images. It outputs RGB, HEX, RGB Integer, raw Array with R, G, B elements or an object. Once I've got myself registered and whatnot I'll submit it to the Modules Directory. Installs from zip for now: https://github.com/solonmedia/ImageColorThief/archive/refs/heads/main.zip I'd consider it Beta - the underlying libraries are pretty stable but I'd like to run a few more tests on input. Let me know if you have any questions/thoughts.

Using PNG compression for pictures might generate large files. Even with your black gradient try to export the original image as JPEG instead. The file size should be considerable smaller for all variations including webP files.

Hi @horst thanks for getting back! I guess I have a very specific use case. My client uses a lot of gif’s which are bloating the front end… been migrating most images to webp and found that webp also does animation. Did a quick test and found a webp animation was roughly 10x smaller than the small gif. woudl love to allow my clients to upload and view in the admin as they do a lot of arranging of images. However, encoding an image to webp doesn’t keep any animations on the server (also the quality is worse going from giff to webp instead of jpg slides to webp). I guess I can’t see any reason why if presented with a webp upload the image field couldn’t just display as is in the backend… or maybe toggle this on in settings?

Is anyone here using WEBP as their output image format and what is your server / environment setup? I know there's support for it in PW lately and decided to investigate. Found it quite difficult to do this on a practical level. IE My current VPS is Cent OS 6 and Plesk and unless I'm wrong, WEBP is not supported by either. Which host and setup are you on that allows you to run WebP? Cheers

Its copied on the bottom because its an example of a feature not finished on another (not really) WIP module. it does what you are talking about. Copy image from another field, or from a screenshot, it doesnt matter, I understood you was talking about « clipboard ». The specific reason is as you are limited on mimetypes when working with the clipboard write api, in the example above it render the blob in a canvas, on différent format, including webp. Voila 🙂

This week we’ll take a look at 3 different WEBP image strategies that you can use in ProcessWire 3.0.132+. Then we’ll dive into a major update for the Google Client API module, and finish up by outlining some useful new updates in FormBuilder— https://processwire.com/blog/posts/webp-images-and-more/