Jonathan Lahijani

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:

@Ivan Gretsky Yes, still using Apache on the LXCs. I've never heard of Incus, but thanks for mentioning it. Seems it started in 2023 so in the early stages. For now, I'm going full force on Proxmox (I spent a lot of time in December and January experimenting with it), but will keep a close eye on it. Users on this post on HN say some nice things about Incus so that's a good sign.

This is a bit off-topic (however related to Caddy), but I have been re-doing my internal development setup, which is now powered by a dedicated Proxmox server (on a Minisforum MS-01) and uses LXC containers for ProcessWire sites. On some containers, I just have one ProcessWire site, and on others, I have multiple. Previously, I just had one bare-metal, dedicated server with all my sites on it, which is very convenient but I lose having parity with my production environments (which isn't a big deal with a typical website, but more-so for mission critical webapps; also I am trying to avoid using Docker). So my internal infrastructure might look like this: lxc1 site1.domain.com site2.domain.com site3.domain.com lxc2 site4.domain.com Since I want some of my development sites to be accessible from the outside on a dedicated subdomain like shown above, this requires the need of a reverse proxy since my internet connection has only 1 IP address. Therefore, I set up another LXC which runs Caddy as a reverse proxy (also set up fail2ban to deal with stupid hackbots) which works so well and it's ridiculously easy to set up and takes care of SSL automatically. I did this just a couple days ago, after not having played with Caddy for a couple years, so maybe this bit of excitement will get me back into using it directly as well.

@Pete I did get far with it, but I never ended up running a site with Caddy so it hasn't been battle tested. I've messaged it to you directly as I don't want to post something incomplete for the public until I've really done my due diligence on it.

From my experience, even asking an LLM (like ChatGPT in their website chat interface) about ProcessWire's architecture is pretty impressive. I spent a lot of time last year using AI to compare (verbally compare, not direct code) ProcessWire to full-stack web application frameworks like Laravel and the language it used to describe ProcessWire, with API variables like $pages, $fields, etc as "services-like objects" was something I've never seen described anywhere (pw docs or forums), but it's technically correct, and a lot of things clicked with me after that. These coding agents do really well with ProcessWire without any special harnesses already. I'm excited for all these upcoming features.

So ProcessWire now has the beginnings of a first-party "schema" (in the ProcessWire sense) migrations system? YES!!!

There may be a time where you need to create a page reference field using the Select inputfield and it's selecting repeater pages. Let's say I have a repeater field called "order_line_items" and I want to create a page reference field called "order_line_item" that allows me to select a repeater item (which is a page) of the "order_line_items" repeater field. Repeater pages are a bit different from regular pages in that their "parent" is a container admin page associated with the page in which it exists (dig into /admin/repeaters/order_line_items/ in your page tree to see what I mean). So when you are configuring your page reference field, you can't really choose a Parent. However when configuring your field, your instinct would be to choose the Template of "repeater_order_line_items". Then because you need extra precision in what pages are actually available for selection (rather than all of them across all pages), your instinct will be to implement custom PHP code: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if($event->object->hasField == 'order_line_item') { $event->return = $event->pages->find('your selector here'); } }); The problem with that approach is that even though you have defined the custom PHP code and the select field correctly shows the selectable repeater pages in the select field, behind-the-scenes, ProcessWire has still loaded EVERY SINGLE REPEATER that has the "repeater_order_line_items" template (you can see this is TracyDebugger's pages loaded list)! Your site will definitely be slower as a result, dramatically so if you have thousands or tens of thousands of repeater pages of that template. I hit this issue years ago (2018) and I thought it was a bug. I discussed it with Ryan and it's technically not a bug, but kind of the way ProcessWire works, which is beyond this tutorial. While you can circumvent this using the PageAutocomplete field, I don't like the ergonomics of that field in certain situations. I want the good-old select field. The solution to this is to NOT select anything for the "Template" when configuring your field. So in my example, I chose "repeater_order_line_items", but instead, it should be left blank. Now the field will just rely on the code portion and all the unnecessary page loads will be eliminated.

I saw it on HN last week and it caught my eye as well: https://news.ycombinator.com/item?id=47285876 I will be playing around with it at some point as I love the hypermedia approach of doing things (big HTMX fan). I like that it can do what they call "patch modes" (what other libraries call "islands"?). HTMX can do that too, but it's feels off with the "OOB" approach. That has always bothered me, but I think they are addressing that in HTMX v4. I've played with Alpine-Ajax and Datastar as well, but muJS seems like it best aligns with the way I think.

I spent a few hours this morning making an MCP module for ProcessWire similar to Laravel Boost. I'm going to call it Octopus. In just 2-3 hours with Opus 4.5, I'm already what feels like being done with 90% of it. I'm going to finish the remaining 90% (heh) as I work on various projects to actually test it. I will have to figure out the best way on how to provide ProcessWire documentation to the MCP (hence why I'm on this thread), but even without it, Opus 4.5 is insanely good in following ProcessWire conventions, even with little context! The hype is real. Let me know if you have any questions or suggestions. Screenshot attached.

@BrendonKoz The problem with that option in the screenshot is that while it ungroups the taskbar items, it keeps the "text" part of it, which I don't want because it's not necessary for me and I like to have a lot of windows open so I want to conserve horizontal space. Windows 10 used to have that option, but they removed it in Windows 11. That's why you have to use this Windhawk mod I mentioned in the readme: https://windhawk.net/mods/taskbar-grouping A registry setting alone won't fix it unfortunately. Come on Microsoft!

While my plan is to switch to Linux one day (probably Omarchy), I'm still putting that (and tiling window managers) off for a bit. Let it cook a little more. In Windows 11, I like my taskbar, but one nagging thing is that it's hard to differentiate the icons of many Code/Codium instances given that I don't group them. I use both programs actually: Code for actual coding and Codium as my Markdown note taking tool (I prefer to not use Obsidian and the million other markdown editors; Code/Codium for Markdown is fantastic since you get all the developer ergonomics) With the help of AI, I developed a program with dotnet that makes it easy to add custom icon overlays effectively differentiating the program instances. This saves a lot of headache of knowing which icon corresponds to which project with a quick glance. Feel free to use it! https://github.com/jlahijani/TaskbarIconOverlay

Totally valid. However to address this they added an option in 3.2.0 so that when updating, you don't get bleeding edge packages, but instead it's lagged by 1 month: https://github.com/basecamp/omarchy/releases/tag/v3.2.0 So that's comforting. Similarly, I use ProcessWire bleeding edge / dev branch, but if there have been changes in a particular week that I sense as more in-depth, especially those that touch selectors and database stuff, I usually wait another week or two to avoid potential subtle issues that are difficult to catch. I'd imagine I would use the same judgement with Omarchy.

I've settled on Omarchy! I spent a couple days getting used to Hyprland and tweaking it to my needs. It's a bit of a mind shift not having a taskbar/dock anymore, but I made it nice and easy to switch workspaces very quickly and do some basic window manipulations. It's nice having a Windows VM set up as well (I need Photoshop for work since I work with printing companies; CMYK support is a must). It's time to say goodbye to Windows!