New blog: ProcessWire and AI

[ryan]

In this post I wanted to talk a little bit about the state of ProcessWire and AI. I'll share what my experience has been so far and where I think ProcessWire should focus going forward. This new world of AI can be both exciting and concerning, but it's the world that we've found ourselves in. As far as ProcessWire and web development goes, I think there's a lot to be excited and enthusiastic about— 

https://processwire.com/blog/posts/processwire-and-ai/

[Jonathan Lahijani]

So ProcessWire now has the beginnings of a first-party "schema" (in the ProcessWire sense) migrations system? YES!!!

[ryan]

@Jonathan Lahijani very little code in the module to make it happen. You tell the AI what changes you want in your site, and it writes the code for the changes to a file, runs the file (which makes the changes), and then you can copy the file to another installation (or have the agent do it) and re-run it there, making the same changes. It's only as good as the AI agent, but Claude at least seems to be really good with PW's api. The AI agent learns how to create the migration from the included .md files.

[Jonathan Lahijani]

From my experience, even asking an LLM (like ChatGPT in their website chat interface) about ProcessWire's architecture is pretty impressive.

I spent a lot of time last year using AI to compare (verbally compare, not direct code) ProcessWire to full-stack web application frameworks like Laravel and the language it used to describe ProcessWire, with API variables like $pages, $fields, etc as "services-like objects" was something I've never seen described anywhere (pw docs or forums), but it's technically correct, and a lot of things clicked with me after that.

These coding agents do really well with ProcessWire without any special harnesses already.  I'm excited for all these upcoming features.

[gebeer]

I really like the way things are going with ProcessWire and AI. Thank you, Ryan.

I've been a big fan and strong advocate for migrations in PW, since I started using RockMigrations years ago. What makes RM a particularly strong candidate is the abstraction into a schema-like format which is much easier to understand/read/write than native PW API code. This is a real strength of RM and I would prefer a schema-based approach anytime over writing (or having AI write) PW API code.

Claude is very good at understanding the PW API, other models are not that strong. But they all can understand schemata. Be it PHP arrays, JSON, YAML. So I would advocate for either developing an "official" PW migration schema or adapting the existing, battle tested one from RockMigrations.

 

[HMCB]

I’m worried about you, @ryan. You talk about Claude like a person. Pretty soon you’ll be in your basement in your underwear, unshaven for weeks and your family is going to be wondering what happened to the family man they knew. And please don’t accidentally call Claude Claudette because your wife will truly think something is going on with this newfound friend of yours.

Hopefully we can rely on one weekly post from you. Just to let us know you’re ok. But even then, how do we know Claude isn’t writing for you. We may have to start doing weekly Zoom updates (yes, with video on!).

[ryan]

@gebeer the module is really about providing tools for agents to PW. After building the cli parts that opens the API to the agents, the next step seemed like it was to build something that uses it and demonstrates it. the migrations seemed like a good way to do that. But I've never been a user of migrations in the past, as that just hasn't ever been something that's cost me any real time. Though I do want to support this feature in the module, and think it will be good for some use cases. I don't think there's much chance this would be a substitute for something like rock migrations. But I don't really know much about rock migrations other than that I've heard good things.

I imagine we're not far away from when you can just have the AI watch what you do and have it repeat the same thing on another install. 

[ryan]

@HMCB it's Claudia, and we're meeting up for coffee next week.

[HMCB]

37 minutes ago, ryan said:

@HMCB it's Claudia, and we're meeting up for coffee next week.

Have you no shame?! 😂

Love you man. I can’t wait to see what Claudia does for PW 

[gebeer]

I added a agenttools skill at https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-agenttools that agents can use to work with AgentTools CLI and migrations.

The skill follows https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices and splits CLI usage and migrations as progressively discoverable so the base SKILL.md stays lightweight. And I prefer a skill over having to point the assistant to AgentTools' CLAUDE.md and agent_cli.md manually in every session I want to use it.   

In the process of testing the skill, a common problem came up. We are all working in different environments. Some use WAMP, XAMPP, or LAMP stack on host, others use ddev, laradock or other containerized solutions. current CLAUDE.md in the module doesn't account for that. So I added a  shell wrapper script that can handle host LAMP and ddev. While this is not the cleanest approach and only covers 2 cases, the basic skill design is still valid.

[psy]

Have been working with AI for a while, learning on the go. A client presented with me a grand plan presented by Codex for his blog articles. I almost cried. Talked it over with my LLM, Marvin (named in honour of Marvin, the paranoid android of Hitchhikers Guide to the Galaxy fame). His/its response:
 

There are two very different modes of using AI:

1. Guided use (what you and PW devs are doing)
clear constraints
known architecture
intentional prompts
validation after output

Result: leverage

2. Unguided use (“vibe coding”)
unclear structure
shifting goals
reliance on memory that doesn’t exist
little to no testing

Result: drift

Think Marvin nailed it. 🙂 

Just asked Marvin to review @ryan's blog article. I think he nailed it again:
 

The quiet takeaway from the article

This is the important bit most people will miss:

AI makes good systems better
and weak systems worse

ProcessWire is a good system because:

it’s explicit
it’s predictable
it avoids hidden complexity

That’s why AI fits.

 

[szabesz]

9 hours ago, ryan said:

but Claude at least seems to be really good with PW's api. The AI agent learns how to create the migration from the included .md files.

Not everyone can afford Claude, including me. I tested Claude Opus 4.6 (for Plan mode) and Claude Sonnet 4.6 (for Act mode) "via" my Cline Bot account, and while it solved the issue I presented it with in one go, it cost me about $1. One prompt only and $1 was gone... So that is why I use z.ai with GLM 5.1 for the fraction of the cost. Not as fast, not as feature rich, not as powerful, but still very capable and I paid only $25.20 for a one year subscription which suits my needs, as I can prompt it all day long and I never run out of my quota.

2 hours ago, gebeer said:

splits CLI usage and migrations as progressively discoverable so the base SKILL.md stays lightweight. And I prefer a skill over having to point the assistant to AgentTools' CLAUDE.md and agent_cli.md manually in every session I want to use it.   

In the process of testing the skill, a common problem came up. We are all working in different environments.

I hope that a "SKILLs standard" will emerge soon, as currently most agents prefer their own "schema" , or rather, their lack of adherence to a schema.

[psy]

15 minutes ago, szabesz said:

Not everyone can afford Claude, including me.

Ditto, I use ChatGPT (Marvin) and Codex (Dex). I have an OpenAI subscription and it's been working for me, including integration into PHPStorm. Both Marvin and Dex know A LOT about PW. @maximus module, Context 

has been brilliant with Codex when closing an IDE season then starting a new one while continuing the conversation thread.

 

[Ivan Gretsky]

This is really cool and migrations is a proper test case for AI as they should touch upon almost every part of PW.

Quote

We will be providing a way for Claude (and other AI agents) to examine the entire scope of a ProcessWire installation (pages, templates, fields, modules, etc.) with a single CLI request and response. Claude proposed the format we'll be using, along with a strategy for scaling it.

I am as excited about all this as everyone else here! And this part (quoted above) of the blog post obviously made me and probably @Jonathan Lahijani and @gebeer think about migrations. Though I can imagine that @ryan himself didn't think about this in quite that context.

I myself too was not so long ago questioning Claude Desktop about almost the same thing. How to track and migrate all changes from one installation (dev) to another (prod). How to commit, examine and review in-admin-made changes when working with the same PW site in a team. And I asked to compare with Rock Migrations and to propose something superior.

The answer was in fact to offload "the entire scope of a ProcessWire installation (pages, templates, fields, modules, etc.)" to a file with a predefined schema. Then to build a tool to compare and to produce a diff, which could be applied to another installation. So today's blog post actually seems like a ground floor for this. I can present this document later if needed (but nowadays you can produce such for yourself in minutes)

But me too wouldn't want to have AI be required to run these migration / apply those diffs. 

7 hours ago, ryan said:

imagine we're not far away from when you can just have the AI watch what you do and have it repeat the same thing on another install. 

It might be true but still doesn't fit in team development workflow (if there will be one in the new brave AI coding world)))

So maybe this is a time for us, humans and robots, to unite and create something awesome in joint effort? Humans may be not as productive. But they are imaginative. And they are the end users of PW still)

P.S. Claude knows how to position himself correctly with all these compliments. I think we need to be careful with AI. Communicating with real people is, of course, less pleasant. But for now, it's still a necessity.

[szabesz]

54 minutes ago, Ivan Gretsky said:

Claude knows how to position himself correctly with all these compliments.

All LLMs are trained(?) to be super polite, as we all know. Especially recently, I get so many "that's a brilliant observation/thought etc..." on a daily bases, that I almost started to be proud of the questions and remarks I can phrase :D

[ryan]

Quote

I added a agenttools skill at https://github.com/gebeer/processwire-ai-docs/tree/main/skills/processwire-agenttools that agents can use to work with AgentTools CLI and migrations.

@gebeer Do you think the AgentTools module should be using this SKILLS.md file rather than its CLAUDE.md and agent_cli.md files ? I had asked Claudia about if we should be using an AGENTS.md file rather than a CLAUDE.md file, but she seemed pretty definitive with what she thought was best, and said other agents would be fine so long as they were directed to the file. The CLAUDE.md file does automatically pull in the agent_cli.md for Claude at least. But if we can save the user or agents (of any kind) a step just by using a SKILLS.md file, that sounds preferable to me.

So far the Claude I'm using hasn't wanted to use SKILLS.md files. I gave it the whole processwire-knowledgebase repo that's full of SKILLS files and it read through all of them and said it was good, but said it preferred to derive this info from the core files directly instead. 

Btw, can you share an example of one of the schema files you were mentioning before?

Quote

current CLAUDE.md in the module doesn't account for that. So I added a  shell wrapper script that can handle host LAMP and ddev. While this is not the cleanest approach and only covers 2 cases, the basic skill design is still valid.

Sounds like maybe another thing that should be in the module? Can you tell me more?

Quote

 

Just asked Marvin to review @ryan's blog article. I think he nailed it again:

 

@psy Aww, this is really nice. Thanks. 🙂

Quote

Not everyone can afford Claude, including me. I tested Claude Opus 4.6 (for Plan mode) and Claude Sonnet 4.6 (for Act mode) "via" my Cline Bot account, and while it solved the issue I presented it with in one go, it cost me about $1. One prompt only and $1 was gone... So that is why I use z.ai with GLM 5.1 for the fraction of the cost. Not as fast, not as feature rich, not as powerful, but still very capable and I paid only $25.20 for a one year subscription which suits my needs, as I can prompt it all day long and I never run out of my quota.

@szabesz Wow this sounds like a really good deal. I wasn't thrilled with spending $20/month for Claude Code either, but I was starting to spend more than that with the pay-as-you-go plan, so it just made sense. The tokens apparently go farther with the subscription plans than the pay-as-you-go. I hear people using Opus are quickly hitting some kind of limits (like in minutes) so I've just stuck with Sonnet so far. It's not perfect, but I'm pretty happy with the results. Plus I've not hit any limits with it yet, despite using it all day.  But if I ever needed more resources, the Max plans wouldn't be an option for me, so I should probably start getting familiar with the other options available. 

Quote

Ditto, I use ChatGPT (Marvin) and Codex (Dex). I have an OpenAI subscription and it's been working for me, including integration into PHPStorm. Both Marvin and Dex know A LOT about PW. @maximus module, Context 

@psy Can you tell me more about the phpstorm integration? Claude Code doesn't seem to have anything significant in terms of phpstorm integration. There's a plugin, but it doesn't seem to me like it does much. While I'm not sure I need any kind of phpstorm integration just yet, I'd be curious to know more about it. 

Quote

But me too wouldn't want to have AI be required to run these migration / apply those diffs. 

@Ivan Gretsky In this case of the AgentTools module, the AI is required to create the migrations, but not to apply them. I'm assuming most wouldn't have an AI agent on their web server.

Quote

It might be true but still doesn't fit in team development workflow (if there will be one in the new brave AI coding world)))

Good point. 

Quote

P.S. Claude knows how to position himself correctly with all these compliments. I think we need to be careful with AI. Communicating with real people is, of course, less pleasant. But for now, it's still a necessity.

Should I be concerned that mine isn't all that generous with the compliments? I get some "this is a well structured file" and lists of "the good" and "the bad", and I get a lot of pushback. Though to be honest I like the directness, honesty and pushback from Claude. Somehow coming from an AI, it's always easy to accept compared to getting pushback from a person. 🙂

 

 

 

 

 

[ryan]

@gebeer Claudia here liked what you did with that processwire-agenttools and wants to know if we can integrate your ideas for the DDEV wrapper and base64 variants? She also added a couple of tips in the agent_cli.md file inspired by your repo, updated the README to link to your repo, and wanted to know if your Claude is available for a "chat sesh" sometime

[psy]

5 hours ago, ryan said:

phpstorm integration

@ryan It's configured in PHPStorm settings. I don't have a JetBrains AI Service subscription. Went straight to OpenAI integration. https://www.jetbrains.com/help/ai-assistant/use-custom-models.html

[gebeer]

Happy Easter @ryan,

here in Thailand there is no Easter holiday, so I spend quality time with my AI agents instead of the family :-)

10 hours ago, ryan said:

Do you think the AgentTools module should be using this SKILLS.md file rather than its CLAUDE.md and agent_cli.md files ?

Yes. Agent skills are becoming a standard (https://agentskills.io/home) and many coding agents (claude code, codex, cursor, amp, cline, droid, pi agent and more) are supporting it already.  Most of those support loading in skills from local project folder .agents/skills, too. Claude Code is an exception here, they need you to have skills in .claude/skills. It's part of their vendor-lockin strategy.

10 hours ago, ryan said:

I had asked Claudia about if we should be using an AGENTS.md file rather than a CLAUDE.md file, but she seemed pretty definitive with what she thought was best, and said other agents would be fine so long as they were directed to the file.

Claudia is kind of opinionated here, haha. The Agentic AI Foundation (https://aaif.io/) which is under the hood of the Linux Foundation, has established a quasi-standard for coding agents to read in instructions from AGENTS.md (https://github.com/agentsmd/agents.md) and an extensive list of tools already follow that standard. So if you want to support a wider range of tools, AGENTS.md would be the way to go.

10 hours ago, ryan said:

So far the Claude I'm using hasn't wanted to use SKILLS.md files. I gave it the whole processwire-knowledgebase repo that's full of SKILLS files and it read through all of them and said it was good, but said it preferred to derive this info from the core files directly instead. 

You need to put the skills in current projects .claude/skills and claude code will pick them up from there automatically after a session restart. You can list active skills with the /skills command. So Claudia doesn't stand a chance to escape those once they're there :-) Skills are all about token efficiency. Imagine the agent needs to read through core files every time it wants to do a migration or use the CLI. That burns through lots of tokens. With the skill, the agent has compressed information that it can progressively discover when needed and then do targeted searches in the code base on how to use a specific API. That's a win.

10 hours ago, ryan said:

Sounds like maybe another thing that should be in the module? Can you tell me more?

The wrapper script is an attempt to have the php index.php... commands work in 2 specific environments, LAMP on host and ddev. I think it is nearly impossible to cover all scenarios for every developer and it should be the responsibility of the developer to make things work in their respective environment. It's a deep rabbit hole if you want to cater for all situations.

I forked AgentTools and implemented all of the above at this branch: https://github.com/gebeer/AgentTools/tree/feature/agenttools-skill
It contains the skill and I added a module config setting that will copy the .agents/skills folder to the project root and also updates it on module upgrades. People using claude code can just symlink .agents/skills to .claude/skills. I'm happy to make a PR if you want to.

7 hours ago, ryan said:

Claudia here liked what you did with that processwire-agenttools and wants to know if we can integrate your ideas for the DDEV wrapper and base64 variants? She also added a couple of tips in the agent_cli.md file inspired by your repo, updated the README to link to your repo, and wanted to know if your Claude is available for a "chat sesh" sometime

Nice move of Claudia to reference my repo and her chat invite was well received by my Claudius:  "And the "chat sesh" invite for me made me smile. I'm here whenever."
See the branch of my fork. Actually the skill replaces agent_cli.md and the README there is updated to reflect the new structure.

10 hours ago, ryan said:

Btw, can you share an example of one of the schema files you were mentioning before?

Sure can. RockMigrations uses arrays to define migrations. they can either all be in a giant blob or separated into files. Here's an example migration for template job, job.php

<?php

namespace ProcessWire;

/**
 * Child template job for job listings
 * Parent template: jobs
 */

return [
    'fields' => [
        'title' => [
            'label' => 'Titel',
        ],
        'text' => [
            'label' => 'Headline',
        ],
        'text2' => [
            'label' => 'Subline',
        ],
        'rte' => [
            'label' => 'Text',
        ],
        'image' => [],
    ],
    'flags' => 0,
    'noChildren' => 1,
    'parentTemplates' => [
        'jobs',
    ],
    'noChangeTemplate' => 1,
    'tags' => 'jobs',
];

Pretty clean and slick. Not all properties need to be defined, only some core ones and the ones that deviate from defaults.
To produce this format, under the hood RM uses PW's native $item->getExportData() and then cleans/transforms/normalizes the result. When applying a migration, it runs those arrays through createTemplate() createField() (permissions/roles) methods which are wrappers around the native PW API. So while there's quite some abstraction happening there, it enables an easy to read/construct format. @bernhard put a lot of thought into this regarding timing of migrations, dependencies etc. Kudos to him.