horst

@Tom. Many thanks for your feedback! And, uhm, - GD does not use the compressed jpeg for webp creation, but currently IMagick does. But this is not intended and I locally have a version that uses the uncompressed src variation for webp creation. I will finalize this and commit an update to the test branch later this evening. So the intended usage is that you can define independend quality settings for jpeg and webp, and both final variations will be created from the uncompressed variation bitimage. ["quality" => 80; "webpQuality" => 90] If you simply want to test out GD-Lib when IMagick is installed with higher priority, you can pass the param "forceEngine" with the options array to the size method: $options = [ 'forceEngine' => 'ImageSizerEngineGD', // ImageSizerEngineGD | ImageSizerEngineIMagick 'forceNew' => true, 'webpAdd' => true, 'webpQuality' => 90, 'quality' => 80, 'sharpening' => 'none' ];

I have sent a pull request on github for webP support in the core: https://github.com/processwire/processwire/pull/141 Explanation of its usage: I implemented two new options for the imagesizer that can be set globally in the site/config.php or can be passed within an individual options array to any size-method: $options = [ "webpAdd" => true, // boolean, if true, an additional webp variation will be created "webpQuality" => 80 // integer range 0 - 100, 100 is best ]; This creates an additional webp variation file besides the regular JPEG, PNG or GIF variations. In the template files you have two new image properties to work with the webp variation: $image->hasWebp; // boolean, true indicates that a webp variation is available for that image variation ?> <img src="<?= $image->srcWebp ?>" alt="" /> So we can create conditional markup like in this example: $image = $page->images->first()->size(300, 300); ?> <picture> <?php if($image->hasWebp) { ?> <source srcset="<?=$image->srcWebp?>" type="image/webp" /> <?php } ?> <source srcset="<?=$image->src?>" type="image/jpeg" /> <img src="<?=$image->url?>" alt="Alt Text!" /> </picture> The pull request and my test branch are based on this weeks pw dev branch. So if someone want to test it, please grab a copy, play with it and report back here. I don't know what timeline @ryan has and what parts need to be modified / rearanged, etc. Maybe the property names or the option names will be changed, but I think the main functionality will be close to that in the current test branch. ----- And here are a filesize comparision with different quality settings and with both engines, GD-Lib and IMagick: EDIT: An approach without conditional markup for webp comes from @arjen see lazyload. ...

Yes, once the webp variation is created and cached, it only will be served, but the PHP engine is invoked for every image call. This makes a difference compared to simply serve a static file directly by apache on sites with lots of images, like archives. Thats why I said it is a nice solution for sites with smaller amounts of images. For example: I maintain sites with 60k+ images, that presents 100 thumbs per page and have infinite scrolling, that may result fastly in 100 to 1000 thumbs on a single page view. There it makes a difference, if apache serves 1000 thumbs from static files, or if the webserver has to invoke 1000 times the PHP engine for serving static files. And multiply this with a decend amount of simultaneous visitors of the site, I bet you too definetly want to avoid invoking the PHP engine for serving static image files.

Hi @joshua, a nice and global solution. But want to say that invoking the PHP engine for "every" image on a website may result in to much serverload. This in mind, it is a nice solution for sites with a smaller amount of images.

@Tom. I have downloaded all four images and what you are saying, at least how I do understand it, seems not to be completly valid. What exactly was the source for what variation, as you said without resizing? (The original is larger than the others) I found these images: The original image is 4x larger (in pixel) than the compared variations. And it only has 157k, whereas the other have 300k. The original image is from a source of 1920x1080 resized in Photoshop CC2017 to 1500x1074 px and is very strong compressed. That is NOT a useful choice for a master image! Masterimages should be saved in 100% quality, (or quality 12 in Photoshop), in every single item of a workflow chain. Once you saved with lesser quality, you damaged the image, regardless if you later on save it with better quality. When I save your original image in Photoshop with quality 12, I get a 427k image file, not 157k. Another ProTip is: work with images in 16bit colordepth all the time, best in a larger color spectrum like AdobeRGB, not sRGB, use PSD or TIFF as your local master image, and only transform from this local master image to every desired target format according these steps, respecting the chronology: - 1) resize to target dimensions - 2) transform into target color space, (AdobeRGB into sRGB, or AdobeRGB into CMYK, etc) - 3) reduce the color depth from 16 bit to 8 bit, (the last step always!) - 4) save into your target fileformat, for ProcessWire (online) master images, with the max quality in JPEG. From these (online) master images you can create very good results with the GD-Lib and with the IMagick-Lib. If you do not resize the original or only resize a very small value, you may set the sharpening property to "none". Also when using the GD-Lib, you may set the "defaultGamma" to -1. Experimenting with this two properties should be enough to render good results for all possible usecases. At least this are my experiances. Can you tell me why the original is compressed so strong? And do you have an uncompressed version too? (uncompressed means: never ever compressed in its total live workflow chain!) ------------ There definetly is a difference when using the same sharpening values with GD-Lib and IMagick. This is due to the fact that IMagick internally already uses a sharpening algorythm when resizing images, and GD-Lib completly lacks about this feature. Looking at PWs image resizing history, there first only was GD-Lib without sharpening, resulting in blurry images. Than we introduced a sharpening algorythm with four available values: none | soft | medium | strong, (defaults to soft) A long time later, we introduced the ImageMagick-Lib with all the same params available as for the GD-Lib. At this time my thinking was, when switching from GD to IMagick, one may switch from medium to soft, or from soft to none in the site/config.php file, as it is a global decision what image library to use. But a review / rework of the used algorythmvalues in the core libs is possible, so that we maybe will have nearly no differences between IMagick none and soft, but keep the currently used differences within the GD-Lib.

Oh, yep. It is a left over from debugging. many thanks for testing and reporting back.

Hi @androbey, I have created a dev-branch on github with the requested functionality. Please can you try it out and give some feedback? https://github.com/horst-n/WireMailSmtp/tree/5600cb0230531327438d6a333b2c8a3eb29cc08d There is also a new $mail->debugSend() method available that you can use instead of the regular $mail->send() method. With calling the debugSend() method in a template file you will get detailed log information like this: C STARTTLS S 220 2.0.0 Ready to start TLS Starting TLS cryptographic protocol TLS started: STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT

Hi @androbey many thanks for pointing me to this. I add it to my todo list with an urgent flag.

Maybe this helps a bit to test and understand? https://stackoverflow.com/questions/10909911/php-setlocale-has-no-effect

Also worth a look for new projects:

@ryan, I want to test the new blacklist support with WireMail and WireMailSmtp, but on both configurations I get error of missing method isBlacklistEmail() Error: Exception: Method WireMail::isBlacklistEmail does not exist or is not callable in this context (in G:\VHOSTS\_PW-REPOSITORY\wire-3.0.latest\core\Wire.php line 519) (I took the latest DEV branch 3.0.130 this morning) My code is like in the blog example: $mail = wireMail(); $to = ['info@nogajski.de']; $result = $mail->isBlacklistEmail($to, [ 'why' => true ]); if($result === false) { echo "<p>Email address is not blacklisted</p>"; } else { echo "<p>Email is blacklisted by rule: $result</p>"; } Also if I use the to() method of the WireMail base class with WireMailSmtp, I need to adapt the cc() and bcc() methods of it to support it too.

WOW! Many thanks Charles.

Hey @WillyC, nice to read from you again. (Long time no see.)

If you need the Croppable Image Field, you may install the CroppableImage3. But with the newer PW versions there is the feature focuspoint with or without zoom. If you not already know it, it is well worth a test.

and with AdminOnSteroids installed in the backend, you can switch the admin language on the fly and independent from your selected language in the user profile: