-
Posts
2,224 -
Joined
-
Last visited
-
Days Won
58
Posts posted by wbmnfktr
-
-
On 4/30/2026 at 11:17 AM, Peter Knight said:
module built for today's SEO
Can you define this a bit more detailed?
I mean we have a lot of new AEO, GEO, LLMO, AIO, VEO, NEO, AISO acronyms out there.
The name would suggest that NEO (Neural Engine Optimization) would be the focus... is this the case?
-
1 hour ago, ryan said:
Now all core classes that will receive their own API.md documentation also have their own directory. The /wire/core/ directory kind of resembles the /wire/modules/ structure now. In addition, new API.md files have been created for the Pages, Page, PageArray, Modules and Module, all of which also improve the online API reference documentation too, which is what those links are linking to. We'll continue adding more API.md documents every week.
This will retire my whole set of ProcessWire skills... and I love it!
I really enjoy the pace and direction you, @ryan, and ProcessWire are going now.
Let alone AgentTools in a fresh installation of ProcessWire does some magic with LLMs (from super cheap Mistral, Deepseek, to great models like Kimi 2.6, MiniMax 2.6, and to Opus 4.6/7 and Codex 5.4/5) which was NOT possible in that way 6 weeks ago.
🥰
-
6
-
-
-
-
In Kilo Code there is this:
You can set a model for each mode.
-
3
-
1
-
-
1 minute ago, ryan said:
maybe a select/drop-down under the engineer prompt box where you can select the model to use
That's what I was thinking about. Like in other tools (Kilo Code Extension in VS Code in the screenshot).
3 minutes ago, ryan said:And we should be able to share memory between them too, once it's added.
-
2
-
-
What about being able to configure multiple models and then selecting the one for each specific task?
Planning: Opus 4.x (or GLM 5.1, Kimi K2.5)
Workload: MiniMax, Qwen, ...Most plans (I use) support Anthropic-, OpenAI-compatible, and custom endpoints. Right now we have Anthropic and OpenAI available (should cover 90% i guess).
-
5
-
-
9 minutes ago, ryan said:
I'm thrilled to see the AgentTools module working with another AI Agent.
Used Droid (https://factory.ai/) and OpenCode (https://opencode.ai/) in this project for now and they both had no issues at all (besides learning that the project is running in a DDEV environment). Also Z.AI GLM 5.1 and MiniMax M2.7 did a really great job.
Not as fast (and by far not as expensive) as Opus 4.6 but planning everything in GLM 5.1, spawning subagents (only really works in OpenCode) with MiniMax that does the heavy lifting and then using GLM 5.1 again to confirm and double-check everything. 🤯
-
2
-
-
-
4 minutes ago, Jonathan Lahijani said:
This feels like the next era of ProcessWire!
YES!
-
6
-
-
Holy... this feels like a bit of Christmas and Easter on the same day during summer holidays.
Just plugged Z.AI GLM-5.1 into this and ...
From the side notes:
SpoilerThe whole project was migrated from Hono, React, Vite, Cloudflare Workers with D1 just by using AgentTools in the last couple of days.
From this:
To this without me adding or creating any template or field:
Took around 5 hours for the inital migration (Droid with GLM 5.1) and another 3 for frontend and a little bit of fine-tuning (OpenCode with GLM 5.1). Around 170,000,000 token in total so far.
That was a fun ride!
I might never touch NextJS or similar again now.
-
9
-
-
Ran into this issue here in another project using the latest version from the module directory.
QuoteWarning: include_once(/var/www/html/site/modules/AgentTools/AgentToolsSitemap.php): Failed to open stream: No such file or directory in /var/www/html/site/modules/AgentTools/AgentTools.module.php on line 243
Warning: include_once(): Failed opening '/var/www/html/site/modules/AgentTools/AgentToolsSitemap.php' for inclusion (include_path='.:/usr/share/php') in /var/www/html/site/modules/AgentTools/AgentTools.module.php on line 243The file AgentToolsSitemap.php in the module directory is actually named AgentToolsSiteMap.php (capital M) and also renamed the class.
I renamed the file and it seems to work for now.
Also ran (not me, the agent) into some other issue.
SpoilerAgentTools Issues
--at-sitemap-generatenot accessible from--at-evalProblem
The sitemap can only be generated via the dedicated CLI flag:
php index.php --at-sitemap-generate # worksBut calling it from
--at-evalfails:php index.php --at-eval 'wire("at")->sitemap()->generate();' # ERROR: Method AgentTools::sitemap does not exist or is not callable in this contextRoot cause
$at->sitemapis a property, not a method.AgentTools::get('sitemap')returns anAgentToolsSitemapinstance via the helper system (line 316–319 ofAgentTools.module.php). But PHP's method syntax$at->sitemap()looks for an actualsitemap()method on theAgentToolsclass, which doesn't exist.The correct eval call requires chaining the property access with the method call:
// Works: wire('at')->sitemap->generate(); // Fails — treats sitemap as a method call: wire('at')->sitemap()->generate();Why this matters
AI agents frequently use
--at-evalfor quick API calls. The sitemap is documented as a first-step orientation tool, so agents will naturally try to call it from eval. Without a clear API path, they hit the error and then see the full help output (which confusingly lists--at-sitemap-generateas a CLI flag, not an API method).Suggested fix
Either (or both):
-
Add a
sitemap()method toAgentToolsthat returns the helper instance — this makeswire('at')->sitemap()->generate()work naturally from eval:public function sitemap() { return $this->getHelper('sitemap'); } -
Document the correct eval syntax in
agent_cli.mdandAGENTS.md— use property access, not method call:php index.php --at-eval 'wire("at")->sitemap->generate();'
Option 1 is cleaner since
migrationshas the same property-only pattern and would benefit from the same treatment.Environment
- AgentTools v2 (ProcessWire module)
- ProcessWire 3.0.247
- PHP 8.4, DDEV
pw-at.shwrapper does not supportsitemap-generateProblem
The wrapper script (
.agents/skills/processwire-agenttools/scripts/pw-at.sh) only passes through a fixed set of subcommands:eval, eval-b64, stdin, stdin-b64, cli, migrations-apply, migrations-list, migrations-testAny other command exits with the usage message. This means
sitemap-generatecannot be invoked through the wrapper:bash .agents/skills/processwire-agenttools/scripts/pw-at.sh sitemap-generate # prints usage, exits 1Agents must fall back to calling
ddev exec php index.php --at-sitemap-generatedirectly, which breaks the "always use the wrapper" convention documented in AGENTS.md.Suggested fix
Add
sitemap-generate(and any future helper CLI actions) to the wrapper's case statement. One approach:# In the argument validation case: sitemap-generate|skills-install) [[ $# -eq 0 ]] || { echo "$mode does not accept positional arguments" >&2; exit 1; } ;; # In the execution case: sitemap-generate) run_php "--at-sitemap-generate" ;; skills-install) run_php "--at-skills-install" ;;Or make the wrapper generic: pass any unrecognized subcommand through as
--at-<subcommand>to let AgentTools handle validation server-side.-
2
-
-
I could swear that was playing at the gym today.
-
52 minutes ago, ryan said:
and install to "/.agents/..."
Various agents have various needs unfortunatelly.
Not sure if this changed recently but in order to test my SKILLS I needed to create various folders (as symlinks) like:
- .agent
- .claude
- .cline
- .factory
- .goose
- .kilocode
- .kiro
- .pi
- .roo
- .windsurf
Like for the ~/.config/ folder on Mac and Linux also the dot is necessary.
Another option could be using the ~/.agents/ folder but here as well, not all agents support this yet.
-
Just created a new test project and added the module.
One thing I noticed immediately was that in my DDEV environment I needed to prefix the commands in order to run them in the actual container.
// non-DDEV environment php index.php --at-eval 'echo wire()->pages->count() . " pages\n";' // DDEV environment ddev exec php index.php --at-eval 'echo wire()->pages->count() . " pages\n";'
-
2
-
-
I'm happy to see you found your workflow using Claude Code. 🙂
A few things I'd suggest to make it a bit more future-proof and less focussed on one tool (Claude/Claude Code).
I'm not sure if you use a CLAUDE.md file yet but in case you do or when you start using it, do this:
In CLAUDE.md just add:
@AGENTS.md
And then write your instructions in/to AGENTS.md.
The reason is simple:
CLAUDE.md just works for Claude, but AGENTS.md works for almost any other AI agent.
This way, either in a CLAUDE.md or AGENTS.md, you can customize comments in issues, like:
## GitHub issue and PR comments When responding in GitHub issue or PR comments: - Be concise, direct, and helpful. - Start with the answer first. - Use short paragraphs or bullets when useful. - Avoid unnecessary disclaimers, hedging, or repetition. - If the user asks for a change, give the exact action or code needed. - If more context is needed, ask one clear follow-up question. - Keep the tone professional, friendly, and technical. - Do not write long explanations unless explicitly requested. - Always add this as the last line in comments: [🤖 Answered by Joshi - Ryan's custom AI Agent.]Another thing you could change is updating the Claude settings.json to disable or customize the attribution line in commits and pull requests.
-
4
-
-
The closest to a traditional setup for me would probably be:
- VS Code (or any fork or the Codium version)
- plus one of these extensions: Kilo Code, RooCode or Cline
- Coding Plan from either Z.AI or MiniMax.io
VS Code an be installed almost everywhere without adding Node.js or other packages.
The extensions can be installed from within VS Code but as they are quite similar, you should probably test them all.
I kept Kilo Code as it felt to be the most stable and reliable one.Also Kilo Code offers additional features but only when using their subscription, for daily usage you can bring your own API keys and use those.
-
1
-
A little heads-up: WirePDF ≠ WirePDF
I am in the process of upgrading a pretty old project, still running 3.0.240. I wanted everything up to date from ProcessWire to each and every module. So I was happy to see new version of WirePDF and went with it.
Right after finishing the installation error messages showed up, Pages2Pdf broke and was messing with me, PDF generation threw errors, and so on.
I started digging and found the problem: the listed update belongs to a totally new module called WirePDF (by @maximus) and has nothing to do with the file in the Pages2Pdf module folder.
So there is a weird name collision and hijacking of the old module happening in the ProcessWire Upgrade (by @ryan) module right now.
-
1
-
-
2 minutes ago, gmclelland said:
It was kinda hard to read
Yeah, tried to fix that but it's not working out as expected. 🙈
Doesn't matter, the diff shows the changes pretty well: https://github.com/webmanufaktur/pwaiworkflow/commit/f0dba82a796881153ac6140aa9db70fdf2875d3e
Updated that skill to have those advanced features.
-
1
-
-
That's a great find @gmclelland - I never use markup regions so wouldn't have noticed this at all. Ever.
I compared the new details with the existing skill, this was the result:
SpoilerComparison Analysis
Missing Details from SKILL.md1. Alternative ID Attributes (pw-id, data-pw-id)
- The skill file mentions id attribute but doesn't document that pw-id and data-pw-id are alternatives that are removed from final output (invisible to CSS/JS)
- From new file (line 68-70): "you are also welcome to use "pw-id" or "data-pw-id" attributes instead. They do the same thing, but only ProcessWire can see them – they are removed from the final output"2. <region> and <pw-region> Placeholder Tags
- Completely missing from skill file
- From new file (lines 74-77): These tags define regions where only inner HTML is used, wrapping tags don't appear in final markup
- Example: <region id="something">...</region> or <pw-region id="something-else">...</pw-region>3. data-pw- Prefix Alternatives
- Skill file only shows pw- prefix attributes
- From new file (line 128): Any pw-action attribute can also be data-pw-action format4. Debug Output Format Details
- Skill file mentions the debug comment but doesn't explain the output format
- From new file (lines 227-236): Shows format is number. action => region-id ... tag plus timing info5. Performance Considerations
- Completely missing from skill file
- From new file (lines 254-258): Markup regions have overhead compared to direct/delayed output. Not recommended for sites with "really heavy amounts of output"6. Target Audience Guidance
- Missing from skill file
- From new file (lines 254-258): Best for those who like direct output simplicity but want delayed output benefits. Good for front-end developers and ProcessWire newcomers---
Recommended Additions to SKILL.md
| Section | Addition |
| ------------------------- | ---------------------------------------------------------------------------------------------- |
| Enable Markup Regions | Add note about pw-id/data-pw-id being invisible alternatives to id |
| Region Definition Example | Add <region> and <pw-region> tag syntax with explanation that wrapper doesn't appear in output |
| Region Action Attributes | Add note that data-pw-_ prefix works as alternative to pw-_ |
| Debugging Regions | Expand with output format explanation and timing info |
| New Section: Performance | Add warning about overhead for heavy output sites |
| New Section: When to Use | Add guidance on target audience and use cases |I guess we should add it. Right?
-
On 2/27/2026 at 2:59 PM, gebeer said:
Where I would disagree is having each learning also in skills.
It's not about adding every new learning into a new skill. It's about updating existing skills with new learnings. For example: in case a modules skill always returns an error when creating backend pages, that skills needs an update and I feed the learnings back into that skill.
On 2/27/2026 at 2:59 PM, gebeer said:Another interesting approach that I just found...
Yes, but I honestly don't like to have too much external requirements in my projects. I'd like to test Context+ (https://contextplus.vercel.app/) yet the overall setup is way too much hassle. For super big projects maybe, but for all those smaller to medium sized projects that's way off my comfort zone.
I tried Gastown, SpecKit, OpenSpecs, Beads, BMAD ... whatever else there was. They always came with some kind of setup and bloat. Taking a day or two off meant I couldn't even remember I installed and used that tool in my projects or forgot to start a new task in a certain way.
Skills are always there. They live in my OpenCode config folder now. They are portable, too. Way easier and no headaches. At least for me.
Of Course everyone else has their own prefered way of doing things and may have the capactity to remember each tool and setup for each project. I don't. 😂On 2/27/2026 at 2:59 PM, gebeer said:So many things still to explore 🙂
Way too many things. Way too little hours per day for that. 🙈
On 2/27/2026 at 3:00 PM, bernhard said:What problem do you solve?
I try to solve the knowledge gap that most LLMs have in regards to ProcessWire. There isn't that much of training data for ProcessWire as there is for NextJS, React, Symphony, Laravel, and of course Java and C++. LLMs know the basics or "invent" new ways of doing core things, like URL hooks. PHP itself was never a real problem - just to make this clear.
I found that skills are a great way to solve this - for me. I can use way cheaper models, like Kimi K2.5 or Minimax M2.5, with way better outcome using skills. Sure I could just burn through my $200+ Claude Code/Cursor plan but babysitting that agent to fix issues it isn't even aware off while it would repeat those same mistakes over and over again with a smile the next time - I was tired of that. That's why I played a lot with the JS-tools out there.
On 2/27/2026 at 3:00 PM, bernhard said:What is the goal? // What would be the expected outcome? // What would be the benefit (compared to other approaches)?
Paying less money and investing less time for a way better outcome. I could run 10 agents in parallel that check each others work and fix issues, report back and forth, and could then somewhat get what I was looking for but it never felt right and looking at the code often even scared me. My skills contain about 80-90% of ProcessWire knowledge. Not perfect in every aspect, maybe sometimes even outdated examples or older PHP code (<8.x) but the results turn out to be great.
On 2/27/2026 at 3:00 PM, bernhard said:What is the solution?
For me at least it is: SKILLS, plus AGENTS.md thats referencing those skills, concepts/specs/PRDs
For now.
Maybe next week there is another concept that lives locally without any big setup in a folder that does everything I want and need.On 2/27/2026 at 3:00 PM, bernhard said:How would it help me with my day to day work?
I don't know. What's your (daily) workflow? What's ruining your day to day work? What annoys you when working on something?
On 2/27/2026 at 3:00 PM, bernhard said:What would be the benefit [...]?
My benefit is:
- I don't need $200 Claude/Cursor plans to get something done.
- I don't need Opus/Sonnet 4.6, Codex 5.3-x-whatever-they-named-it.
- I get MVPs up and running in ProcessWire like it was a NextJS/React project.
Look into the ProcessWire skills here and you will notice that it's actually just the documentation - which is missing or is incomplete in so many LLMs. Sometimes with additional details, other code examples, or sometimes it's a missing part of the docs like for URL Hooks - as they actually only exist as a blog post right now - yet I can use them now without issues.
That's what I tried to fix and for the moment this fixes it.
Is that the best way to go? I don't think so. But I am lazy and tired. And this works. For me.
I don't want to learn yet another tool or framework to get things done. Just to learn another framework and tool tomorrow and next week.
I don't need 10-20 agents per project to run 24/7. I'm not trying to rebuild SAP/Sage or Asana/Trello/Jira.But let's find out how my (lazy) approach might help you or give you ideas.
-
5
-
For those who want to play around with that workflow:
https://github.com/webmanufaktur/pwaiworkflow-profile
- DDEV setup (customise .ddev/config.yaml to your needs)
- clean ProcessWire installation
- clean database backup: site/assets/backups/database/clean-start.sql
- all necessary modules (core, 3rd party)
- Skills in .agents + custom symlinks for various IDE/tools
- AGENTS.md ready to go
Testing & Demo:
Branch: feature-restaurants-directory
Specs file: https://github.com/webmanufaktur/pwaiworkflow-profile/blob/feature-restaurants-directory/specs/restaurants-directory.mdAsk your agent to run that file and see what happens. Results may vary.
Minimax M2.5 was fine, Z.AI GLM-5 did way better.Tell me your results and findings if you like to share.
Reference result with Claude Sonnet 4.6 for comparison:
https://github.com/webmanufaktur/pwaiworkflow-profile/tree/feature-restaurants-directory-claude-sonnet-46-
1
-
Not that long ago I started with a completely new approach in regards to ProcessWire an AI.
I had some rules, commands, and settings for Windsurf and Cursor months back but nothing really worked as good as I hoped it would and lost interest. Even switched to Astro, NextJS, BHVR, and other JS solutions. 🙈
ProcessWire-based development went back to 80% hand-coded with some assistance on the sidelines, mostly debugging, security, and tasks that were more PHP-focussed than ProcessWire-related.
Then AGENTS.md and SKILLS came up.
Custom instructions, guardrails, links to docs and example code. Almost similar to a README.md but for AI coding tools. The main problem still was the knowledge gap in models. They just didn't know enough about ProcessWire works and how to do more complex stuff.
With SKILLS this changed.
I pulled the entire docs, some blog posts, took some of the old recipes and let the AI do its magic.
The AI repackaged the entire docs, custom instructions, module docs, PHP best practices, and everything else into skills.
I installed new and clean instances of ProcessWire and just asked the AI to build things. Yeah... didn't work as expected.
I gave the AI more tools to work with and fixed the AGENTS.md:
- RockMigrations - for creating and updating templates, fields, and pages 🥰
- AutoTemplateStubs - for details about existing templates and fields 🤯
- ProcessDatabaseBackups - can be a good idea to give your tools a database file it can look into without the need to bootstrap ProcessWire into a custom script or similar.
- Inline comments in config.php to mark things as important or noteworthy otherwise that file would be ignored
- /init - a custom action OpenCode, Claude Code, and some other tools have to initialize the whole project 💯
Now my tools have all the skills and know how to use RockMigrations to create templates, fields, and pages, can trigger database backups and look into the made changes, know how to build a custom module.
Even custom page classes or URL hooks aren't a problem anymore.
The AGENTS.md contains now critical changes in the config.php, has links to all the skills, and whatever necessary. The /init command is very capable of creating it nowadays.
I just started to test it more and more. With fresh installations, older projects and even recent projects that have tons of everything.
Whenever problems occure I let the AI update the skills or create new ones that take care of the problems it faced. Learning by mistakes.
The overall workflow
A README.md with a scope of the project, necessary templates and their fields, overall main features besides handling page rendering, like a bookmarking function for recipes or read articles, newsletter signups, automation tasks to clean up older data, and whatever the project needs.
The amount of typing is still the same but now mainly in markdown files that explain what to build (/specs), what to fix (/issues), and what we have done already (/docs).
I always start in PLAN mode.
Starting simple with the overall idea, goals, and outcome. Then the combination of tool and model is important. OpenCode and Claude Code are great at thinking and planning but they need a capable model like Opus, Kimi K2.5 Thinking or even GLM-5. They start to ask questions, give options, recommend workflows. When that's done i ask to save everything to a file in the /specs folder. From here I can either switch to BUILD mode, manually tweaks the plan file, or let other models (Gemini 3 Pro or Codex) review it and ask for suggestions, changes, fixes.
Github: https://github.com/webmanufaktur/pwaiworkflow/
Installation:
- Download and extract files
- Move entire .agents folder into the project root next to the wire/ folder
- Look into create-symlinks.sh, run if necessary
---
Plans
-
Windsurf
$10/month (Legacy) with access to all Anthropic, OpenAI, Google models, and many more -
Z.AI
Coding Plan Pro $120/year (BlackFriday Deal) with all GLM models, including GLM-5 and future releases -
Kimi
Moderato $19/month with Kimi K2.5 (just expired) -
Minimax
Coding Plan $20/month with M2.5 (started using it as successor to Kimi)
Tools
-
OpenCode - https://opencode.ai/
Similar to Claude Code, easy to configure, and even easier to extend with custom modes, agents, skills, and whatever you might need or want. Has a great planning mode and doesn't ask unnecessary questions in the middle of tasks like Claude Code did for a while just to burn more tokens. -
Kimi Code CLI (with Kimi K2.5) - https://www.kimi.com/code/en
Tested it last month and while it's a CLI like OpenCode/Claude Code it feels and works totally different. It doesn't have any modes but supports AGENTS.md and SKILLS. Super fast and it is super capable for quick fixes, smaller features, or heavy automations. -
Windsurf IDE - https://windsurf.com/editor
Like Cursor with almost identical features, a custom terminal integration, includes a browser that has full access and control which is great for debugging, UI/UX (especially with Opus 4x.) - I guess most of you have seen in the past or even tried it. Was called Codium before and I know some of you used that Codium Extension which was awesome.
-
8
-
12 hours ago, markus-th said:
All that's missing now is a curl/wget command or a public URL on Github we can just copy and paste and go from there.
Send a PR with a fresh README.md that contains what I was looking for.
-
1
-
1
-
PW 3.0.260 – Core updates
in News & Announcements
Posted
You won't believe how these changes make my day(s) now!
Moving away from ProcessWire to NextJS/AstroJS/HonoJs/WhateverJS just to be able to prove a concept and go live within a super short time using AI/LLMs/Agents was hard but I got things done. I was able to test things, to experiment, to explore, to fail, to succeed.
Well... now ProcessWire is back.
Back in my preferred stack of tools.
Back on #1.
I've already moved 2 big projects back from HonoJS and NextJS to ProcessWire. The RSS Monitoring Tool and another one.
Cloudflare Workers and Vercel were great hosts with pretty awesome free tiers, yet... at some point I scratched limits big time.
Now everything is hosted on H*stinger for a few dollars a month with full CI/CD pipeline, no limits on reads/writes to the database, just a 5GB size limit per database and some other weird limits those projects will never reach.
It's unbelievable how fast things turned around and back to a language (PHP) I actually can read and understand and a framework I kind of know how to work with.