Leaderboard

This week in the core, dev branch updates were largely focused on API documentation, with several minor core bug fixes (via WireTests) resolved during the at the same time. We also have new versions of the AgentTools and WireTests modules released this week as well. Core New: API.md documentation files (for agents and us): $classLoader / WireClassLoader — covers namespace registration, class maps, prefix/suffix path fallbacks, and findClassFile() for debugging (view) $datetime / WireDateTime — covers all public methods including date formatting, string-to-timestamp conversion, and relative/elapsed time output, with live-tested examples (view) $log / WireLog — covers save(), message(), warning(), error(), reading with getEntries()/getLines(), pruning, deleting, and built-in log names (view) $notices / Notices — covers adding notices, Notice flags (including string names), iterating, filtering with viewable(), hasErrors(), hasWarnings(), rendering, and Notice properties (view) $fields / Fields and Field — covers getting, creating, saving, cloning, tagging, flag constants, and field methods; (view) $fieldgroups / Fieldgroups and Fieldgroup — covers field membership, template relationships, and field context (view) $templates / Templates, Template, and TemplateFile — three separate API.md files covering the templates manager, the Template object in full, and the TemplateFile rendering class (View: Templates, Template, and TemplateFile). AgentTools module In AgentTools admin, you'll find a new "Tasks" feature. This lets you create your own custom tasks, which are essentially saved prompts that you can reuse and configure. The system also comes with several built-in tasks, including: WCAG accessibility review: Review templates and representative content for common accessibility issues. Recent log review: Scan ProcessWire logs for recent errors, suspicious activity, and operational issues. Migration review: Review pending AgentTools migrations before they are applied. SEO and content hygiene review: Review site structure and representative content for SEO/content quality issues. Template file security scan: Scan template files for common security risks in output, selectors, and request handling. A shared animated processing overlay UI was also added, used by both AgentTools and Page Engineer. (Try it!). Probably only of interest to agents, but more tools were made available via the CLI, which helps out with Engineer requests, as well as AI agents that you may have available on your localhost dev environment. WireTests module New comprehensive tests added to WireTests for the following API variables: WireClassLoader ($classLoader) User and Users ($user and $users) Role and Roles ($roles) Permission and Permissions ($permissions) WireDateTime ($datetime) See the full list of included tests (so far) Thanks for reading and have a great weekend!

Hi, A small but practical module for anyone working with ProFields Repeater Matrix on the frontend. GitHub: https://github.com/mxmsmnv/InputfieldMatrixType The problem Repeater Matrix is great for building flexible content blocks — but when you need to identify item types programmatically, things get messy fast. Types are stored in internal template names like repeater_matrix_123, there's no clean way to get a human-readable type identifier, and extracting structured data from different item types means repetitive code in every template. I ran into this building a gift catalog on e-commerce project — a matrix field with three item types: Box, Handbag, and Bouquet. Each has different fields and pricing. I needed clean type identifiers for frontend rendering and a JSON API for Alpine.js components. What it does FieldtypeMatrixType — a dedicated field for storing type identifiers per matrix item (e.g. box, handbag, bouquet) InputfieldMatrixType — admin UI to configure identifier and display name per type MatrixDataProcessor — PHP class that extracts all matrix item data into a consistent structured array, JSON-ready $processor = new MatrixDataProcessor($page); $items = $processor->getItems('opt'); echo json_encode($items); Each item returns id, type, displayName, price, and a fields array with name/label/type/value — ready for Alpine.js, Vue, or any API endpoint. Supports Text, Textarea, Options, Checkbox, Integer, Float, Page references, and Image fields out of the box. Custom field types via formatValue() override. Requirements: ProcessWire 3.0+, PHP 8.1+, ProFields Repeater Matrix MIT License.

Hey everyone! Our frontend developer saw GitSync and said "this is lovely for module repos — but what I actually want is the whole /site/ on a branch. Push, switch, done." Reasonable. We said "yeah, we'll get to that." That was a while ago. SiteSync is what we eventually built. What it does: SiteSync deploys a ProcessWire installation's /site/ from a configured GitHub repository — one repo active at a time, but repoint it whenever you like, we're not the boss of you. Every template, stylesheet, RockMigrations config file, content seed lives on a branch. The admin lists every branch in the repo, you click Switch, /site/ is atomically replaced with that branch's tree, RockMigrations applies schema changes on the refresh hook, content seeds run. Click another branch, switch back. Click Rollback on yesterday's deploy, you're on yesterday's deploy. No git binary on the server, no CI runner, no SSH keys — everything goes over the GitHub REST API from PHP. What's new here: Coding-agent fluent. An AI coding agent (Claude Code, Cursor, OpenAI Codex, …) reads a shipped AGENTS.mdfrom your ProcessWire root — which SiteSync auto-scaffolds on install — edits files on a feature branch, opens a draft PR, and the SiteSync admin shows you updates available. We bootstrapped a complete blog — schema, templates, styling, three seed articles — from an iPhone with the Claude app. No laptop in the loop. Real staging via two installs. One SiteSync per environment, both pointed at the same repo, different active branches. Feature → PR onto staging → staging auto-deploys → browse staging.example.com like an actual human → second PR onto live-stable → live deploys. Schema changes hit the staging DB first, not directly into live. The grown-up workflow you usually pay a SaaS for. The technical guts: Versioned everything. Each deploy is <branch> + <SHA> + <commit title> in the Recent deploys table. One-click Rollback to any prior row — the rollback is itself just a regular deploy of that exact tree, same atomic two-pass write, same snapshot, same tracked-sync. Tracked sync, not strict mirror. A new file in your branch shows up on the server. A file your branch never knew about (a third-party module's helper, a hand-edited template, last night's debug log) stays where it is. SiteSync only deletes what SiteSync itself wrote — verified by per-file blob SHA in managed-files.json. Atomic two-pass write. Pass 1 downloads every blob to <final>.sitesync-tmp next to its target. Any failure cleans up all tmp files; /site/ is never half-mutated. Pass 2 POSIX-renames each tmp → final. Pre-deploy snapshots as tar.gz, configurable retention, one-click restore. Your /site/ before SiteSync touches it. If you've ever pasted find . -delete into the wrong shell, this is your safety net. Webhook with hold-back. A direct edit on the server (3am emergency typo fix) is detected; the next webhook push to that same path is held back with HTTP 409 + a clear admin banner instead of silently overwriting your hotfix. The push waits patiently for you to commit and push the local change. Fits your stack: RockMigrations marriage. Fields, templates, roles, permissions as config files under site/RockMigrations/. SiteSync deploys the files and calls $modules->refresh() — RockMigrations hooks the refresh and applies your schema changes. No custom post-deploy step, no extra wiring. Schema-as-code that actually deploys. Editorial seeds under site/content/ for the "first article" / "bootstrap pages" problem — every .php file in there runs on every deploy. The bundled AGENTS.md documents the conventions for keeping seeds safe: idempotency guards (so a re-deploy doesn't duplicate content), and versioned filenames like 99-patch-rename-foo-v1.php for the rare "we need to rename this on every install" case. Conventions, not magic — your seeds are plain PHP doing whatever you want. What it doesn't try to do: replace your CI, sync site/assets/ (uploads stay where the editor uploaded them), or pretend to be a fleet deployer. One site, one active repo, one Switch at a time. The simplicity is the point. Beta status: in active use on real ProcessWire sites. The atomic-deploy + tracked-sync + hold-back + snapshot machinery is stable. The agent-templates and staging walkthrough landed in the most recent sprint and would benefit from more real-world miles. Bugs, edge cases, and "wait, that's a weird hosting setup" reports very welcome. Boring details: License: MIT. Requires: ProcessWire 3.0+, PHP 8.0+ with curl and phar extensions. GitHub token: fine-grained PAT, Contents: read only — read-only. SiteSync literally cannot modify your repo. If the server is ever compromised, the token can pull source code but not push anything back. Get it: Repository: https://github.com/frameless-at/SiteSync Install: drop into /site/modules/SiteSync/, Modules → Refresh → Install README has the whole tour: config, webhooks, path filters, staging walkthrough, agent workflow. Companion to (but not dependent on) GitSync — install both side by side if you want module-level granularity and whole-/site/ branch deploys. SiteSync can even reuse GitSync's GitHub token, because typing the same PAT twice is a crime. One last flex: For a proof of concept we just used SiteSync in combination with Claude to migrate a 20-year-old blog — articles, comments, gallery images, the lot — out of its previous CMS into a fresh ProcessWire install. We just installed the module, pushed /site/ to a Repo and connected the agent to it. We fed it with a JSON Dump of the Blog-Data and said what we wanted: Schema as files on a branch, content as idempotent seeds, snapshots between attempts because of course the image migration didn't work on the first run (or the second, or the third). New /site/ deployed clean, two decades of writing intact, old URLs preserved. Tataaaa. Curious to hear how it lands in your setup. Cheer, Mike

Hi everyone, I've been running this module in production a spirits catalog with 12,000+ products — for several months. Today I'm releasing it publicly. GitHub: https://github.com/mxmsmnv/Collections The problem ProcessWire's page tree is brilliant for site structure. It's painful for data management. When you have thousands of pages as records — products, listings, vacancies, menu items — you hit the same walls on every project: no table view, no inline filters, no bulk actions, no export, no REST API, no role scoping per dataset. Every PW developer has solved some version of this. Collections solves it once. Screenshots What it does Gives any ProcessWire template a configurable admin table — live search, dropdown filters, inline status toggles, bulk actions, CSV/JSON export, and a REST API — all configured through a UI, without writing code. Admin UI: Configurable columns per collection with custom labels Live search with 300ms debounce across multiple fields including Page references Dropdown filters for FieldtypePage and FieldtypeOptions fields Inline publish/unpublish toggle via AJAX Bulk actions: publish, unpublish, delete with CSRF protection CSV and JSON export with active filters preserved Role-based permissions matrix — scope each role per collection "View in Collection" button injected into the page edit form REST API: Bearer token, query param, HTTP Basic, and PW session auth API key management with expiration dates and per-key capability scopes SHA-256 hashed keys, usage tracking, rate limiting (100 req/min) WireCache support for GET responses ProFields support: Table, Textareas, Multiplier, Repeater Matrix, Combo — including dot-notation for subfields (address.city, blocks.hero.title, prices.*.amount) Field types: Text, Textarea, Integer, Float, Checkbox, URL, Email, Date, Image, File, FieldtypeFileB2, FieldtypePage, FieldtypeOptions, MapMarker, Color Requirements: ProcessWire 3.0.244+, PHP 8.2+ There's a thread from 2013 asking for exactly this: Module Idea: Flat Listings — here it is, 12 years later. Known issues are tracked on GitHub — the module is stable for production use, active development continues.