Search the Community

Tested on PW 3.0.148 on the image field and the site is able to upload and present the webp image on the front end, but in the admin I get a blank transparent image with the warning [image url].webp - not a supported image type Just wondered if the image field in new PW versions had a fix for this or not?

Hello all, I am trying to enable webp support for images, but i am having some problems with it. Somehow i have uploaded some images but i cannot delete them from field, when i try to delete it is log me out of processwire. See attached screenshots. P.s my server supports webp images. On my server logs i have only these errors: [Mon Jun 01 21:57:30.399211 2020] [fcgid:warn] [pid 26424] [client 162.158.88.107:22838] mod_fcgid: stderr: #4 /public_html/wire/core/ProcessController.php(337): ProcessWire\\Wire->__call('executeEdit', Array), referer: /setup/language-translator/edit/?language_id=1154&textdomain=wire--modules--languagesupport--languagesupport-module&filename=wire/modules/LanguageSupport/LanguageSupport.module [Mon Jun 01 21:57:30.399219 2020] [fcgid:warn] [pid 26424] [client 162.158.88.107:22838] mod_fcgid: stderr: #5 public_html/wire/core/Wire.php(380): ProcessWire\\ProcessController->___execute() setup/language-translator/edit/?language_id=1154&textdomain=wire--modules--languagesupport--languagesupport-module&filename=wire/modules/LanguageSupport/LanguageSupport.module [Mon Jun 01 21:57:30.399226 2020] [fcgid:warn] [pid 26424] [client 162.158.88.107:22838] mod_fcgid: stderr: #6 /public_html/wire/core/WireHooks.php(823): ProcessWire\\Wire- in /public_html/wire/modules/LanguageSupport/ProcessLanguageTranslator.module on line 634, referer: /setup/language-translator/edit/?language_id=1154&textdomain=wire--modules--languagesupport--languagesupport-module&filename=wire/modules/LanguageSupport/LanguageSupport.module Can anyone point me to right direction? Thanks in advance

When generating a WebP image from the originally uploaded file (not as a result of using the 'size()' method), I see the following file error in the logs: unlink: Given filename is not a file or link: /site/assets/cache/WireTempDir/.PFM0.24368300T1680350648RozEvGgLCG8JdZGUwLM/0/cookies.960x0.png-tmp.png Note that the actual original filename is 'cookies.png' -- but the error message appears to show PW has attempted to use a (non-existant) variation. The simplified code I'm using in the template (it will eventually be a srcset, hence the small 'width' to large file): // Cut code fetching the $img itself echo '<img src="' . $img->webp->url . ' " width="300">'; The strange this is, that the correct WebP image *is* generated and subsequently served ('cookies.webp'), it just throws a hissy fit while doing it (once generated no error is shown). This error does not occur when generating WebP images from variations. Is this a known issue, should I submit an issue on Github?

WebP to JPG Converts WebP images to JPG format on upload. This allows the converted image to be used in ProcessWire image fields, seeing as WebP is not supported as a source image format. Config You can set the quality (0 – 100) to be used for the JPG conversion in the module config. Usage You must set your image fields to allow the webp file extension, otherwise the upload of WebP images will be blocked before this module has a chance to convert the images to JPG format. https://github.com/Toutouwai/WebpToJpg https://processwire.com/modules/webp-to-jpg/

Hi all, I'm searching for Alpha/Beta tester of the new rewritten Croppable Image module. I opened a new repo on Github, with the name CroppableImage4: https://github.com/horst-n/CroppableImage4 It is a rewrite of the CAI3. I dropped all internal image manipulations, to be more future safe. Now I delegate all this to the parent core image fields methods. To be able to do this, I need to change some things and the module is no longer backwards compatible. A) For the alpha & beta testing, there is a new crop method name: $image->getCrop4(), this may be changed later to the legacy $image->getCrop() method. But for the testing period to avoid conflicts with CAI3, it is named getCrop4(). <- OBSOLETE, see the next post here in thread B) With the first param, you pass the cropname into the method. Optionally you can pass image processing options as a second param, like with the core image field. To do this, you may use an array or a selector string. C) You can use every known options param. Width, Height, Size is ignored! If you also want create WebPs in one go, please add "webpAdd" => true to the options array, (or webpAdd=1 to the options selector string)! D) The resulting image variation names will differ from those of the previous version 3! Please refer to the readme of the repo and, maybe compare it against the version 3, if you not already know it. Thats it so far. I have tested it a bit in the last days and haven't found any issues. But it would be nice if some of you can test it too.

One of PW 3.010's major novelty was the introduction of Horst's new image resizing engine that uses ImageMagick. Now I understand that ImageMagick can convert images to Webp, the image format that Google says can reduce image size up to 34% compared to JPEG. Mozilla is apparently adding support to Firefox, and even the Safari team is playing with it, so it looks like Webp is soon going to be available in most major browsers. If Horst's module can be extended to add Webp conversion, that would be a great addition to PW's already very powerful image manipulation arsenal. I'm currently using the free ImageEngine Lite to serve Webp images to supporting browsers, and the results are impressive. I routinely get images that are between 25 and 60% smaller compared to JPEG, with the same visual quality. I would love to eliminate the need to rely on a third-party service though.

Hi, i have implemented htaccess rewrite to our htaccess within section 8. i've followed this instructions and used method 2: https://processwire.com/blog/posts/webp-images-and-more/ I also added a hook to ready.php. The webp format is created and i can hardcode it into our main file. but our htaccess doesnt rewrite the url from png,jpg to webp? Does anyone have an idea?

After enabling WebP support you may notice it can take a long time for ProcessWire to create WebP copies of all images and their variations. For instance, on a site I work on (with over 10k images), it was taking about 1 second per image, ie. more than 3 hours in total.. ? If you are comfortable around the command-line, you can use the cwebp program and this bash script to speed things up drastically. I have built upon this script and got things to work in combination with xargs and find, making it rather powerful for PW's purposes. 1. Save this script as 'convert-webp.sh' (or download the Gist from Github), and follow instructions ######################################################################################################### # # Fast Recursive Images to WebP converter # Customized for ProcessWire CMS/CMF <https://www.processwire.com> # # Author: Eelke Feenstra <dev@eelke.net> # Version: 001 # Based upon: https://github.com/onadrog/bash-webp-converter # # Quick & dirty script to add webp versions to all PNG / JPG / JPEG files inside your PW assets folder # # 1. Set this script to executable: # $ chmod +x convert-webp.sh # # 2. Check if cwebp is installed: # $ cwebp -version # If it is not, install: # $ brew install webp # Or follow instructions https://developers.google.com/speed/webp/download # and change $executable to cwebp's full path # # 3. Run the script directly on a folder: # $ ./convert-webp.sh /path/to/your/folder # ######################################################################################################### # Configuration executable="cwebp" # update this to reflect your installation! quality=90 # change to desired WebP quality ######################################################################################################### converted=0 skipped=0 echo "Entering $1" for file in $1/* do name="${file%.*}" echo "FILE: $file" echo "NAME: $name" # Skip the folder itself.. if [ "$name" = "./." ]; then echo "SKIP: $name" continue; fi if [[ $(file --mime-type -b $name.webp) == image/webp ]]; then echo "FOUND: $name.webp, skipping.." skipped=$((skipped+1)) elif [[ $(file --mime-type -b $file) == image/*g ]]; then echo "NOT FOUND: $name.webp" newfile(){ echo "$file" | sed -r 's/(\.[a-z0-9]*$)/.webp/' } $executable -q $quality "$file" -short -o "$(newfile)" converted=$((converted+1)) fi done echo "Converted $converted, Skipped $skipped" 2. Run to create webp versions of all jpg/jpeg/png images in a given folder (for example the site's homepage) $ ./convert-webp.sh /path/to/processwire/site/assets/files/1 3. And in order to create WebP copies of ALL images inside the /site/assets/files folder, you can run this script. It searches for all directories inside the files directory, and passes these to the convert-webp.sh script using xargs. $ find /path/to/processwire/site/assets/files -maxdepth 2 -type d | xargs -I '{}' ./convert-webp.sh '{}' Tested both on MacOS 12 and Debian

Hi there, When I delete all image variants, ProcessWire does not remove previously generated webP files from the assets/files folder. The variants list is empty. PNG and jpeg images are removed just fine, but webP files are left on the server. This will increase dramatically disk space on bigger projects. How can I automatically clean up webP leftovers on deletion? Steps to reproduce: I am using a ProFields:repeater Matrix with a FieldtypeImage. webP variations are created with $img_1920->webp->url, $img_1600->webp->url ... in a <picture> element. 1. Within the repeater image field, → Variations → Delete checked → close the modal → Save 2. When I go to assets/files/1134/ all png variations are deleted. webP variations are still kept e.g. testgrafik-logodesign.1600x0se.webp, testgrafik-logodesign.1920x1080se.webp 3. When I open again the variations modal → the variation list is still empty, except the original file. 4. However deleting the repeater Item, will also remove all files from assets/files directory. ProcessWire 3.0.165

If using server side resize, a webp version of the uploaded image is automatically created (at least if the uploaded image is larger than the field's max dimensions). But when using client side resize this doesn't happen. Is it possible to have a webp version automatically created while using client side resize (without resorting to creating a variation)?

Hi guys, I’ve recently set up 2 PW installations for using WebP images (following this explanations, strategy 3). Both servers run on identical system configurations and PW versions (3.0.184). While integrating the WebP functionality was no problem at all, I’m massively confused by the results: one server works as expected, the other one does the sheer opposite. Server 1 (the good one): Images total: 326 WebP bigger than JPG: 41 (on average more than 40 %) WebP smaller than JPG: 285 (on average 30–40 %) Server 2 (the bad one): Images total: 862 WebP bigger than JPG: 773 (on average 30–40 %) WebP smaller than JPG: 89 (on average less than 10 %) As far as I know, the quality of the source JPG has an impact on the WebP: highly compressed JPGs may lead to hardly smaller or even bigger WebPs, while the savings with high quality JPGs tend to be more spectacular. Server 1 seems to confirm this assumption (the JPGs with bigger WebPs here are highly compressed 3rd party images) while server 2 ist acting completely strange. The source JPG’s size is around 1.200 x 800 pixel with a moderate compression rate and file sizes ranging between 100 and 500 kB with an average of 250 kB. The JPG quality on server 1 is about the same (regardless the 41 lousy ones), the only difference is their smaller size of 900 x 600 px with an average file size of 150 kB. So I’d consider the WebP use on server 1 as clearly progressive, while server 2 essentially limits itself to fill up the webspace with bigger images that will never appear on a display. Is there any influence on the WebP conversion I might have missed?

WebP image support is great and works fine. But once created I've issues to get rid of all API generated WebP variations. The backend image field variations "Delete" works and I can remove all variations JPEG plus WebP. Image list is clean but all WebP API variations are still stored in file system (for instance files/12345/84.900x675.webp etc). I can only use ImageSizer with temp 'force' option to request fresh WebP variations or have to delete WebP files from folders. No other way so far. Tested with 2 sites and latest master PW 3.0.165. Is there somewhere a "magic button" or config/setup thing to solve my sticky WebP issue?

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? ?

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

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?

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?

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

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?

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

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

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

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/

ProcessWire added WebP image support this year and many have been adopting it enthusiastically in existing projects. In this post we’ll look at a process used for migrating an existing website to use WebP images. We’ll cover everything from preliminary considerations to implementation and testing, with lots of tips and tricks along the way— https://processwire.com/blog/posts/webp-images-on-an-existing-site/

Hello processwire world! Im having a little problem with getting my image in WEBP format. $image = $pages->get('/')->images->first(); echo $image->webp()->url();