Jump to content

ryan

Administrators
  • Posts

    17,242
  • Joined

  • Days Won

    1,704

Posts posted by ryan

  1. @gebeer Sounds like Claudia would like to add the .agents/skills directory like you have. So if you are able to send a PR for that and with the ddev support, please do. We'll add something in the module that checks that we can write off the root path, and if not, we'll instruct them how to manually copy. The .agents directory may not survive all install methods, like ZIP upload and some FTP installations, so may be better to start with site/modules/AgentTools/agents/ dir and install to "/.agents/..." (with the period, if necessary). 

    • Like 1
  2. @gebeer Thanks! Sounds like Claudia would like a PR for the ddev update if available. For the skills stuff, thanks for explaining it all. I'll look forward to having a closer look in your commits but one thing noticed so far is that your version has the option to install the skill files off the PW install root in a .agents dir. But the only place PW an assume is writable is off the /site/assets/. So the .agents off the root would work in some installs and not in others. 

    Thanks for the example rock migrations file. It looks to me like the same format that the core Pages Export/Import module uses, except that the module uses them JSON encoded. While we're calling the ones generated by Claude with the AgentTools module "migrations", they really are just repeatable logic. So the logic can be about creating/updating/deleting some pages/fields/templates or perhaps something else. How does the Rock Migrations format work when you need some logic as part of the migration, such as creating a page, then creating another page that references that page (FieldtypePage)? You could do this with the pages export/import but would have to run the JSON through more than once to do it. Also, how does it handle files? Handling files is something AgentTools does not yet do. 

     

     

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

    • Like 1
    • Haha 2
  4. 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. 🙂

     

     

     

     

     

    • Like 2
  5. @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. 

    • Like 2
  6. @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.

    • Like 2
  7. 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/

    • Like 9
    • Thanks 2
  8. 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

     

     

     

    • Like 7
    • Thanks 1
  9. 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. 

    • Like 6
  10. @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. 

    • Like 6
  11. 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!

    • Like 17
  12. Quote

    If PW's codebase adopts any changes suggested by AI, my hope would be that it undergoes the same level of testing and scrutiny as any other code revision, and it seems like Ryan is doing just that.

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

    • Like 9
  13. @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.  

    • Like 1
  14. Quote

    I am sure many of you have seen @Ex-user's comments about AI data centres in the in the ProcessWire 3.0.257 – Core updates thread. It seems like we have lost them from the community, but I do think a Pub topic about the darker side of AI is worthwhile.

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

    • Like 8
    • Thanks 1
  15. @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. 

    • Like 18
  16. @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. 

    • Like 12
  17. @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. 

    • Like 8
    • Thanks 1
  18. 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! 

    • Like 22
    • Thanks 3
    • Sad 1
×
×
  • Create New...