horst

Another possibility is to use different names for htaccess files for local development and for live servers. In your local httpd.conf you can set for AccessFilename something like AccessFileName .htaccess.test or AccessFileName .htaccess.local where you can define different settings for local development by keeping the .htaccess file untouched for online server settings.

you may use the new debug info for images. and / or skip the rewrite: /site/assets/files/1/basename.jpg?skiprewrite And: nobody is forced to use it this way. You always can create conditional markup. My goal is to collect different solutions, and with the .htaccess only, to show and discuss a solution that would not need a rewrite for existing sites, or at least, makes the rewrite as small as possible. (change all image variations in markup from .jpg to .webp). EDIT: I think maintainers should know about the fact if they have implemented a webp solution and if so, wich one. If, for what ever reason, someone don't like this solution in a site, he shouldn't use it.

Thanks for testing. And yes, this is right. But for me personally, (and for most of my clients), the main goal is to present pages with text and images on the screen, and not to let the visitors save images for later use. I think, if a visitor need a visual copy of a page, he still can save the complete page with his browser, or he can do screenshots. On photographer sites, the use of images independend from viewing the site / page are often prohibited. There it even should not be recognized that images with filetype jpeg in real are weppys. But that is my personal opinion, and maybe thats not a sufficient reason to include this into the PW htaccess. But it also could be done the other way round: send .webp in markup and let the htaccess directives change this to (png|jpg) if a) the browser doesn't support this, or b) if there is no webp file available. This way round, in a 100% perfect site, all newer browsers would get 100% webp with correct file type. Only older browsers would get jpegs or pngs with file type webp. ?

Please can someone test the .htaccess solution for WebP support in other environments? It is not much work, you don't have to install test branches or anything else. You only need to copy some lines into your .htaccess file and create a single webp image with the tool of your choice. Or if you don't have a converter tool for webp, simply make a copy of a jpeg and rename it with type .webp instead of .jpg. Steps to proceed: Copy the rewrite directives into the top of your .htaccess file Grab any image variation you already have embedded into a PW site, create a webp variation of and save it into the same assets/files/{ID}/ folder. (Maybe you want to invert the colors of the webp copy for better detection!) Create or go to a page where this image should be rendered as jpeg in a regular img tag, and look if the webp copy is served and displayed. (Don't forget to flush browser caches) The .htaccess code: My matched.php for debugging: Examples in Opera with opened Network-Tab, requesting one image that has a webp copy, and requesting the second image that do not have a webp copy: Same page in Opera and old IE11: If we have a wider test case, the chance that this can be embedded into the PW .htaccess file for optional usage (commented by default) would be helpful for many users to support webp with less effort on their sites!

Another update to the PageImage class, comes in handy during the webp work. But it is not only useful for WebP copies, but for everything in regards of experimenting and debugging with images. I added a new method: ->getDebugInfo($options). See examples here: https://biriba.de/pw_pop3/pw_pageimage_getdebuginfo/

@ryan, may I point you to a WebP pull request? https://github.com/processwire/processwire/pull/141 And a ".htaccess only solution" for site wide webp support: https://processwire.com/talk/topic/14236-webp-support/page/2/?tab=comments#comment-184669 ?

Hi @Noboru, is your own ImageSizer written as a pw image rendering engine, or do you use the hooks like in the times before the pw image rendering engines were implemented?

Hi @Tom. the new code is online in my test branch. And following is a test with also the .htaccess solution installed. My template code: <?php $image1 = $page->images->first->size(100, 100, $options); ?> <img src="<?=$image1->url?>" alt="<?=$image1->alt?>" /> <img src="<?=$image1->url?>?skiprewrite" alt="<?=$image1->alt?>" /> <?php $image2 = $page->images->first->size(100, 100, $options); ?> <img src="<?=$image2->url?>" alt="<?=$image2->alt?>" /> <img src="<?=$image2->url?>?skiprewrite" alt="<?=$image2->alt?>" /> The quality settings for the regular variation is set to 10, it is created first in the image engines. The webpQuality was set to 100, and it is created after the regular variation. The following screen first shows the webp copy and due to the "?skiprewrite" GET varname, it shows the (distorted) jpegs at second place. Once with GD and once with IMagick: I really love the .htaccess only solution! With this, you simply can update any existing site by upgrade to the new PW core that include the webp support and running a maintenance script over all image variations to create the webp copies. After that you are done! ?

I have played with a .htaccess only solution to serve WEBP instead of JPEGs or PNGs. This way you can - leave your existing template markup untouched, and the apache_rewrite will - detect if the browser supports WEBP - if a WEBP copy is available for a JPEG or PNG image. Locally it's working out nicely! ? This markup automatically serves a WEBP copy to all browsers that support it: $options = ['webpAdd'=>true, 'webpQuality'=>90]; $image = $page->images->first()->size(300, 300, $options); // this will create a 300x300 Thumb for JPEGs and PNGs with an additional WEBP copy ?> <img src="<?=$image->src?>" alt="<?=$image->alt?>" /> <!-- this will serve the WEBP image to all Browsers that supports it, and the JPEG/PNG to other browsers --> AddType image/webp .webp <IfModule mod_rewrite.c> RewriteEngine On AddDefaultCharset UTF-8 ### Redirect regular PW JPEGs and PNGs to their WEBP image copies, ### if available and if the Browser supports WEBP: ## Does Browser accept WEBP images? RewriteCond %{HTTP_ACCEPT} image/webp ## Is it an existing file? RewriteCond %{REQUEST_FILENAME} -f ## Does a WEBP copy exist for it? RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.webp -f ## With an added GET var or GET value of skiprewrite we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch '*skiprewrite*'" ## With an added GET var or GET value from the PW Page Editor, we do send the original JPEG or PNG RewriteCond expr "! %{QUERY_STRING} -strmatch 'nc=*'" ## Is it a regular PW JPEG or PNG image, stored under site/assets/files? RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.(jpe?g|png)(.*)$ /$1$2$3/$4.webp [L] </IfModule> Adding a GET var or GET value with the string "skiprewrite" added to an image bypasses serving the WEBP copy in favour for the original variation. (Maybe useful for debug purposes!)

@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 higher 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 file format, 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 use cases. At least this are my experiences. 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 definitely 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 algorithm when resizing images, and GD-Lib completely 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 algorithm 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 algorithm values 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: