Leaderboard

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!

As some of you might know from my monthly newsletter I have been struggling with how to proceed with my commercial modules. It's a long story, but last year I reached a point were something had to change. The main problem is that building and selling modules for ProcessWire has never been sustainable for me. Not even close. It has been a lot of work to build the shop. It has been a lot of work to provide proper docs. It has been a lot of work to create videos about the modules so that interested people can get an idea of my modules. That's fine. I knew it would probably not be easy. But I wanted to try 🙂 You never know if you don't try. And I've had hope that it is possible. Unfortunately I don't have this hope any more and that's why I have to draw a line under it. That's also fine. I've learned a lot and I'm really thankful for anybody that has sent some Euros to a stranger that they have never met in person and that excludes any refund 😄 So for me the decision was taken. It took me quite some time to get there, but here we are. There was just one problem left: My clients. They have put trust in me and I didn't want to disappoint them. Just drawing a line might be a good solution for myself but might be a terrible solution for them (and their clients as well). Just not providing updates and keeping selling them is also not my style. With open sourcing my modules I try to find the best solution for everybody involved and I want to especially thank @FireWire for helping me get there 🙂 What does that mean? I'm using my modules in many of my own projects, which means that I will likely keep them alive for some time. On the other hand I don't plan to develop a lot of websites any more and many modules are somewhat feature complete as @FireWire helped me to realise, so there are no bigger updates planned for any of my modules at this time. Also, none of my modules is tested with the new admin theme. If you want to help out on that front, I'll be happily merging PRs, but as I'm not using it myself I'm not going to fix any issues or adding support for it in my spare time. So if you want to keep using my modules: Go ahead and have fun! 🙂 If you find the modules helpful it's always nice to let me know. Hope this is a good solution for everyone! Thx for reading and all the best.

Seems this module has not had its own forum thread. Now it has. https://github.com/baumrock/RockIcons

@olafgleba @maximus I just pushed an update to kickstart.php. It is now possible to install any arbitrary Site Profile! You can either provide a URL to a ZIP file or upload a local ZIP file directly within the tool. The script extracts the profile to the correct location, allowing the standard ProcessWire installer to pick it up seamlessly. Give it a try and let me know if it works for your custom skeletons.

Hey @ryan, hey all readres, I'd like to propose two features that would help those of us working with business and organizational clients. OAuth 2.0 Login Support Several of our clients use Microsoft 365, and it would be nice to integrate their websites seamlessly with e.g. Microsoft Entra ID. Native OAuth 2.0 support would allow users to log in with their organizational accounts instead of managing separate credentials. For an urgent case I'll try to set up @flydev's module (https://processwire.com/modules/oauth2-login/) but unfortunately the creation of users is not yet (?) possible. Microsoft Graph API for Email Delivery As said before, more and more peopele rely on Microsoft 365, and traditional SMTP with basic authentication is being phased out. Supporting Microsoft Graph API would allow us to: Use OAuth 2.0 tokens instead of storing SMTP passwords Leverage existing Microsoft 365 infrastructure Ensure better deliverability and avoid authentication headaches Native support for both would make ProcessWire from my perspectibe a more compelling choice for organizations looking for enterprise-grade SSO and email solutions.

@BrendonKoz breakpoint and aspect ratios not comma separated, its line by line config. its a copy paste input field issue. I am using this external library on all my project. I decide to make it a module. Now its a module. There is base Pageimage library problems for me and there is no solution until now: https://github.com/processwire/processwire-issues/issues/2048 https://github.com/processwire/processwire-issues/issues/2016

BTW - just again: this module is outstanding - love it so much (beside of course PW and other modules :) But the UI is just incredible easy :)

Cool @snck very interesting read. Glad you found a good solution for your problem and glad that RockMigrations helps you as much as it helps me 🙂

Hi @bernhard — first of all: thank you again for RockMigrations. It has become one of those “can’t-live-without” tools in my ProcessWire projects and makes CI/CD + deployments incredibly smooth. Why I needed a workaround (shared hosting reality) In this client project I migrate pretty much everything via RockMigrations: fields, templates, roles/permissions, installed modules — and also some pages/permissions that are created dynamically based on constants/config values that change from time to time. That works great conceptually, but on a very slow shared host it led to painfully long migration runs even when there was nothing to change. A lot of my migrations are “dynamic config” style and get evaluated every deploy, which was costing me minutes per run (and that adds up quickly with multiple deploys/commits per day). A tiny helper module: hash-based skipping for config migrations I wrote a small helper module (not meant to be more than a little utility) that helps specifically with this scenario: Build a migration $config array (can include dynamic parts). Normalize + hash the config. If the stored hash for a key matches, skip running the migration. If it differs, run it and store the new hash. So migrations only execute when the effective config changed. How I use it (complete example) This is how it’s used in my migrations (example shortened, but complete in terms of usage): <?php namespace ProcessWire; use RockMigrations\MagicPage; class AuthorPage extends Page { use MagicPage; public function migrate(): void { /** @var RockMigrations $rm */ $rm = $this->wire->modules->get('RockMigrations'); $speed = $this->wire->modules->get('DlfMigrationSpeedUp'); $config = [ 'fields' => [ 'firstname' => [ 'label' => 'First name', 'type' => 'FieldtypeText', ], 'lastname' => [ 'label' => 'Last name', 'type' => 'FieldtypeText', ], ], 'templates' => [ 'author' => [ 'fields' => [ 'title' => [ 'columnWidth' => 50, 'label' => 'Display name', ], 'firstname' => [ 'columnWidth' => 50, ], 'lastname' => [ 'columnWidth' => 50, ], ], ] ] ]; $key = 'template:AuthorPage'; if ($speed && !$speed->shouldRun($key, $config)) { // unchanged -> skip } else { $rm->migrate($config); if ($speed) $speed->remember($key); } } } Important limitations (when this does not apply) This only works if the migration outcome is fully determined by the config you hash. It’s not a good fit if relevant parts can be changed outside code, for example: field/template settings changed in the PW admin GUI, manual permission tweaks, any DB drift that is not represented in the hashed config. In my case it’s safe because I enforce “everything via RockMigrations/API” for this instance — but it’s definitely not something I’d blindly recommend for every setup. Performance impact (real numbers) On that shared host, some of my “dynamic config” migrations were extremely slow even when they effectively had nothing to change. Example excerpts from one run before the helper (I’m anonymizing the real class names here): Before: TemplateXPage::migrate() 53.434s TemplateYPage::migrate() 29.347s TemplateZPage::migrate() 20.431s …many more similar steps… Total runtime in that log was ~226s. With the helper enabled, unchanged migrations are skipped and return immediately: After (unchanged config): TemplateXPage::migrate() 0.000s TemplateYPage::migrate() 0.000s TemplateZPage::migrate() 0.000s …everything essentially no-op… Total runtime (from the log): ~0.72s. That’s a night-and-day difference for repeated deployments where the effective config didn’t change. Code (module) on Gist I didn’t want to paste the whole module here; the code is in this Gist: https://gist.github.com/fsnck/cf7799c1f761681cc5f0dea13e3b802a If anyone has thoughts on edge cases or improvements, I’m happy to discuss. And again: thanks @bernhard — RockMigrations is awesome.

I found a solution - even though I don't understand in depth, what is going on: The Userrole not only needs the right to delete the content-element pages, but also needs the right to use the delete button in the pagelist: =>modules => processPageList => allow trash for non superusers Perhaps this will be helpfull for others ...