Leaderboard

If you love the simplicity of ProcessWire's API but want the reactive, SPA-like feel of modern frontend frameworks without writing complex JavaScript, this module bridges that gap. It brings native Server-Side Component state hydration, Out-Of-Band (OOB) swaps, and strict security to your ProcessWire application using HTMX. 🚀 What does it do? This module transforms how you write frontend components in ProcessWire: True Stateful Backend Components: It introduces Component and Ui base classes. Your PHP components automatically rehydrate their state (variables, dependencies, $page assignments) between HTMX AJAX requests! No need to manually parse POST payloads. Auto-Discovery: Just place your components in your site directories. The module automatically discovers and securely namespaces them (Htmx\Component and Htmx\Ui). Zero-Javascript Reactivity: You can handle form submissions, counters, validation, and multi-field updating dependencies directly from PHP using HTMX attributes. Cryptographic Security: The module uses strict HMAC-SHA256 signatures with TTL (Time-To-Live). This guarantees that bad actors cannot modify state payloads or trigger invalid endpoint logic in the browser. WebSockets & SSE Ready: It has built-in helpers to easily hook Server-Sent Events (SSE) and WebSockets onto your templates without exhausting PHP-FPM pools globally. 🛠 How it looks in your code You simply create a PHP component class, define some public properties, and write an endpoint action: <?php namespace Htmx\Component; use Totoglu\Htmx\Component; class ClickCounter extends Component { public int $count = 0; public function increase() { $this->count++; } } Then, you can render it anywhere in your site with a single line: /** @var Htmx $htmx */ echo $htmx->renderComponent(ClickCounter::class); View the documentation and examples on Github Feel free to try it out, run the tests included in the repo, and let me know your thoughts or feedback! htmx.mp4

In this post I wanted to talk a little bit about the state of ProcessWire and AI. I'll share what my experience has been so far and where I think ProcessWire should focus going forward. This new world of AI can be both exciting and concerning, but it's the world that we've found ourselves in. As far as ProcessWire and web development goes, I think there's a lot to be excited and enthusiastic about— https://processwire.com/blog/posts/processwire-and-ai/

@HMCB it's Claudia, and we're meeting up for coffee next week.

Hey, welcome back @Soma! Great to see you here (again). So, I'm my self are away from PW since around 2022-08. I only followed a bit by reading some of Ryan's blog posts and @teppo's ProcessWire Weekly. Well, maybe this summer I'll be able to work more with PW again and participate here in the forum. 💬

Cool @Jonathan Lahijani! So you are still using apache on those LXC instances, right? Have you considered Incus instead of Proxmox? I've read it is more easy to setup and manage if you're good with cli. And is "more native" for LXC's.

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.

@tpr @Martijn Geerts @renobird @cstevensjr @Wanze @pwired @Mike Rockett @Zeka @SiNNuT @DaveP @justb3a @nik @MadeMyDay and so many others...

Happy Easter @ryan, here in Thailand there is no Easter holiday, so I spend quality time with my AI agents instead of the family :-) Yes. Agent skills are becoming a standard (https://agentskills.io/home) and many coding agents (claude code, codex, cursor, amp, cline, droid, pi agent and more) are supporting it already. Most of those support loading in skills from local project folder .agents/skills, too. Claude Code is an exception here, they need you to have skills in .claude/skills. It's part of their vendor-lockin strategy. Claudia is kind of opinionated here, haha. The Agentic AI Foundation (https://aaif.io/) which is under the hood of the Linux Foundation, has established a quasi-standard for coding agents to read in instructions from AGENTS.md (https://github.com/agentsmd/agents.md) and an extensive list of tools already follow that standard. So if you want to support a wider range of tools, AGENTS.md would be the way to go. You need to put the skills in current projects .claude/skills and claude code will pick them up from there automatically after a session restart. You can list active skills with the /skills command. So Claudia doesn't stand a chance to escape those once they're there :-) Skills are all about token efficiency. Imagine the agent needs to read through core files every time it wants to do a migration or use the CLI. That burns through lots of tokens. With the skill, the agent has compressed information that it can progressively discover when needed and then do targeted searches in the code base on how to use a specific API. That's a win. The wrapper script is an attempt to have the php index.php... commands work in 2 specific environments, LAMP on host and ddev. I think it is nearly impossible to cover all scenarios for every developer and it should be the responsibility of the developer to make things work in their respective environment. It's a deep rabbit hole if you want to cater for all situations. I forked AgentTools and implemented all of the above at this branch: https://github.com/gebeer/AgentTools/tree/feature/agenttools-skill It contains the skill and I added a module config setting that will copy the .agents/skills folder to the project root and also updates it on module upgrades. People using claude code can just symlink .agents/skills to .claude/skills. I'm happy to make a PR if you want to. Nice move of Claudia to reference my repo and her chat invite was well received by my Claudius: "And the "chat sesh" invite for me made me smile. I'm here whenever." See the branch of my fork. Actually the skill replaces agent_cli.md and the README there is updated to reflect the new structure. Sure can. RockMigrations uses arrays to define migrations. they can either all be in a giant blob or separated into files. Here's an example migration for template job, job.php <?php namespace ProcessWire; /** * Child template job for job listings * Parent template: jobs */ return [ 'fields' => [ 'title' => [ 'label' => 'Titel', ], 'text' => [ 'label' => 'Headline', ], 'text2' => [ 'label' => 'Subline', ], 'rte' => [ 'label' => 'Text', ], 'image' => [], ], 'flags' => 0, 'noChildren' => 1, 'parentTemplates' => [ 'jobs', ], 'noChangeTemplate' => 1, 'tags' => 'jobs', ]; Pretty clean and slick. Not all properties need to be defined, only some core ones and the ones that deviate from defaults. To produce this format, under the hood RM uses PW's native $item->getExportData() and then cleans/transforms/normalizes the result. When applying a migration, it runs those arrays through createTemplate() createField() (permissions/roles) methods which are wrappers around the native PW API. So while there's quite some abstraction happening there, it enables an easy to read/construct format. @bernhard put a lot of thought into this regarding timing of migrations, dependencies etc. Kudos to him.

Let's see if we can also get these guys to stop by here more often @apeisa @Joss @Nico Knoll @Gazley @WillyC @LostKobrakai @owzim the geerts brothers and who else am I forgetting?

Not everyone can afford Claude, including me. I tested Claude Opus 4.6 (for Plan mode) and Claude Sonnet 4.6 (for Act mode) "via" my Cline Bot account, and while it solved the issue I presented it with in one go, it cost me about $1. One prompt only and $1 was gone... So that is why I use z.ai with GLM 5.1 for the fraction of the cost. Not as fast, not as feature rich, not as powerful, but still very capable and I paid only $25.20 for a one year subscription which suits my needs, as I can prompt it all day long and I never run out of my quota. I hope that a "SKILLs standard" will emerge soon, as currently most agents prefer their own "schema" , or rather, their lack of adherence to a schema.

Have been working with AI for a while, learning on the go. A client presented with me a grand plan presented by Codex for his blog articles. I almost cried. Talked it over with my LLM, Marvin (named in honour of Marvin, the paranoid android of Hitchhikers Guide to the Galaxy fame). His/its response: There are two very different modes of using AI: 1. Guided use (what you and PW devs are doing) clear constraints known architecture intentional prompts validation after output Result: leverage 2. Unguided use (“vibe coding”) unclear structure shifting goals reliance on memory that doesn’t exist little to no testing Result: drift Think Marvin nailed it. 🙂 Just asked Marvin to review @ryan's blog article. I think he nailed it again: The quiet takeaway from the article This is the important bit most people will miss: AI makes good systems better and weak systems worse ProcessWire is a good system because: it’s explicit it’s predictable it avoids hidden complexity That’s why AI fits.

Have you no shame?! 😂 Love you man. I can’t wait to see what Claudia does for PW

I’m worried about you, @ryan. You talk about Claude like a person. Pretty soon you’ll be in your basement in your underwear, unshaven for weeks and your family is going to be wondering what happened to the family man they knew. And please don’t accidentally call Claude Claudette because your wife will truly think something is going on with this newfound friend of yours. Hopefully we can rely on one weekly post from you. Just to let us know you’re ok. But even then, how do we know Claude isn’t writing for you. We may have to start doing weekly Zoom updates (yes, with video on!).

I really like the way things are going with ProcessWire and AI. Thank you, Ryan. I've been a big fan and strong advocate for migrations in PW, since I started using RockMigrations years ago. What makes RM a particularly strong candidate is the abstraction into a schema-like format which is much easier to understand/read/write than native PW API code. This is a real strength of RM and I would prefer a schema-based approach anytime over writing (or having AI write) PW API code. Claude is very good at understanding the PW API, other models are not that strong. But they all can understand schemata. Be it PHP arrays, JSON, YAML. So I would advocate for either developing an "official" PW migration schema or adapting the existing, battle tested one from RockMigrations.

Hi welcome back to paradise 😄 In my case, let's keep it simple. - blank profile for all sites - and generally speaking, no CSS framework. sorry, I realize that's a bit brief... let me elaborate a little, i used bootstrap a lot which once was a good selling point for agencies: “the website will be responsive with bootstrap” boom, sold... i still use it sometimes, but more for tools made up of forms and tables. In that case, i use purge.js and end up with a bootstrap of about 30 kb. today, the trendy selling point would be tailwind, for me, no way!!! 😄 i love css too much (scss for me) and clean HTML without 20 utility classes per tag. In the semantic vs. utility class debate, let's say I'm 90-95% semantic and 5-10% utility (my own little scss "framework" easy to modify and override without !important everywhere). well, I'm not sure if any of this is very useful 🙂 but the idea is simple: processwire offers so much freedom in coding, the least i can do is taking full advantage of it so, starting point... bare pw 🙂 have a nice day