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!

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

A lot of things changed in the world. I do not quite like many of them... But this what is happening here right now with ProcessWire is just amazing! Ryan finally found himself a companion to work with and they both are doing really well! I was kind of concerned about PW development, but not anymore.

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

CLI modules sound great, can't wait to play around with that! Two things I hope ProcessWire will eventually tackle natively (and also the things I currently think are kind of its weak points) are scheduled tasks and queues. For reference: https://laravel.com/docs/13.x/scheduling (or, pardon my french, https://developer.wordpress.org/plugins/cron/ and https://developer.wordpress.org/cli/commands/cron/) and https://laravel.com/docs/13.x/queues. I would assume that Jonathan was thinking of something similar, but I won't try to speak for him 🙂

Amazing stuff. And support for goose turd green !! 😀

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

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.

Hello! 👋 I'm thrilled to (re-)introduce WireWall — an advanced security firewall module for ProcessWire that I've been actively developing and refining in production for months. After blocking massive amounts of malicious traffic (99.98%+ on my e-commerce sites) with zero impact on real users, it's time for a refreshed community announcement with all the latest features from v1.3.4. What is WireWall? WireWall turns your ProcessWire site into a secure fortress with enterprise-grade tools: city-level geo-blocking, full IPv6/CIDR, multi-layer bot protection, true stealth mode, rate limiting fixes, and file-based caching that easily handles 1M+ IPs. Key Features (as of 1.3.4) Geographic Control City-level blocking (e.g. Philadelphia, Beijing, Sydney) Subdivision/region blocking (Pennsylvania, New South Wales, Île-de-France) Country blocking (blacklist/whitelist 200+ countries) MaxMind GeoLite2 integration (Country + ASN + City) — 0.5-2ms lookups HTTP fallback (ip-api.com) when MaxMind not available Full IPv6 + CIDR support Bot & Threat Protection Bad bots, scanners, vulnerability tools AI training bots (GPTBot, ClaudeBot, GrokBot, Perplexity, etc.) Fake/headless browser detection (Puppeteer, Selenium, etc.) VPN/Proxy/Tor detection (multi-API chain) Datacenter blocking (AWS, GCP, Azure, Hetzner, etc.) ASN blocking & whitelisting (block/allow entire networks) Security & Rate Limiting Configurable rate limiting with burst handling & permanent/temporary bans JavaScript challenge for suspicious traffic IP whitelist/blacklist with CIDR Priority system — now 16 levels (logged-in users at #3, trusted modules at #2) Stealth & UX True silent 404 mode — plain "Not Found" text (no HTML/branding) Beautiful custom block page with location/IP display Custom redirect or message on block Option to completely disable AJAX protection (fallback for tricky integrations) Performance & Management File-based cache — scales to millions of IPs, no DB overhead Cache UI with stats & per-type clear buttons Detailed logging (city/region/ASN included) Admin area always protected (triple-layer) Real-World Results On production sites (e-commerce + others), WireWall consistently: Blocks 99.98%+ of attacks/scrapers/VPN fraud Zero false positives for logged-in users & legitimate traffic (thanks to priority fixes) Handles spikes without issues after rate limiting improvements Eliminates most cloud-based automated probes Installation (Quick) cd site/modules/ git clone https://github.com/mxmsmnv/WireWall.git Then in admin: Modules → Refresh Install WireWall Configure (start with rate limiting + VPN detection + bad/AI bots) Monitor: Setup → Logs → wirewall Priority System (how requests are evaluated) Admin area → always ALLOW Trusted ProcessWire module AJAX → ALLOW Logged-in users → ALLOW (new in 1.3.4 — unconditional bypass) IP whitelist → ALLOW Allowed bots / IPs / ASNs → ALLOW Rate limiting → BLOCK if exceeded IP blacklist → BLOCK JS challenge → CHALLENGE VPN/Proxy/Tor → BLOCK Datacenter → BLOCK ASN blocking → BLOCK Global rules (bots/paths/UA/referer) → BLOCK Country blocking → BLOCK/ALLOW City blocking → BLOCK/ALLOW Subdivision blocking → BLOCK/ALLOW Country-specific rules → BLOCK First match wins. MaxMind Setup (strongly recommended) Free GeoLite2 databases → fast & offline. See README or https://wirewall.org for setup guide. Requirements ProcessWire 3.0.200+ PHP 8.1+ Resources GitHub: https://github.com/mxmsmnv/WireWall Releases & Changelog: https://github.com/mxmsmnv/WireWall/releases Landing: https://wirewall.org License: MIT (free for commercial use) Why build this? ProcessWire deserved a native, scalable, granular firewall with city-level control, offline capability, and proper exception handling — things missing or hard in other solutions. Happy to answer questions, hear about your security setups, or debug any issues! Feedback from the community has already shaped big improvements (like the recent logged-in & stealth fixes). Best regards, Maxim

Hey everyone! Pushed a big update to WireWall today. The main addition is a dashboard module — install ProcessWireWall alongside the main module and you get a live stats page at Admin → Setup → WireWall. It shows blocked/allowed counts, a 24-hour chart, top block reasons, top countries, top IPs, active bans with countdown timers, and a recent events table. Works in both light and dark admin themes since it reads PW CSS variables. Also rewrote the settings page from scratch — went from 15+ scattered fieldsets down to 10 logical sections. City and subdivision blocking options now only show up if you actually have GeoLite2-City.mmdb installed, which cleans things up a lot. A few security fixes in this release too: proxy headers like CF-Connecting-IP are now validated against Cloudflare's published IP ranges before being trusted (previously any client could spoof them), unserialize() in the cache layer got hardened, and some overly broad AJAX bypass patterns were tightened up. Silent 404 mode now throws ProcessWire's native 404 page instead of plain text. GitHub: https://github.com/mxmsmnv/WireWall

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

I have it in a Controller file in renderSomething() method called from render(). Function or throw - doesn't matter. I moved this code to init() and even to wireframe.php. The issue is the same. The server returns a 404 code but doesn't redirect and shows an error page. I have tried this on two other sites with Wireframe. And the behaviour is different there. If i put the code in wireframe.php there, it gives me a 500 error. But in controller it works ok and shows the 404 page. Those 2 sites are not multilingual and not so heavily modified... Can you suggest a way I can debug further? I have found the issue. The template of 404 page was changed to a template that caused an infinite loop. Sorry for bothering you @teppo. But natural intellect also needs prompts and you helped me with a one)

The structure you want is actually slightly different from what Option #1 describes, but it's achievable. Option #1 assumes all sites share the same web root — the multi-site switching happens via index.config.php in that single root. Your setup (separate vhost docroots) requires a different approach. The cleanest way to do this with separate docroots: In each domain's docroot (/domaintwo/, /domainthree/, etc.) you only need: A symlink (or include-based) index.php that bootstraps from domainone's /wire A site/ directory with its own config.php, templates, modules The trick is the index.php in each secondary domain. Replace it with something like: <?php // /domaintwo/index.php $rootPath = '/var/www/html/domainone'; chdir($rootPath); require($rootPath . '/index.php'); And in each domain's site/config.php make sure $config->paths->root isn't hardcoded — ProcessWire resolves this dynamically, so it usually just works. You also need to copy (not symlink) .htaccess from domainone to each secondary docroot, since Apache serves it per-vhost. No index.config.php needed since routing is handled by vhosts at the server level — each domain already hits its own docroot. So the final structure: /domainone/wire/ ← shared core /domainone/site/ ← site 1 /domainone/index.php ← original /domainone/.htaccess /domaintwo/site/ ← site 2 (own db, templates, modules) /domaintwo/index.php ← bootstraps from domainone /domaintwo/.htaccess ← copy from domainone Each site/config.php points to its own database. Works cleanly without symlinks to /wire (which can cause issues with __DIR__ resolution in some PW internals).

I wasn't realy planning to, we'll see! R

Small update on PW Native Analytics I made a few refinements to improve usability and setup: cleaned up and improved the module settings added short text descriptions to make technical options easier to understand improved the date format setting so it now offers cleaner and more useful format choices made important beginner-friendly options enabled by default on install, such as: Enable tracking Enable event tracking Respect Do Not Track Ignore query strings in stored paths This makes the module easier to understand and ready to use immediately after installation, especially for less technical users. thx to matjazp for feedback 😉 I updated the file in first post! Cheers

In your site config.php... Remove localhost from the array here $config->httpHosts But add yours like so... $config->httpHosts = array('domain.com', 'www.domain.com'); //Replace domain.com with the hostname(s) your site runs from. This is a new recommended security feature in PW2.4