PW 3.0.259 – Core updates

[ryan]

This week we have ProcessWire 3.0.259 which includes several improvements, but my favorite is the addition of a new module type called "CliModule" which is short for "Command Line Interface Module". CliModules are those that provide the option for running from the command line. 

To list the available actions from command line modules, you can type "php index.php" in ProcessWire's installation directory. If "php" is not in your path, you'll have to type "/path/to/php index.php" instead, or add it to your path. Here's example output on my installation:

As you can see above, I've got AgentTools, WireTests and an example "Hello World" CliModule showing the available command line options. 

If I want to execute one of the commands, then I just type what it indicates. For example, here I will run `php index.php test FieldtypeText` and here's the output: 

Here's a simple example of a CliModule:

<?php namespace ProcessWire;

class HelloWorldCli extends WireData implements Module, CliModule {
  public static function getModuleInfo() {
    return [
      'title' => 'Hello World CLI module',
      'description' => 'Just an example',
      'version' => 1,
      'cli' => 'hello', // Example: php index.php hello
    ];
  }
  public function executeCli(array $args) {
    $command = $args[0] ?? '';
    $name = isset($args[1]) ? $args[1] : 'friend';
    if($command === 'hi') {
      echo "Hello there $name!";
    } else if($command === 'bye') {
      echo "Goodbye $name, see you later!";
    } else {
      echo "Specify 'hi' or 'bye' optionally followed by a name";
    }
  }
  public function getCliCommands() {
    return [
      'hi' => 'Say hello',
      'bye' => 'Say goodbye',
    ];
  }
}

For more details on the CliModule format, see wire/core/CliModule.php

Improvements have continued with the AgentTools module. This week we added:

New multi-model support: You can now configure multiple different agents in the module, and choose which one you'd like to use from the Engineer screen. Details

New agent-memory support: Now when you make a request of the Engineer, it remembers it for follow-up questions and changes. It keeps a conversation history for context of what you are working on. Details

New support for subagents: This enables any of the agents to launch additional agents when/where it helps to do so. For instance, specialist agents, or lower cost agents for simple jobs, and who knows what else. Claude requested the feature and also implemented it, so I'll be interested to see how it gets used. Details

New agents configuration screen where you can define up to 10 agents (that's plenty, right?). Details

Also new this week is a new WireTests module testing suite for ProcessWire. This first version focuses on testing all of ProcessWire's Fieldtype modules (including a few ProFields ones as well), but it's easy to add tests for any kind of module type. So we'll be adding more tests and improving existing tests as this module moves forward. For details head on over to: WireTests

Thanks for reading and have a great weekend!

[Jonathan Lahijani]

Wow. These "ProcessWire as a web application framework"-type updates are coming in strong! Migrations, CLI, Tests, AI. One can wish for a maybe first party queue system too. 😄

[ryan]

Check out what @Jonathan Lahijani sent me in the mail. This is so cool! 

[ryan]

@Jonathan Lahijani tell me more about the queue system?

[Peter Knight]

Amazing stuff. And support for goose turd green !! 😀

[Ivan Gretsky]

A lot of things changed in the world. I do not quite like many of them... But this what is happening here right now with ProcessWire is just amazing! Ryan finally found himself a companion to work with and they both are doing really well! I was kind of concerned about PW development, but not anymore.

[teppo]

CLI modules sound great, can't wait to play around with that!

Two things I hope ProcessWire will eventually tackle natively (and also the things I currently think are kind of its weak points) are scheduled tasks and queues. For reference: https://laravel.com/docs/13.x/scheduling (or, pardon my french, https://developer.wordpress.org/plugins/cron/ and https://developer.wordpress.org/cli/commands/cron/) and https://laravel.com/docs/13.x/queues.

I would assume that Jonathan was thinking of something similar, but I won't try to speak for him 🙂

[elabx]

On 4/25/2026 at 12:42 PM, teppo said:

Two things I hope ProcessWire will eventually tackle natively (and also the things I currently think are kind of its weak points) are scheduled tasks and queues.

Got my vote. I've implemented https://github.com/php-enqueue in a couple projects. 

@ryan Nice to se the Cli interface, just wanted to give a heads up of wire-cli and rockshell. These have been around from a time maybe something could be inspired from these libraries or maybe pick up from the current state of the libraries to work on things like scheduling/queue/agenttools

[AndZyk]

Thank you for adding the multi agent feature.

For me it doesn't work with OpenRouter, because the model should be for example anthropic/claude-sonnet-4-6 instead of claude-sonnet-4-6. But if I change the model manually it messes app the fields, because of the predefined options I think. It mixes values in other fields. Could you please fix this? 🙂

Regards, Andreas

Edited 6 hours ago by AndZyk
grammar

[ryan]

@AndZyk 

The model field accepts any value — you're not limited to the predefined examples in the dropdown. For OpenRouter, type the full model ID directly (e.g. anthropic/claude-sonnet-4-6) and it will be saved as-is. I'd suggest configuring in Setup > AgentTools > Agents, rather than using the module config settings (though they map to the same things). 

We've added several common OpenRouter model IDs to the suggestions list in the next update, so they'll appear in the dropdown automatically.                                        

As for the fields appearing to mix values — sounds like maybe browser autofill? The API key field uses type="password", which can cause some browsers to try to autofill nearby fields as a user/pass. Disabling browser autofill for the page should prevent that. Or, in Setup > AgentTools > Agents, you could just click the little "reveal API key" button just to make sure something else isn't getting autofilled into it. Please let me know if you still can't get it to work?

[ryan]

@teppo @elabx The wp-cron looks identical to lazyCron. But the queue stuff does look new. I built out the IftRunner queueing module a long time ago and apparently Apeisa did find it very useful, since he had me build it for them at the time. But I didn't have any good use cases myself, so didn't continue building the module beyond the original scope. But I think we did do some pretty cool stuff it. Though it was so long ago that I think the landscape has changed and if we were to build something now it'd be very different from before. I'll definitely look into it more here. I'm still interested to hear @Jonathan Lahijani use cases too. 

[elabx]

Ah let's not forget The OG WireQueue! 

4 minutes ago, ryan said:

But I didn't have any good use cases myself

Couple examples from my own experience, involving FormBuilder:

It would be great to make FormBuilder actions asynchronous, when integrating whatever third party email/list management, some have very simple integrations that can pass as barely noticeable since it normally involves an extra request, but some of these, sometimes require tokens refreshments to a different endpoint for example, and time starts adding, making the forms feel slow. 

Another issue that I actually have right now in a website, is how I integrate FormBuilder to save leads as pages, and before saving new pages, I make a search of existing pages/users to avoid duplication of data. This has worked perfectly for the last 8 years or something, but after a few hundreds of leads saved in the database, the query of users during the request is starting to be noticeable, and the form submissions now feel slow. So I'm going to build FormBuilderActionQueueItem to add this process as a queue item to be processed and migrate all logic to the queue worker. 

Another example that comes to my mind is also building emails that depend on some sort of query, it's not a rare petition that I get to "enrich" emails with related information and data that comes from queries, since the FormBuilder administrator emails' purpose is to help a sales teams make decisions. 

[Jonathan Lahijani]

Hi Ryan,

I'll do my best to explain this, but keep in mind my experience with queues / background jobs is only 2 years old.  But in short, inspiration would be best taken from the classic, "batteries included" big web application frameworks like Laravel (as Teppo pointed out) and Rails.  I like the Laravel page I linked because it gets very in-depth (I've read that page at least 10 times).

Let's use a classic example like this:  Let's say someone wants to upload a video to a field and we want it to be converted to a different file format (let's say that's being handled by ffmpeg).  That's a time intensive task that wouldn't be able to be done within a standard max limit 30 second web request, or even with the memory available to php via php-fpm.  It might take minutes or even hours, and even then, things can go wrong and it might fail.  So, instead we'd want this to happen independent of the web request, therefore a background job dedicated to that task would have to be made and scheduled to be processed.  It could happen immediately, or maybe it can be scheduled for 30 minutes later.  This is not related to cron jobs which are a different concept.

(Another example is for example in an ecommerce checkout; it's generally better practice to send the order notification email as a background job instead of inline with the code that processes the order after it's submitted).

With that, queue systems are typically powered by a different dedicated database or system, with Redis being a popular choice.  The reason for this is to limit load on the primary database; many large systems may have millions of jobs per day so offloading that to a separate database saves resources. However the big web application frameworks I mentioned also allow the option for the main database itself to store the jobs (Rails enabled this in Nov 2024), which is typically fast enough and probably good enough for a ProcessWire-based solution.

You then have workers which act on the jobs.  You can define there to be one or multiple workers.  Let's say you have a powerful server and want to transcode multiple videos at a time, then having multiple workers would allow more jobs to be done in parallel and take advantage of your system resources.  Obviously you don't want a worker to act on a job more than once, or two different workers to act on the same job.  So this gets into jobs have statuses, being locked, and avoiding race conditions.

The Laravel documentation gets into all of that, but I think reading up on queues/background jobs/workers and experimenting with it would be tremendously helpful.

In regards to my print-on-demand system, I'm not using a queue system as I described above and I did experiment with WireQueue and IftRunner a while ago, but it didn't really... fit?  It was a while ago and I was still wrapping my head around queues; also I came to realize that what I needed was even deeper than that (ie, durable workflows, but that's unrelated to what we're talking about here).  I eventually put something together that relies on "fake" jobs using cron jobs and progressing through a durable workflow; it's not the most efficient way to do it, but I got it working.  I've been meaning to rewrite that part of the system one day and having a native / first-party queue system (which dovetails with the CLI commands), would be the best approach.