Search the Community
Showing results for 'webp'.
-
This module allows you to automatically rename file (including image) uploads according to a configurable format This module lets you define as many rules as you need to determine how uploaded files will be named and you can have different rules for different pages, templates, fields, and file extensions, or one rule for all uploads. Renaming works for files uploaded via the admin interface and also via the API, including images added from remote URLs. Github: https://github.com/adrianbj/CustomUploadNames Modules Directory: http://modules.processwire.com/modules/process-custom-upload-names/ Renaming Rules The module config allows you to set an unlimited number of Rename Rules. You can define rules to specific fields, templates, pages, and file extensions. If a rule option is left blank, the rule with be applied to all fields/templates/pages/extensions. Leave Filename Format blank to prevent renaming for a specific field/template/page combo, overriding a more general rule. Rules are processed in order, so put more specific rules before more general ones. You can drag to change the order of rules as needed. The following variables can be used in the filename format: $page, $template, $field, and $file. For some of these (eg. $field->description), if they haven't been filled out and saved prior to uploading the image, renaming won't occur on upload, but will happen on page save (could be an issue if image has already been inserted into RTE/HTML field before page save). Some examples: $page->title mysite-{$template->name}-images $field->label $file->description {$page->name}-{$file->filesize}-kb prefix-[Y-m-d_H-i-s]-suffix (anything inside square brackets is is considered to be a PHP date format for the current date/time) randstring[n] (where n is the number of characters you want in the string) ### (custom number mask, eg. 001 if more than one image with same name on a page. This is an enhanced version of the automatic addition of numbers if required) If 'Rename on Save' is checked files will be renamed again each time a page is saved (admin or front-end via API). WARNING: this setting will break any direct links to the old filename, which is particularly relevant for images inserted into RTE/HTML fields. The Filename Format can be defined using plain text and PW $page variable, for example: mysite-{$page->path} You can preserve the uploaded filename for certain rules. This will allow you to set a general renaming rule for your entire site, but then add a rule for a specific page/template/field that does not rename the uploaded file. Just simply build the rule, but leave the Filename Format field empty. You can specify an optional character limit (to nearest whole word) for the length of the filename - useful if you are using $page->path, $path->name etc and have very long page names - eg. news articles, publication titles etc. NOTE - if you are using ProcessWire's webp features, be sure to use the useSrcExt because if you have jpg and png files on the same page and your rename rules result in the same name, you need to maintain the src extension so they are kept as separate files. $config->webpOptions = array( 'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) ); Acknowledgments The module config settings make use of code from Pete's EmailToPage module and the renaming function is based on this code from Ryan: http://processwire.com/talk/topic/3299-ability-to-define-convention-for-image-and-file-upload-names/?p=32623 (also see this post for his thoughts on file renaming and why it is the lazy way out - worth a read before deciding to use this module). NOTE: This should not be needed on most sites, but I work with lots of sites that host PDFs and photos/vectors that are available for download and I have always renamed the files on upload because clients will often upload files with horrible meaningless filenames like: Final ReportV6 web version for John Feb 23.PDF
-
Hi, I have a question regarding WebP support that I would like to clarify. I added WebP to my allowed image extensions, and while uploads work fine and the original images display correctly, I'm seeing "not a supported image type" errors when ProcessWire tries to generate thumbnails or variations from WebP source files. After some digging, I found Ryan's blog post from 2019 which says: > "WEBP is purely an output format, not an input format... PNG and/or JPG images should still be the standard for any images you upload to your site." So it sounds like this is expected behaviour - WebP is designed for output (converting JPG/PNG → WebP for delivery) rather than input (uploading WebP and resizing it). Just wanted to confirm: Is this still the case in 2026? Is there any plan to support WebP as a source format in the future? For those who do allow WebP uploads - do you just accept that variations won't be generated? For now, I'm working around it by skipping resize attempts on WebP source images and using the originals, which works fine but results in larger file transfers for thumbnails. Thanks! Peter
-
WebP as source/input images - expected behaviour?
Peter Knight replied to Peter Knight's topic in General Support
Hey thanks for the link. Neat module. Was there a technical or philosophical issue with support for webp as input source image? -
WebP as source/input images - expected behaviour?
monollonom replied to Peter Knight's topic in General Support
Did you check https://processwire.com/modules/webp-to-jpg/ ? -
Hi everyone! 👋 I'd like to share SquareImages - a simple module that creates perfect square images from any source format. Born from a real-world need: displaying vertical product images (like Coca-Cola bottles) uniformly in galleries and grids without distortion or awkward sizing. The Problem // Traditional methods don't work well for mixed aspect ratios: $image->width(300); // Too narrow for vertical images $image->height(300); // Too wide $image->size(300, 300); // Distorted The Solution // One simple method - smart cropping, perfect squares: $square = $image->square(300); Key Features 🎯 Smart Cropping - Automatically centers on longer dimension 📦 Format Preservation - Maintains original format (JPG/PNG/GIF) 🌐 WebP Support - Chain with ->webp() for compression ⚡ Performance - Fast URL generation 💾 Automatic Caching - Built on PW's image engine Quick Example <div class="product-grid"> <?php foreach ($page->products as $product): ?> <?php $thumb = $product->photo->square(300); ?> <img src="<?= $thumb->url ?>" alt="<?= $product->title ?>"> <?php endforeach; ?> </div> Perfect uniform squares, regardless of source dimensions! API Methods $image->square(400); // Main method $image->squareWidth(500); // Based on width $image->squareHeight(600); // Based on height $image->getSquareURL(300); // Direct URL (faster) // WebP conversion $image->square(500)->webp(); // 25-65% smaller files Installation GitHub: https://github.com/mxmsmnv/SquareImages cd site/modules/ git clone https://github.com/mxmsmnv/SquareImages.git Or download ZIP and extract to /site/modules/SquareImages/ Then refresh modules in admin and install. Use Cases E-commerce product galleries Team member avatars Blog thumbnails Social media previews Instagram-style grids
-
- 7
-
-
-
I've been meaning to revise PageimageSrcset for a while now, to remove some features that I felt were unnecessary and to implement a better rendering strategy. The result is PageimageSource. What does it do? It provides a configurable srcset method/property for Pageimage It allows WebP to be enabled for images it generates. It allows Pageimage:render() to return a <picture> element It provides a Textformatter that replaces <img> elements with the output of Pageimage:render() Although it is based on a current module, this should still be considered beta and not used in production without a prior development stage. Here's the README: PageimageSource Extends Pageimage with a srcset property/method plus additional rendering options. Overview The main purpose of this module is to make srcset implementation as simple as possible in your template code. For an introduction to srcset, please read this Mozilla article about responsive images. Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.165 and PHP >= 7.3 are required to use this module. Configuration To configure this module, go to Modules > Configure > PageimageSource. Default Set Rules These are the default set rules that will be used when none are specified, e.g. when calling the property: $image->srcset. Each set rule should be entered on a new line, in the format {width}x{height} {inherentwidth}w|{resolution}x. Not all arguments are required - you will probably find that specifying the width is sufficient for most cases. Here's a few examples of valid set rules and the sets they generate: Set Rule Set Generated Arguments Used 320 image.320x0-srcset.jpg 320w {width} 480x540 image.480x540-srcset.jpg 480w {width}x{height} 640x480 768w image.640x480-srcset.jpg 768w {width}x{height} {inherentwidth}w 2048 2x image.2048x0-srcset.jpg 2x {width} {resolution}x How you configure your rules is dependent on the needs of the site you are developing; there are no prescriptive rules that will meet the needs of most situations. This article gives a good overview of some of the things to consider. When you save your rules, a preview of the sets generated and an equivalent method call will be displayed to the right. Invalid rules will not be used, and you will be notified of this. WebP If enabled, WebP versions of the image and srcset variations will be generated and these will be returned by Pageimage::srcset(). As with the default implementation, the image with the smaller file size is returned. In most cases this is the WebP version, but sometimes can be the source. Make sure to experiment with the quality setting to find a value you find suitable. The default value of 90 is fine, but it is possible that lower values will give you excellent kB savings with little change in overall quality. For more information on WebP implementation please read the blog posts on the ProcessWire website. Rendering These settings control how the output of Pageimage::render() is modified. Use Lazy Loading? When enabled this adds loading="lazy" to the <img> attributes. It is useful to have this on by default, and you can always override it in the options for a specific image. Use the <picture> element? When enabled, the <img> element is wrapped in a <picture> element and <source> elements for original and WebP variations are provided. This requires WebP to be enabled. For more information on what this does, have a look at the examples in Pageimage::render() below. Remove Variations If checked, the image variations generated by this module are cleared on Submit. On large sites, this may take a while. It makes sense to run this after you have made changes to the set rules. Please note that although the module will generate WebP versions of all images if enabled, it will only remove the variations with the 'srcset' suffix. Usage Pageimage::srcset() // The property, which uses the set rules in the module configuration $srcset = $image->srcset; // A method call, using a set rules string // Delimiting with a newline (\n) would also work, but not as readable $srcset = $image->srcset('320, 480, 640x480 768w, 1240, 2048 2x'); // The same as above but using an indexed/sequential array $srcset = $image->srcset([ '320', '480', '640x480 768w', '1240', '2048 2x', ]); // The same as above but using an associative array // No rule checking is performed $srcset = $image->srcset([ '320w' => [320], '480w' => [480], '768w' => [640, 480], '1240w' => [1240], '2x' => [2048], ]); // The set rules above are a demonstration, not a recommendation! Image variations are only created for set rules which require a smaller image than the Pageimage itself. This may still result in a lot of images being generated. If you have limited storage, please use this module wisely. Pageimage::render() This module extends the options available to this method with: srcset: When the module is installed, this will always be added, unless set to false. Any values in the formats described above can be passed. sizes: If no sizes are specified, a default of 100vw is assumed. lazy: Pass true to add loading=lazy, otherwise false to disable if enabled in the module configuration. picture: Pass true to use the <picture> element, otherwise false to disable if enabled in the module configuration. Please refer to the API Reference for more information about this method. // Render an image using the default set rules // WebP and lazy loading are enabled, and example output is given for <picture> disabled and enabled echo $image->render(); // <img src='image.webp' alt='' srcset='image.jpg...' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.webp..." sizes="100vw" type="image/webp"> <source srcset="image.jpg..." sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules echo $image->render(['srcset' => '480, 1240x640']); // <img src='image.webp' alt='' srcset='image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w' sizes='100vw' loading='lazy'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x640-srcset.webp 1240w" sizes="100vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x640-srcset.jpg 1240w" sizes="100vw" type="image/jpeg"> <img src="image.jpg" alt="" loading="lazy"> </picture> */ // Render an image using custom set rules and sizes // Also use the `markup` argument // Also disable lazy loading // In this example the original jpg is smaller than the webp version echo $image->render('<img class="image" src="{url}" alt="Image">', [ 'srcset' => '480, 1240', 'sizes' => '(min-width: 1240px) 50vw', 'lazy' => false, ]); // <img class='image' src='image.jpg' alt='Image' srcset='image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w' sizes='(min-width: 1240px) 50vw'> /* <picture> <source srcset="image.480x0-srcset.webp 480w, image.1240x0-srcset.webp 1240w" sizes="(min-width: 1240px) 50vw" type="image/webp"> <source srcset="image.480x0-srcset.jpg 480w, image.1240x0-srcset.jpg 1240w" sizes="(min-width: 1240px) 50vw" type="image/jpeg"> <img class='image' src='image.jpg' alt='Image'> </picture> */ // Render an image using custom set rules and sizes // These rules will render 'portrait' versions of the image for tablet and mobile // Note the advanced use of the `srcset` option passing both `rules` and image `options` // WebP is disabled // Picture is disabled echo $image->render([ 'srcset' => [ 'rules' => '320x569, 640x1138, 768x1365, 1024, 1366, 1600, 1920', 'options' => [ 'upscaling' => true, 'hidpi' => true, ], ], 'sizes' => '(orientation: portrait) and (max-width: 640px) 50vw', 'picture' => false, ]); // <img src='image.jpg' alt='' srcset='image.320x569-srcset-hidpi.jpg 320w, image.640x1138-srcset-hidpi.jpg 640w, image.768x1365-srcset-hidpi.jpg 768w, image.1024x0-srcset-hidpi.jpg 1024w, image.1366x0-srcset-hidpi.jpg 1366w, image.1600x0-srcset-hidpi.jpg 1600w, image.jpg 1920w' sizes='(orientation: portrait) and (max-width: 768px) 50vw' loading="lazy"> TextformatterPageimageSource Bundled with this module is a Textformatter largely based on TextformatterWebpImages by Ryan Cramer. When applied to a field, it searches for <img> elements and replaces them with the default output of Pageimage::render() for each image/image variation. Assuming a default set of 480, 960 and lazy loading enabled, here are some examples of what would be returned: Example <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" /> </a> </figure> WebP enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.webp" width="300" srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" loading="lazy" /> </a> </figure> <picture> enabled <figure class="align_right hidpi"> <a href="/site/assets/files/1/example.jpg"> <picture> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.webp 480w" sizes="100vw" type="image/webp"> <source srcset="/site/assets/files/1/example.300x0-is-hidpi.jpg 480w" sizes="100vw" type="image/jpeg"> <img alt="" src="/site/assets/files/1/example.300x0-is-hidpi.jpg" width="300" loading="lazy" /> </picture> </a> </figure> Because the variation is small - 300px wide - the srcset only returns the source image variation at the lowest set width (480w). If the source image was > 1000px wide, there would be a variation at both 480w and 960w. PageimageSrcset This module is built upon work done for PageimageSrcset, which can be considered a first iteration of this module, and is now deprecated. Migration PageimageSource is a simplified version of PageimageSrcset with a different approach to rendering. Most of the features of the old module have been removed. If you were just using $image->srcset(), migration should be possible, as this functionality is essentially the same albeit with some improvements to image variation generation.
- 86 replies
-
- 22
-
-
-
Looks great. New to PW here and have been scanning the forums for best practices on including images on static pages (no image fields). A media library seems to be the way... I wanted to understand how I might use the PageImageSource module to render webp srcsets on the fly for static images but was disappointed to learn that it can only be used with PageImage images. https://github.com/nbcommunication/PageimageSource I think ProcessWire would be a hard sell to many clients without some a full-featured image library solution, which is a great pity. The UI looks well done.
-
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. 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 ?
-
Hi @elabx Thanks for your post. Your code looks clean but I'd like a little more flexibility ideally for my use case. I'd like the option to choose any image from my projects (not just the first). Also, sometimes I'll need to pick more than one image from the same project for display on the masonry gallery. For this reason, I'm thinking image tags might be the way to go but then the question is, how do I wrap that image in a link to its respective project page.. Page references seem like the way to go, but I'm still trying to wrap my head around how these work tbh. Custom image fields could also work but I'm trying to keep things as simple as possible. I also don't want to screw up alt fields for SEO and I'm looking to use PageimageSource to manage srcset and webp automatically (maybe I'm looking to learn too much at once for my first PW site 😂) https://github.com/nbcommunication/PageimageSource Assuming all image fields are image arrays with tags enabled in admin, could I do this?: // "sections" is the repeater on my projects pages that contain images and content. // "project_header" is a repeater in project template that contains project title and info. // Can I can use find() to get repeaters with template=repeater_repeaterName, like this? $projSections = $pages->find("template=repeater_sections, images.tags=gallery"); foreach ($projSections as $section) { $projectPage = $section->getForPage(); $title = $projectPage->project_header->first()->project_title; foreach ($section->images->findTag("gallery") as $img) { echo "<a href='{$projectPage->url}' title='{$title}'>"; echo $img->render(); echo "</a>"; } } It seems inefficient to me to have to parse through all project content repeaters for tagged images like this but maybe with caching it wouldn't be a problem? In my setup project title and description text is in one repeater, and all images are in another - not sure if that complicates things. I would like to wrap each image in a <a> that links to the respective project page.
- 7 replies
-
- beginner portfolio
- masonry
-
(and 3 more)
Tagged with:
-
Hi everyone, This module completely replaces the default ProcessWire image sizing engine with the powerful Intervention Image v3 library. The goal was to modernize how we handle images in ProcessWire, bringing in features like AVIF support, superior resizing quality, and strict aspect-ratio handling, while keeping the API compatible with what you already know. 🚀 What does it do? Replacement: It hooks into Pageimage. You can keep using $image->width(300), $image->size(800, 600), or $image->crop(...) just like you always have. Modern Formats: Automatically handles WebP and AVIF generation. Smart Responsive Images: It introduces a configuration-based approach where you define Breakpoints, Grid Columns, and Resizing Factors. The module uses these settings to automatically calculate and generate the perfect srcset for your layouts. ✨ New Methods: render() and attrs() While standard methods work as expected, I’ve added/updated methods to handle modern HTML output: 1. $image->render(string $preset, array $options) This outputs the complete HTML tag. It automatically handles: The <img> tag with srcset and sizes. The <picture> tag with <source> elements if you have enabled extra formats (like AVIF/WebP) in the settings. Lazy Loading & LQIP: It automatically generates a Low Quality Image Placeholder (pixelated/blur effect) and applies a base64 background to the image tag for a smooth loading experience. // Example: Render a 'landscape' preset defined in module settings echo $page->image->render('landscape', ['class' => 'my-image']); 2. $image->attrs(string $preset, array $options) Perfect for developers who use template engines like Twig or Latte, or prefer full control over their HTML. This returns an array of attributes instead of an HTML string. $data = $page->image->attrs('landscape'); // Returns array like: // [ // 'src' => '...', // 'width' => 1200, // 'height' => 675, // 'srcset' => '...', // 'sources' => [ ... ], // Array for picture tag sources // 'style' => 'background-image: url(data:image...);', // LQIP Base64 // 'class' => 'iv-lazy ...' // ] ⚙️ Configuration Strategy Instead of hardcoding sizes in your templates, you configure your design tokens in the module settings: Breakpoints (e.g., 1200px) Aspect Ratios (e.g., 16:9) Grid Columns (e.g., 1-1, 1-2, 1-3) Factors (e.g., 0.5, 1, 1.5, 2 for Retina support) The module calculates the necessary image dimensions based on these combinations. If you request a specific aspect ratio, it ensures strict adherence to it, preventing 1px rounding errors. 📝 A Note on Documentation I wanted to get this into your hands as soon as possible, but due to a heavy workload, I haven't finished writing the detailed README.md yet. Currently, you can grab the code from GitHub (link below). I will submit this to the official ProcessWire Modules Directory after add some other features and after update readme.md Download / GitHub: GitHub Repo I’d love to hear your feedback and suggestions!
-
Hello, We've recently been researching how to use ProcessWire in a horizontal scaling environment (multiple server instances using a load balanced, read replica databases), and ran an experiment using AWS Elastic Beanstalk. Getting read replica databases up and running was easy - it's built in to the core: https://processwire.com/blog/posts/pw-3.0.175/#how-to-use-it-in-processwire Using multiple server instances throws up one big problem: how to keep the filesystem on multiple instances in sync given that ProcessWire doesn't currently support using an external service (like s3 or EFS) as the filesystem. The solution that we came up with is to use various Cloudflare services (R2, Stream, Images) to serve file assets, and we've built a module to facilitate this: We're not using this in production yet, but our tests on EB were successful, and we're confident this will solve the main part of this problem. However the Cloudflare Images service is still quite new and there's still features to be rolled out (e.g. webP for flexible variants) so it can't be considered a complete solution yet. Additionally, we use ProCache and this presents an additional multi-instance problem - if the cache is cleared on one, how can we clear it on all? Our solution is to log clears in the database and use this to sync up clearing. We built another module: Again this worked well in our test, but isn't yet being used in production. The main purpose of this thread, aside from sharing these potential solutions, is to ask for and discuss other experiences of hosting ProcessWire in a horizontal scaling environment. What solutions did you come up with (if you want to share them) and are there other potential issues we maybe haven't thought about? Cheers, Chris
- 3 replies
-
- 10
-
-
-
We recently launched the digital home for the TECH.LAND Xperience, a cross-border innovation festival. The project required a robust system capable of handling complex schedules and providing a seamless, app-like user experience. Technical Stack & Advanced Techniques: ProcessWire CMS & RockMigrations: The flexible backbone for managing dynamic content. We used RockMigrations for a completely code-driven development workflow, ensuring that all fields, templates, and configurations are version-controlled and easily deployable. Modern Frontend Workflow: Built with RockFrontend and Vite, we utilized the Latte template engine for clean, secure, and maintainable markup. This setup allowed us to use a modern build pipeline with HMR (Hot Module Replacement) during development. Tailwind CSS & DaisyUI: For a rapid, modern, and futuristic UI. DaisyUI provided the foundation for complex UI components like the Side-Panel drawers. AJAX, Fetch API & HTMX Integration: To keep the user experience fluid, we implemented a decoupled approach for session and speaker details. Instead of traditional page reloads, content is fetched dynamically from dedicated ProcessWire endpoints (/ajax/speaker/, /ajax/event/). Interactivity with Alpine.js: We leveraged Alpine.js for lightweight frontend logic, managing the state of the program filters and the dynamic drawer UI without the overhead of a heavy framework. Dynamic Drawer UI: Speaker biographies and session details are presented in a modern Side-Panel component. This allows visitors to explore details without losing their position on the interactive timeline. Hash-URLs & Deep Linking: We implemented Hash-based URLs for the drawers. This ensures that every session and speaker has a unique, shareable link that opens the corresponding drawer automatically on page load, while also supporting the browser's "back" button functionality. Interactive Program Timeline: A high-performance schedule with four parallel stages. Modular Content with RockPageBuilder: For editorial flexibility, we used RockPageBuilder, allowing the team to create complex landing pages with modular, reusable components. Performance Optimization: Fast loading times were achieved through WebP delivery, lazy loading are integrated into our Vite build process (custom module). Key Modules used: RockMigrations: Code-first field and template management. RockFrontend: Vite integration and Latte support. RockPageBuilder: Modular content blocks for editors. SeoMaestro: Comprehensive SEO management. TracyDebugger: Indispensable for rapid development and debugging. Key Success Metrics: 5,000+ Visits shortly after launch. High Engagement: Seamless navigation through complex datasets with zero layout shifts. Editorial Efficiency: Automatic session-to-speaker assignment and drag-and-drop scheduling. complete case-study in german: Explosives Wachstum: Über 5.000 Besucher für die TECH.LAND Xperience kurz nach Launch Visit our website for more insights: dotnetic.de techland-xperience-dotnetic-referenz.mp4
-
- 14
-
-
-
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.
-
@nbcommunication thanks for testing it out! I tried to replicate the steps you took but my results are still the same. First, outputting the srcset array gives this: array 0 => '/site/assets/files/1651/startbild_architektur.640x361-srcset.jpg 640w' 1 => '/site/assets/files/1651/startbild_architektur.1024x578-srcset.webp 1024w' 2 => '/site/assets/files/1651/startbild_architektur.1500x847-srcset.webp 1500w' 3 => '/site/assets/files/1651/startbild_architektur.1920x1084-srcset.webp 1920w' 4 => '/site/assets/files/1651/startbild_architektur.2550x1440.2550x1440-srcset.jpg 2550w' Note: The webp images are not created in the first place, only after reloading the page they get generated from the -srcset.jpg versions (depending on the current screensize, thats why the array is mixed with jpg and webp images). What I still don't understand is that for the largest image variant - 2500px in width - the webp image variant gets created in the file system but is never ever used in the srcset attribute. I extended my browser window width on > 1920 to make sure it will be loaded. In my case the max size for an image variant hast to be lower than the size given in the config. Only then it will be used in the srcset. That's why I am using 2500px instead of 2550px for the srcset in the module settings. $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; I entered a webp quality setting of "1" in the module settings but this setting is not applied. All webp variants were created at 90% quality based on the filesize. This behaviour is the same on all of my local DDEV projects and on the live servers. I don't use Imagick though, it's the standard GD engine instead.
-
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/
-
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/
-
Hi @Stefanowitsch, I've tested based on the information you've provided and it isn't replicating: <?php // /site/config.php $config->imageSizes = [ 'title-img' => [ 'width' => 2550, 'height' => 1440 ] ]; // output, original pageimage is > 3000px wide echo print_r(explode(', ', $pageimage->size('title-img')->srcset([ 640, 1024, 1500, 1920, 2550, ])), 1); // result Array ( [0] => /site/assets/files/1031/very_large_array_clouds.640x361-srcset.webp 640w [1] => /site/assets/files/1031/very_large_array_clouds.1024x578-srcset.webp 1024w [2] => /site/assets/files/1031/very_large_array_clouds.1500x847-srcset.webp 1500w [3] => /site/assets/files/1031/very_large_array_clouds.1920x1084-srcset.webp 1920w [4] => /site/assets/files/1031/very_large_array_clouds.2550x1440.2550x1440-srcset.webp 2550w ) With module config webpQuality setting at 85 With module config setting at 10 With module config empty (defaults to 90 - there was a bug here, fix to be pushed shortly) The quality setting in the module config is definitely being used in this case. Reviewing the above, I'm quite surprised at the difference in file size between 85 and 90. There has to be something else going on here, maybe the image sizer engine (Imagick used here but that about as far as my knowledge goes on these things). Do you have access to any other server environments to try to replicate the test on? I've run this on a dev server and a production server which have different setups with the same result on both. Cheers, Chris
-
Thanks again! It seems that one or two things are still not working correctly. First the webp image quality setting is still not applied. However the created webp versions have roundabout 50% of the original JPG image size and still look excellent so I don't bother about that. Another problem is that the srcset() method now outputs JPG image paths exclusively (in each case), even when there are webp images available that are way smaller than the JPG versions (Enable webp images ist set to "yes" in the backend). Does this has to do with the latest changes? <img srcset="/site/assets/files/1264/startbild_architektur.640x412-srcset.jpg 640w, /site/assets/files/1264/startbild_architektur.1024x659-srcset.jpg 1024w, /site/assets/files/1264/startbild_architektur.1500x966-srcset.webp 1500w, /site/assets/files/1264/startbild_architektur.1920x1236-srcset.jpg 1920w, /site/assets/files/1264/startbild_architektur.2500x1610-srcset.jpg 2500w" src="data:image/svg+xml;charset=utf-8,%3Csvg xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg' viewBox%3D'0 0 2550 1642'%2F%3E" sizes="auto" alt="" uk-cover="">
-
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?
-
Thanks @Robin S for this great module – and all your other great modules, too! I am using really a lot of them, and the number is still growing 🙂 DelayedImageVariations works perfectly with JPEG images. But unfortunately, it does not work in my case, because I am using WEBP images, like so: $image_url = $image_object->size(1200,400)->webp()->url; So I get real 404 pages for the generated WEBP-URLs, which result in empty image frames on my website. Is this the expected behaviour, i.e. is WEBP not supported by DelayedImageVariations? Or am I doing something wrong? Additional Info: I am currently not using the .htaccess WEBP to JPEG fallback stuff, which is described here https://processwire.com/blog/posts/webp-images-and-more/#strategy-2-delivering-webp-and-automatically-falling-back-to-jpg-png , because I am using <picture>-tags with srcset everywhere. And also the webpAdd option in $config->imageSizerOptions is set to `false`, which I believe is the default. My site also doesn't use any caching at all. [ Also I just found out, that the "Render Queued Variations" Feature somehow generates the missing WEBP images, too – even if they are not displayed on the "Render Queued Variations" output page, where only the JPEGs are displayed. Although it once takes a long time to reload the frontend page, after using "Render Queued Variations". So it could also be that the WEBPs are generated only on the frontend. But they won't be generated without hitting "Render Queued Variations" first. ]
-
Here's another website that i recently made that I would like to share with the community: https://www.w2-ingenieure.de/ W² Ingenieure (which is german and translates to "W² Engineers") is a small office that offers that develops, modernizes, and optimizes living and working spaces in Germany like: Schleswig-Holstein, Hamburg, and Lower Saxony. Whether for private households, commercial enterprises, public institutions, or industrial plants – they plan and implement customized solutions for even the most complex requirements. This project is a redesign of an existing website. While the old website had plenty of good content, there were multiple flaws in the design (especially the mobile version of the website) so my main task was not to make a from-the-ground-new-concept but to give it a better, functional and more polished look based on the CI. As we are talking about an engineering company that offers planning for the construction industry the look of the site hat to be sleek, clean, somehow modern and overall "serious". We are not talking about a design-agency website here. Tech Talk: - UiKit as frontend framework - RockPageBuilder for content creation and editing - TextformatterRockDown to enable headline formatting - RockFrontend for Ajax Endpoints (used in form submissions) - RockDevTools for Asset Management and Minification - SEO Maestro for SEO meta data - PageImageSource for webp image creation - FileMover as a workaround for a global media management solution - WiremailSMTP to handle form submissions So here it is: The website consists of several page templates, including: - Homepage - Content Page - Project Page - Job Page - etc. The Homepage and Content Page templates can be populated with pre-defined content-blocks via @bernhards RockPageBuilder. This is straight-forward and easy-to use. The user can chose between multiple content elements and place those elements in any order they want: For Example we have: - Textfields - Teaser in multiple variants - Description Lists - Hero Title Image Sections - etc. Once added the content can be edited directly in the frontend or inside a convenient popup window (or from the backend page edit view of course). Other templates like the Project Page offer a more strict, predefined, layout to achieve a uniform look throughout any project page that is crated. These type of pages can be populated from the backend more easily: I have to keep my attachment file list small, so please have a look on this site for yourself and don't hesitate to ask any questions if you would like to know more about the tech in the background. Have a great week! Stefan
-
- 16
-
-
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
-
The output of both is: "0 Bytes" I then tried this: <img src="<?php echo $image->size(2550, 1440, [ 'webpQuality' => 10, 'webpAdd' => true, 'webpOnly' => true, 'suffix' => 'q10', ])->webp->url; ?>" /> Which results in in a "502 Bad Gateway" error (for the jpg image file path), because the img src in the DOM refers to the "jpg" version: <img src="/site/assets/files/1651/startbild_architektur.2550x1440-q10.jpg" width="2550" height="1440" sizes="auto" alt="" uk-cover=""> The jpg version however is not created (probably because webpOnly is 'true'). The webp version is created in the filesystem (and the quality setting is working!) but this webp version is not used in the src attribute.
-
@nbcommunication Hello! It's me once again. After excessive testing I found out that the modules webp quality settings were never applied to generated webp iages when outputting the srcset like this: <img srcset="<?php echo $image->size($imgFormat)->srcset ?>" ... The webp versions that were created always used a quality setting of 90%, no matter what I entered as value in the module settings. The solution: I had to place this line in my config.php to kind of "override" the default webOptions of ProcessWire: $config->webpOptions = array(); By the way the default options are set to this: 'quality' => 90 'useSrcExt' => false 'useSrcUrlOnSize' => true 'useSrcUrlOnFail' => true Only then (when the 'quality' option is missing) the entered value from the module settings is applied correctly. I did not test this with the $image->render method, though. Can you confirm if this is the intended behaviour?
-
@nbcommunication Thanks for the hint. I think there indeed lies my problem. Let me try to explain: I am using the size method to crop images to use the aspect ratio / format that I need for my layout (for example a hero slider uses a 16:9 image ratio). The $imgFormat value in that case would look like this: 'title-img' => [ 'width' => 2550, 'height' => 1440 ] <?php echo $image->size('title-img')->srcset() ?> So then the PageImage module takes this image to create variations based on the set rules in my module settings: 640 1024 1500 1920 2550 So there exists a 2550px version of the image (created by the size method) but I have to include this width in the size set rules, otherwise only the image variations up to 1920px will be used in the srcset attribute in the DOM. And this might be the problem: When adding the 2550px rule the cropped 2550px wide jpg image is used int the srcset attribute and not the wepb version (all other image sizes use the webp version, they just weren't created yet - instead queued - when I testet it lately). So to make it finally work for my case I have to crop the image larger than used in the srcset. For example 3000px wide. In that case the 2550px webp version is generated and used correctly together will the other sizes from the set rules in webp format.