Leaderboard

This module provides a ProcessWire Admin UI (“bridge UI”) for the ProcessWire Console ecosystem. It does not re-implement Console features itself; instead it integrates with: trk/processwire-console (required for most features) trk/processwire-boost (optional; status/info only) Module repo

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!

A tiny ProcessWire admin utility. Hold a modifier key and click any Inputfield toggle to copy the field's machine name to the clipboard — without collapsing the field. Useful when building templates, writing selectors, or debugging: no more hovering to read the name in the title attribute. Github: https://github.com/dlzi/FieldNameCopier

We might have a minor misunderstanding here. Building modules, tools, apps, anything with little to a lot of logic and functions is not the issue here. My problem is not that there are functions or config fields (Admin UI) missing or not working in a way or form I imagined them to work. The problem is that the Agents and LLMs are not ready yet to build module backends (Admin UI) - even when outlined in high detail. Sometimes they are almost there or at least it looks like it, sometimes they invent something totally new and won't even use existing field types, wrappers, and classes. Having an existing module, adding new functionality, new config settings, or even pages works incredibly well. That's because the Agent/LLMs can re-use existing structure of backend code. Besides that I totally support your step-by-step process and workflow. You can't just throw a vague idea towards whatever tool and expect a wonder. That's for sure. Little side note: I asked Kimi and Opus to build a module that's only purpose is to showcase module pages, all sorts of inputs and outputs. So I have a working base for interfaces I can point at later on. The prompt for those interested: The result: https://github.com/webmanufaktur/ProcessShowcase

Hi @maximus, I have been testing your module, and so far it’s really impressive! The only problem I’ve found is how to map an image field that lives inside a combo field to an og:image. I’ve tried combo:image, combo.image, and {combo.image}, but none of those have worked. I also want to take the chance to thank you for your recent modules, you’ve been on an impressive productivity streak and personally I’m using several of your modules in production

Hi everyone, I've been timing my bigger releases with the lunar cycle — new moon for launches, full moon for milestones. Collections shipped on the full moon two weeks ago. Tonight the moon is invisible. The module isn't. 🌑 GitHub: https://github.com/mxmsmnv/Ichiban Why Ichiban? Ichiban (一番) is Japanese for "number one" — fitting for an SEO module whose entire purpose is to help your pages rank first. Why another SEO module? There hasn't been a comprehensive SEO module for ProcessWire for a while. Yoast and RankMath solve this for WordPress — both charge $59–$99/year for the full feature set. Ichiban is MIT, free, and built specifically for ProcessWire. What it does Page field — five-tab editor per page: Meta (Google-style SERP preview), Social (OG + Twitter/X cards), Schema, Sitemap, Advanced. Render with echo $page->seo; or enable auto-injection. Source expressions — resolve field values dynamically: title|truncate:70 field:summary|truncate:160 {splash} Admin sections: Dashboard — battery-style site score, health stats, GSC highlights, indexing issues Bulk Editor — edit all meta titles/descriptions in one table, grouped by Critical/Warnings/Healthy Audit — site-wide SEO rule checks, priority cards, CSV export, hookable rule system Redirects — 301/302/307/410/451, regex rules, hit counts, CSV import/export, auto-redirects on slug change Insights — Google Search Console OAuth, metrics, top pages/queries, countries, devices, URL Inspection scan Backlinks — Moz API snapshots, cached history, links/domains/anchors views Schemas — database-backed Schema.org builder, map properties to PW fields Revisions — tracked SEO field changes with restore Cleanup — remove low-value head tags, block spam crawl queries Migration — SeoMaestro → Ichiban converter (15 fields mapped) Reports — scheduled SEO email reports, DOCX export AI — OpenRouter-backed SEO prompt workspace with Context module integration XML Sitemap — built-in generator with hreflang, image sitemap, LazyCron auto-regeneration IndexNow — one-click key generation and verification robots.txt / llms.txt — dynamic serving (companion to RobotsTxt module) Known alpha limits GSC requires a Google OAuth client setup — not plug-and-play Moz free API quota is very small — refresh intentionally Schema Builder is alpha — test before production Auto head injection can conflict with existing theme SEO tags — use manual echo $page->seo; first SeoMaestro migration is experimental — always backup before running Disable debug mode before production Requirements: ProcessWire 3.0.200+, PHP 8.1+ MIT License — free, no Pro tier, no upsell.

Hi @Krlos, Thank you so much for testing Ichiban and for the kind words. I really appreciate it. You found a real gap there. Ichiban was resolving top-level image fields, but it was not yet following ProFields-style dot notation for nested fields inside Combo/Table/Repeater Matrix fields. I’ve fixed this in v0.1.1-alpha. For a Combo image field, you should now be able to use: field:combo.image or: {combo.image} I also aligned it with the same dot-notation style used in Collections, so nested ProFields paths are supported too, for example: field:blocks.hero.image field:media.property_photos.photos field:prices.*.image For Open Graph images, the resolved image will still go through Ichiban’s normal OG image handling and create the 1200x630 variation when possible. Thanks again for catching this, and also for the very kind note about the recent modules. It means a lot, especially knowing you’re using some of them in production.

Looks like Claude/Codex is good at introducing regressions/bugs in the core, or am I mistaken?

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

If you want to try cheaper models, while having the same experience as Claude Code, check out Deepseek TUI or, for multi providers, check Openecode or Aider.

@zilli I'm kind of just getting started too, as a couple of months ago I knew nothing about Claude Code or Codex or any of the other tools. I also felt overwhelmed which led me to avoid the AI stuff for awhile. Too much noise. But my client started using Claude Code and I started getting interested in it. Start with Claude Code or Codex, they are basically identical. Codex is a better value overall IMO, but Claude might be slightly easier to start with. To get started, install Claude or Codex (use instructions on their site). If using Claude, and you have a choice of "model" choose "Sonnet". Claude's premium model is "Opus" but they don't give you enough usage of it on the $20/month plan. Whereas Sonnet is still very smart and lasts for quite awhile on the $20/month plan. If using Codex, you'll get GPT 5.5 which is their latest model and you get plenty of usage on the $20 plan. That's why I say Codex is a better value. The best way to get started is just start asking Claude or Codex questions about how to do things. Create a hello-world/ directory somewhere on your localhost. If you are comfortable with the terminal, go to the directory and type "claude" (or "codex"). It will ask you to login to your Claude or OpenAI account. Then you are ready to go. If not comfortable with the terminal, then stick to the Claude or Codex desktop apps, which can do just as much and maybe more. Ask Claude or Codex to do something like "create a hello-world.html file" just to get a feel for how it works. Ask it to continue making edits to it just for fun. Once you feel comfortable with this, then you are ready to use it in ProcessWire. No need to start creating any .md files at first. Once you get going, ask Claude when/if you should create a CLAUDE.md file (or AGENTS.md for Codex and others, same thing). These files are really only useful once you are working on an actual project and want to provide instructions in a file that gets read every time, rather than pasting them into a prompt. But technically there's very little difference between providing something in an .md file and just providing it in a prompt, at least until it comes time to /compact or /clear (but you can learn about that later). Both Claude and Codex are already well trained on ProcessWire, and they don't need to read the codebase unless they want to. But I do think it's beneficial to run the latest dev branch version of ProcessWire, which includes documentation for AI agents built in. Installing the AgentTools module will be worthwhile for Claude or Codex to be able to most effectively use ProcessWire's API and use built-in tools for pulling documentation, site/schema maps and booting ProcessWire on its own. You don't need to configure any agents in AgentTools for this kind of usage. Just install the module and tell Claude/Codex to go read the /site/modules/AgentTools/AGENTS.md file, and it will be ready to do anything in ProcessWire. If you later want to add agents in AgentTools, that will let you use Claude/Codex inside of the ProcessWire admin for making edits, creating migrations, etc. But you don't need that to get started. I haven't yet even tried any tools other than just plan Claude and Codex (and AgentTools)--so far I haven't felt like I need anything more. I'm also not using any MCP servers. The others here can better speak to those tools and such. Every morning while making and eating breakfast, I do watch YouTube videos on using Claude and Codex though. It's become part of my boot up sequence. 🙂