All Activity

@gebeer Thanks! Sounds like Claudia would like a PR for the ddev update if available. For the skills stuff, thanks for explaining it all. I'll look forward to having a closer look in your commits but one thing noticed so far is that your version has the option to install the skill files off the PW install root in a .agents dir. But the only place PW an assume is writable is off the /site/assets/. So the .agents off the root would work in some installs and not in others. Thanks for the example rock migrations file. It looks to me like the same format that the core Pages Export/Import module uses, except that the module uses them JSON encoded. While we're calling the ones generated by Claude with the AgentTools module "migrations", they really are just repeatable logic. So the logic can be about creating/updating/deleting some pages/fields/templates or perhaps something else. How does the Rock Migrations format work when you need some logic as part of the migration, such as creating a page, then creating another page that references that page (FieldtypePage)? You could do this with the pages export/import but would have to run the JSON through more than once to do it. Also, how does it handle files? Handling files is something AgentTools does not yet do.

@maximus this looks awesome! Is the dashboard interactive? On your screenshot it doesn't look like it is. So for example when a user clicks on "Instagram" in the sources panel would it filter for that source or segment etc? Or is it intended as a basic dashboard and advanced insights would be via plausibles dashboard itself? eg like in the demo https://plausible.io/plausible.io

@maximus You're on fire 😄

@BitPoet Thank you for info 🙂 I updated video

Thanks @maximus Does it state in the docs that the project-summary.md should be updated at the end of each session via a prompt? Didn't RTFM 🙂

The video uses the HEVC codec (h.265). Firefox on Windows doesn't support h.265 due to licensing issues. A workaround is to download the video and open it with whatever video viewer is associated with mp4 files.

This song is a total banger:

Quick bump to 1.2.0: Fixed: Hardcoded Export Paths All /site/assets/context/ paths in prompt templates now use dynamic export_path Works correctly with custom paths like /home/user/context-exports/ Affects: project-context.md, create-template.md, create-api.md Prompts Description Clarity Changed wording to clarify these are templates for manual use "Prompt templates for manual LLM/agent use (not auto-loaded by agents)" Prevents AI agents from mistakenly treating them as project data Added: "Go to Module's Settings" Button Quick access button on dashboard next to "Re-Export" No more hunting through admin menus! Changed Project Summary Preservation project-summary.md no longer overwritten on re-export Preserves your session history and changes Only created on first export Thanks @szabesz and @psy for the excellent feedback!

Hi everyone, I've built a module that integrates Plausible Analytics directly into the admin — with a full dashboard, charts, and a per-page stats widget on the edit screen. GitHub: https://github.com/mxmsmnv/PlausibleAnalytics What it does: Dashboard under Setup → Analytics with summary cards (Visitors, Pageviews, Bounce Rate, Visit Duration) Traffic trends chart + Top Pages bar chart + Traffic Sources donut chart Tabbed breakdown: Geography, Devices, Browsers Per-page widget on the page-edit screen — shows last 30 days stats inline Period selector: Today / 7d / 30d / 6m / 12m API response caching via LazyCron (configurable interval) Self-hosted Plausible support via custom base URL Chart.js vendored locally — no external CDN dependency Role-based access via plausible-view permission Screenshot: Built on Stats API v2 (POST /api/v2/query). The module handles all v2 quirks internally — event vs session metrics split, correct date_range values, visit:entry_page filter for per-page session stats. Happy to answer questions. Bug reports and PRs welcome!

I have trouble following the instructions here. I have several virtual domains successfully installed on Apache Ubuntu, with index.php placeholder files. I want to install Processwire sites in each of them, each with their own config and database, and have all of them use the same /wire codebase in /domainone. /www/html/domainone/site (+ /wire) /www/html/domaintwo/site /www/html/domainthree/site etc. The 'how to install' instructions on the link talk about creating subdirectories off the web root, tmp directories, moving and renaming folders, having to come up with different names for the site folders, etc. It does not sound like what I am looking for. Is there a simpler way to get the structure described above? ChatGPT claimed I could just bootstrap the /wire folder into the other with one line and install normally, but that did not work of course.

One benefit of using an AI while writing/debugging new and old code is that you could, at this point, ask it to create and maintain as-it-goes a separate unit test repo or folder that any modifications can test against, update, and compare the potential efficiency impact on all ongoing changes. This could then be applied to either agent-based code updates, or check-ins of user-created modifications. Since you already have the bot running against and alongside the repo, it might be worthwhile to see if that's something that could be built alongside to reduce cross-module errors. Maybe. 🙂

AFAIK Incus is a community fork of LXD developed (partly) by same people. So not so new actually)

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

@gerritvanaaken @pideluxe Yes, it automatically takes over all mail sending. I've updated the module and added OAuth2 support, but I haven't tested Azure specifically. You can follow the instructions here: https://github.com/trk/WireMailPHPMailer#xoauth2-google-microsoft-yahoo-azure-support Please test it and let me know the results, or feel free to submit a PR if any fixes are needed!

Sorry about that @PWaddict - both versions should be fixed now.

@Ivan Gretsky I don't know why but video is there and I can see 🙂

Now when they're all pinged, we need to have something for them... Something to do or to write about... Maybe just say hello and share where they're at now...

I can't see the video. Is it just from where I'm at?

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.

With the 1.4.0 version, after I click the image icon on TinyMCE to upload the image and insert it to the body field and finally save the page I'm getting this Error: Class "DOMDocument" not found in C:\laragon\www\mysite\site\modules\ProcessCustomUploadNames\ProcessCustomUploadNames.module.php:308 The 2.0 version doesn't have any issues when I'm doing the above method for TinyMCE. On another page where I have 1 image field (single image), on every 2nd save the image is renamed with -1. So, first the image is saved "mysite-123" as I want it and then if I save the page again, the image renamed to "mysite-123-1", if I save the page again the image will get back to what I want "mysite-123" and if I hit save again it will become "mysite-123-1" and so on... Also, if I try to upload new image or delete the current one and hit save, the page gets unpublished. Note: These testings didn't happened on a clean PW installation. For now, I'm gonna stay with my forked version as at least for me there are 0 issues. I will get back to you probably next week with more testings but this time on a clean installation.

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

Just created a new test project and added the module. One thing I noticed immediately was that in my DDEV environment I needed to prefix the commands in order to run them in the actual container. // non-DDEV environment php index.php --at-eval 'echo wire()->pages->count() . " pages\n";' // DDEV environment ddev exec php index.php --at-eval 'echo wire()->pages->count() . " pages\n";'

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.

@Jonathan Lahijani just wondering if you got further with your Caddy file? Caddy looks really interesting to me but where you were at with your own config sounds like if I could take a look at your file it would save a lot of headaches working it out from scratch (lazy of me I know).