ryan

Let's see if we can also get these guys to stop by here more often @apeisa @Joss @Nico Knoll @Gazley @WillyC @LostKobrakai @owzim the geerts brothers and who else am I forgetting?

@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

@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? Sounds like maybe another thing that should be in the module? Can you tell me more? @psy Aww, this is really nice. Thanks. 🙂 @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. @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. @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. Good point. 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. 🙂

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

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

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

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/

Enables AI coding agents to access ProcessWire’s API. Also provides a content migration system. This module provides a way for Claude Code (or other AI helpers) to have full access to the ProcessWire API via a command-line interface (CLI). Once connected to your site, you can ask Claude to create and modify pages, templates and fields, or do anything that can be done with the ProcessWire API. It's even possible for an entire site to be managed by Claude without the need for ProcessWire's admin control panel, though we're not suggesting that just yet. While working with Claude Code, I asked what would be helpful for them in working with ProcessWire, and this module is the result. Claude needed a way to quickly access the ProcessWire API from the command line, and this module provides 3 distinct ways for Claude to do so. Claude collaborated with me on the development of the AgentTools module, and the accompanying ProcessAgentTools module was developed entirely by Claude Code. Admittedly, a big part of the purpose of this module is also to help me learn AI-assisted development, as I'm still quite new to it, but learning quickly. This module aims to add several agent tools over time, but this first version is also somewhat of a proof of concept. Its first feature is basic migrations system, described further in this document. Please note that this module should be considered very much in 'beta test' at this stage. If you do use it in production (such as the migrations feature) always test locally and have backups of everything that can be restored easily. While I've not run into any cases where I had to restore anything, just the nature of the module means that you should use extra caution. Continue reading in the GitHub README Agent Tools in the modules directory

Thanks, great suggestions. Being still kind of new to this, I've found myself overwhelmed by all agents tools and options. So having Claude code as the base is what I feel helped me to finally get into this stuff. It's like my key into this world. And I think it's working so well right now that I'm not concerned about whether a file is named Claude or agents, but it's good to know about for sure. If we start adding this type of file to the core then no doubt we'd want it to be an agents file, so that a broader audience can benefit from it. At the moment I'm loving the commit messages, claude attributions and GitHub replies. Feels like I have a coworker working with me at my computer all day now, which is something I've never had. but if it gets to be too much it's definitely helpful to know that this stuff is configurable. New PW AI updates coming tomorrow too.

@Soma Great to see you back! A couple weeks ago I was just thinking about you and how I wished you were still around here. I've been seeing your amazing paintings on Facebook and figured you had moved on to other things, but thought of sending you a message there, so what a nice surprise to see you here.

This week I worked with Claude Code on refactoring the core WireHooks class to improve it in various ways. I do this work because I like to code, so am of course handling that part. But Claude has been very helpful in finding issues as well as reviewing all my code before it gets committed. In this case, Claude found several bugs that are now fixed, and also saved me from introducing more when I added new features. Working with Claude Code reminds me of 1989 when I was in high school learning Turbo Pascal and building a BBS, and getting help from a neighbor and good friend that was doing the same. I learned so much then and now it feels like that time again. But man have things come a long way since then. I asked Claude about helping with the ProcessWire issues and requests GitHub repos, and now it's solving issue reports, replying to them and committing fixes. For simple fixes that involve a line or two, I'm going to let it handle the the whole thing. It's posting under my GitHub account, but it identifies itself as Claude in replies and and in commits. That way it's easy to tell what it does under my account. I had it just cover a couple of issue reports today as a test (see 2195 and 2192), but will be having it do a lot more going forward. Back to the WireHooks class, I asked Claude about writing a commit message for the WireHooks updates, and wow, check this out: Bug fixes in WireHooks: - conditionalArgMatch(): Fix Selector mutation bug where the shared Selector object stored in hook options was permanently mutated after the first call, causing argMatch hooks (e.g. addHook('WireLog::save(=errors)')) to stop matching after their first invocation. - getHooks(): Remove key variable from foreach to prevent shadowing $method param. - getHooks(): Replace array_merge() in loops with direct array append. - addHook(): Prevent 'noAddHooks' option from leaking into stored hook options. - isHookedOrParents(): Use $className string consistently in cache key writes, rather than $class which may be a Wire object. - runHooks(): Scope $useHookReturnValue inside foreach so it resets per hook. - runHooks(): Use strict null comparison ($toObject === null). Bug fixes in HookEvent: - arguments(): Allow setting an argument value to null (use func_num_args() > 1 instead of $value !== null check). - arguments(): Use array_key_exists() instead of isset() for null-correct lookup. - getArgumentNames(): Guard ReflectionMethod instantiation with method_exists() to avoid uncaught ReflectionException for dynamically-added hook methods. - __toString(): Fix argument list building (was appending to string instead of array), add null/bool display, avoid PHP fatal for objects without __toString(). New features in WireHooks: - cancelHooks: Now accepts string values 'before' or 'after' (in addition to boolean true) to cancel only hooks of a given type. For example, a before hook can set $event->cancelHooks = 'after' to cancel remaining after hooks without affecting the hooked method call. - Custom event data carry-forward: Custom data set on a HookEvent (via $event->customKey = $value) is now carried forward to subsequent HookEvent instances within the same runHooks() call. This allows before hooks to pass data to after hooks without using external variables. - getHooks('*'): Supports wildcard method to return all hooks for all objects. Available in debug mode only (uses allStaticHooks/allLocalHooks aggregates). - allStaticHooks: Now tracked alongside allLocalHooks when debug mode is on. - addHooks() comment fix: "If there is a parenthesis" corrected to "no parenthesis". - addHook() exception messages improved with additional context. - runHooks() docblock updated to include 'either' type. - hookTimer() PHPDoc: @param String corrected to lowercase string. New features in HookEvent: - $defaults static property: Defines the canonical set of standard HookEvent fields, used to distinguish custom data from built-in event properties. - $eid property: Each HookEvent instance gets a unique sequential event ID. - set() override: Tracks non-default keys set on the event in $customKeys. - getCustomData(): Returns only the custom (non-default) data set on the event, used internally by runHooks() for the carry-forward feature. - cancelHooks property updated to support bool|string type. Anyway, I know a lot of you here are deep into the AI stuff, and I'm just getting started, so none of this is surprising. But it sure is a pleasure collaborating with Claude Code on this stuff and it brings back that coding wonder and excitement from 1989. Some Claude and Claude Code podcasts I've enjoyed listening to or watching this week include one from AI for Humans Claude is Cooking, Wednesday's AI Daily Brief on How to use Claude's new upgrades, and the Get Educated AI video of how to setup Claude to use your computer and web browser, etc. (though I've not tried this just yet!). Lastly, last week I put together a ProcessWire powered JSON feed of bike tours, and the client prompted that they wanted a map and look what Claude Code did, I'm impressed!

@jploch @diogo Awesome work, I love the new website!

Most important to me is that I understand everything that goes into the core, and that means that AI is used for ideas and suggestions, but the code is still written by hand. And even then, the suggestions and ideas only end up in the core if they produce a measurable improvement. After testing and benchmarking, sometimes the ideas/suggestions result in an improvement, and just as often they do not. I do the same with pull requests. Coding and re-coding something is how I feel comfortable that I understand it. Perhaps too old-school but I don't think that will ever change. So long as I'm in charge of the core, I need that level of understanding with it. On another project I'm working on with a client (an add-on to their website), we're letting Claude handle the code entirely, with lots of instructions from us, but zero code from us. It's kind of a test and a learning experience, and the client initiated it. We don't know the details of the code, but we do know that the code works quite well. Though I had a peek at its code and found it to be quite solid. What's funny is that in this case, Claude is having me build web services it can pull data from. So I'm giving it instructions, but it's also giving me instructions. 🙂

I think it depends what ProDrafts features you are using. But in general ProDrafts can be installed and uninstalled easily, so having it installed doesn't make any permanent changes to your site or anything. The primary drawback in ProDrafts is repeater support, particularly nested repeaters.

I don't have an ETA just yet but this is one of my main projects currently.

@diogo Thanks, that post is well written and relatable. Interesting comparison with React. I agree with a lot of it, but not really with the AI conclusions. Admittedly, so far I'm not using AI to write code for me, and not sure when/if I will. Instead, I'm using it more as a coding companion. I write the code, and AI looks over everything I do and helps me spot issues and improvements, which it does extremely well. My use of AI so far is very minimal compared to what some others here are doing. But even with this minimal use and understanding, it's clear to me that the world is changed. I don't know about all the other stuff AI is used for, and it wouldn't surprise me if there are some big bubbles. But at least as far as using AI with code (even just as a helper), it is mind blowing, we are in a new world. I think the comparisons to outsourcing and React communicate a lack of experience with AI. But to be fair, I'm also writing about something I don't have a lot of experience with either. I do like this blog and the author's style, looking forward to reading more of his posts.

@adrian Thanks for bringing this up. It seemed like x-user came here to troll with an expectation that ProcessWire should ignore and blacklist anything having to do with AI. That doesn't seem realistic. But it did make me wonder, are there any other CMS projects that are taking this approach? It seems unlikely. I imagine we're not too many years away from the point where a CMS project can't compete if it's not involved in the AI space in some way or another. I also think that the AI changes are coming whether we like it or not. So we can either jump on and grow, and make things better, or get left behind, and perhaps get left without a job. If it's only the people that dismiss environmental concerns using AI and voting with their wallets, then there's no incentive for these companies to do better. X-user would make a greater difference to the world by being an AI user that cares and chooses companies based on their values. And I think that's what we all should do. Whereas abandoning anything having to do with AI does nothing to improve the direction of AI and seems a little like self-sabotage. In the future, and with users that care, there will be pressure on AI companies to do things right. For example, when they build that next data center, they will also build a giant solar array or wind farm to power it. Depending on coal and gas plants for electricity is not sustainable, and now it's more costly than solar. Coal and gas is EOL'd. It may be that the power demands of AI push us towards sustainable solutions faster than otherwise, and we need that as quickly as possible. My opinion: We can't dismiss AI and complain. We have to participate and push for better solutions when there are opportunities to do so. If we sit out, there will be no such opportunities. The environmental problems were here long before AI. As I understand, the root of it is power generation. The US (at least) is not solving the power generation problem in a way that can overcome the politics, corruption and outright stupidity. But I also think that it's very likely AI that will be in some way responsible for the solutions for these problems. There are so many problems to solve that are bigger than any of us have answers for. And if there are solutions for these problems, I have no doubt they'll be coming with the help of AI in some fashion. From my perspective blacklisting AI solves nothing and instead is abandoning the problems and giving up.

@mattgs This is a very friendly community as a whole. But to be fair, both of you guys posted kind of unfriendly messages. And both of you make good points too. There are some big challenges in the world right now, none of us are perfect, and we've all got to do the best we can, where we can. So I think it's good that you guys have these environmental concerns, and we all should, and it's good to communicate these, share and learn, while also being friendly.

@mattgs Like Adrian, I also consider myself very environmentally conscious. I've not spent much time learning AI in part because I thought it was problematic for a lot of reasons. But I don't think we're likely to stop these AI companies so that's why I thought I should try things out with a company that seems to have more ethics than the others. Anthropic seems to have a mission for AI safety and sustainability. I hope it's legit. And as far as I can tell, the other companies don't, which I find concerning. But I'm also not as up-to-speed as you are on the on the issues you brought up, so I'll have to look closer as well as check out the video you mentioned (do you have a link?). I'm also aware that a project like ProcessWire gets executed millions upon millions of times every month (or day?) throughout the world, and every execution consumes energy. So I've always been very interested in optimization and making ProcessWire use as little time and energy as possible to do its work. The updates that we've been focusing on here are aimed directly at that. So perhaps AI is using a little energy to find optimizations and bugs in PW, but that single brief code review session reduces the energy usage of every ProcessWire execution going forward. This is a case where AI is likely saving a lot more energy than it consumes, indirectly by making ProcessWire use less energy. Some of the optimizations and bugs its found have been there since the beginning, and likely would have never been identified otherwise.

@teppo Thanks, good to hear the more I use it, the more I'll be blown away. I've been using AI ever since ChatGTP first came out, but primarily just for technical questions and such. For instance, a couple months ago Claude helped me figure out how to reduce static pressure in our HVAC system by rebuilding (DIY) the return plenum and filter rack, and it was super helpful. I posed the same questions to GPT and Gemini but they weren't nearly as helpful. This week is the first that I've gotten into collaboration with the actual code. Adrian showed me all the things Claude Code had recommended for the PageFinder, and I found myself really liking what it had found and suggested... Seemed like we were on the same page, just like with the HVAC work. The other thing is that I've found it a little overwhelming with all these models (GPT, Grok, Gemini, Claude, etc.) with big changes almost weekly, and if these companies were ethical and ones I'd even want to be putting money towards. Then I learned about why they created Anthropic in the first place, and last week heard how they were sticking to their ethics and wouldn't cross their red lines despite government pressure. Sounds like integrity to me, something that is hard to find with big companies. That opened my comfort level and clarified for me that Anthropic's Claude Code was a good place to dive deeper with this stuff.

@Peter Knight is that a C2 BikeErg?

This week on the dev branch we've got several commits with various core improvements and fixes. @adrian has been using Claude Code to suggest core optimizations (focused mostly on the PageFinder) and so he sent the suggestions to me. (PageFinder is the brains behind the $pages->find() method, and many others). I took the suggestions and coded them into our PageFinder, but didn't want to mess with what was already working well, so put them in a new class named PageFinder2, at least temporarily. If running the latest dev branch, you can enable PageFinder2 by adding the following to your /site/config.php: $config->PageFinder('version', 2); The most significant changes are: using subqueries for subselectors rather than separate independent queries; Reusing PageFinder instances (keeping a pool of typically 1-3 PageFinders rather than creating a new one for each $pages->find() operation); and lots of in_array() calls have been converted to isset() lookups, which should technically be faster (still the case in PHP8?, I'm not sure). There were some other changes as well. Theoretically these changes should make PageFinder even faster than it already is. I did quite a bit of testing and found that for the most part it performs the same as PageFinder v1. But then I came across a rather complex selector that translated to a much faster PageFinder operation, nearly twice as fast, and that convinced me it was worthwhile. While PageFinder v2 is not consistently faster than v1, there are some situations where it can be a lot faster. I'm not totally clear on what those situations are just yet, but I'll be doing more testing. In other situations it also can use a lot fewer queries, though that doesn't necessarily translate to a performance difference. But on the whole, all of Claude's suggestions were quite good, regardless of performance improvements. I was pretty impressed with what Claude Code had suggested, so decided to install it on my computer too. I've found it's particularly good at finding bugs. I'll ask it to do a code review on a core file, and it always has good suggestions. It uses ProcessWire terminology too. For instance it pointed me to an object that wasn't properly "wired to the ProcessWire instance", and that's something you'd only ever hear in ProcessWire land. Claude code also helped with improvements to our DatabaseQuery* classes, PagesVersions module, Wire base class, NullPage class, and minor updates to the PagesLoader* classes. I'm not having it write any code just yet, but am having it suggest where improvements can be made. I like to code. I asked it how it knew so much about ProcessWire, and it said that it stays up-to-date with the forums, the website, API docs, and GitHub repo. Thanks to @adrian and @Jan V. for recommending it to me (Jan V. uses it to manage this webserver), I can see how it's going to be a big help to ProcessWire with its suggestions and ideas, I'm already learning a lot from it. And if you get a chance to try the updated PageFinder, please let me know how it works for you. Thanks for reading and have a great weekend!

ProcessWire and photo-heavy sites go hand-in-hand. But these sites can also present development challenges, especially when cloning a large site. This post goes into detail about techniques you can use to keep lightweight development sites without all the photo/image overhead. https://processwire.com/blog/posts/developing-photo-heavy-sites/

@maximus Thanks for updating it. I had tried to do so a week or two ago and there were various variables involved in it that I couldn't figure out the source of, so ended up adding it to some version history log, thinking maybe it was pulling from that, but apparently it wasn't. It looks like you replaced the variables with the actual version, which is much simpler.

@gebeer That's an excellent summary, thanks! On the core-patterns one, the 'getExcerpt' example probably isn't ideal because it's only returning an excerpt if output formatting is on, otherwise it's returning the entire 'body' field with tags stripped out, which isn't an 'excerpt'. Usually a 'body' field is HTML (TinyMCE, CKE, etc.), so the formatted version would be the same as the unformatted version, unless there's some other formatters being applied on top of it, like TextformatterVideoEmbed, etc. There's an example of a getExcerpt() in the blog post that I think might work better, though I'm sure there are even better examples possible. In the same file, under API wire access, it says that pages() would not work in a Page class. But actually it would work just fine, so long as functions API is enabled. But what's preferable is $this->wire()->pages because it would be guaranteed to be tied to the correct instance (just in case multi-instance, even if rare). For calls like $this->wire('sanitizer') (where API var is in quotes) I'd suggest $this->wire()->sanitizer instead, just because the IDE will know that it's referring to the Sanitizer class, whereas if 'sanitizer' is in quotes then the IDE won't know, or at least it will have to do a lot more work to know. The same goes for any API variable. Lastly, do you think it could link to the blog post also, since that's the source for some of it -- It might help for folks looking for additional info? Thanks!