Jonathan Lahijani

CliModules The "native" way to do CLI with ProcessWire as of April 2026 Forum post Developer: @ryan processwire-console Based on Symfony CLI. Installed via composer local to project / in composer.json. Very deep functionality and the most developed; also includes Scheduling, Testing, Queues, Migrations, Seeding; released May 2026 Forum Post ; GitHub Developer: @ukyo RockShell Based on Symfony CLI. Installed via placing RockShell dir in root of PW; released 2022 Forum Post ; GitHub Developer: @bernhard WireCLI Based on Symfony CLI. Installed via composer globally; released 2023 Forum Post ; GitHub Developer: @flydev Wire-Shell Based on Symfony CLI. This project died a while ago. --- I suppose the reason I'm posting this is to start a discussion. Should there ultimately be "one true way"? If CliModules approach "wins", does the fact that it's dependency free (ie, not based on Symfony CLI, as ProcessWire is more of a unified system) pose any potential limitations? Note: I'm personally going to be using some combination of CliModules and processwire-console moving forward.

Some time ago, I decided to install xdebug on my development server, but I never really needed it or used it. TracyDebugger is enough for what I'm doing. I didn't notice it then because my app was not highly developed at the time, but it really causes speed issues especially if you're working on a sophisticated site with a lot of business logic. For a long time, I thought it was just ProcessWire itself being slow, my app being slow due to some optimizations I hadn't done yet, my database being very large, combined with my low spec dev server, but it turns out disabling xdebug, which I had long forgotten about, made things much faster. Just a heads up if you're having speed issues!

I didn't know that either! I too always assumed you have to click the "upgrade available" link, and if that link wasn't there, you could not upgrade. That seems like a UX issue to me.

How much RAM does your new M5 Mac have? Hopefully you got 96 or 128GB if you're looking to run local LLMs. A lot is happening in this space; see DwarfStar 4: https://github.com/antirez/ds4

I think today represents an important milestone in running a good model locally. See what Antirez (creator of Redis) has released. Tweet embedded below. Does anyone have an Apple M3 with 128gb RAM? I'd be interested to hear how it goes if you run it.

The PW Upgrade module.

One minor nitpick with this module is that if you're running the dev version of ProcessWire (lets say version 3.0.123) and that version receives additional commits/updates but without a version bump, you can't "upgrade" to it given how this module works. You can only upgrade when 3.0.124 dev version is available. Not a big deal for me since I have a bash script that takes care of pulling the latest from GitHub, however it would be nice to support getting the absolutely latest bleeding edge version with this module.

I use VSCode and have been a subscriber to GitHub Copilot for a few years. I didn't pay much attention to the plan I was on until I started using agentic coding in ~October 2025. I then realized what made GitHub Copilot a ridiculously good value, as others discovered as well, was that it works on a "per-request" billing model. In short, if you knew what you were doing (I didn't realize this fully at the time), you could use a high-end model like Opus 4.5, which costs 3 credits, and if just have it rip for HOURS on a task and it would only cost 3 requests (lower end models would be 1 request). With the cheapest plan on GitHub Copilot, it is (well, now WAS), $10/month which gave you 300 requests. A lot of people took advantage of this... imagine paying $10/month and getting like $5000/$10,000 worth of value (ie, what would be the real cost of per-token billing) out of it per month! Absolutely insane. Microsoft understandably put an end to that last week because they were losing their shirts: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ In short, they are one of the first to go per-token/per-usage billing and I suspect others like Anthropic and OpenAI will eventually follow suit. It's only a matter of time given the economics of it all. However as you may know, the Chinese AI labs are extremely competitive with their AI offerings and have both monthly plans and token-based plans (generally 90% less cost) and of course, they release the models outright. Because of what Microsoft did, I've been experimenting with the various Chinese models via OpenRouter (and still using VSCode GitHub Copilot "Bring Your Own Key" which they support), so it's basically the same experience. However there seems to be a lot of advancements in high density, low parameter models (Qwen3.6 27B, Deepseek V4 Flash) which can be run on consumer hardware at good speeds and output that is not far behind something like Sonnet or Opus, or at least catching up quickly. I haven't owned a discreet GPU in many many years (I don't game), but I believe with a RTX 5090 and 64-128GB of RAM, it can be done. Don't quote me on any that however... I haven't dived into this world yet and don't yet have an understanding of all the settings that determine how well an LLM runs and how it affects its intelligence. I'd be interested to hear anyone who is playing with this idea: What models are you using? What hardware? What software are you using to run it?

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.

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

Ahh ok. So 150 million of it is cached and therefore not charged. Makes more sense.

What was the cost for that many tokens?

I can't wait to play with all this stuff. I love that ProcessWire was envisioned over 2 decades ago, yet is adaptable with the cutting edge in web development. This just speaks to how well it was architected when it was publicly released. This feels like the next era of ProcessWire!

For my management execution system web application which was built with PW, 50+ templates and another 50+ repeater fields which are technically templates.

This song is a total banger: