All Activity

@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.

Yes, I see a lot of issues there, of course I'll fix them! Thanks a lot for testing!

@maximus - this is really great - thank you. I have gone to town with bug reports and feature suggestions on the repo though - hope you don't mind the barrage :)

That’s brilliant 🤩 Thanks for the skill

I’ve been doing regular ProcessWire updates for years, and honestly, they’re usually pretty painless. Ryan keeps things sane, modules mostly behave, and if you don’t wait forever between updates, compatibility drama is rare. But there’s still one part that always felt a bit… clicky. Check module updates. Download paid modules ZIP files. Upload/install. Refresh modules. Commit. Repeat. Then core. Then smoke test. Not hard, just enough tiny steps to make you think: “surely my robot coworker can do this?” So I made a reusable AI-agent skill for doing ProcessWire system updates through DDEV CLI: https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-system-update-cli plays nice with https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-ddev-cli Don't have ddev? Too bad, consider using it or tweak the skill. Or use Ryan's AgentTools module. Your agent will figure it out, eventually. What it does The workflow is basically: Ask ProcessWire what’s outdated via ProcessWireUpgradeCheck Check module requirements before touching anything Update modules first, core second, unless compatibility says otherwise Install public and Pro module ZIPs from the CLI Refresh module caches and verify versions Commit every module update separately Update ProcessWire core last Smoke test the site in a browser (given your agent has the tooling. I use cdp-cli with a skill derived from its readme). Less admin panel dance, more deterministic “do the thing, verify the thing, commit the thing”. The important bit: compatibility first The skill does not blindly follow “modules first” in all cases. Before updating, it checks module requirements from places like: public static function getModuleInfo() { return [ 'requires' => [ 'ProcessWire>=3.0.240', 'PHP>=8.1', ], ]; } …and from the module directory data returned by ProcessWireUpgradeCheck. If a module needs a newer PHP version, the agent should stop and warn you. If a module needs a newer ProcessWire version, that’s a legit exception to the usual “modules before core” rule: update core first, then come back to modules. This matters especially for folks who wait a long time between updates. If you update regularly, you may never hit this. If you update once every few years, dependency gremlins are much more likely. Pro modules too For Pro modules, the skill doesn’t pretend it can magically access your PW account. It scans first, sees which Pro modules need updates, then asks you for local ZIP paths. After that it copies the ZIP into the project cache and uses ProcessWire’s own module installer internals: ProcessModuleInstall::unzipModule() modules()->refresh() modules()->resetCache() Tiny gotcha: unzipModule() deletes the ZIP it extracts, so the skill uses a temp copy. Ask me how I know. 😄 Why I like it The end result is not fancy. That’s the point. It’s just a solid update ritual encoded as a skill: scan first check compatibility snapshot DB update one module verify commit repeat update core browser smoke test For my latest run it took care of TracyDebugger, MaintenanceMode, ProFields Table, ProFields RepeaterMatrix, ProMailer and ProcessWire dev core with clean commits for each step. ProcessWire updates were already pretty friendly. This just removes the boring click choreography. Coffee stays warm. Git history stays clean. Robots get to do robot work 🤖

Hi everyone, Most project management tools are generic. Verk is built specifically around ProcessWire's data model — tasks link directly to PW pages, the calendar reads real page date fields, and content audits run PW selectors. Everything stays inside your install. GitHub: https://github.com/mxmsmnv/Verk Why Verk? Verk means "work" or "task" in Icelandic and Swedish. Short, abstract, and fitting for a tool built around getting things done inside ProcessWire. It follows the same naming approach as other modules in this series — Arbor, Ichiban, Collections — names that mean something without being literal. Screenshots: What it does Dashboard — open tasks, upcoming publications, audit alerts, and active sprint planning Tasks — create/assign tasks linked to specific PW pages; one click opens the page editor directly Calendar — month, week, and quarter views for page publications and task due dates Content Audit — run PW selectors with dot-notation field checks to find missing content Knowledge Base — rich editorial notes organized by category, searchable and exportable Sprints — sprint planning, quarter grouping, task assignment, DOCX export, and progress tracking Key details: Tasks store page_id — page data lives in PW, never duplicated Page Editor Widget injected via hookAfter('ProcessPageEdit::buildForm') — no template files modified Audit to tasks — bulk-create tasks from audit results with page context prefilled Rich text via TinyMCE when InputfieldTinyMCE is installed DOCX exports for task lists, notes, sprints, and knowledge base Return-aware forms — create/edit flows preserve filtered list URLs Requirements: ProcessWire 3.0.200+, PHP 8.0+ MIT License.

Great :-) I have also done a small genealogy/history project with ProcessWire this year: https://www.glashytt.at/