Jonathan Lahijani

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!