Leaderboard

Hi all — we're putting this one up as a public beta and looking for feedback before we tag a stable release. How it started. Over the past months we've been moving an old blog into a fresh PW site using our own SiteSync module and a Claude Code agent doing most of the migration grunt work. At some point the blog owner mentioned, in that very offhand way clients do, "hey, an image search would be nice." It was Saturday afternoon, so we let the agent build a prototype, pushed it through SiteSync, tested it on the phone an hour later. Worked great. Search results were… not great. But the search wasn't the problem – the underlying data was. Thousands of imported images, almost no descriptions, no tags, no nothing. So we needed a way to retroactively caption and tag a few thousand images without clicking through hundreds of page edits one by one. Since PW (rightly) attaches images to the pages they belong to, we needed a tool that reaches across the whole install at once and – crucially – can edit metadata in bulk. Why not the existing modules? We looked at the two obvious candidates: Media Manager by @kongondo – great if you're starting fresh and want a central media hub. But it's its own storage layer: you upload INTO Media Manager, editors pick FROM Media Manager. Images already sitting on per-page image fields stay invisible to it. Also commercial. MediaLibrary by @BitPoet – adds a MediaLibrary template with its own MediaImages / MediaFiles fields plus a CKEditor picker. Same pattern: a separate page hierarchy you migrate media into. Both are well-designed for "we want a central media model from day one." Neither helps you when the media is already scattered across lead_image, body_images, gallery, images_in_some_repeater etc. Migrating that into a different storage layer would have broken the original page model the blog depends on. So we built Image Library: a Process module that does nothing to your data – it just surfaces a cross-site table view of everything that's already there, with serious bulk editing on top. The bulk-edit part – the reason this module exists. Selection as a paintbrush. You tick N rows across any pages, templates and image fields. Then you edit a cell on ANY of those rows — the popup gains an Add / Replace mode picker (tags additionally offer Remove) and the value gets broadcast to the entire selection in one server round. Same row applies to description, tags, every custom subfield, AND the filename (with placeholders: (n), (n2)..(n5) padded counters, (N) total, (t) page title, (d) date, (p) page name, (f) field name → e.g. rename 200 selected files to event-2025-(n3).jpg). Same row applies to delete (one trash click, whole selection gone behind one confirm dialog with a where-used preflight – see below). Edits that push a row OUT of the active filter ("missing tags" → tag assigned → row no longer matches) fade out and drop from the table; counters auto-decrement. Other highlights: One sortable, paginated, bookmarkable table across every FieldtypeImage field on every page on every template (with config-side blacklists). Inline edit per cell – multilang-aware: language tabs in the popup, all languages committed in one save. Typed widgets per custom subfield: checkbox, date, integer, options (single + multi), and FieldtypePage rendered through PW's actually configured Inputfield (PageAutocomplete / PageListSelect / ASMSelect / whatever the field uses) — no re-implementation. Replace image in place (drag-drop or upload icon) – basename stays, variations regen. Renaming an image in the library instantly rewrites every CKEditor/TinyMCE embed of that file across the site — original and all variations, in every language — so links never break, and a summary dialog shows which pages were updated. Delete with where-used preflight: dialog scans every Textarea via $pages->findIDs("field%='/pid/stem.', include=all") and lists the pages where the image is still embedded in rich text – CKEditor + TinyMCE both, multilang-aware, with direct edit links so you can fix embeds before deleting. JSON / CSV export + import for offline metadata work – hand a CSV to a copywriter or feed it to your agent, get it back, import it. View prefs (columns, page size, bookmarks) live in $user->meta, cross-device. Status. v0.54.x – public beta. Module + docs (EN + DE concept) at GitHub or the Modules Directory Feedback welcome – especially edge cases we haven't seen yet (weird Fieldtype combos in custom-field templates, ProFields, Repeaters / RepeaterMatrix nesting). And if you've got a use case the current feature set doesn't cover, let us know. Cheers, Mike

It's a rainy Sunday where I'm at. The monsoon is hitting hard. Perfect time to write a love letter. Addressed to a module, my favorite PW module of all times. And its creator @bernhard, of course. A Love Letter to RockMigrations by a long-time user and contributor Dear RockMigrations, I’ve been using you for years. Built sites with you, shipped modules that lean on you, even chipped in a few pull requests along the way. And honestly, I took you for granted. You just worked. Fields appeared. Templates materialized. Modules shipped their own schema like little self-contained suitcases. I never wrote down why you’re so good. I just kept using you. Recently I found myself comparing you to other approaches, side by side, line by line. And I realized: I should write this down. Not because I learned something new, but because seeing the alternatives made your elegance impossible to ignore. Let me count the ways. The Declaration of Truth Most migration systems hand me a blank file and say “write code.” Fair enough. But you, RM, let me declare what a field or template is: // site/RockMigrations/fields/subtitle.php return [ 'type' => 'text', 'label' => 'Subtitle', 'columnWidth' => 50, ]; That’s it. No $fields->save(), no $field->type = wire('modules')->get(...). Just the truth. The current, desired state. You figure out the rest. This means the file is my source of truth, not a historical log of what someone did at 9:14 AM on a Tuesday. If I want to know what the subtitle field looks like right now, I open one file. Not a trail of timestamped breadcrumbs. Circular References? You Solved Them. Elegantly. Every migration system hits the same wall: Template A needs to know about Template B, and Template B needs to know about Template A. Who goes first? Most systems tell me to manage this manually. Order my timestamps. Cross my fingers. You do something way smarter: two passes. Pass 1: Create everything. All fields, all templates, all roles. They exist as empty vessels. Pass 2: Configure everything. Wire up parent-child relationships, attach fields, set permissions. Everyone knows everyone now. Circular dependencies become non-circular across passes. No timestamp juggling. No depends_on arrays. It just works. And if I need to inject imperative code at the right moment, you give me four lifecycle hooks: beforeAssets, afterAssets, beforeData, afterData. Escape hatches at exactly the right places. Not too early, not too late. I’ve used these to install modules, create reference pages, and detach stale fields, all in the right order, every time. You’re Non-Destructive by Default If I remove a field from a template’s config array, you don’t rip it out. You leave it alone. Because you assume I might still need it, or that removing it accidentally would be catastrophic. If I actually want to detach a field, I tell you explicitly: a removeFieldFromTemplate() call, right there in the same config file or in the relevant hook. Destruction is a conscious choice, not a side effect. This alone has saved me from myself more times than I’d like to admit. Modules Ship Their Own Schema A module can drop a RockMigrations/fields/ folder into its own directory, and you just… discover it. No registration. No global config. No “please add this module to your migration scan path.” site/modules/Foo/ ├── Foo.module.php └── RockMigrations/ ├── fields/bar.php → foo_bar └── templates/baz.php → foo_baz You auto-prefix field names with the module name. You auto-tag them. When I look at a field in the admin, I can see which module owns it. And when the module uninstalls, its ___uninstall() method can call a migration script that cleans everything up, fields, templates, the lot. Optionally guarded behind a checkbox in the module config so the site admin decides whether to keep the data. No manual cleanup. No orphaned fields haunting the database for years. A module is a self-contained package: code and schema. And you respect that boundary. No sprawl into a shared site/migrations/. No “did file 47 or module X create this field?” The answer is in the file path on disk. This design choice makes every module I’ve built feel cleaner and more portable. Free Constants, Free IDE Support By just creating a marker file (RockMigrationsConstants.php), you auto-generate class constants for every field and template: // Auto-generated. Do not edit. class RockMigrationsConstants { const field_subtitle = 'subtitle'; const template_award = 'award'; } Now my IDE autocompletes RockMigrationsConstants::field_... and I never type "subtitle" as a raw string again. No typos. No silent breakage when I rename a field. You generate this from the config files, the same single source of truth. Silly bugs prevented. You’ve Grown Without Bloating You’re not a proof of concept. You’re not a shiny new thing I’m nervously trying in production. You’ve grown organically across versions, picking up MagicPages, deploy helpers, auto-release workflows, and about forty other things. You’re the Swiss Army knife that somehow doesn’t feel bloated. I’ve watched you mature over the years. Every feature felt like it earned its place. Nothing feels bolted on. Things that did at one time got removed. Other solutions are ... not bad Look, I need to say this clearly: the other migration approaches out there are not bad. They’re genuinely good work by talented people, and I’m grateful we have choices. A ProcessWire ecosystem with multiple migration approaches is a healthy ecosystem. Every approach has its place and its audience. But every time I sit down and compare feature to feature, RockMigrations comes out uniquely complete. Declarative config? Check. Two-pass circular dependency resolution? Check. Module self-containment with auto-discovery? Check. Non-destructive by default? Check. Auto-generated constants? Check. Battle-tested over years? Check. Not all in one package anywhere else. So if you’re on the fence, give it a spin. Create a site/RockMigrations/fields/ folder, drop in a config array, refresh modules, and watch it work. You might just stick around for years too. Yours declaratively, a long-time user

Now available in the Modules directory at https://processwire.com/modules/chat-ai/ and on gitHub at https://github.com/clipmagic/ChatAI What is it? ChatAI is a native ProcessWire AI chatbot module designed to answer questions about your site content, with a focus on: ProcessWire-first workflows Site-aware answers using RAG (Retrieval Augmented Generation) Respect for ProcessWire access control rule Admin visibility into usage and performance Keeping content ownership within ProcessWire Features include AI chat widget for frontend use RAG indexing of ProcessWire content Multi-role message support (system / assistant / user) Admin dashboard with metrics and observations Configurable prompts and behaviour Integration with AgentTools for model selection Role-aware retrieval (users only see content they can access) Frontend page restrictions Dictionary / weighting support for retrieval tuning Quick Start Ensure prereqs are installed, ie: PHP>=8.0, ProcessWire>=3.0.255, AgentTools>=0.1.1, TextformatterEntities, TextformatterNewlineBR Configure your chat LLM in AgentTools Configure your textembedder LLM in AgentTools Configure ChatAI module config with both the above Go to Setup->ChatAI and index your site pages (turn off Dry Run when you're ready). Add the CSS, Script and Widget to your template(s). After that, tweak to your heart's content, including adding languages, widget theming and prompts. Current status: Alpha Test thoroughly before using on live sites. Feedback welcome.

Hi everyone, a client of ours had a term that shows up all over their site, and they had it registered internationally. So suddenly it needed an ® after every occurrence. The question landed in our inbox as "you probably know an easy way to do this, right?" 😉 There is already Ryan's TextformatterFindReplace, which is powerful and the right tool if you are happy writing regex. We needed something different: a textformatter our clients can edit themselves, i.e. people who do not write regular expressions. So in Annotations you just list the strings and pick options in a small per-string table, no regex anywhere. And so clients never have to touch the Modules section, the module also adds its own page under Setup, guarded by a dedicated annotations-edit permission, where they manage exactly these settings and nothing else. What it can do, for example: Append a mark, the classic case: put (R) (or ©, ™, ...) after a term wherever it appears. Wrap a part of a word, e.g. turn H2O into H2O (subscript the 2). Auto-style certain terms, e.g. make a brand name bold everywhere. Footnote markers, mark only the first occurrence of a term (first-only), great for footnotes1. The real work, though, is in the details that make it safe to hand to an editor: It only changes text, never markup. Tags and their attributes (href, alt, title, class), HTML comments, and the content of skip-tags you configure (code, pre, script, style) are left completely alone. A brand name sitting in a URL or an alt text stays untouched. E-mail addresses are protected. With a frameless to ® rule, info@frameless.at does not turn into info@frameless®.at. It never doubles a mark. It recognises a symbol that is already there, whether it was typed as the literal character (®), as an entity (®, ®, ®, ®, lower or upper case, even with leading zeros), or already wrapped in a tag. No second one gets added. It normalises messy input to your setting. Same spelling, consistent form: a bare symbol gets wrapped, an existing wrapper gets unwrapped (or re-wrapped) if you change the tag later. Editors can be inconsistent and the output still comes out uniform. Longest match wins, and rules compose. Configure both "frameless" and "frameless Media" and each keeps its own treatment. Append runs first, wrap layers on top, so "frameless Media" can be bolded on the word and still get its ® at the end: frameless Media®, while a single "frameless" gets rendered as frameless®. Per-string control: whole-word matching (so cat does not hit category), case sensitivity, and first-occurrence-only, each set per string. Any inline wrap tag: sub, sup, b, strong, em, mark, abbr and more, not just superscript. Get it here https://github.com/frameless-at/TextformatterAnnotations https://processwire.com/modules/textformatter-annotations/ Feedback and ideas welcome. Cheers, Mike!

Suggestion: user-definable collection groups (free-text, self-learning) Hi Maxim — first, thanks for Collections; it's becoming central to how I'm managing a few thousand records in a client’s ProcessWire installation. One small limitation I ran into: the Group field is restricted to the three built-in values (`content`, `taxonomy`, `custom`). The sidebar renderer already handles arbitrary group names gracefully (it appends any non-blessed groups after the three known ones), so the only thing standing between users and custom groups is the form control plus the matching server-side whitelist. Relaxing both makes custom groups work end to end, with no storage, rendering, or migration changes — `Collection::toArray()` / `fromArray()` already round-trip an arbitrary `group` string. Here's what I changed locally (against v1.9.3). Three small edits: 1. `views/configure.php` — Group control: `<select>` → text input with datalist combo This keeps the three defaults as type-ahead suggestions while allowing any new value: <div> <label class="uk-form-label">Group</label> <input type="text" name="group" id="field-group" class="uk-input" list="group-options" autocomplete="off" placeholder="content, taxonomy, custom, or a new name"> <?php // Group suggestions: the three blessed defaults, plus any // groups already used by existing collections ("learned"). $groupSuggestions = ['content', 'taxonomy', 'custom']; foreach ($config->getCollections() as $existingCol) { $g = $existingCol->group; if ($g !== '' && !in_array($g, $groupSuggestions, true)) { $groupSuggestions[] = $g; } } ?> <datalist id="group-options"> <?php foreach ($groupSuggestions as $g): ?> <option value="<?= $wire->sanitizer->entities($g) ?>"></option> <?php endforeach; ?> </datalist> </div> The datalist is seeded with the three defaults and then "learns" any group already in use across existing collections, so previously-coined groups are offered as suggestions going forward. (Naturally, a brand-new group name only becomes a suggestion after its first save — there's nothing persisted to learn from until then.) 2. `src/ProcessCollections.module.php` — `handleSaveCollection()`: drop the server-side whitelist This is the matched pair to the dropdown — without it, any non-blessed value is silently coerced back to `content` on save. Change: 'group' => in_array($post->text('group'), ['content', 'taxonomy', 'custom']) ? $post->text('group') : 'content', to: 'group' => $san->name($post->text('group')) ?: 'content', I used `$san->name()` to keep the value safe as both an array key (it's the grouping key in `layout.php`) and a sidebar heading — lowercase, `a–z 0–9 _ -`, consistent with the convention the Key field already advertises. It still falls back to `content` when the field is empty, preserving the original default behavior. (If you'd rather allow spaces/capitals in headings, `$san->text()` would do it, at the cost of looser grouping keys.) Result With those two edits, custom groups work the whole way through: type a new group, save, and it appears as its own sidebar section (sorting after `content` / `taxonomy` / `custom`, per the existing `$groupOrder` logic in `layout.php` and `dashboard.php`). The datalist addition just makes existing groups discoverable as you go. Happy to adjust naming/sanitizer choices to match your preferences — and thanks again for the module and for being so responsive in this thread. [In the interests of full disclosure, Claude Opus 4.8 helped me identify the spots that needed updating.]

For a number of years we've grappled with how best to implement on-page structured data via JSON-LD. For almost all projects we've ended up using a code-based solution, with a standard JSON-LD output defined for all pages/templates, with any template specific structure defined in the template file (e.g. Article for a post template). This approach isn't particularly malleable, at least not for clients who actually want to implement JSON-LD themselves or via their SEO partners. MarkupJsonldModels is an attempt to find a good solution that's workable for everyone, including AgentTools. It uses the concept of "models" - valid JSON-LD using placeholder tags which resolve to actual page values when output on a rendered HTML page. It allows you to define a default model in the module config, a model for each template (assuming it will be output as HTML), and adds a field (jsonld_model) on installation which you can add to a template to allow a model to be defined per page. As GEO becomes more and more important, this is a module I hope will prove quite useful, however my own motivation for it is more laziness than anything else - I wanted to build something where I could just get an AI Agent to suggest and implement models via Agent Tools! Preliminary tests with this approach have been reasonable, and I can definitely see it being a time saver when I get it integrated into our dev process, and I expect the quality of the JSON-LD will end up significantly better too. However, it doesn't require Agent Tools to work - but an ability to work with JSON is... It is currently in Alpha, as it really hasn't been tested in the wild (just yet). I expect there will be another couple of rounds of dev and improvements once we start using it for existing sites that are current looking for GEO improvements. There's a pretty lengthy README - https://github.com/nbcommunication/MarkupJsonldModels/blob/main/README.md - which is likely a giveaway that I've been using Agent Tools (Claude 4.7) to assist in code and documentation review! Any thoughts and feedback would be much appreciated. Chris

@psy nice! Thank you for creating it and chiming in.

@HMCB Not sure how you'd implement this? You can cap the number of messages sent per conversation. The default is 20. The user will be warned when they have one question left. After that question is answered, the chat widget removes the input form. The user can continue in another chat by resetting the session.

@HMCB ChatAI will only suggest pages the user can access by role. Additional limits can be by template and/or a checkbox on a page template.

@psy This is awesome. Question: Seeing that it can be used on the front-end, are we able to control what content the chat has access to? For instance, depending on the logged-in user, I may only want the chatbot to access certain pages (and sub pages) in a given site.

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.

Core updates A new WireApiDocs class was added that provides an API... for APIs. It’s a tool that can parse ProcessWire’s API.md files to provide various methods for finding and pulling documentation. It also includes the ability to get certain parts of an API.md (chapters). This new tool is accessible through $wire->docs, which returns an instance of WireApiDocs. Here’s a few usage examples: $api = $wire->docs; $api->get(); // get summary array of all documented classes $api->get('Pages'); // get docs for Pages class $api->get('Fieldtype*'); // get names of all Fieldtype classes Lots more examples here: https://processwire.com/api/ref/wire-api-docs/get/ and the entire class reference can be found here: https://processwire.com/api/ref/wire-api-docs/ WireApiDocs also comes with a full CLI command set, which can be viewed by typing: php index.php docs WireApiDocs: ============ php index.php docs list List classes with API docs as string php index.php docs list 'Class*' List classes matching wildcard pattern as string php index.php docs list-json List classes with API docs in JSON php index.php docs list-json 'Class*' List classes matches wildcard pattern in JSON php index.php docs list-json-verbose List classes with API docs in JSON verbose mode php index.php docs list-json-verbose 'Class*' List classes matching pattern in verbose JSON php index.php docs get Class Get API docs for given Class php index.php docs get-json Class Get JSON API docs for given Class php index.php docs toc Class Get table of contents for given Class (string) php index.php docs toc-json Class Get table of contents for given Class (json) php index.php docs body Class num Get body for given Class and chapter number php index.php docs body Class 'title' Get body for given Class and chapter title New API.md files Speaking of API docs, several new API.md files were added to the core this week. You can view any of them by clicking the links below: WireArray: Covers the base collection class for all PW iterable sets. WireData: Covers the base data-storage class used throughout ProcessWire. LanguageSupport: Covers all things multi-language in ProcessWire. This is probably our most comprehensive API.md yet. WireHooks: Comprehensive guide to ProcessWire's entire hooks system. Fields: the API variable that manages all custom fields in ProcessWire. Templates: The API variable that manages all Template instances. FieldtypeOptions: Field that stores one or more selected options from a predefined list. New LanguagePorter class for exporting and importing translations This new class provides a simple "export CSV" and "import CSV" for language static translations. It was added so that agents and developers could have an easy way to pull all text to translate, translate it, then push it back into the system. It is used by the new "static phrase translation" task that appears in this week's new version of AgentTools. The LanguagePorter can be accessed for any language from the $language->porter() method. WireTests in the core Tests for the WireTests module are now being placed directly in the core. We are slowly migrating the existing tests, while new tests are being committed to the core rather than in the WireTests module. This week tests were added for the following (click links to view tests file): Sanitizer, WireData, WireArray, WireDateTime, LanguageSupport (covers all multi-language features). AgentTools updates New “run in background” option for Site Engineer and Page Engineer AgentTools now has the ability to queue and run AI agent requests in the background on the server, rather than through a web request. This is especially helpful with long running tasks, as they can run without Apache/server http timeouts. The AgentTools module configuration screen tells you what you need to do to enable background jobs. But primarily it’s just a matter of enabling a cron job for AgentTools. When the background job is finished, you can view the agent’s response in the admin. But it also gets emailed to you. Background jobs are available for Site Engineer, Page Engineer as well as the built-in and custom tasks. New built-in task: Static phrase translation and language pack creation Per last week’s update, AgentTools now comes with several built-in AI tasks that you can use. Added this week is yet another new task for multi-language sites: you can now have all the phrases in your site, in modules, or even the entire core, translated to another language by your AI agents. Not only does the task handle all of the translation, but it also handles creating and installing the language pack(s) once it is finished. Please note that this particular task requires that you 1) have ProcessWire 3.0.264 or newer; and 2) have multi-language support enabled on your installation. Also note that mass translation of phrases can take some time, so the new background mode can come in especially handy when doing lots of automatic translations. New engineer preview / dry-run mode If you want to know what the agent would do to accomplish something, without actually committing the changes now, check the new “Preview” checkbox before submitting an Engineer request. The agent will run in a read-only mode to describe what it would do before you commit to making it do the real thing.

I’ve uploaded a new NativeAnalytics update from v1.0.25 to v1.0.26. Big thanks to @adrian for the PRs, testing, feedback and useful suggestions. What’s new / improved: Added improved 404 bot/probe detection with the new scanner_404 rule. Added an option to show/hide bot traffic in the 404 report. Fixed dashboard tabs so the ?tab= URL parameter updates correctly. Current visitors are now grouped by visitor instead of showing duplicate sessions. Current visitors counters and tables are now more consistent. Removed duplicate/native SVG chart tooltips. Fixed chart/date labels so they no longer show unnecessary 00:00:00. Added new Avg active time / session metric. Added active time tracking with cookieless tracking support. Improved session quality reporting. Added new export options and improved export handling. Reworked the export button/dropdown for a cleaner admin UI. Improved Current Visitors auto-refresh so action buttons are not removed. Cleaned up export dropdown IDs and admin UI behavior. Improved install/schema consistency. Improved module info and permission definitions. Small UI, stability and code cleanup fixes. This update should make NativeAnalytics cleaner, more accurate and more consistent, especially around bots, 404 traffic, current visitors, exports and reporting. Cheers R

Hi everyone, Building a package forwarding platform means dealing with phone numbers from dozens of countries. US customers, European recipients, warehouse staff - each expects a different format. Storing a raw string and hoping for the best doesn't work. This fieldtype does it properly. GitHub: https://github.com/mxmsmnv/FieldtypeTel What it does Powered by intl-tel-input v28 - bundled locally, no CDN dependency. Country flag picker with search Stores four formats per number: e164 - +12025550123 - for tel: links and shipping APIs intl - +1 202-555-0123 - for international display national - (202) 555-0123 - for local display country - us - for filtering and selectors echo $page->phone; // (202) 555-0123 echo $page->phone->e164; // +12025550123 echo $page->phone->country; // us // tel: link echo "<a href='tel:{$page->phone->e164}'>{$page->phone}</a>"; // Selector — find all Australian numbers $pages->find("phone.country=au"); Restrict countries, set preferred countries, per-field defaults Auto-format as user types AdminThemeUikit themed - light and dark mode via --pw-* CSS variables Requirements: ProcessWire 3.0.200+, PHP 8.2+ MIT License.

Wow!!

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