Jump to content

Search the Community

Showing results for 'webp'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Product Groups

  • Form Builder
  • ProFields
  • ProCache
  • ProMailer
  • Login Register Pro
  • ProDrafts
  • ListerPro
  • ProDevTools
  • Likes
  • Custom Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

  1. Hello @horst, first of all thank you for all your efforts to bring WebP support to ProcessWire. ? I have installed ProcessWire 3.0.132 and implemented this code to almost every image: <?php $image = $image->size(1600, 900); ?> <picture> <source srcset="<?=$image->webp->url?>" type="image/webp"> <img src="<?=$image->url?>" width="<?=$image->width?>" height="<?=$image->height?>" alt="<?=$image->description?>"> </picture> Of course with more variations. This is just an example code. My issue is, that my local MAMP server doesn't support WebP and my webhosting does support it. On the webhoster the WebP variations get generated and everything is fine. But on my local MAMP server, ProcessWire can't generate the WebP variations and tries to generate them on every page load, which leads to a server timeout. I saw a condition $image->hasWebp in your early drafts. Can I use this for environments that don't support or should ProcessWire better not try to generate WebP variations at all, if there is no WebP support? ? Regards, Andreas
  2. 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:
  3. Another very important find I just made that might be helpful for others as well. There is no need to upload a webp version of an image in the admin panel if you have already uploaded the jpg version of it to that page. As long as the webp versions of that image adhere to the variations naming, meaning filename DOT width x height DOT file extension, they will be served by ProcessWire! That is scary but also awesome. Not sure yet. For what I am trying to do though, that is great news. Now I can just pull the jpg variations array, swap the file extension for webp, have my srcset array for webp, done. Well one thing though. With this approach there will be no "official variations" of webp versions in ProcessWire. Meaning one will not be able to work with "variations" in the code or dump them. Ideally it would be great if given the original filename one could add variations of different file types to the same variations array. Something like this if you dump an $image. $image info path url array "variations" jpg image.0x260.jpg image.2400x360.jpg ... webp image.0x260.webp image.2400x360.webp ... png image.0x260.png image.2400x360.png ... In the admin panel, when clicking on Variations for an image, it would kind of be helpful to include an "add variation" button where then users can add variations of different file types to the original image.Perhaps with this approach also different versions of the same image, i.e. a 300x300 version with low quality and a 300x300 version with high quality could be included. But I think this is already possible by just including one more DOT and simply have hq (high quality) and lq (low quality) in front of it. Meaning filename DOT lq DOT width x height DOT file extension and then filename DOT hq DOT width x height DOT file extension. Just me thinking out loud.. and more testing to be done. ?
  4. I too failed to get Strategy 2 working, but this does seem to work for me: RewriteCond %{HTTP_ACCEPT} !image/webp RewriteRule (.+)\.webp$ $1.jpg [T=image/jpeg,E=REQUEST_image]
  5. Hi! I did a recent test and found the file size save from gif to webp was about 10x for comparable look. I tested using teh google CLI as linked above but wondered if it was possible to have the processwire $image->webp() method also produce a animated webp? I'm only getting static images out when tested... do I need to install something else on the server or are we not there yet?
  6. So, for the first time ever, I am trying to use the Webp feature. Alas, no luck. ProcessWire: 3.0.147 PHP: 7.2.19 Webserver: Apache/2.4.35 (Win64) OpenSSL/1.1.1b MySQL: 5.7.24 I used the .htaccess method. I tried with FF + Chrome. I created new images, de-activated Pro Cache. I have added this to site/config.php: $config->contentTypes('webp', 'image/webp'); // seen elsewhere in a forum thread + these lines at the top of my .htaccess: <IfModule mod_mime.c> AddType image/webp .webp </IfModule> Still, no Webp images are generated (assets/files/123/ only has JPG versions) or shown in the browser. The mod_mime Apache module is definitely loaded, and I have restarted the server. What else do I need to check?
  7. @MoritzLost I actually don’t know which component is doing the conversion, both are running on the server. As I usually tend to go the easiest way, I just rely on PW so far: calling $img->webp->url produces a WebP. So I might dive into the deeper areas of the docs as soon as I find a little patience … The mentioned difference between the two servers results from different compression rates of JPG sources, at least that is clarified now.
  8. @rash Do you use Imagick or GD to convert to WebP? For GD, the imagewebp function accepts the quality level as the third parameter. For Imagick, Imageick::setImageCompressionQuality should be the equivalent. Other options can be set with Imagick::setOption, see this post on Stack Overflow. No idea if ProcessWire's image API supports those, check the documentation or read through the source code to find out … Both of those are defined in code, so it shouldn't differ between servers. However, there are some possibilities why it might depend on the server: Different PHP installations with different default settings. Or different PHP versions with different levels of optimization / encoding efficiency. Maybe ProcessWire doesn't use GD/WebP at all, but calls the underlying C-libraries directly. In this case, the default parameters used by those libraries might be different.
  9. @MoritzLost I agree. Unfortunately, it’s the other way round until now: slighty better images with considerably larger file sizes. But I’m working on it ? I already use a picture element with different sources and want to establish responsive image sizes in the next step. And I already know your tutorial and find it pretty helpful – thanks for it! I’m not giving up yet, just had to whine a bit yesterday, because everything appeared so sadly. Regarding your settings proposal: Where could I set quality levels on a shared server with limited access to it’s settings? It‘s indeed annoying me to have either WebP or not WebP without knowing how to affect the result.
  10. 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)
  11. Hi, On desktop everything works fine: Chrome, FF, Edge shows webp On mobile (IOS) nothing works at all: no webp and no fallback jpg/png in no browser PW Version: 3.0.142 .htaccess: AddType image/webp .webp config.php: $config->useWebP = true; $config->contentTypes('webp', 'image/webp'); ImageMagick 7.0.8-25 Cleared cache! Any ideas?? Thank you
  12. 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. ...
  13. Is it just me who don't understand the percentage for the webp generated variation? Original is 311k, webp is 62k, how do I get 80% ? That means webp is 80% smaller than original? And if webp is bigger than original, I get (webp -20%). And while here, how do I delete webp variation?
  14. This means that if I have a src size of 1024px width in my responsive images array and somewhere down the line during work on a site I install a module "xyz" that also does, for any reason, create a 1024px wide variation of the original those might get mixed up or worst case overwritten? So work starts, original.jpg -> original.1024x0.jpg is created. Later during further dev of the site module "xyz" is installed and it also, for any reason that also might not be documented in the module docs, wants to create a 1024x0 variation. Will ProcessWire overwrite the variation created first? Or would the ProcessWire internal code make sure to see "ah, module xyz is installed and it wants to create a variation, but there is already a variation with that filename and 1024x0, so better not touch it!" The implications would be that in the end the responsive image array I want to work with would be mixed up/diluted/changed/affected by images that I did not intend to be used, for any reason. So this really means I have to come up with a way to strictly separate the ProcessWire image workflow from the responsive images array? Or are people just fine with "ok, Ill upload this, whatever happens in the assets folders I don't care, I will just write a responsive image function that refers to those images and their variations, it should be ok.." Perhaps because I am new to ProcessWire it has not "clicked" with me how one can have a tidy/clean/solid way of i.e. producing this responsive image syntax below while also being sure that the images created for it will never be touched/affected/overwritten/changed by either ProcessWire or any future module for any reason. <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>
  15. Hello there! I recently updated my own website - I am a frontend developer living in the northern part of germany. https://www.thumann-media.de The old design has been online since five years (time flies...) and I thought that it was time to make things a bit flashier and include a better showcase of my web projects to give the user a more detailed description of the project features. It's a classic one pager design just for the sake of keeping things as short and simple as possible (I hope the image fits inside this thread). The new version of my site includes a "portolio section" where users get a sneak preview of each project I've been working on recently. It features nice fade-in-out animations powered by aos.js (animate on scroll). Also new is that every project gets a dedicated subpage where I describe some of the unique features that this website offers: I like to have some eye-catchers. I always used the animated wave theme on my website, so why not include a message in a bottle? The animation of the bottle is done via the awesome GSAP animation engine (https://greensock.com/gsap/). This is a super powerful library and I just started diving into the possibilities of this one. Tech Talk: Some of the things I used: - ProFields used for this one (repeater matrix, combo) - Frontend framework is Bootstrap 5. I had a hard time of deciding between Bootstrap and UIKit as my new go-to framework (I am bit biased though because I've been always using bootstrap since version 2). But the grid system alone makes bootstrap so flexible and powerful for me, so I will stick with it for another 10 years I think... - https://github.com/nbcommunication/PageimageSource for image srcsets with webp support - Ajax driven contact form with bootstraps frontend validation - AIOM+ for compressing the assets (CSS and JS) https://github.com/matjazpotocnik/ProcessWire-AIOM-All-In-One-Minify - SEO Maestro - WireMail SMTP AOS.js vs GSAP Which animation library you should use? I discovered the GSAP library a bit too late in the development process, tough. So I am still using aos.js for some animations. AOS has a super small footprint considering its filesize (14 kb, minified) and is super easy to use and super reliable. Whereas GSAP is quite large (71kb, minified) and if you want to make use of scroll triggers you have to include a second library which adds another 40kb. AOS has lots of nice animations which come out of the box. GSAP does not offer this, you have to program those transitions yourself. So you need to spent some time, reading the docs and looking for tutorials! GSAP can do all that AOS can and beyond. If you want to have full control over everything I would advice you to give it a try. So that's all for now. I wish all of you a great weekend!
  16. Hey @horst why is that by design? I don't understand why we should not be allowed to upload webp directly if we want to display webp afterwards?
  17. $config->webpOptions = array( 'quality' => 90, // Quality setting of 1-100 where higher is better but bigger 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) 'useSrcUrlOnSize' => true, // 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? ); Set 'useSrcUrlOnSize' to false?
  18. Today I again bumped into an issue I had last year with creating WebP images: Enabling WebP on another project by setting imageSizerOptions' webpAdd to true immediately resulted in the same behaviour as I had last year: the server simply keeps on creating new variations of images, while they already exist. WebP images are created correctly by the way. Seems to be a bug, can anybody else confirm? I am using PW Master (3.0.165) on MAMP Pro (MacOS 11.2, PHP 7.4.2)
  19. @ryan here is a screenshot with barlow font. Looking good here, (not best but good!) https://biriba.de/pw_pop3/Screenshot_2019-01-08.png Regarding webP, we have had discussions in the forums and at github, plus I have built it into GD already for basic usage. With the current version here, you can add an additional param with the images calls to additionally create a webP image besides the requested variation. With two hooks I'm already using it in test sites: hasWebp and urlWebp. In my markup generation for picture elements (or srcset), if hasWebp is true, I generate alternative webP image src for browsers that do support it. The other cool thing (what I not have tried yet, but should become my favourite usage) is to use it with the lazyload class, that already includes checking for webP alternatives via JS, when enabled. So the only thing to do is to create the webP format besides the requested image. I had planned to finish this during the holidays, but then got two jobs with one deadline 29.12.18 and the other has to be finished this tomorrow. (uff) Here are the links to the discussions: https://github.com/processwire/processwire-requests/issues/1#issuecomment-443164642 https://processwire.com/talk/topic/14236-webp-support/?tab=comments#comment-176944 https://processwire.com/talk/topic/14236-webp-support/?tab=comments#comment-177630
  20. This will not work as @horst correctly pointed out, it will not work with ProCache. I'm looking at the .htaccess method however, it doesn't seem to work if it is running in a subdirectory # Output WEBP image URLs from ProcessWire, but redirect them to the # JPEG or PNG when the browser does not support WEBP. RewriteCond %{HTTP_ACCEPT} !image/webp [OR] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.jpg -f RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.jpg [R=307,L] RewriteCond %{HTTP_ACCEPT} !image/webp [OR] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{DOCUMENT_ROOT}/$1$2$3/$4.png -f RewriteRule ^(.*?)(site/assets/files/)([0-9]+)/(.*)\.webp(.*)$ /$1$2$3/$4.png [R=307,L] .htaccess rules are definitely not my strong point. Though I've noticed %{REQUEST_URI} mentioned. What is the correct way of getting it to work in a subdirectory?
  21. Sorry to bump this old post, but it's actually something I just came across myself now. Are there any news/change/plans about this? Webp as valid input imageformat appears to be useful nowadays.
  22. Hello! I wanted to share my latest website with you. https://www.reese-moden.de It's called "Reese Modehäuser" (beware! It is a german speaking website...) which loosely translates to "Reese Fashion Boutiques". A translator is not needed at all. The whole content is "picture-heavy" and there is not much text. I wanted to create a fashion boutique site that has a very crisp and clear look with huge magazine-like images that showcase the current fashion trends that are for sale. The page also features a simple blog/news system for posting new content. Because there are lots of large pictures I wanted to keep those loading times small. So the whole site makes full use of the processwire WEBP image support. In order to make responsive images in WEBP format available this site makes use of @nbcommunication fantastic PageimageSrcset module: https://github.com/nbcommunication/PageimageSrcset I can highly recommend this module! Nowadays everyone has an Instagram page. So I included an Instagram feed directly to the site, again with the help of @nbcommunication and his Instagram Basic Display Api Module: https://processwire.com/modules/instagram-basic-display-api/ This is another fantastic module which I am looking forward to use on other pages. Other modules I used on this site (als recommended): - AIOM+ (https://github.com/matjazpotocnik/ProcessWire-AIOM-All-In-One-Minify) for the compression of all JS and CSS files - Wiremail SMTP (https://processwire.com/talk/topic/5704-module-wiremailsmtp/) for sending mails. I am using a custom form builder system I created myself with some repeater fields. - Redirects (https://processwire.com/talk/topic/148-release-redirects/
  23. Not that it really matters, but until now I was unaware that WebP even supported "lossy" compression for PNG images. Turns out that for PNGs one can indeed use either WebP-lossless or WebP-lossy, while for JPGs you're obviously always using WebP-lossy ? Thanks to @horst for explaining the use cases! I did also wonder why we wouldn't want WebP source images. Technically I still think that it could make sense (ProcessWire can be used for a number of use cases, but "displaying images online" is still the most popular one by a wide margin), but it isn't really such a big deal. Not to mention that I'm not sure how well supported WebP manipulation operations are (in GD/Imagemagick).
  24. ? Heya, success! This seems to be a reliable and resource-saving method to bring webp support to (existing) PW sites: .htaccess only 2.0 ? (subtitle: learning more about htaccess directives) When only calling webpUrl | webpSrc for all image sources, without any conditional markup, the whole site / page tries to get all images as webp files. $options = ["webpAdd" => true]; $img = $page->images->first()->size(120, 120, $options); echo "<img src='{$img->webpUrl}' alt='{$img->description}' />"; The new htaccess directives will check if the browser supports webp. If not, it redirects the webp requests to the jpeg or png variations. Also if the browser supports webp, but a webp file is not available (for what ever reason), the htaccess redirects to an existing jpeg or png file. So, it redirects, it does not only rewrite the URL. Look at this screenshot, the redirected request has the correct file extension: The new .htaccess directives: To support png too, we need to copy the block and change .jpg to .png, or there is a way to implement both types into one block. We will see. ?
  25. Thank you for the update. I am always using the latest MAMP PRO and didn't notice this issue anymore. But I also defined as workaround a own config variable "useWebP", which I set to false for my development environment. ? <picture> <?php if ($config->useWebP): ?> <source srcset="path/to/image-webp" type="image/webp"> <?php endif; ?> <img src="path/to/image"> </picture>
×
×
  • Create New...