ProcessWire updates are fun again (or: less clickery, more coffee)

[gebeer]

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:

1. Ask ProcessWire what’s outdated via ProcessWireUpgradeCheck
2. Check module requirements before touching anything
3. Update modules first, core second, unless compatibility says otherwise
4. Install public and Pro module ZIPs from the CLI
5. Refresh module caches and verify versions
6. Commit every module update separately
7. Update ProcessWire core last
8. 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 🤖

[Peter Knight]

That’s brilliant 🤩 Thanks for the skill