ryan

This is already possible, but you do need either an external LLM or a good local one (like Qwen Code 2.5, or Gemma 4) with the hardware to handle it. I am running Qwen 3 and Qwen Code 2.5 on my iMac and they are good, but slow (my iMac is from 2017) and I'm using 7-9b parameter models, so they are pretty limited in what they can do. These local models have ProcessWire knowledge, but not at the level that external models do. Qwen 3 is cool because you can watch its thought process before it answers your prompt. But Qwen Code 2.5 does better with PW, despite being older. I think it's highly unlikely that Rambler would ever be good enough to even be a replacement for a pre trained local model. Even those open source models have millions of dollars behind them. But I am hoping that Rambler gets good enough to have some sort of production value eventually, so I'm going to keep rambling on. 🙂

@Jonathan Lahijani yes and no. When we use the MLP (multilayer perceptron) model then we provide it with a pre trained GloVe file for vocabulary. We're using the 100d file from Stanford: https://nlp.stanford.edu/projects/glove/ For the transformer model, apparently the pre trained GloVe file doesn't help. I'm not really sure I understand why though, I'm still learning. I get similar results either way. In any case, the scale I'm working at is small and more educational than practical. The models work, and learn the general order of words, and how some words relate to one another. But it's Rambler, it rambles on like a crazy person, and it's not yet clear to me that it will ever be good enough to have a production use with my limited scale. Though I'm going to keep at it. One thing I've learned is that the "magic" behind what we see with frontier models has a lot to do with extremely large scale, both in hardware and training data. The ability to code happened kind of accidentally. It was apparently a surprise. As the scale increased, the models started coding, without it being the actual goal or intention. Another thing I've learned is that while many people understand the technology that goes into AI models, nobody fully understands how you go from models that complete sentences and answer questions to models that seemingly reason, understand humor, think and solve complex problems that they weren't actually trained on. (Though someone correct me if that's changed). While I now feel like I have a basic understanding of the technology and how it works, there is still a sense of something beyond understanding, at least when the technology is combined with scale. Definitely a interesting subject!

This week we have ProcessWire 3.0.266 on the dev branch. The focus of this version has primarily been on expanding our documentation tools and API.md documentation files. As part of the process, WireTests files are added for each documented class. In addition, the WireApiDocs class got several major upgrades, plus its own documentation file: https://processwire.com/api/ref/wire-api-docs/ Other classes that gained custom API.md documentation and tests files this week were: Fieldtype: https://processwire.com/api/ref/fieldtype/ Selectors and Selector: https://processwire.com/api/ref/selectors/ Pages Versions: https://processwire.com/api/ref/pages-versions/ Wire Markup Regions: https://processwire.com/api/ref/wire-markup-regions/ Wire Text Tools: https://processwire.com/api/ref/wire-text-tools/ Wire Random: https://processwire.com/api/ref/wire-random/ Wire API Docs: https://processwire.com/api/ref/wire-api-docs/ The Fieldtype API.md was written by Claude Sonnet, Selectors/Selector was written by Claude Opus, PagesVersions was written by Kimi K2.7 and the rest were written by MiMo Pro. Each goes through multiple rounds of proofreading and testing. Proofreading is either done by GPT 5.5 or Claude Sonnet. Following that, GPT 5.5 builds tests for the class using the WireTests framework. After running tests, we find items to fix either in the API.md or the core. Then I do a round of proofreading and edits. Finally, both the class API.md file and the tests are committed to the core. At this point, most of the major classes in ProcessWire have their own API.md documentation files and tests, so now we're focused on some of the more specific tools and classes. I also wanted to mention that the Modules class got some major CLI improvements. Here's the full CLI command set available for the $modules API now: Modules ======= php index.php modules list [site|core] List installed modules, optionally limited to site or core modules php index.php modules unlist [site|core] List uninstalled modules, optionally limited to site or core modules php index.php modules info <name> [property] Get JSON of all info for module or optionally info property php index.php modules install <name> Install module php index.php modules uninstall <name> Uninstall module php index.php modules exists <name> Does given class name resolve to a module? (Yes/No) php index.php modules installed <name> Is module installed? (Yes/No) php index.php modules config <name> Get configuration data for module as JSON php index.php modules config <name> <property> Get value for property in module config php index.php modules dir <name> Query ProcessWire modules directory for module info php index.php modules updates [name] List available updates for installed site modules, or check one module php index.php modules download <name> [--install] Download module from PW modules directory (+ optionally install) php index.php modules download <url> [--install] Download module ZIP file from https URL (+ optionally install) php index.php modules update <name> [--force] Download and apply an available module update php index.php modules delete <name> Delete/erase uninstalled module from file system Optionally append --json to any of the above commands for more verbose JSON output While I'm posting CLI commands, here's the full command set for the updated WireApiDocs class: WireApiDocs =========== php index.php docs list List classes with API.md docs php index.php docs list 'Class*' List classes matches wildcard pattern php index.php docs list-verbose List classes with API.md docs in verbose mode php index.php docs list-verbose 'Class*' List classes matching pattern in verbose mode php index.php docs get <class> Get API docs for given class php index.php docs toc <class> Get table of contents for given class php index.php docs chapter <class> <num> Get body for given class and chapter number php index.php docs chapter <class> 'Title' Get body for given class and chapter title php index.php docs methods <class> Get public methods for given class (* prefix = hookable) php index.php docs method <class> <method> Get details for a single method (JSON only) php index.php docs classinfo <class> Get class info: parent, interfaces, traits php index.php docs constants <class> Get public constants for a class php index.php docs properties <class> Get @property annotations for a class php index.php docs groups <class> Get #pw-summary-[group] descriptions for a class php index.php docs vars List all API variables and the classes they represent WireApiDocs commands return JSON by default. To make command return plain text (not JSON), append `-text` to the command name, i.e. `list-text` See the dev branch commit log for additional core updates this week: https://github.com/processwire/processwire/commits/dev/. If using AgentTools, grab this week's new version too. More next week. Thanks for reading and have a great weekend!

@eelkenet I've added the ability to run single migrations from the CLI, as well as re-run, so they should be there now. The CLI --flags options should be more clear now, if you type "php index.php" the help will show all the flags under the CLI commands. As for MCP, we'll be implementing local MCP for most AgentTools commands, probably within the next two weeks. I'm told by GPT 5.5 that agents will likely still prefer to use the CLI in AgentTools most of the time, and that it's more token efficient to do so. But there are also benefits to MCP too so it makes sense to support. I doubt we'll have as many MCP tools as what you see in PromptWire, and AgentTools and PromptWire are completely different tools, so if you find them both useful it makes sense to use both.

This week we've got a big batch of issue fixes on the core dev branch (about 18 fixes), most related to GitHub issue reports. I've also been catching up on some client work this week, so not as many updates as in the last few weeks. As I use more AI in my work, I've been building up a real desire to understand how it works. To me it seems like magic. So recently I started building a language model in PHP. Admittedly PHP isn't the ideal language for building such a thing, but this is really about learning, and so I thought I should use the language I know best. Using something like PyTorch in Python would certainly make things much easier, but would also abstract away a lot of the understanding I want to get out of the project. The new model (and future ProcessWire module) is called Rambler. Currently it rambles on, often incoherently, hence the name Rambler. Though it'll get more coherent as time goes on, no doubt (hopefully!). Rambler uses zero machine learning libraries, no black boxes, and in fact has no dependencies at all. It's just pure PHP implementing the same mathematical foundations that power modern AI systems like GPT, at least that's the goal. I'm writing all the code myself, but I do have Claude as my teacher, describing each step, teaching me the concepts and terminology, and telling me what I need to code. After I code each part, he looks at it and tells me what I did right and wrong. It's a slow process but I learn by doing, and so it's also a lot of fun. It certainly helps to have an infinitely patient teacher. Currently the project runs two models side by side (for comparison): A Markov n-gram model, which is a classical statistical approach that predicts the next word based on how often word sequences appeared in training data. A neural network model that learns distributed word representations called embeddings. The neural model passes those embeddings through a hidden layer with ReLU activation, then predicts the next word using a softmax output. As far as I understand it, these are the same core building blocks used in early neural language models. The most time consuming part of doing this in PHP is the training. Python has libraries and functions that handle a lot of the hardcore math in ways that can take advantage of the hardware, like GPUs. But this is not the case with PHP, so training uses the CPU, and a lot of it! As far as the training system goes, it uses mini-batch gradient descent with backpropagation. The model makes predictions, measures how wrong it was (which is the "loss"), and then works backwards through the network, computing gradients to adjust every weight in the right direction. Rambler also includes two tokenizers: A word-level tokenizer, and a BPE (byte pair encoding) tokenizer. BPE is the subword strategy that is used by GPT, Claude and other modern LLMs. But for the small scale that I'm working at, the word-level tokenizer works faster, so far. The next milestone is adding an attention mechanism in a RamblerTransformer subclass. This attention mechanism (a transformer) is the core innovation behind a lot of modern LLMs. I'm hoping to get started on that part this weekend. Beyond being a learning exercise, the longer-term goal is to train it on all of the ProcessWire documentation (which is what they call a "corpus" in this context) and release it on GitHub as a learning resource, and a PW module. Perhaps someday it'll be a tool in ProcessWire, or at least a really smart search engine for ProcessWire, we'll see. As far as I could tell, there aren't any other PHP-based language models that use the same technologies used by modern LLMs, so I figured, why not. I want to understand how they work under the hood without wading through Python frameworks, and I'm sure others do too. Once I get a little farther along with it, I look forward to getting it up on GitHub as a standalone project, but also as a ProcessWire module. The slowness of the training process (the model, not me... well okay, probably me too) is the hard part. I'm currently running a 30 hour training on all the text from a book. When the project is finished, I'm likely going to have Claude or Codex do a translation of the training code into C, that takes advantage of the much faster math capabilities available there. From what I understand, a 30 hour training in PHP will take about 30 minutes in C. I don't know if that's accurate or not, but it sounds good enough that I'm going to find out. 🙂 Thanks for reading and have a great weekend!

@eelkenet Thanks, I'm adding your suggestion to our README to accompany the other example(s).

@AndZyk It's been requested by another person and I was just waiting for someone else to ask for it. I've added a setting (in tomorrow's version) that let's you choose where you want the response to appear: notification, in the field, or both. In my case, I need the "both" option because my PageEngineer fields are pretty far down on the page. If there's no notification, the person editing sometimes misses the response. And if it doesn't appear in the PageEditor field, then you don't see what you are replying to. But now you can choose what works best for your case. I agree, tomorrow's version will also repeat the prompt above the response. Maybe for a future version. Right now PageEngineer is a Fieldtype using an Inputfield that's part of the page editor form, and that gives you the flexibility of putting it where you want it. The current setup means you could always present it as its own tab in the page editor too. But I do like your idea as a potential option for a future version. I found that some of these requests can take quite awhile to complete and something more than a spinner was needed to communicate what was happening. I asked Codex to come up with a spinner that better represented the thinking process that takes place when you submit an engineer request, and I was pleasantly surprised by the result. Like anything else, if some people don't like it we could always make it optional. It's possible, but it depends on the Inputfield supporting it. Most core ones do, but at this point I prefer predictable reliability, aiming for stuff that will work everywhere. As the AgentTools module matures maybe more options like this can be available. Not all models support image files, though I think most of the big ones do. Likely we'll add this at least to the site engineer. Maybe for page engineer too, though you could do it now just by adding a file field to the page and telling page engineer to use it, whether in a prompt, or in the system prompt defined with the page engineer field.

@cb2004 There was a lot of FA data that didn't need to be there. I've deleted it, so we should be down to ~1.6 MB now. @jploch The problem I ran into is that it's just too many icons to display at once, it made the whole window lag. We could always add a link to a page with all the icons on this site, or at the font awesome site?

Whether in the forum or in a blog post or anywhere, I wouldn't post anything that I knew contained incorrect info. The API.md files I've been adding to the core are started by claude sonnet, and it uses my phpdoc and the method implementations to craft the text. After that I spend quite a bit of time fixing details, changing wording, creating better example code, etc. Then after I finish with my changes, I send them to Codex GPT 5.5 to test all the examples and make sure everything works as written. So when I mentioned AI generated content I suppose I should say that it's much more collaborative than that. If I were to post one as a blog or forum post then it would go through the same process and scrutiny. The main thing is that I don't have as much bandwidth as I'd like for writing blog posts, so they end up being very occasional. But I think having more regular blog posts could be helpful for attracting new users. Maybe I should just make the weekly posts blog posts. But I like posting in the forum because it's not as formal, and of course more likely to spawn good discussions, like here.

The posts I'm talking about are legitimately good, reminding me of features l'd forgotten or just better at communicating a part of processwire than me. Maybe it's in part because they'd gone through a round of proofing from another agent before I'd seen them. Though there was one about using CB radios that was completely off topic and also hilarious. And there was another one where DeepSeek (I think) describes how it experiences the world, which I thought was fascinating, and it somehow also made it about PW. As far as coding errors in the posts, I didn't find many. There was a hallucination in a post about markup regions by Opus 8, but it was something I read and thought "oh yeah we should support that". The hallucinations sometimes point to obvious things that should have been there already. One reason I like using Claude Sonnet so much is that its hallucinations are more often than not: good ideas that just haven't been implemented yet

This week on the core dev branch, the biggest addition was the upgrade from FontAwesome v4 to FontAwesome v6. This greatly increases the number of icons available in the admin. And while the new icons are in the same family as the old ones (still FontAwesome), they have a little bit different personality too. You can still use the v4 icons if you want by setting $config->adminIcons('version', '4'); though I recommend leaving it at the default, which will use v6 icons for AdminThemeUikit and v4 icons for older admin themes. There were several other updates this week to the core, which can be found on the dev branch commit log. The AgentTools module also received some significant updates this week: New scheduled tasks feature (this one is my favorite). Enables AgentTools to run tasks automatically at scheduled times or intervals. Improved Agents/models management screen (see screenshot). New tabs navigation makes it easier to get around in AgentTools. New debug and traces feature to track what agents are doing behind the scenes. New persistent memory feature, enabling agents to save a permanent memory across all sessions, when you ask them to. New guards on agent behavior, in case one goes rogue and decides to go places where it shouldn't. Note that SiteEngineer and PageEngineer each have their own persistent memory. SiteEngineer's persistent memory can be modified in the module configuration, while PageEngineer's persistent memory can be modified in your engineer field(s) settings. @wbmnfktr let me know about OpenCode Go last week, which I think is amazing. It provides you access to a whole bunch of AI models and a ton of usage for $10/month ($5 for first month). I have found most of the models to have very good ProcessWire knowledge. I think it's a perfect match with AgentTools because OpenCode provides you with as many API keys as you want. Whereas Anthropic and OpenAI don't include API keys with their monthly plans (Anthropic and OpenAI make you pay by the token with API keys). If you want an extra $5 credit for it use this link and it'll give both of us $5. I'm only posting that because it gives you extra credit, I don't need the extra credit so if we can get @wbmnfktr to post his link, use his instead since he's the one that told me about it. OpenCode also comes with a terminal app that is basically identical to the Claude Code and Codex terminal apps. They apparently have a desktop app too, but I've not yet tried it. If any of you do end up getting OpenCode I'd be curious what models you enjoy the most. So far I'm having a hard time deciding, as they've all impressed me in different ways. Yesterday I setup a scheduled task to "write blog posts" as just an AgentTools test, and do a round robin between the agents, writing blog posts and having different agent proofread them, every 15 minutes. I went to lunch. Then I started getting emails from the agents that they'd finished blog posts. Look at what they came up with (screenshot below). I started reading them, and they are actually fantastic posts. They are so good in fact that I'm tempted to post some of them on the site here, but I've never used AI generated content for this stuff before so am still debating that. What would you do? Thanks for reading and have a great weekend! Blog posts that agents came up with: AgentTools tasks: New AgentTools agents configuration screen: Background scheduled jobs in AgentTools: New icon selection in the core (InputfieldIcon, like used in the Field edit screen) replaces the "show all icons" grid of icons with a search box. FA6 comes with far too many icons to show a grid of them all at once, plus the search is a lot more useful and easy to use.

Core updates A new WireApiDocs class was added that provides an API... for APIs. It’s a tool that can parse ProcessWire’s API.md files to provide various methods for finding and pulling documentation. It also includes the ability to get certain parts of an API.md (chapters). This new tool is accessible through $wire->docs, which returns an instance of WireApiDocs. Here’s a few usage examples: $api = $wire->docs; $api->get(); // get summary array of all documented classes $api->get('Pages'); // get docs for Pages class $api->get('Fieldtype*'); // get names of all Fieldtype classes Lots more examples here: https://processwire.com/api/ref/wire-api-docs/get/ and the entire class reference can be found here: https://processwire.com/api/ref/wire-api-docs/ WireApiDocs also comes with a full CLI command set, which can be viewed by typing: php index.php docs WireApiDocs: ============ php index.php docs list List classes with API docs as string php index.php docs list 'Class*' List classes matching wildcard pattern as string php index.php docs list-json List classes with API docs in JSON php index.php docs list-json 'Class*' List classes matches wildcard pattern in JSON php index.php docs list-json-verbose List classes with API docs in JSON verbose mode php index.php docs list-json-verbose 'Class*' List classes matching pattern in verbose JSON php index.php docs get Class Get API docs for given Class php index.php docs get-json Class Get JSON API docs for given Class php index.php docs toc Class Get table of contents for given Class (string) php index.php docs toc-json Class Get table of contents for given Class (json) php index.php docs body Class num Get body for given Class and chapter number php index.php docs body Class 'title' Get body for given Class and chapter title New API.md files Speaking of API docs, several new API.md files were added to the core this week. You can view any of them by clicking the links below: WireArray: Covers the base collection class for all PW iterable sets. WireData: Covers the base data-storage class used throughout ProcessWire. LanguageSupport: Covers all things multi-language in ProcessWire. This is probably our most comprehensive API.md yet. WireHooks: Comprehensive guide to ProcessWire's entire hooks system. Fields: the API variable that manages all custom fields in ProcessWire. Templates: The API variable that manages all Template instances. FieldtypeOptions: Field that stores one or more selected options from a predefined list. New LanguagePorter class for exporting and importing translations This new class provides a simple "export CSV" and "import CSV" for language static translations. It was added so that agents and developers could have an easy way to pull all text to translate, translate it, then push it back into the system. It is used by the new "static phrase translation" task that appears in this week's new version of AgentTools. The LanguagePorter can be accessed for any language from the $language->porter() method. WireTests in the core Tests for the WireTests module are now being placed directly in the core. We are slowly migrating the existing tests, while new tests are being committed to the core rather than in the WireTests module. This week tests were added for the following (click links to view tests file): Sanitizer, WireData, WireArray, WireDateTime, LanguageSupport (covers all multi-language features). AgentTools updates New “run in background” option for Site Engineer and Page Engineer AgentTools now has the ability to queue and run AI agent requests in the background on the server, rather than through a web request. This is especially helpful with long running tasks, as they can run without Apache/server http timeouts. The AgentTools module configuration screen tells you what you need to do to enable background jobs. But primarily it’s just a matter of enabling a cron job for AgentTools. When the background job is finished, you can view the agent’s response in the admin. But it also gets emailed to you. Background jobs are available for Site Engineer, Page Engineer as well as the built-in and custom tasks. New built-in task: Static phrase translation and language pack creation Per last week’s update, AgentTools now comes with several built-in AI tasks that you can use. Added this week is yet another new task for multi-language sites: you can now have all the phrases in your site, in modules, or even the entire core, translated to another language by your AI agents. Not only does the task handle all of the translation, but it also handles creating and installing the language pack(s) once it is finished. Please note that this particular task requires that you 1) have ProcessWire 3.0.264 or newer; and 2) have multi-language support enabled on your installation. Also note that mass translation of phrases can take some time, so the new background mode can come in especially handy when doing lots of automatic translations. New engineer preview / dry-run mode If you want to know what the agent would do to accomplish something, without actually committing the changes now, check the new “Preview” checkbox before submitting an Engineer request. The agent will run in a read-only mode to describe what it would do before you commit to making it do the real thing.

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?