Leaderboard

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.

So... the very first iteration looks like this. Used a "Look there, apply to that"-prompt. We wiill get there. Now I have to dig a little bit deeper to fine-tune. Big help already! Thanks @maximus!

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

@Jonathan Lahijani m5 Mac air has 24 gb, the only options available were 16 or 24 at microcenter when I bought it. But I was already stretching my budget so more ram than that would not have been an option. But I'm looking to experiment with local LLMs on my iMac, which has 16gb, not the new computer. They can run as slow as they want, I'm only experimenting, I'm not looking to replace the AI services, just wanting to learn and give my iMac something to do.

I tried adding examples, but it doesn't always work. Sometimes he often doesn't understand what needs to be implemented and how. Sometimes he's pulling hardcode, sometimes something else. I usually write prompt in AI "apply the design system to the module https://github.com/mxmsmnv/pw-design-system" and then it makes a more conscious design. To ensure the design is consistent across both the old and new versions of the theme, you need to create a hardcoded framework like in my Collections module. Then it will look the same across all versions. If you write directly for the new design, some parts won't display in the old one. I've migrated almost all of my websites to the new theme. Clients just need to get used to it, then they'll say it's so cool. I'd also make a colored header module in the admin panel, but that's a whole other story. Design system https://mxmsmnv.github.io/pw-design-system/

So far I tried with: Z.AI GLM 5.1 Kimi K2.6 MiniMax 2.7 Opus 4.7 Codex 5.3 DeepSeek Pro & Flash V4 Results don't vary that much here in this case. I generated a few variations now and will pick the best parts from each variation. Huge context windows do help when I tell the agent to inspect a module that has a certain type of block i want to use/copy. Like tables or listing, like button groups or dropdown buttons. Outside of ProcessWire modules absolutely. They do a great first draft you can fine-tune then. I played a bit with ui.sh and impeccable.style to achieve quite good results. Even landing pages, newsletter templates, and everything non-dashboard type of design. Shadcn/TailwindCSS are great for fast prototyping of good looking interfaces. Even when using models like the older MiniMax 2.5. I did a small comparison a while back using older models and no skills or design frameworks. It was fine. https://log.nerd.to/log/ai-frontend-design-comparison/ Pointing in 2 directions helps: pointing at existing modules and how they did it, or just copy and paste the code (which isn't that easy sometimes) pointing at static examples and design systems for the fine-tuning - in this case the one from @maximus. I'm complaining on a high level here. 😂 The main part, developing the module, took an hour. So there is room left to design the UI a bit. The module is up and running, does what it should do. I am happy for now.

Version 2.0.0 ProcessCronJobs no longer relies on ProcessWire's LazyCron module. Due-state is now checked internally against each CronJob's lastRun and its configured interval. LazyCron definitions such as LazyCron::everyDay still work, though. Remove lazyCron dependency add build in delay methods fix race condition with the original LazyCron Module fix cron command preview;

I recently started to use more desktop apps, in this case OpenCode Desktop, which is quite similar to OpenAI Codex and the Claude Desktop app, but actually available for Linux. One great feature is Git worktrees support. They just work with NextJS, AstroJS, HonoJS but not with ProcessWire in my DDEV setup. I'm not sure if anyone else already found a great solution or maybe even built a module, script or anything like that (and I couldn't find anything) to support Git worktrees in DDEV environments with almost no manual intervention, so... I asked my agent to help me. I just pushed the inital/experimental version to Github. I tested it quite a bit with two projects locally in my setup and it works on my machine. https://github.com/webmanufaktur/processwire-ddev-worktree This is more like a proof-of-concept than a stable release. In case you want to test it, maybe don't. Or at least not with important projects. There might be plenty of edge-cases it won't handle right now or even break things on your machine. But it just solved a pretty big problem (for me) I ran into today. Look into it, feel free to fork it or send a PR.

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.

I would still recommend following the following scenario, at least that's how I did the Job Board, not just everything chaotically, but purposefully in stages. 1. You need to write a module specification, explain the idea, and ask the AI to ask you questions interactively - this will help you open up better. 2. Once the specification is ready, you can start coding. Sometimes you have to bet big, like in a casino. That's what I did with Opus 4.7—the cost of a week's worth of code was $5—meaning I'd burned through the weekly limit. 3. Launching in the environment. Previously, I simply uploaded files, debugged using screenshots - I worked like this for quite a long time, copied the code from the chat window to an FTP file, made an update, and then continued testing. 4. Buy a $99 license for MAMP and specify the folder with files for Claude Code or Codex. 5. Request a technical analysis, preferably cross-analysis using several models—sometimes they can contradict each other. Fix critical bugs. 6. Continue testing. Sometimes, when I don't like the interface, I tell the AI, "Simplify the interface in WireWall or add more data to the Dashboard in Job Board." 7. Manual testing of inputs and checkboxes. However, this can be replaced with Claude Cowork. You just need to describe the task to it and then ask it to generate a report so you can continue making the code work. 8. Sometimes the AI doesn't know what's inside or how the data is stored. You need to install TracyDebugger with Adminer or, alternatively, write a small tool that receives the data and then saves it as JSON so it can debug itself. In general, this simple plan will help you write a good application. I like Processwire for its interactivity and the fact that you can build the architecture of 3-4 full-fledged websites within it. Teams and investors with bloated staffs are no longer needed. Everything can be done solo. Thanks to @ryan for your work, the forum and the people who move this platform forward!

I didn't know that either! I too always assumed you have to click the "upgrade available" link, and if that link wasn't there, you could not upgrade. That seems like a UX issue to me.

Thanks @maximus! It's a pity I can't give at least 5 likes to your post :)

I think Opus is a sledgehammer, and Codex is quite an ordinary hammer.

Which AI model are you using? I've found that high-end AI models, such as Opus 4.7 (Extra High), are great at complex data tasks. However, I've always had better visual and UI results with Sonnet 4.6 (outside of PW). Having said that, I've developed several non-ProcessWire professional tools with AI. If you have the benefit of using Tailwind or ShadCN, you can achieve very nice, clean and consistent UIs with little prompting or babysitting (even if they can be generic). I think the models have more training, data and Tailwind references to work from. When it comes to PW, I don't know why the models have such a hard time, even when you point them to working examples. You might have better luck having them scaffold something first with just HTML and CSS based on UIKIT and then get them to apply the interaction and functions?

This week on the dev branch we have around 35 commits that cover mostly minor bug fixes. Most of them were submitted by @adrian and several others were found by Claude and GPT 5.5 Codex using the WireTests framework. Claude and Codex seem to work well together, each having different strengths, and they are always complimenting one another. Codex seems to be more accurate with the technical stuff, so is reviewing everything before it gets committed, often finding and fixing details along the way. Claude usually writes better commit messages, so Claude is handling most of the commits. A couple new API.md files were added this week also: WireCache ($cache) and WireMail ($mail). We're getting close to having all the API variables covered, and all the Fieldtype modules have already been covered. Some new tests were added and updated in the WireTests module as well. WireTests has also been updated with the ability to support external tests. This enables you to specify a different directory or php file to run for tests, rather than the default. This will come in handy as we start moving the test files into the core. But the majority of this week was actually spent setting up a new computer. I got a M5 Macbook Air to replace my 2017 iMac, and it's taken most of the week to get things setup the way I want, and I'm still working on the details. It's been so long since I've had a new computer that I forgot how much work it is to get things just right. 🙂 Thanks for reading and have a great weekend!

That's great. I've been running a 5090 here because I still do conventional rendering but even on 32GB there are some great local models.

Also checked BuiltWith — there are 22,000+ live ProcessWire sites out there. Would love to see Ichiban running on as many of them as possible someday. 🙂

Thanks for the kind words, Peter! This actually gave me the push to keep going - after several iterations I had almost given up on building something substantial, because every popular CMS already has mature SEO tooling. I went through Yoast, RankMath, SEOmatic, and a bunch of others, took notes on what worked and what didn't, and tried to bring the best of it to ProcessWire. Still a long way to go, but the foundation is there. Looking forward to seeing SEO NEO when it's ready too - good SEO tooling for ProcessWire benefits everyone!

Thanks for the kind words! I have a month's worth of modules, not as big as Collections, Ichiban, or Context, but very useful. Usually, when I run into a problem, I try to solve it right away using a module so that other users can use it in the future.

I’ve been using `TextformatterVideoEmbed` for YouTube/Vimeo embeds and made a small local patch that seems generally useful for generated iframe output. The change adds two attributes to generated iframe embeds when they are not already present: ```html loading="lazy" referrerpolicy="strict-origin-when-cross-origin" ``` This is independent of any consent/privacy module. It simply improves the default iframe markup produced by `TextformatterVideoEmbed`. The intended behavior is: - add `loading="lazy"` to iframe embeds by default - add `referrerpolicy="strict-origin-when-cross-origin"` by default - do not override either attribute if it already exists in the iframe markup - keep existing embed behavior unchanged otherwise Example implementation pattern: ```php if(stripos($embedCode, ' loading=') === false) { $embedCode = preg_replace('/<iframe\b/i', '<iframe loading="lazy"', $embedCode, 1); } if(stripos($embedCode, ' referrerpolicy=') === false) { $embedCode = preg_replace('/<iframe\b/i', '<iframe referrerpolicy="strict-origin-when-cross-origin"', $embedCode, 1); } ``` Reasoning: - Native iframe lazy loading is now widely supported and helps avoid loading off-screen video embeds unnecessarily. - `strict-origin-when-cross-origin` is also the modern browser default in many contexts, but making it explicit gives generated third-party embeds a safer baseline. - The change is low risk because it only applies to iframe markup and skips attributes already present. Would this be suitable as a small PR to the module? If preferred, it could also be exposed as module config options rather than hardcoded defaults.

Hello everyone, We're slowly working through our site and moving things into modules for antarctica.gov.au, in the process we hope to open source some handy things we've built over the years. As we operate in Microsoft heavy corporate environment, we've noticed more and more strange looking links getting pasted into our site. These are Microsoft protected links and are a 'intercept' link that attempts to check the link is legit before letting the user proceed to the original URL. These links get automatically made when a user copies a link from Outlook/Teams/Office. The issue is, these links leak data in the URL parameters, including the email address of who has copied the link! Hence, we wrote two companion modules to find and format these links. First is TextformatterMicrosoftProtectedLinks which formats the links at render time. Second is FormatMicrosoftProtectedLinks which replaces the link with the original URL when saving the page. We provided both modules as it depends on your preference. Some people like to leave the page content as the original (including the protected link), others like to replace this. Let us know if you notice any issues using these modules.

How much RAM does your new M5 Mac have? Hopefully you got 96 or 128GB if you're looking to run local LLMs. A lot is happening in this space; see DwarfStar 4: https://github.com/antirez/ds4

I can recommend OpenCore Legacy Patcher for upgrading macOS on older Macs. You could upgrade your iMac to Sonoma with it. 😉

Hi everyone, I needed a solid subscription module for a client project — something that handles multiple lists, double opt-in, and plugs cleanly into order and contact forms via a PHP API. Nothing in the directory quite fit, so I built Subscribe. It's been running in production on a few sites since March, so the edge cases are ironed out. GitHub: https://github.com/mxmsmnv/Subscribe What it does: Multiple subscription lists with many-to-many subscriber relationships Double opt-in with configurable HTML email ({confirm_url}, {unsub_url} placeholders) Honeypot spam protection — no CAPTCHA needed IP-based rate limiting (configurable threshold and time window) One-click unsubscribe with unique token per subscription WireMail provider selector — works with default, SMTP, Brevo, or any WireMail module Admin UI (Setup → Subscribers): Sidebar list switcher with subscriber counts Add/toggle/remove subscribers, create/rename/delete lists Search, status filter, pagination CSV import, JSON/CSV export per list Resend confirmation for pending subscribers PHP API — drop it into any template, order form, or contact form: $sub = $modules->get('Subscribe'); $sub->subscribe('user@example.com', $listId); Hookable event for integrations (Telegram notifications, CRM sync, etc.): $wire->addHookAfter('Subscribe::subscribed', function(HookEvent $event) { // $email, $listId, $subscriptionId }); Ships with an Alpine.js form block ready to drop into any template. Requirements: ProcessWire 3.x, PHP 8.0+ MIT License.

@BillH Man, you saved my live. I had a nightmare last night, seeing myself migrating dozens of entries manually but your code came to the rescue. It works! Here is my code: page()->of(false); foreach (page()->images as $image) { $image->artist_name = $page->title; if($image->description): $image->title = $image->description; $image->image_caption = $image->description; endif; // first save inside loop saves the field value $page->save('images'); } // saves the page $page->save(); Yesterday I had the output formatting statement inside the loop and I assume this was the mistake. Thanks for helping me!