Leaderboard

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.

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 🤖

Whether in the forum or in a blog post or anywhere, I wouldn't post anything that I knew contained incorrect info. The API.md files I've been adding to the core are started by claude sonnet, and it uses my phpdoc and the method implementations to craft the text. After that I spend quite a bit of time fixing details, changing wording, creating better example code, etc. Then after I finish with my changes, I send them to Codex GPT 5.5 to test all the examples and make sure everything works as written. So when I mentioned AI generated content I suppose I should say that it's much more collaborative than that. If I were to post one as a blog or forum post then it would go through the same process and scrutiny. The main thing is that I don't have as much bandwidth as I'd like for writing blog posts, so they end up being very occasional. But I think having more regular blog posts could be helpful for attracting new users. Maybe I should just make the weekly posts blog posts. But I like posting in the forum because it's not as formal, and of course more likely to spawn good discussions, like here.

This week on the core dev branch, the biggest addition was the upgrade from FontAwesome v4 to FontAwesome v6. This greatly increases the number of icons available in the admin. And while the new icons are in the same family as the old ones (still FontAwesome), they have a little bit different personality too. You can still use the v4 icons if you want by setting $config->adminIcons('version', '4'); though I recommend leaving it at the default, which will use v6 icons for AdminThemeUikit and v4 icons for older admin themes. There were several other updates this week to the core, which can be found on the dev branch commit log. The AgentTools module also received some significant updates this week: New scheduled tasks feature (this one is my favorite). Enables AgentTools to run tasks automatically at scheduled times or intervals. Improved Agents/models management screen (see screenshot). New tabs navigation makes it easier to get around in AgentTools. New debug and traces feature to track what agents are doing behind the scenes. New persistent memory feature, enabling agents to save a permanent memory across all sessions, when you ask them to. New guards on agent behavior, in case one goes rogue and decides to go places where it shouldn't. Note that SiteEngineer and PageEngineer each have their own persistent memory. SiteEngineer's persistent memory can be modified in the module configuration, while PageEngineer's persistent memory can be modified in your engineer field(s) settings. @wbmnfktr let me know about OpenCode Go last week, which I think is amazing. It provides you access to a whole bunch of AI models and a ton of usage for $10/month ($5 for first month). I have found most of the models to have very good ProcessWire knowledge. I think it's a perfect match with AgentTools because OpenCode provides you with as many API keys as you want. Whereas Anthropic and OpenAI don't include API keys with their monthly plans (Anthropic and OpenAI make you pay by the token with API keys). If you want an extra $5 credit for it use this link and it'll give both of us $5. I'm only posting that because it gives you extra credit, I don't need the extra credit so if we can get @wbmnfktr to post his link, use his instead since he's the one that told me about it. OpenCode also comes with a terminal app that is basically identical to the Claude Code and Codex terminal apps. They apparently have a desktop app too, but I've not yet tried it. If any of you do end up getting OpenCode I'd be curious what models you enjoy the most. So far I'm having a hard time deciding, as they've all impressed me in different ways. Yesterday I setup a scheduled task to "write blog posts" as just an AgentTools test, and do a round robin between the agents, writing blog posts and having different agent proofread them, every 15 minutes. I went to lunch. Then I started getting emails from the agents that they'd finished blog posts. Look at what they came up with (screenshot below). I started reading them, and they are actually fantastic posts. They are so good in fact that I'm tempted to post some of them on the site here, but I've never used AI generated content for this stuff before so am still debating that. What would you do? Thanks for reading and have a great weekend! Blog posts that agents came up with: AgentTools tasks: New AgentTools agents configuration screen: Background scheduled jobs in AgentTools: New icon selection in the core (InputfieldIcon, like used in the Field edit screen) replaces the "show all icons" grid of icons with a search box. FA6 comes with far too many icons to show a grid of them all at once, plus the search is a lot more useful and easy to use.

Hi everyone, I've been building this for a while - a full genealogy system inside ProcessWire. Family trees, people, relationships, sources, documents, DNA kits, research workflow, and GEDCOM export. All inside the PW admin. GitHub: https://github.com/mxmsmnv/Arbor Status: Beta. Usable on a test copy. Always backup before installing. Screenshots: Why ProcessWire for genealogy? Genealogy data is complex, relational, and research-driven - not a blog. ProcessWire's flexible data model and custom DB table support make it a natural fit. Everything in Arbor lives in arbor_ prefixed tables, completely separate from the PW page tree. What it does Multiple trees - owner/public settings per tree Person profiles - names, events, notes, sources, photos, relationships Family/union management - partners, parents, children, relationship types Interactive tree viewer - main person panel, selected-person panel, agenda, legend Places & repositories - archives, sources, citations, documents, document leads Research workflow - questions, tasks, search log, proof conclusions, next actions DNA - kits, matches, segments GEDCOM 5.5.1 and GEDCOM 7 export GEDCOM import foundation (in progress) AI helper via AiWire-compatible providers - research suggestions, name analysis REST API via ArborApi submodule Three submodules: Arbor - schema, models, configuration, permissions, shared services ProcessArbor - admin UI under Setup → Arbor ArborApi - optional REST endpoints Requirements: ProcessWire 3.0.200+, PHP 8.1+, MySQL/MariaDB with InnoDB MIT License.

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

Thank you @ryan. I really appreciate it. But in case anyone wants to try OpenCode Go, please use Ryan's link so ProcessWire development will benefit from it.

Thanks @gebeer! Love is something that unites people. There are different kinds of love and love to a PW module is certainly a valid one. Any kind of love is IMHO an expression of openness to something outside yourself. Willingness to accept and even incorporate something seemingly foreign. Another human being. Another style of writing code. Another vision of the future. Another business model. Another opinion. My relationships with RockMigrations is too of hard road to love. I didn't accept its bloated nature and desire to bring the whole Rock infrastructure with it)) But I learned the way to ignore and work around those. And even built a complex PW scaffolding script using this super module. And I have met its author, a passionate man and developer. I am writing this knowing that Bernhard has almost quit the PW community. I know what brought him to this decision. And that was kind of a lack of love. So I think this post is a great one and I totally agree with it 100%. And I wish that everyone here, including @ryan, @bernhard, @Pete (and actually everyone) would consider finding time, energy... humility and open mindedness to give ProcessWire and its daughter RockMigrations a bit more family love. A love that would raise them both to a greater future. A love that no AI could ever give. A love that is the core of this community which has so much unrealized potential. Peace ☮️

A big thanks to @@Mikel for flagging some of the items which form 1.19.1. Uninstall (fixed) The safety check that requires you to opt-in via `$config->MediaHubUninstall` in `site/config.php` was firing a beat too late. By the time the error showed, companion modules and their pages were already partially torn down. 1.19.1 hoists that check into a `hookBefore('Modules::uninstall')` so nothing is touched if the flag is missing. Also tightened companion module cleanup, admin page deletion, and crop-field removal so the whole flow is now atomic: succeeds completely or aborts cleanly. Import (fixed) Importing existing images on a non-MediaHub site (Setup → Media Hub → Import Existing) wasn't generating thumbnails. Bonus: retina `srcset` (1x/2x) and lazy loading on inputfield thumbnails. Icons (aligned) The library and the MediaHub inputfield each have view-mode toggles (grid, proportional or masonry, detail or list), but 1.19.0 used slightly different icon sets between the two surfaces. 1.19.1 aligns them on the same Lucide set. Labels bug (fixed) The new Labels section in 1.19.0 shared structural class names with Collections. This meant Labels were incorrectly displayed on some Collections filters nd menus. Labels and Collections are now strictly separate row types throughout the sidebar. Full changelog 1.19.1 blog post 1.19.1 download