Leaderboard

This week we have ProcessWire 3.0.259 which includes several improvements, but my favorite is the addition of a new module type called "CliModule" which is short for "Command Line Interface Module". CliModules are those that provide the option for running from the command line. To list the available actions from command line modules, you can type "php index.php" in ProcessWire's installation directory. If "php" is not in your path, you'll have to type "/path/to/php index.php" instead, or add it to your path. Here's example output on my installation: As you can see above, I've got AgentTools, WireTests and an example "Hello World" CliModule showing the available command line options. If I want to execute one of the commands, then I just type what it indicates. For example, here I will run `php index.php test FieldtypeText` and here's the output: Here's a simple example of a CliModule: <?php namespace ProcessWire; class HelloWorldCli extends WireData implements Module, CliModule { public static function getModuleInfo() { return [ 'title' => 'Hello World CLI module', 'description' => 'Just an example', 'version' => 1, 'cli' => 'hello', // Example: php index.php hello ]; } public function executeCli(array $args) { $command = $args[0] ?? ''; $name = isset($args[1]) ? $args[1] : 'friend'; if($command === 'hi') { echo "Hello there $name!"; } else if($command === 'bye') { echo "Goodbye $name, see you later!"; } else { echo "Specify 'hi' or 'bye' optionally followed by a name"; } } public function getCliCommands() { return [ 'hi' => 'Say hello', 'bye' => 'Say goodbye', ]; } } For more details on the CliModule format, see wire/core/CliModule.php Improvements have continued with the AgentTools module. This week we added: New multi-model support: You can now configure multiple different agents in the module, and choose which one you'd like to use from the Engineer screen. Details New agent-memory support: Now when you make a request of the Engineer, it remembers it for follow-up questions and changes. It keeps a conversation history for context of what you are working on. Details New support for subagents: This enables any of the agents to launch additional agents when/where it helps to do so. For instance, specialist agents, or lower cost agents for simple jobs, and who knows what else. Claude requested the feature and also implemented it, so I'll be interested to see how it gets used. Details New agents configuration screen where you can define up to 10 agents (that's plenty, right?). Details Also new this week is a new WireTests module testing suite for ProcessWire. This first version focuses on testing all of ProcessWire's Fieldtype modules (including a few ProFields ones as well), but it's easy to add tests for any kind of module type. So we'll be adding more tests and improving existing tests as this module moves forward. For details head on over to: WireTests Thanks for reading and have a great weekend!

Hi everyone, in particular @ryan @Peter Knight@ukyo @gebeer @maximus who seem to have been most AI active lately. I've just added dai() and bdai() dumping calls so that objects and arrays are rendered in plain text format more friendly to LLMs, but I am curious what AI/LLM integration features you think would be most useful? Claude suggested an MCP server - here is its plan. Does this sound useful? Any other ideas? Two processes, loosely coupled: ┌──────────────────┐ ┌──────────────────────────┐ │ Claude / Cursor │ stdio MCP │ TracyDebugger site │ │ client │ ─────────────────► │ │ │ │ HTTP + token │ tracy-ai/* endpoints │ └──────────────────┘ ◄───────────────── └──────────────────────────┘ MCP server — a tiny program the agent launches over stdio (the MCP transport). Ships as a sibling module (TracyDebuggerMCP/) or a standalone npm package the user npx's. TracyDebugger HTTP endpoints — new authenticated tracy-ai/* routes inside the ProcessWire site. The MCP server is just a thin translator between MCP tool calls and these HTTP requests. The MCP server holds no site logic. It's a dumb adapter. All the real work (reading panels, redacting secrets, rendering plaintext) stays inside TracyDebugger where the ProcessWire API is available. What the agent sees A handful of tools in the MCP catalog: tracy_export_bundle(preset: "debug" | "performance" | "template" | "full") tracy_get_request_info() tracy_get_last_errors(limit: int = 10) tracy_get_slow_queries(limit: int = 10) tracy_get_template_schema(template: string) tracy_list_dumps() tracy_run_console(code: string) ← gated, opt-in only Every tool returns the scrubbed plaintext/JSON produced by AIExport — same output Phase 2's "Copy" button produces. Config on the site New module-config section: aiExportHTTPEndpointEnabled (default off) aiExportMCPToken — a random token generated once per site, shown to the user to paste into their MCP client config aiExportAllowConsoleExec (default off) — gates tracy_run_console aiExportAllowedIPs — optional whitelist Config on the client User's ~/.config/claude/mcp.json or equivalent: json { "mcpServers": { "tracy": { "command": "npx", "args": ["-y", "tracy-mcp"], "env": { "TRACY_URL": "https://mysite.test", "TRACY_TOKEN": "<paste token from module config>" } } } } The agent launches the MCP server locally; the MCP server talks to the site over HTTPS with the token. Auth Per-site token (generated in module config, rotateable). Token sent as Authorization: Bearer … header on every HTTP call. Optional IP whitelist on the site side. tracy_run_console additionally requires aiExportAllowConsoleExec=true — otherwise the MCP server gets a 403 and reports "console execution disabled for this site" to the agent. Example flow — agent debugging an error User in Claude: "Why is /about/team throwing a 500?" Agent: Calls tracy_export_bundle(preset: "debug"). MCP server hits GET https://mysite.test/tracy-ai/export?bundle=debug with the bearer token. Site responds with scrubbed JSON: request info, PW info, last error with stack, slow queries, recent PW logs. Agent reads the traceback, sees TemplateFile.php:123 Undefined index "featured_image", asks tracy_get_template_schema(template: "team"). Site responds with the template's fields — no featured_image field exists. Agent suggests the fix, possibly calls tracy_run_console (if enabled) to verify. No human pasting. Agent pulls what it needs on demand, scoped by the tool it calls. What ships where In TracyDebugger itself: the tracy-ai/* HTTP endpoints + auth + token config + AIExport (already built in Phase 1, extended in Phase 2). In the MCP server (separate repo, ~200 lines): tool definitions, HTTP calls, response shaping for MCP. This separation matters because the MCP server can be installed independently of the site, and the site is still useful without it (you can hit tracy-ai/export with curl directly). Footprint on production Zero unless you explicitly enable it. The endpoints, token, and MCP config are all opt-in behind module settings. That's the shape. The main design choices worth confirming before building: Token-only auth, or also require the existing Tracy access? — i.e., should the agent's token have to belong to an allowed Tracy dev user, or is a separate machine token fine? I'd lean separate machine token for agents; reusing session auth is awkward over stdio. Read-only by default? — I strongly recommend yes. tracy_run_console is the only write path and should be a separate opt-in. Does the MCP server live in this repo or a separate repo? — I'd say separate. Different language, different release cadence, and the site works without it.

Hi everyone, I’m happy to share NativeAnalytics, a native first-party analytics module for ProcessWire. The module is now available in the ProcessWire modules directory: https://processwire.com/modules/native-analytics/ NativeAnalytics provides a useful analytics dashboard directly inside the ProcessWire admin, without relying on external analytics platforms, third-party scripts or external APIs. All analytics data is stored locally in your ProcessWire installation, which makes it a good fit for projects where you want a simpler, more self-contained analytics solution. The module currently tracks and displays: page views unique visitors sessions current visitors top pages referrers devices and browsers 404 hits engagement events such as form submits, downloads, tel/mail clicks, outbound clicks and custom CTA events It also includes: charts and trend views comparison between periods custom date range filtering page-level analytics inside the page edit screen optional monthly email reports optional PDF report attachments exports to CSV, PDF and DOCX helper examples and a small snippet generator for custom event tracking There are also several privacy and consent-related options: optional cookie-less visitor/session mode consent-based tracking helper functions for custom consent integrations optional PrivacyWire localStorage consent helper support cleaner behaviour when global tracking is disabled The reason I built this module was that I wanted something that feels natural inside ProcessWire itself, instead of embedding another analytics service into the admin. For many sites, it can be useful to have core traffic and engagement data available right where content is managed. ! If you tested one of the earlier development versions named PW Native Analytics, I recommend uninstalling that old test version first and installing NativeAnalytics as a fresh module, because the module name and structure changed during development. Multi-site analytics is not included yet, but it is something I am looking into. It would need proper per-site separation in the stored analytics data, so I want to approach that carefully rather than adding a quick workaround. Feedback, bug reports and suggestions are very welcome. Get it here: https://processwire.com/modules/native-analytics/ Enjoy!

Check out what @Jonathan Lahijani sent me in the mail. This is so cool!

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

Hey everyone. I have a new Module in the works. It's 99.9% 75% ready for general release, but already running on my own sites for weeks. [Edit: see post about bug re. 3rd party module] If you've ever opened /site/templates/ on a project that's been running for a year, you know the feeling. 20-50 PHP with no structure, no grouping - an alphabetical avalanche. I usually get so far by namespacing all my files, but sometimes I wish for more organisation. Stemplates lets you organise your templates into folders. That's real directories on the filesystem - the way you're used to working. So, instead of leaving everything in a flat directory, you can go from this… site/templates/ ├── account-dashboard.php ├── account-billing.php ├── shipping-methods.php ├── shipping-tracking.php ├── blog-index.php ├── blog-post.php └── blog-category.php to this… site/templates/ ├── account/ │ ├── dashboard.php │ └── billing.php ├── shipping/ │ ├── methods.php │ ├── tracking.php └── blog/ ├── index.php ├── post.php └── category.php I've been running it on my own sites without issues for a while, and it takes just minutes to set up, even on a large site. Setup takes even less time if you're using AI/MCP. Even better, Stemplates is: ✅ completely non-destructive ✅ doesn't touch your database ✅ doesn't modify your templates or fields ✅ doesn't change anything in the admin UI ✅ doesn't alter your workflow ✅ free from manual aliases, no mapping files, no rewrite rules to maintain ✅ doesn't touch system templates (admin, repeaters, etc.) It also works with page classes and supports nested subfolders (50 levels tested). Understandably, I was reluctant to mess around with such a fundamental part of my sites, so a few safeguards exist... Migrate one template at a time at your own pace - no big switchover required Your existing flat templates keep working untouched, alongside any you've already moved If a file can't be found in its subfolder, ProcessWire falls back to its normal flat-folder behaviour automatically - the site doesn't break Uninstall cleanly at any time. Stemplates Free is undergoing a slight rework available now DM me for access. Stemplates Pro (coming soon) takes Stemplates even further. More soon, but honestly, Stemplates (Free) will take care of 99% of your new template -> folders world. Thanks for reading! Peter

The imminent dangers of "vibe coding", developer shouldn't "vibe", they should control imho.

Sooo, I'm still alive and in August, I will start on a new job and project that probably brings me back to work with the cool and great Processwire. :D 7 years ago I was forced to change job and ended in a cool new place doing front-end dev not using PW anymore. So unfortunately I didn't really use or follow PW in that time except once a year doing something tiny bits on the handful of websites I am responsible for. I'm sorry if I just disappeared "over night" and maybe left some things behind I was doing for PW, and didn't spend time looking out for them. The reason is, I also was very frustrated with a lot of things with the job and life at that time and 2019 was also when I started painting again digitally, as maybe some of you know. I went full hyper focus mode, everyday almost for 2-3 years in my spare time and since then slowed down. I was able to make a small career with it, and made a lot of new connections and experiences which was awesome. I will continue to work on making art and illustrations as I have a lot of new freedom with the new job too combine a lot of my skills. Finally I can work from home full time. A little dream come true. Thanks for still being here and keeping this small but awesome community alive! I have to catch up now! :D Cheers Soma