Search the Community

Yes, it creates files. But it creates from source files and want it to create a square WEBP file based on an existing square JPG file.

Hi @maximus, welcome to the forum. Are any webp image variations actually being generated by ProcessWire? You can check either in the admin interface on the page with the image field, or by looking in the site/assets/file/<page-id>/ folder for .webp variations of any image you saved to the page with id <page-id>

Hello, i have question how to make square images. I am developing an alcohol online storefront and in it I need to implement square images of bottles - so that they visually all look the same. Right now I am using the following code to position and create the images. <div class="fotorama p-4 bg-white w-full lg:w-2/5 lg:pr-4 hidden lg:block pt-16" data-nav="thumbs"> <?php if(count($page->get('images'))): foreach($page->get('images') as $image): $thumbSize = 500; $largeSize = 1000; // If image already 500x500 or less, don't do any scaling if($image->width <= 500 && $image->height <= 500) { continue; } // If image is not square else if($image->width != $image->height) { if($image->height > $image->width) { $thumb = $image->size(0, $thumbSize); $large = $image->size(0, $largeSize); } else { $ratio = $image->width / $image->height; $newWidthThumb = $thumbSize * $ratio; $newWidthLarge = $largeSize * $ratio; $thumb = $image->size($newWidthThumb, $thumbSize); $large = $image->size($newWidthLarge, $largeSize); $differenceThumb = $thumb->width - $thumbSize; $differenceLarge = $large->width - $largeSize; $thumb = $thumb->crop($differenceThumb / 2, 0, $thumbSize, $thumbSize); $large = $large->crop($differenceLarge / 2, 0, $largeSize, $largeSize); } if($thumb->width < 500 || $thumb->height < 500 || $large->width < 1000 || $large->height < 1000) { $imagickSmall = new Imagick($thumb->filename); $imagickLarge = new Imagick($large->filename); $canvasSmall = new Imagick(); $canvasLarge = new Imagick(); $canvasSmall->newImage(500, 500, new ImagickPixel('white')); $canvasLarge->newImage(1000, 1000, new ImagickPixel('white')); $canvasSmall->compositeimage($imagickSmall, Imagick::COMPOSITE_OVER, ($canvasSmall->getImageWidth() - $thumb->width) / 2, ($canvasSmall->getImageHeight() - $thumb->height) / 2); $canvasLarge->compositeimage($imagickLarge, Imagick::COMPOSITE_OVER, ($canvasLarge->getImageWidth() - $large->width) / 2, ($canvasLarge->getImageHeight() - $large->height) / 2); $canvasSmall->writeImage($thumb->filename); $canvasLarge->writeImage($large->filename); } } // The image is square else { $thumb = $image->size($thumbSize, $thumbSize); $large = $image->size($largeSize, $largeSize); } ?> <a href="<?=$large->url?>"><img src="<?=$thumb->url?>" class="pt-2" alt="<?=$page->title?>" width="64" height="64"></a> <?php endforeach; ?> <?php else: ?> <img src="<?=urls()->templates?>images/notfound.png" width="64" height="64" alt=""> <?php endif; ?> </div> The code works great and generates square images. BUT! When I try to add webp support <a href="<?=$large->webp->url?>"><img src="<?=$thumb->webp->url?>" class="pt-2" alt="<?=$page->title?>" width="64" height="64"></a> <?php endforeach; ?> code nothing works. There is a crop image function, but no function to position the image centered with the background added. How to implement this as simple as possible, using core functions and adding webp support ?

OK. More than few I see now :D All In One Minify, Email Obfuscation, Database Backups, Send Mass Email (inactive), Video embed for YouTube, Convert JPG/PNG images to WEBP, and 3 custom (super uber decently coded I guarantee) ones for backend. All modules load on every single template except for Email Obfuscation, which loads only on the contact page.

Thank you @bernhard I appreciate it especially coming from you. Rockfrontend/Latte have been indispensable tools! So the @import in the main custom.less was brought-in from a previous PW codebase I used … I was trying to load fonts locally instead of from external Google Fonts references and it must be there because I remebmer some discussion of that here in the PW forums, but honestly I can't specifically recall why I decided on that. My thinking was that @import was an outdated way of achieving this? CSS variables are used to control the dark-mode/light-mode functionality. I'm interested in what you have in mind for any CSS variables in future Rockfrontend releases. The webp function in ready.php is coming from a ProcessWire documentation post @ryan made about serving webp … specifically under Strategy 2. I'm still unclear exactly what it's doing except that this snippet seemed to be recommended. Good catch pointing out the inaccuracies in README, I will fix those in the next commit. And thank you again for kind feedback on the site itself!

Hey @protro congrats that's a great site!! Really beautiful design and absolutely awesome to also see the code and it looks great as well 🙂 When I read the readme I was confused about how you structured the site (with sections folder inside the layouts folder), but that readme is not showing what you actually did 🙂 --- In custom.less you have this Could you please elaborate on that? --- Also you are using css variables, which I'd also like to see in UIkit and I was thinking about creating a less file with hooks and overrides that provides that in a reusable way. What do you think? --- In ready.php you have this: // webp image support if($page->template != 'admin') { $wire->addHookAfter('Pageimage::url', function($event) { static $n = 0; if(++$n === 1) $event->return = $event->object->webp()->url(); $n--; }); } I'm not sure I understand what this is doing? First I thought it's a clever feature to always request webp on the frontend! But what is the $n for? Isn't it always resetting itself to 0 and on the next call it will again be incremented and if(1 === 1) will again return the webp? --- And I have a special request via PM 😄

You can either use hooks: <?php $wire->addHookMethod("Page::thumbnail", function(HookEvent $event) { $event->return = ...; }); Or even better you use custom page classes (it's really easy thx to pw!) and there you create a DefaultPage class that adds your method: <?php namespace ProcessWire; class DefaultPage extends Page { public function thumbnail() { return ...; } } Then you just make sure that thumbnail() always returns a PageImage object and then in all your templates you can do this: echo $page->thumbnail()->size(100,100)->webp->url; And it will automatically render either the custom or the fallback image. Check out https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes for details

Hello all, For my current project, each page have an image called thumbnail used for various purposes. If the thumbnail is not provided, I have a fallback image. So on almost each PHP template, I have the following code at the beginning: $thumbnailUrl = $page->pageThumbnail ? $page->pageThumbnail->size(1920, 400, ["crop" => "center"])->webp->url : $pages->get(1039)->configDefaultImage->url ; To avoid repeating that on each page PHP template, what can I do to generate, for each page, something like $page->thumbnailUrl automatically? Do I have to use a hook ? Thanks guys for your help Cheers Thomas

Hello @benbyf, You can update to the latest version of PW. If that doesn't solve the problem, convert the WebP images to a supported format like JPEG or PNG for admin use and for compressing them you can use any online application such as https://jpegcompressor.com/ it compresses JPEG, PNG and other.

Hey @horst and @Robin S here is a real use case from today: A website mockup with transparent background. Exporting it as PNG results in 369kB: WEBP 109kB WEBP created from PNG via PW: 66kB That seems to be a 90% quality setting 🙂 @Robin S is there a reason why your module converts to JPG and not PNG? I'd lose the transparency when using JPG... I guess I export PNG and use that for my website for now, but I'd still think that it would be nice to support WEBP @horst maybe you can rethink that?

Has anyone experienced a scenario where a PDF (or other) file that's been uploaded, and shows as having been successfully uploaded, is reporting as an improper size, and then doesn't load correctly when attempted to be accessed/downloaded/viewed from the website? I have a PDF that, I believe, was generated from Canva. It is 4.5MB in size. During upload, the JS upload GUI reports the proper size in the progress bar, but then once complete, shows a filesize that is not the same as the original (2.5MB in this case). Unfortunately, it also seems to break and corrupt the file. It is indeed smaller. Thus far, I've manually uploaded, via FTP, the file overtop of the one processed by ProcessWire, but if this comes up again, I'm not sure what to look at. I have FileValidatorSVG installed, but the file extension here is definitely PDF. Also installed that might process files: WireRequestBlocker, SearchEngine File Indexer, WebP to JPG. I thought I'd recently seen a topic about this, but when trying to find it again, was unable.

Hey @gebeer nothing dangerous 😉 I don't think that anybody except me was using this, but it's a breaking change... Anybody not using it can safely update. Before: {$img->maxSize(500,500)->murl} After: {$img->maxSize(500,500)->webp->url|vurl} This adds a version-url string for cache busting which is especially great when changing image focus point as then often the image url does not change (its still ...500x500...) but the image should get reloaded by the browser. This simple latte filter ensures that and the old ->murl had problems with webp so I changed it 🙂

This module won't suit everyone because... It requires what is currently the latest dev version of ProcessWire It requires your server environment have AVIF support Generating AVIF files is slow It offers fewer features than the core provides for WebP It is likely incompatible with the core WebP features so is an either/or prospect ...but it allows for the basic generation and serving of AVIF files until such time as the core provides AVIF features. Auto AVIF Automatically generates AVIF files when image variations are created. The AVIF image format usually provides better compression efficiency than JPG or WebP formats, in many cases producing image files that are significantly smaller in size while also having fewer visible compression artifacts. Requires ProcessWire v3.0.236 or newer. In order to generate AVIF files your environment must have a version of GD or Imagick that supports the AVIF format. If you are using ImageSizerEngineGD (the ProcessWire default) then this means you need PHP 8.1 or newer and an OS that has AVIF support. If you want to use Imagick to generate AVIF files then you must have the core ImageSizerEngineIMagick module installed. The module attempts to detect if your environment supports AVIF and warns you on the module config screen if it finds a problem. Delayed Image Variations Generating AVIF files can be very slow - much slower than creating an equivalent JPG or WebP file. If you want to use this module it's highly recommended that you also install the Delayed Image Variations module so that image variations are created one by one on request rather than all at once before a page renders. Otherwise it's likely that pages with more than a few images will timeout before the AVIF files can be generated. Configuration On the module configuration screen are settings for "Quality (1 – 100)" and "Speed (0 – 9)". These are parameters for the underlying GD and Imagick AVIF generation methods. There is also an option to create AVIF files for existing image variations instead of only new image variations. If you enable this option then all image variations on your site will be recreated the next time they are requested. As per the earlier note, the process of recreating the image variations and the AVIF files is likely to be slow. Usage Just install the module, choose the configuration settings you want, and make the additions to the .htaccess file in the site root described in the next section. How the AVIF files are served The module doesn't have all the features that the ProcessWire core provides for WebP files. It's much simpler and uses .htaccess to serve an AVIF file instead of the original variation file when the visitor's browser supports AVIF and an AVIF file named the same as the variation exists. This may not be compatible with the various approaches the core takes to serving WebP files so you'll want to choose to serve either AVIF files via this module or WebP files via the core but not both. Two additions to the .htaccess file in the site root are needed. 1. Immediately after the RewriteEngine On line: # AutoAvif RewriteCond %{HTTP_ACCEPT} image/avif RewriteCond %{QUERY_STRING} !original=1 RewriteCond %{DOCUMENT_ROOT}/$1.avif -f RewriteRule (.+)\.(jpe?g|png|gif)$ $1.avif [T=image/avif,E=REQUEST_image,L] 2. After the last line: # AutoAvif <IfModule mod_headers.c> Header append Vary Accept env=REQUEST_image </IfModule> <IfModule mod_mime.c> AddType image/avif .avif </IfModule> Opting out of AVIF generation for specific images If you want to prevent an AVIF file being generated and served for a particular image you can hook AutoAvif::allowAvif and set the event return to false. AutoAvif generates an AVIF file when an image variation is being created so the hookable method receives some arguments relating to the resizing of the requested variation. Example: $wire->addHookAfter('AutoAvif::allowAvif', function(HookEvent $event) { $pageimage = $event->arguments(0); // The Pageimage that is being resized $width = $event->arguments(1); // The requested width of the variation $height = $event->arguments(2); // The requested height of the variation $options = $event->arguments(3); // The array of ImageSizer options supplied // You can check things like $pageimage->field, $pageimage->page and $pageimage->ext here... // Don't create an AVIF file if the file extension is PNG if($pageimage->ext === 'png') $event->return = false; }); Deleting an AVIF file If you delete a variation via the "Variations > Delete Checked" option for an image in an Images field then any corresponding AVIF file is also deleted. And if you delete an image then any AVIF files for that image are also deleted. Deleting all AVIF files If needed you can execute this code snippet to delete all AVIF files sitewide. $iterator = new \DirectoryIterator($config->paths->files); foreach($iterator as $dir) { if($dir->isDot() || !$dir->isDir()) continue; $sub_iterator = new \DirectoryIterator($dir->getPathname()); foreach($sub_iterator as $file) { if($file->isDot() || !$file->isFile()) continue; if($file->getExtension() === 'avif') { unlink($file->getPathname()); echo 'Deleted: ' . $file->getFilename() . '<br>'; } } } Saving an original variation file Because requests to images are being rewritten to matching AVIF files where they exist, if you try to save example.500x500.jpg from your browser you will actually save example.500x500.avif. You can prevent the rewrite and load/save the original variation file by adding "original=1" to the query string in the image URL, e.g. example.500x500.jpg?original=1. https://github.com/Toutouwai/AutoAvif https://processwire.com/modules/auto-avif/

Imagine you want to display an image on your website. Easy. Imagine you want to open the bigger version in a lightbox. Easy when using UIkit (or any other framework). Imagine you only want to add the lightbox link only if there is actually a larger version than the one displayed. Easy when using LATTE 🙂 <div n:if="$img = $page->image" class="uk-background-muted uk-padding-small uk-text-center" uk-lightbox > <a n:tag-if="$img->width > 800 || $img->height > 400" href="{$img->maxSize(1920,1920)->webp->url}" > <img src="{$img->size(800,400)->webp->url}" alt="{$page->title}" /> </a> </div> This takes care of so many things with so little and clean code: the n:if on the outer div makes sure that we don't get any errors if no image is uploaded the n:tag-if makes sure that the anchor wrapper is only added if the original image is larger than the thumbnail Note that you can assign $img directly in the n:if condition. No need for an additional {var $img = $page->image} at the top. For some that might be too short, but I like it 🙂

For whoever stumbles on this, the issue was exactly in the FileContentTypes. Every type that should be forced to download should have a "+" in front, which I did not have. So, this is the correct setup in config.php (for my case): $config->fileContentTypes = array( '?' => '+application/octet-stream', 'txt' => '+text/plain', 'csv' => '+text/csv', 'pdf' => '+application/pdf', 'doc' => '+application/msword', 'docx' => '+application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'xls' => '+application/vnd.ms-excel', 'xlsx' => '+application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', 'ppt' => '+application/vnd.ms-powerpoint', 'pptx' => '+application/vnd.openxmlformats-officedocument.presentationml.presentation', 'rtf' => '+application/rtf', 'gif' => '+image/gif', 'jpg' => '+image/jpeg', 'jpeg' => '+image/jpeg', 'png' => '+image/png', 'svg' => '+image/svg+xml', 'webp' => '+image/webp', 'zip' => '+application/zip', 'mp3' => '+audio/mpeg', ); In addition, I wanted to use original file names, not the ones that Processwire creates when uploading files. This modification to Zeka's code manages that through html_entity_decode: if($input->urlSegment1 == 'download') { if($input->urlSegment2) { $names = array(); $urls = array(); $originalNames = array(); foreach ($page->handoff_files as $handoff_file_repeater) { $file = $handoff_file_repeater->file; $original_name_unencoded = html_entity_decode($file->uploadName); array_push($names, $file->name); array_push($urls, $file->filename); array_push($originalNames, $original_name_unencoded); } $key = array_search($input->urlSegment2, $names); if($key !== false) { wireSendFile($urls[$key], [ "downloadFilename" => $originalNames[$key], ]); } else { throw new Wire404Exception(); } } } else if($input->urlSegment1) { // unknown URL segment, send a 404 throw new Wire404Exception(); } foreach ($page->handoff_files as $handoff_file_repeater){ $file = $handoff_file_repeater->file; $fileSizeInBytes = $files->size($file->filename); $formattedSize = formatFileSize($fileSizeInBytes); $original_name_unencoded = html_entity_decode($file->uploadName); ?> <div class="file-block"> <div class="file-info"> <h3><?=$original_name_unencoded;?></h3> <p><?=$formattedSize;?></p> </div> <!--<a href="<?=$file->url;?>" download="<?=$original_name_unencoded;?>" class="download-button">download</a>--> <a href="<?= 'download/'.$file->name; ?>" download="<?=$original_name_unencoded?>" class="download-button">download</a> </div> <?php } ?>

Sorry to bring a thread from the dead, but I'm banging my head against the wall with this. I'm by no means a processwire expert and this is probably the most in-depth I've ever gone into understanding it. I've used Zeka's solution. In 2023 you need to add <?php namespace ProcessWire; ?> for wireSendFile() to work. The URL segment works and creates a link to the file, but the file does not download - it opens in the browser. This is an example url with the downloads: https://zar.co.com/handoffs/hera-title-colorado-posters/ The URL segment gets appended after this, for example - ....colorado-posters/download/name-of-file.jpg This is my setup in the config.php: $config->fileContentTypes = array( '?' => '+application/octet-stream', 'txt' => '+text/plain', 'csv' => '+text/csv', 'pdf' => '+application/pdf', 'doc' => '+application/msword', 'docx' => '+application/vnd.openxmlformats-officedocument.wordprocessingml.document', 'xls' => '+application/vnd.ms-excel', 'xlsx' => '+application/vnd.openxmlformats-officedocument.spreadsheetml.sheet', 'ppt' => '+application/vnd.ms-powerpoint', 'pptx' => '+application/vnd.openxmlformats-officedocument.presentationml.presentation', 'rtf' => '+application/rtf', 'gif' => 'image/gif', 'jpg' => 'image/jpeg', 'jpeg' => 'image/jpeg', 'png' => 'image/png', 'svg' => 'image/svg+xml', 'webp' => 'image/webp', 'zip' => '+application/zip', 'mp3' => 'audio/mpeg', ); Could someone point me in the right direction?

I can't quite see how WEBP images are different from JPEGs or GIFs in this regard, and why they shouldn't be allowed as source images. All these formats are lossy and have the potential to look fantastically terrible when set to high compression rates, so there's really no ideal input format apart from TIFFs and lossless PNGs. The browser and OS support of WEBPs is such that we should allow them as source format if the server is configured to resize them. From what I've seen, most GD and Imagick installations these days handle WEBP just fine. With websites now outputting WEBP files, a growing number of PW users will expect to keep working with them as they've always been working with other common formats.

Sorry to catch up this older topic again, but there seems to be no changes in sight so far. I also still would find it useful to have webp as input format. The need- or the wish- to use it, is from my experience originated in Google requesting (or recommending) webp format in order to reduce loading times when doing speed tests with lighthouse. So people start to use and store images in webp format. Then to convert them back to jpg or png just to output these as webp again makes no sense at all.

I want to show a new website that I made at the beginning of this year using @bernhard's RockPageBuilder module: https://www.kurrat-terrassendaecher.de/ The client: Kurrat Terrassendächer (which translates to "Kurrat Terrace Roofs") is a dealer from germany that is specialized in building custom made terrace roofings, awnings and solar protection. The goal: The customer had a old website that was used as a basis for the new design. The new website should offer a more "catalogue-like" look with lots of information for the customer. Fortunately the client had access to high quality images of the products that really make the whole website shine. The page features three main categories: 1. Terrace Roofs 3. Solar Protection 3. Winter Gardens Each category subpage is made of modular content blocks: The user is able to make custom page layouts using these blocks directly in the frontend. With the RockPageBuilder module it is super fun an super straight forward to work with these content blocks. If you don't know this module yet I highly recommend to check it out! If you like the RepaterMatrix you will love this module. It is far superior IMHO! Inserting a content block looks like this: It is also possible to edit content on-the-fly in the frontend: As with the RepeaterMatrix each content block an also be added end edited in the backend of the page: Here you see the list of content blocks used on the home page. To edit a block, just click on it and you can edit it just like using the RepaterMatrix. Screenshots from the website: Modules used for this page: - RockFrontend (for asset bundling, minifying, etc.) - RockPageBuilder (instead of RepeaterMatrix! For building and editing all content in the frontend) - WireMailSMTP - PageImageSource (for creating webp image variations) - PrivacyWire (for cookie consent banner) - SEO Maestro - Redirects The frontend framework is UIKit

Happy to announce the launch of the completely rebuilt San Francisco Contemporary Music Players website, using ProcessWire. https://sfcmp.org/ The previous website was a hornet's nest of disorganized content, dozens of 3rd party plugins, duct taped together within WordPress... difficult to use, time consuming and confusing to manage. And didn't look so good either. Lot of fun to rebuild this, though took several months. YOOtheme Pro and UiKit were a dream for me to work with, just love those. Made it so possible to create all of the custom sections, widgets, sliders, cards, mega menus, and so on. Don't consider myself a front-end focused web dev, so have a deep appreciation for the time, care and effort that Yoo has put into both UiKit and YOOtheme Pro. Almost no additonal CSS was needed to be written for this; the stock UiKit classes and attributes make it possible to just build things in HTML and not have to fiddle with CSS. Ryan's commercial modules played a major role in the build. ProFields, ListerPro, ProCache, and FormBuilder were all important. FormBuilder+Stripe allowed me to confidently migrate their need for a stripe checkout from some WP plugin to the clean and simple setup now using FB. ( https://sfcmp.org/donate/print-for-sale-dirge-by-hung-liu/ ) Some libraries also were of great use and value, namely PLYR for audio, and tabulator for some table display type of stuff. As always, the API was a dream to work with, many custom import scripts were created along the way to import legacy Press, Albums, Repertoire works, Program Booklets library, Players etc.. The image API is doing wonders with SRC sets, and webp images. The PW documentation site was a daily companion. This forum likewise was always a most valuable and enjoyable resource to search and rely on for solving the occasional conundrum. There is such a wealth of info here that i never found it necessary to post a question. Lastly, to underscore just how unparalleled, flexible and user-friendly the PW backend is, we had the backend training session a couple of weeks after the site was launched, and within 30 minutes, the person who will be managing the content was able to know how to create and manage concerts, blog posts, albums, press articles and more.

Native AVIF support would be great for creating performant sites. When WEBP support was added to the core, it was done as a one-off addition. AVIF could be added in the same way by accessing an $image->avif property on the image object. However — I think @BrendonKoz touched on this above — adding more alternative output formats will probably require some rethinking to keep this part of the core modular. We'll definitely see more image formats being developed in the future, and it'd be great to access them from a single property or as a single parameter with formats and fallbacks, e.g. $image->url(300, ['format' => 'webp,png']).

I'm a little late chiming in, but I'm building my first PW site and was looking to see if AVIF was supported and found this thread. I likewise am surprised this hasn't been requested more. AVIF is _much_ more impressive than WebP in my opinion. I would be happy if it behaved the same way as WebP support as described here: https://processwire.com/blog/posts/webp-images-in-pw/ I've yet to see an instance where AVIF was a larger image size than the source. Because browser support still isn't there on Edge, I'd want to use it with srcset fallbacks anyway.

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

I added support for automatic WebP to JPG conversion via the WebP To JPG module. To make use of this update to Add Image URLs v0.3.0 and install/update to WebP To JPG v0.2.0.

Any solutions? I thought it was possible because the Mime types is in the config image/webp:webp