All Activity

Looking good, Mike. It's great to see image options. And thanks for the MediaHub mention too 🙂

@ryan Thank you for your continued progress on the Agent Tools module. It is amazing to see how well ProcessWire is capable to work with AI already. 🙂 Here are some thoughts/suggestions I had while using the Page Engineer module: After submitting a prompt you get the answer two times: As notification and in the page engineer field. Wouldn't it be better to just get the answer one time? After submitting a prompt you cannot see the prompt anymore. Maybe it would be nice to have the prompt above the answer, f.e. for screenshots or context. Field visibility: Currently the field is either at the beginning/between/end of the other fields or as tab. Maybe it would be nice to have a fixed field visibility (in the corner) that you can toggle via icon. But I know that would be a new general field visibility. Prompt animation: The new prompt animation is cool, but maybe a little too much for my taste. It feels like entering the matrix after submitting a prompt. But that is just my taste and this is really subjective. 😅 Would it be possible for the Page Engineer to display results that don't change the page without reloading the page editor via Ajax? I guess that will be hard to manage, which result changes the page or not, but right now the page gets saved even without changes. I mentioned this a while back and this would be a general suggestion for the Agent Tools module: It would be cool, if the engineer would have a file field to directly give the engineer files. For example "Create a new image element in the content field with this image." The new tab navigation is nice to switch between the categories. In the Migrations tab a little space for the button would be nice, if you have no migrations. I am exited about the future of the Agent Tools module. 😀

New version (v 0.55.0) – This changes everything Barely a week on from the public beta release here's where Image Library went next. Short version: it grew a brain for duplicates, and that quietly changed what the module is for. How it continued. Barely a week after the first post, a different client site handed us the next problem – and this time it wasn't missing metadata, it was duplication, and a lot of it. ~10,000+ images on the site, of which only ~3,500 were actually unique – meaning roughly 6,500 exact-or-near-duplicate copies of the same pictures scattered across lead_image, body_images, galleries, repeaters, you name it. Years of "just re-upload it on this page too." So we went looking for a way to make duplicates stop mattering – without migrating anything. The full rationale is in the repo (docs/deduplication-design.md); the gist: Give every image a content identity – a byte hash (xxh128, md5 fallback), computed lazily and cached by path+size+mtime, with a cheap size/dimension pre-filter so we only hash real candidates. Group identical images into clusters = "this picture, in these K places." Then duplicates become manageable, not just visible: a Duplicates filter, a copy-count badge per image, an expandable cluster in the table (a cluster modal in the gallery), where-used per cluster, and the big one – edit-once-propagate: caption/tag a cluster once, written to all copies. Pure DB writes, fully reversible, zero filesystem risk. Optional, opt-in, reversible disk reclaim: byte-identical copies get hardlinked onto one inode, so 6,500 copies stop costing 6,500× the bytes. Lossless, runs in the background (on save + hourly), with Scan / Re-measure / Revert tools and a live "disk reclaimed" readout. (We tried perceptual near-dup detection too – dHash/pHash — and pulled it: it grouped unrelated photos that merely share a tonal layout. Detection-only, never destructive, and still not trustworthy enough to ship.) And then it clicked. What we'd built, almost by accident, was a DAM without the DAM. Strip a digital-asset manager down to what it actually gives you: one logical asset instead of scattered copies, metadata edited once as a single source of truth, a "where is this used," a central place to browse and pick – and storage that doesn't pay for the same file twice. Every one of those falls straight out of the content-identity + cluster technique. The difference: we get it over the images already sitting in native FieldtypeImage fields – the asset layer is synthesised from what's there, not a store you migrate into. No central library, no new page type, no migration, and crucially no template changes. That last part is the whole point: on some of these projects, re-wiring every template and every chunk of content onto a new media model would be a multi-week job and a regression-test nightmare. We just… didn't have to – and the editors get the DAM experience anyway. A word on MediaHub. If you are starting a fresh project and want a proper central media model from day one, MediaHub is – in our opinion – the best option out there. Huge thanks to @Peter Knight for letting us test it; we're genuinely impressed, it's a lovely piece of work. Different tool, different job: new site → MediaHub. Existing site full of scattered images → this. Image Library isn't trying to change the way PW image handling works; it's a layer over the files, pages, templates, methods and structures you already have. Which is exactly the rule we build by: must work with existing installations, as-is; plug & play – install, open, done; no rebuild, no migration, no new fields, no template surgery; no new workflow for editors; and – new – front-end-editor capable. BAM. 💥 That last one is the other big addition: two optional, off-by-default picker add-ons: Choose from library – a button on every image field to assign an existing library image without re-uploading (version-aware: inside a page version it lands in that version's folder, and it's deduped on the spot). Insert from library – a button in TinyMCE and CKEditor that drops a library image straight into rich text… and it works in the front-end inline editor (PageFrontEdit) too. Editor live on the page, click, pick, done. Plus, while we were in there: Collections – a hand-picked set of images no filter could reproduce (tick the ones you want, save them as a named tab). Recalled by a tiny ?coll=<id> link – the image list lives in your user profile, not the URL, so a 100-image collection is still a ~12-character link. Add/remove just by clicking a collection's tab while images are selected (the cursor tells you which way it goes), and collections are themselves filterable. Masonry gallery view – height-balanced (shortest-column) packing, natural aspect ratios, hover-revealed selection checkboxes – the same selection that drives bulk edits and collections. Status. v0.55.0 – public beta on top of the original. Module + docs (EN + DE concept, plus the dedup design doc) on GitHub / the Modules Directory. As before: feedback very welcome – especially duplication in the wild, odd Fieldtype combos in custom-field templates, ProFields, deep Repeater/RepeaterMatrix nesting, and anything the front-end picker trips over. Cheers, Mike

Hi @ukyo, thanks for this great module! It's a real time saver 👍 According to the README, this module supports focus and position mapping, but the focal point is ignored when rendering the image. It simply performs a center crop. Focus and zoom applied in Image field: Rendered output via $image->render("landscape"):

Hi @maximus I am using SEOMestro at the moment but saw that this module has a convenient migration feature for that case. Really nice! Is it possible to automatically add a "suffix" to the meta_title? What I like to to is created titles like: "Home | my-company.com" or "Our Services | my-company.com" Where the first part is the actual page title and the second part is my suffix text. Is it somehow possible to define this pattern in the global configuration of the module inside this global defaults JSON? { "meta_title": "field:title", "meta_description": "field:summary|truncate:160" }

I'm trying out this module at the moment. It's looking really good so far except that my top page and top landing and exit pages are all /pwna-track/ Am I missing a step to exclude pwna-track ? Thanks for all your effort though - it's a great looking module and something I'm sure I'm going to find really useful.

@zilli this is such a great progress review you gave us here. From "not knowing where to start/anything" to trying and exploring, finding solutions and new options, and even noticing that nothing is perfect on first try but iterating on it can you bring you quite far. 3 months ago I had to ton of ProcessWire skills in my projects to be able to get things done in a proper and clean way, but since Ryan started to explore and use AI more and brought us AgentTools, I skipped my skill files in projects that use AgentTools. It's working perfectly fine so far. Modules are sometimes edge-cases but at the end everything started to work as intended. I love to explore more tools, guidelines, agents, harnesses, models, and whatever the latest hype is. But at the end of the day I mostly only use OpenCode with Z.AI and the OpenCode Go plan to get things done. Sometimes for really huge tasks I try the Opus models through Windsurf/Devin ($10 legacy plan ftw!). What I learned with trends and hype cycles... wait a week or two. If people still talk about it, try it. Otherwise don't even care. Gastown? Beads? OpenClaw? Ralph Loop? Karpathy XYZ? SpecKit? [...] - meh. Not really. Looks nice, may work for some, but not for me.

@cb2004 There was a lot of FA data that didn't need to be there. I've deleted it, so we should be down to ~1.6 MB now. @jploch The problem I ran into is that it's just too many icons to display at once, it made the whole window lag. We could always add a link to a page with all the icons on this site, or at the font awesome site?

Respectfully disagree here. I believe ProcessWire follows a convention where it's air-gapped / doesn't rely on outside servers like CDNs for libraries. It's a potential security issue and goes against things being fully unified. Also it doesn't pass the "can I work on a site without internet" test.

Update: Withdrawals tab + Stripe custom fields (v 1.1.0) Hi all, a quick update on StripePlAdmin, the companion admin module for StripePaymentLinks. Two new things in this release: Withdrawals tab Surfaces the right-of-withdrawal (cancellation) requests that the main module stores per user (spl_withdrawals repeater). Same architecture as the other tabs — configurable columns, status/date/search filters, CSV export — plus inline-editable status and admin notes that save immediately via a small CSRF-protected AJAX endpoint. Consumer name/email link straight to the user account. The tab only shows up when the main module actually provides the feature. Custom Fields column Stripe checkout custom fields (the ones you define on a Payment Link) are now read out of the stored stripe_session meta and shown as Label: Value pairs — text, numeric and dropdown fields (dropdowns mapped back to their option label). It's a configurable column on the Purchases tab, flows into the CSV export, shows up in the purchase-details modal, and is included in the search. As always, feedback welcome, Cheers, Mike

Yeah, this definitely needs to load from CDN.

This is now a massive download with the Font Awesome changes.

Hey, just a follow up here 🙂 Following the advice in this thread, I’ve been pretty happy with Codex CLI so far. I also tried Claude, but I ended up using Codex more. From what I’ve seen, both can do the job well. Most of the time, when something goes wrong, the problem is on my side 🫣 Usually weak planning, a vague prompt, or both. I’m still very much at the beginning, so there’s a lot to learn. But these are a few things that have been working for me: I treat AI like a very competent junior developer. Most of the time, I plan the task first and then ask him to execute. I might promote him to associate if things keep going well 🤣 I’m using the $20 Codex plan. You can actually get quite a lot done with it if you spend some time planning before asking it to code. I’ve just started using RTK to save tokens. I’m not sure yet whether it’s worth it, but I’m giving it a try. I’m comfortable with the CLI, so my setup is pretty simple: Arch Linux, Codex CLI, phmate, sqmate, and gog. I don't use MCP. Reading the model documentation and best practices has helped a lot too. It gives you a better understanding of how the model works. From there, it’s much easier to build your own workflow instead of just throwing prompts at it and hoping for the best. One of the most important things for me has been mindset, and I had to work on that quite a bit 😅 Before AI, building a new feature or even fixing bugs could take days, weeks, or months. Today, you can sometimes get something working in minutes. That’s incredibly powerful, but it can also be dangerous, especially for newer developers. The temptation to expect everything to be done in minutes or hours is huge, but reality is often more complicated. Maybe things will be different in the future, but for now, I’m perfectly happy spending a few days on something that would have taken me months before. That still feels like a big win. Finally, I wanted to ask @ryan and the others: are you using any additional guidelines, like the Karpathy Guidelines?

Hi everyone, Accessibility overlays have a bad reputation — mostly because they're sold as SaaS, phone home to third-party servers, and charge monthly fees for something that should be built-in. Ally is different: self-hosted, MIT, no external requests at runtime. GitHub: https://github.com/mxmsmnv/Ally What it does Adds an accessibility panel to your site's frontend, powered by Sienna (MIT). The JS bundle and OpenDyslexic font ship with the module and are served from your own server — nothing loads from external CDNs at runtime. Font size adjustment Dark, light, and high contrast modes High/low saturation, monochrome Dyslexia-friendly font (OpenDyslexic, bundled locally) Highlight links and headings Letter spacing, line height, bold text Reading guide, stop animations, big cursor 53 languages with auto-detection from html[lang] or browser settings Full ProcessWire multi-language support — maps $user->language to the correct locale automatically Configurable position, offset, button size, and accent color Skips admin pages and Chrome Lighthouse by default No build step — prebuilt JS bundle included. One caveat: the widget is injected via Page::render hook. If you serve pages through ProCache static HTML, the hook doesn't run on cached pages — exclude those pages from ProCache if you need the widget there. Overlay widgets supplement, but do not replace, accessible markup. Use Ally alongside good semantic HTML, not instead of it. Requirements: ProcessWire 3.0.200+, PHP 8.1+ MIT License.

Hi @ukyo, when this module is installed, attempting to crop an image using the 'Crop' function results in an error, which prevents the image from being cropped: Given filename is not a file or link: /../site/assets/cache/WireTempDir/.PFM0.80307900T1780994336Rbdli4W6dXi/0/abc.713x276.jpg-tmp.jpg

@AndZyk I know I can look them up, but it would ne nicer to have them in the backend directly without opening a new page. Since we use them so much in the backend, I think it's worth it.

@jploch You could search the icon on Font Awesome (https://fontawesome.com/search?s=solid&ic=free-collection), but yes it would be more convenient to have a grid view. 🙂

@ryan Great update! I really love the updated icons in the backend! One issue I have with the current implementation is that we’re missing the grid view from before. I know there are a lot more icons now, but the grid view would still be helpful. With the new update, you always have to type something into the search bar first, but often I am browsing for a specific icon visually, before knowing the name. Another option would be a custom seletct that shows the icons before the text.

I'll take a look in the near future, I think it's possible to automate this somehow.

There are still a few modules left to do...

So... to keep up with your awesome modules, I decided to up my caffeine-intake to 1,200mg per day now. I love it! 🤯

Thx for the loveletter @gebeer and others. I thought I've already replied, but it seems that post got lost. I'm getting a lot of 500 errors these days in the forum. I wouldn't say I've quit the community. What I've stepped away from is making significant investments in the ecosystem and trying to build a business around it. That didn't work out for me, so I had to move on. As for RockMigrations: I understand and even share some of the concerns raised here (even though I find terms like "bloated nature" a bit harsh). It started as a somewhat experimental proof of concept, and yes, I built it with my other modules in mind. At the same time, it has always been completely free because I felt it was too important to put behind a paywall, and it has always been open to PRs. 😉 Nevertheless, over time it turned out to be very reliable and became an essential tool for my work. Considering that all my ProcessWire projects from the last decade rely on it, I expect it will remain supported for quite some time. That's the status quo. What I did find a little surprising, though, was seeing migrations become part of the core years later, seemingly almost overnight, while RockMigrations and the other migration modules weren't much of a reference point in that process. Unfortunately, it's not the first time I've seen that happen. What I learned from that experience is that it's not something I can build a business on. So I really haven't quit on the community — I've simply moved on from trying to build a business around my ProcessWire contributions, and my reduced forum activity is just a consequence of that. But I check in from time to time to see what's going on and I try my best to be available and helpful if anybody needs anything related to my modules. 🙂

Hey @ryan - Agent Tools still has the same deprecation error Deprecated: Function curl_close() is deprecated since 8.5, as it has no effect since PHP 8.0 in .../pwtest.test/site/modules/AgentTools/AgentToolsEngineer.php:2296 If you explicitly tell your AI tool to remember to always add a PHP version guard to this function, it should hopefully stop making this mistake.

Hi @maximus - I have a fairly detailed hook set up for SEOMaestro. It tweaks the homepage title, but most importantly it sets an automatic description for staff bio pages amd blog posts from existing text fields. It also pulls the first image from the blog post for the ogimage. If I switch to Ichiban I think I will need to do something similar so that staff don't need to manually enter separate descriptions for these pages. Is there an available hook to replicate this? And, if so, could the dashboard process this hook so it knows that these pages actually do have completed descriptions. $this->wire()->addHookAfter('SeoMaestro::renderSeoDataValue', function (HookEvent $event) { $group = $event->arguments(0); $name = $event->arguments(1); $value = $event->arguments(2); $p = $event->wire('page'); if($p->template->name == 'admin' && $event->wire('process') == 'ProcessPageEdit' && $event->wire('input')->get('id')) { $p = $event->wire('pages')->get((int) $event->wire('input')->get('id')); } $service_name = $event->wire('siteSettings')->serviceName ?? 'My Site Title'; if($group === 'meta' && $name === 'title') { if($p->id === 1) { // remove automatically appended [[service_name]] from homepage because we add it to the front in the SEO tab of the homepage $event->return = str_replace(' | [[service_name]]', '', $value); } else { $event->return = str_replace('[[service_name]]', $service_name, $value); } } // people (staff & experts), blog posts — keep the meta description to whole words under 155 chars, // using the editor's explicit description when set, otherwise falling back to summary|body. if(($p->template->name === 'person' || $p->template->name === 'blog-post') && $group === 'meta' && $name === 'description') { $source = $value !== '' ? $value : $this->wire('sanitizer')->textarea($p->get('summary|body')); $event->return = $this->wire('sanitizer')->truncate($source, 155); } elseif($p->id !== 1 && $group === 'meta' && $name === 'description' && $value == '') { $event->return = $this->wire('pages')->get(1)->seo_fields->meta_description; } if($p->image && $value !== "" && $group === 'opengraph' && $name === 'image') { $event->return = $p->image->httpUrl; } elseif($p->template == 'blog-post' && $p->images->count() > 0 && $value !== "" && $group === 'opengraph' && $name === 'image') { $event->return = $p->images->first->httpUrl; } });

Hi Krlos, Thanks for confirming, and good catch on the admin preview. The frontend output was already resolving the Combo image correctly, but the page editor preview JavaScript was still only recognizing simple tokens like {image} and field:image. It did not recognize dotted expressions such as {combo.image} or combo.image when deciding whether to use the resolved URL for the preview. I’ve fixed this in v0.1.2-alpha. After updating, the resolved image path and the social preview should now appear in the editor for Combo image sources as well.