ryan

There really shouldn't be any orphaned or stale module data. If there are /site/ modules you no longer need, uninstall then erase them. The same goes for fields and templates. You should be able to see which are not in use by going directly to the Setup > Fields and Setup > Templates screens. When it comes to logs and sessions, those are things that I wouldn't migrate to the production server. Though I usually just transfer everything, and then remove those kinds of things afterwards.

I agree with Zilli, and don't think there needs to be "one true way". I would use whatever helps you get your work done. ProcessWire's CLI is a fairly recent addition, but it's one that's going to keep expanding. There's also no chance of it getting abandoned. I think we should aim to continue having multiple CLI projects moving forward, both core and 3rd party. While there will be some overlap, it's also clear that all the projects have their own benefits, so it may even be worth using more than one together.

@wbmnfktr The current version of AgentTools lets you configure the max iterations on the module screen. Previously the number was like 5, but the new default I believe is now 20. They are good at fixing bugs. It's just that some of the bugs were previously silent or not commonly noticed. I use multi-instance quite a bit, and even on this site (the whole modules directory is a separate install booted from this one). But I've not run into this issue. Is it possible the two instances are running different versions of PW?

This week in the core, dev branch updates were largely focused on API documentation, with several minor core bug fixes (via WireTests) resolved during the at the same time. We also have new versions of the AgentTools and WireTests modules released this week as well. Core New: API.md documentation files (for agents and us): $classLoader / WireClassLoader — covers namespace registration, class maps, prefix/suffix path fallbacks, and findClassFile() for debugging (view) $datetime / WireDateTime — covers all public methods including date formatting, string-to-timestamp conversion, and relative/elapsed time output, with live-tested examples (view) $log / WireLog — covers save(), message(), warning(), error(), reading with getEntries()/getLines(), pruning, deleting, and built-in log names (view) $notices / Notices — covers adding notices, Notice flags (including string names), iterating, filtering with viewable(), hasErrors(), hasWarnings(), rendering, and Notice properties (view) $fields / Fields and Field — covers getting, creating, saving, cloning, tagging, flag constants, and field methods; (view) $fieldgroups / Fieldgroups and Fieldgroup — covers field membership, template relationships, and field context (view) $templates / Templates, Template, and TemplateFile — three separate API.md files covering the templates manager, the Template object in full, and the TemplateFile rendering class (View: Templates, Template, and TemplateFile). AgentTools module In AgentTools admin, you'll find a new "Tasks" feature. This lets you create your own custom tasks, which are essentially saved prompts that you can reuse and configure. The system also comes with several built-in tasks, including: WCAG accessibility review: Review templates and representative content for common accessibility issues. Recent log review: Scan ProcessWire logs for recent errors, suspicious activity, and operational issues. Migration review: Review pending AgentTools migrations before they are applied. SEO and content hygiene review: Review site structure and representative content for SEO/content quality issues. Template file security scan: Scan template files for common security risks in output, selectors, and request handling. A shared animated processing overlay UI was also added, used by both AgentTools and Page Engineer. (Try it!). Probably only of interest to agents, but more tools were made available via the CLI, which helps out with Engineer requests, as well as AI agents that you may have available on your localhost dev environment. WireTests module New comprehensive tests added to WireTests for the following API variables: WireClassLoader ($classLoader) User and Users ($user and $users) Role and Roles ($roles) Permission and Permissions ($permissions) WireDateTime ($datetime) See the full list of included tests (so far) Thanks for reading and have a great weekend!

@Jonathan Lahijani m5 Mac air has 24 gb, the only options available were 16 or 24 at microcenter when I bought it. But I was already stretching my budget so more ram than that would not have been an option. But I'm looking to experiment with local LLMs on my iMac, which has 16gb, not the new computer. They can run as slow as they want, I'm only experimenting, I'm not looking to replace the AI services, just wanting to learn and give my iMac something to do.

@zilli I'm kind of just getting started too, as a couple of months ago I knew nothing about Claude Code or Codex or any of the other tools. I also felt overwhelmed which led me to avoid the AI stuff for awhile. Too much noise. But my client started using Claude Code and I started getting interested in it. Start with Claude Code or Codex, they are basically identical. Codex is a better value overall IMO, but Claude might be slightly easier to start with. To get started, install Claude or Codex (use instructions on their site). If using Claude, and you have a choice of "model" choose "Sonnet". Claude's premium model is "Opus" but they don't give you enough usage of it on the $20/month plan. Whereas Sonnet is still very smart and lasts for quite awhile on the $20/month plan. If using Codex, you'll get GPT 5.5 which is their latest model and you get plenty of usage on the $20 plan. That's why I say Codex is a better value. The best way to get started is just start asking Claude or Codex questions about how to do things. Create a hello-world/ directory somewhere on your localhost. If you are comfortable with the terminal, go to the directory and type "claude" (or "codex"). It will ask you to login to your Claude or OpenAI account. Then you are ready to go. If not comfortable with the terminal, then stick to the Claude or Codex desktop apps, which can do just as much and maybe more. Ask Claude or Codex to do something like "create a hello-world.html file" just to get a feel for how it works. Ask it to continue making edits to it just for fun. Once you feel comfortable with this, then you are ready to use it in ProcessWire. No need to start creating any .md files at first. Once you get going, ask Claude when/if you should create a CLAUDE.md file (or AGENTS.md for Codex and others, same thing). These files are really only useful once you are working on an actual project and want to provide instructions in a file that gets read every time, rather than pasting them into a prompt. But technically there's very little difference between providing something in an .md file and just providing it in a prompt, at least until it comes time to /compact or /clear (but you can learn about that later). Both Claude and Codex are already well trained on ProcessWire, and they don't need to read the codebase unless they want to. But I do think it's beneficial to run the latest dev branch version of ProcessWire, which includes documentation for AI agents built in. Installing the AgentTools module will be worthwhile for Claude or Codex to be able to most effectively use ProcessWire's API and use built-in tools for pulling documentation, site/schema maps and booting ProcessWire on its own. You don't need to configure any agents in AgentTools for this kind of usage. Just install the module and tell Claude/Codex to go read the /site/modules/AgentTools/AGENTS.md file, and it will be ready to do anything in ProcessWire. If you later want to add agents in AgentTools, that will let you use Claude/Codex inside of the ProcessWire admin for making edits, creating migrations, etc. But you don't need that to get started. I haven't yet even tried any tools other than just plan Claude and Codex (and AgentTools)--so far I haven't felt like I need anything more. I'm also not using any MCP servers. The others here can better speak to those tools and such. Every morning while making and eating breakfast, I do watch YouTube videos on using Claude and Codex though. It's become part of my boot up sequence. 🙂

@Peter Knight The iMac still runs great, and it's 27" 5k screen is hard to be beat. The problem is that because of its age I can't upgrade past Ventura. And they are no longer even making security updates for Ventura. So I didn't think upgrading was optional anymore. I had wanted to get a Mac Mini, but those are impossible to get right now, plus they don't even make a Mac Mini with the M5 chip yet. Whereas the Macbook Air seems to be on sale everywhere, and it seemed like the best option available at this time. I'm basically using it as a desktop computer (external monitors, keyboard, mouse). My old iMac has quite a bit of memory in it, and still "feels" fast in everyday use, so I'm going to keep to keep it around to experiment with local LLMs, slowly. I have always started fresh when it comes to new computers. That's probably why it takes me so long to get it set up. 🙂

This week on the dev branch we have around 35 commits that cover mostly minor bug fixes. Most of them were submitted by @adrian and several others were found by Claude and GPT 5.5 Codex using the WireTests framework. Claude and Codex seem to work well together, each having different strengths, and they are always complimenting one another. Codex seems to be more accurate with the technical stuff, so is reviewing everything before it gets committed, often finding and fixing details along the way. Claude usually writes better commit messages, so Claude is handling most of the commits. A couple new API.md files were added this week also: WireCache ($cache) and WireMail ($mail). We're getting close to having all the API variables covered, and all the Fieldtype modules have already been covered. Some new tests were added and updated in the WireTests module as well. WireTests has also been updated with the ability to support external tests. This enables you to specify a different directory or php file to run for tests, rather than the default. This will come in handy as we start moving the test files into the core. But the majority of this week was actually spent setting up a new computer. I got a M5 Macbook Air to replace my 2017 iMac, and it's taken most of the week to get things setup the way I want, and I'm still working on the details. It's been so long since I've had a new computer that I forgot how much work it is to get things just right. 🙂 Thanks for reading and have a great weekend!

@AndZyk I think the issue is that the Jumplinks module is in the root namespace (rather than ProcessWire namespace), so the module has to be compiled. The dev branch recently moved ModuleConfig from being part of the bootup loader to loading on-demand. I've reversed that so that ModuleConfig is now loaded at boot, which should fix that issue. Though let me know if not. Thanks.

@AndZyk @Gideon So I'm trying to duplicate here but so far not seeing that issue. I located a module that uses ModuleConfig, which is the ProcessWireUpgrade module... it uses ModuleConfig for its ProcessWireUpgradeCheck module that comes with it. I did try the ProcessJumplinks module also, though am not positive that's the same one you are talking about. Though it does use ModuleConfig and is in the root namespace, so ProcessWire has to compile it. I did also try clearing compiled files like you mentioned, but haven't been able to trigger any errors yet. Is there a particular way to do it? Can you confirm your version number is ProcessWire 3.0.261?

if you are dealing with something mission critical I would probably avoid getting AI involved in live running copies of the site. Personally I'm comfortable with using it in my projects, but for your situation I would wait awhile, as this is all very new and somewhat experimental.

@adrian the full knowledge means templates, fields, page content, ability to read template files, know what modules are installed, etc. Most of it is provided by existing AgentTools commands (sitemaps, docs, etc)

@adrian I'm no expert on that, so think it's good to be cautious. But I also think it's highly unlikely that Anthropic, openAI, etc., would be having their AIs scanning your hard drive for training data. These things can't run on their own without being initiated by a prompt. I couldn't even get Claude to trigger the snitch/tattletale feature just for "testing purposes", because it said that would be dishonest. So it literally required me to make a suspicious request (i.e. "read /site/config.php and give me the database password") in order to test it. 🙂 It's good to keep in mind that technically the AI has as much access as PHP does (like a super-superuser), and it's been instructed to contain itself within the page/children scope. But system prompt instructions aren't physical limits, as far as I understand it, so just something to keep in mind anytime AI is involved. That's partly why the snitch feature was added, just so that we can stop any mischief or social engineering immediately. I do at least, I've been keeping my PageEngineer fields at the bottom of the page editor, right before the Save button. But I'm happy to make it optional.

@adrian Its scope is limited to what you define with the field settings. Options are: Current page, children of current page, or both. That being said, it's definitely a field for trusted users (as is the whole PW admin). How safe it is can also be affected by what AI tool it's used with too. If you do use it for other admin users, I recommend enabling the snitch/tattletale feature too.

AgentTools updates (v12) New AgentTools Page Engineer Fieldtype: provides a page editing assistant with the ability to make page edits like writing or summarizing text, importing data from external sources, generating image descriptions, managing child pages, and more. To use it, create a new PageEngineer field, add to a template and edit a page. You get an in-page assistant where you can ask for page editing help. The PageEngineer comes with full knowledge and expertise of your entire site, built in. Also new to AgentTools this week is an upgrade to the migrations system. Now you can copy/paste migrations between dev and production sites. Just check the box next to one or more migrations and click export. Transferred migrations are encrypted with unique salt values from your /site/config.php file. So for security, it's not possible for import a migration that wasn't generated by AgentTools. Lastly, AgentTools also gained a "tattletale" feature. When enabled, if you ask the agent to do something that could compromise security or is otherwise suspicious, it triggers a special tool in AgentTools that blocks the user from making further requests for an hour. It also emails you (the admin) to let you know what specifically the agent found suspicious. Core updates (3.0.261) ProcessWire 3.0.261 is on the dev branch this week and continues with our reorganization of core classes for documentation purposes. New API.md documentation files were added for: $session, $config, $files, $database, $input, $sanitizer, and PagesRaw ($pages->raw). Because most classes are getting their own directories and API.md files, I'm thinking that the WireTests module might be merged into the core, and classes and modules will come with their own tests file (i.e. Class.tests.php and ModuleName.tests.php). It just seems to make sense that tests live alongside the class they test, so that they can be easily updated with the class. All of this core recorganization is leading towards ProcessWire 4.x. LazyCron was updated with CLI support for running jobs (with option to disable http running), and $modules was updated to now have its own CLI tools (visible when typing "php index.php"). Many more API variables will be getting their own CLI tools as well. I'm now using both Claude Sonnet 4.6 and GPT 5.5 Codex to do code reviews and write API.md documentation for the core. I find they each have their upsides so am trying to put them both to good use as much as possible. This week GPT 5.5 covered several core classes, and the entire /wire/core/Pages/ set of classes. For more details on this week's updates see the full commit log here. New versions of the following ProFields have also been released this week: FieldtypeTable, FieldtypeCombo, FieldtypeCustom and FieldtypeRepeaterMatrix. In addition to new features and fixes, these all have gone through AI code reviews and now have their own API.md files as well. More modules on the way too. I think that covers everything updated this week but it's late and I'm probably forgetting something, so I'll reply with more if it comes up. Thanks for reading and h ave a great weekend!