Leaderboard

This week I've been doing a major overhaul of the /wire/core/ directory structure aimed at improving and adding documentation. Now all core classes that will receive their own API.md documentation also have their own directory. The /wire/core/ directory kind of resembles the /wire/modules/ structure now. In addition, new API.md files have been created for the Pages, Page, PageArray, Modules and Module, all of which also improve the online API reference documentation too, which is what those links are linking to. We'll continue adding more API.md documents every week. Every time a new API.md file is completed, it gets sent over to the WireTests module to verify that everything documented in the API.md works exactly as stated. So new tests have been committed to that module as well, and more will be getting added every week. In addition, ProcessWire now has a CLI (command line interface) installer. Installing ProcessWire is as simple as typing this from the command line: php install.php When you do that, it'll present you with the installation options (see below). For human users, the "Standard usage" option is likely to be best, while AI agents will likely prefer the "Alternate usage" option: Standard usage: php install.php --generate Generate ./install-config.php for you to edit php install.php --config install-config.php Install from settings in ./install-config.php Alternate usage: echo '{"dbName":"mydb",...}' | php install.php Install from settings in JSON string php install.php --json '{"dbName":"mydb",...}' Install using an inline JSON string Other: php install.php --help Display all options That last option "--help" displays a giant screen of options, so I won't repeat it here, but take a look if you are interested. New versions of FieldtypeTable, FieldtypeCustom, FieldtypeCombo and FieldtypeRepeaterMatrix next week. Lots more in progress here too so stay tuned! Thanks for reading and have a great weekend!

Thanks for all the feedback, this is great. I just wanted to say ProcessWire has always been "back", never left. It's always been a long term project and never a fad project, so periods of rapid development and periods of slow development are normal, and I'm sure that cycle will always be the case. I've always been careful about making sure the project doesn't get bloated with short term things. So to make sure the quality is high over the long term, it's good to know when to go into rapid development, and when to let things simmer slowly. There's room for both. The other factor is that sometimes I have client work deadlines that I've got to give priority to because that's what keeps me in business, and able to keep investing in ProcessWire. I mention all this just because I don't want folks to be disappointed when there are weeks without any commits, etc., because that's unavoidable. For me this has always been a lifetime project, so ProcessWire isn't leaving or coming back, it's here to stay, as has always been the case.

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.

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!

AgentTools updates (v12) New AgentTools Page Engineer Fieldtype: provides a page editing assistant with the ability to make page edits like writing or summarizing text, importing data from external sources, generating image descriptions, managing child pages, and more. To use it, create a new PageEngineer field, add to a template and edit a page. You get an in-page assistant where you can ask for page editing help. The PageEngineer comes with full knowledge and expertise of your entire site, built in. Also new to AgentTools this week is an upgrade to the migrations system. Now you can copy/paste migrations between dev and production sites. Just check the box next to one or more migrations and click export. Transferred migrations are encrypted with unique salt values from your /site/config.php file. So for security, it's not possible for import a migration that wasn't generated by AgentTools. Lastly, AgentTools also gained a "tattletale" feature. When enabled, if you ask the agent to do something that could compromise security or is otherwise suspicious, it triggers a special tool in AgentTools that blocks the user from making further requests for an hour. It also emails you (the admin) to let you know what specifically the agent found suspicious. Core updates (3.0.261) ProcessWire 3.0.261 is on the dev branch this week and continues with our reorganization of core classes for documentation purposes. New API.md documentation files were added for: $session, $config, $files, $database, $input, $sanitizer, and PagesRaw ($pages->raw). Because most classes are getting their own directories and API.md files, I'm thinking that the WireTests module might be merged into the core, and classes and modules will come with their own tests file (i.e. Class.tests.php and ModuleName.tests.php). It just seems to make sense that tests live alongside the class they test, so that they can be easily updated with the class. All of this core recorganization is leading towards ProcessWire 4.x. LazyCron was updated with CLI support for running jobs (with option to disable http running), and $modules was updated to now have its own CLI tools (visible when typing "php index.php"). Many more API variables will be getting their own CLI tools as well. I'm now using both Claude Sonnet 4.6 and GPT 5.5 Codex to do code reviews and write API.md documentation for the core. I find they each have their upsides so am trying to put them both to good use as much as possible. This week GPT 5.5 covered several core classes, and the entire /wire/core/Pages/ set of classes. For more details on this week's updates see the full commit log here. New versions of the following ProFields have also been released this week: FieldtypeTable, FieldtypeCombo, FieldtypeCustom and FieldtypeRepeaterMatrix. In addition to new features and fixes, these all have gone through AI code reviews and now have their own API.md files as well. More modules on the way too. I think that covers everything updated this week but it's late and I'm probably forgetting something, so I'll reply with more if it comes up. Thanks for reading and h ave a great weekend!

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 everyone, Every site I've launched eventually had a database incident — corrupted table, failed migration, bad deploy. Having a reliable backup system that runs automatically and stores offsite is non-negotiable. This module is what I use in production. GitHub: https://github.com/mxmsmnv/ProcessDbBackup What it does: Three independent backup types — Regular, Weekly, Monthly — each with its own LazyCron schedule and retention count Admin home widget — shows status (🟢 OK / 🟡 Outdated / 🔴 No backups) per type with "Create now" buttons Backblaze B2 upload — optional offsite storage after every backup, keep or delete local copy Chunked upload — upload .sql.gz from your computer in 2MB chunks, bypasses upload_max_filesize entirely Streaming restore — reads .gz line-by-line, flat memory usage regardless of dump size Partial restore — select individual tables from a backup Pre-restore auto-backup — safety backup of current DB before any restore Backup integrity verification — gzip check + SQL structure validation Lock file — prevents concurrent backup processes Exclude tables — skip cache, sessions etc. from all backups Storage protected with .htaccess deny-all Backup methods: mysqldump (preferred, InnoDB-safe hot backup) with PHP PDO fallback. Restore via mysql CLI with PHP PDO streaming fallback. Requirements: ProcessWire 3.0+, PHP 8.0+, zlib, PDO. mysqldump/mysql CLI optional but recommended for large databases. MIT License.

This week we have ProcessWire 3.0.259 which includes several improvements, but my favorite is the addition of a new module type called "CliModule" which is short for "Command Line Interface Module". CliModules are those that provide the option for running from the command line. To list the available actions from command line modules, you can type "php index.php" in ProcessWire's installation directory. If "php" is not in your path, you'll have to type "/path/to/php index.php" instead, or add it to your path. Here's example output on my installation: As you can see above, I've got AgentTools, WireTests and an example "Hello World" CliModule showing the available command line options. If I want to execute one of the commands, then I just type what it indicates. For example, here I will run `php index.php test FieldtypeText` and here's the output: Here's a simple example of a CliModule: <?php namespace ProcessWire; class HelloWorldCli extends WireData implements Module, CliModule { public static function getModuleInfo() { return [ 'title' => 'Hello World CLI module', 'description' => 'Just an example', 'version' => 1, 'cli' => 'hello', // Example: php index.php hello ]; } public function executeCli(array $args) { $command = $args[0] ?? ''; $name = isset($args[1]) ? $args[1] : 'friend'; if($command === 'hi') { echo "Hello there $name!"; } else if($command === 'bye') { echo "Goodbye $name, see you later!"; } else { echo "Specify 'hi' or 'bye' optionally followed by a name"; } } public function getCliCommands() { return [ 'hi' => 'Say hello', 'bye' => 'Say goodbye', ]; } } For more details on the CliModule format, see wire/core/CliModule.php Improvements have continued with the AgentTools module. This week we added: New multi-model support: You can now configure multiple different agents in the module, and choose which one you'd like to use from the Engineer screen. Details New agent-memory support: Now when you make a request of the Engineer, it remembers it for follow-up questions and changes. It keeps a conversation history for context of what you are working on. Details New support for subagents: This enables any of the agents to launch additional agents when/where it helps to do so. For instance, specialist agents, or lower cost agents for simple jobs, and who knows what else. Claude requested the feature and also implemented it, so I'll be interested to see how it gets used. Details New agents configuration screen where you can define up to 10 agents (that's plenty, right?). Details Also new this week is a new WireTests module testing suite for ProcessWire. This first version focuses on testing all of ProcessWire's Fieldtype modules (including a few ProFields ones as well), but it's easy to add tests for any kind of module type. So we'll be adding more tests and improving existing tests as this module moves forward. For details head on over to: WireTests Thanks for reading and have a great weekend!

@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. 🙂

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

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.

Hi all, a small confession from the frameless corner of the PW universe: in the last 15 years we've spent way too many evenings doing the same FTP-shuffle on shared hosting. Delete everything in site/, drop the DB via phpMyAdmin, re-upload, run install.php, log back in, find out the bug we were chasing only reproduces after a reset, sigh, repeat. The reason we do this on real hosting at all is that the gnarly bugs in modules-under-development never show up locally — AllowOverride, mixed file ownership, mod_security, you know the drill. But "let's test cleanly on the real server" and "no SSH access" don't combine well. So we built ProcessWireReset: a module that wipes a PW install back to clean profile state from inside the admin. No SSH, no FTP, no phpMyAdmin. Click the button, log back in, you're at a freshly installed PW with your superuser intact and any modules you marked as keep re-installed automatically. A few things worth knowing, since destructive modules deserve some care: Modules to keep + Directories to keep. Two fields in the config: one picks which modules survive (transitive dependencies included), the other is a free-form list of paths under site/ that should be spared by the cleanup — handy for things like templates/RockIcons or assets/backups that live outside the module directories. Custom tables go into a snapshot. After the reset you can pick which module-specific tables to restore. Auto-restoring everything turned out to fight with re-installed schemas more often than we liked. The reset can crash mid-way — a kept module's install() can fatal in surprising ways. The confirmation modal hands you a one-time recovery URL with a 256-bit token. If the worst happens, that URL gives you a clean reinstall with your original credentials. Belt, braces, and one extra strap. It's interactive only. No cron triggers, no CI hooks. The destructive button has a real human in front of it, on purpose. Pairs nicely with GitSync: If you're already using our GitSync module, ProcessWireReset is the missing other half. GitSync pulls a fresh module version from your GitHub repo into the live install at the click of a button — but it doesn't touch the DB or re-run install(). After a GitSync pull that changed schemas, fields, or admin pages, the previous install state and the new code drift apart. Hit Reset, the module is removed and re-installed cleanly from the freshly pulled code, and you're testing what you actually shipped instead of a frankenstein of old DB state and new files. That GitSync → Reset → test loop is what we use daily on shared-hosting test installs where SSH isn't an option. Repo (MIT): https://github.com/frameless-at/ProcessWireReset Modules Directory: https://processwire.com/modules/process-wire-reset Caveat the obvious: this thing is for development, not for production. Treat it accordingly. Curious to hear what you build/break with it. Bug reports and pull requests welcome. Cheers, Mike

Hi everyone, I’ve released a new module: ProcessLegalDocs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs ProcessLegalDocs generates legal documents directly from the ProcessWire admin, including: Privacy Policy Terms of Use Cookie Policy Data Processing Agreement CCPA Notice Refund Policy Disclaimer It currently supports 93 jurisdictions and 44 languages, with jurisdiction-aware language selection and document requirements. This is also the first module built on top of my new Context module: https://github.com/mxmsmnv/Context Context acts as the AI/site-analysis base layer. ProcessLegalDocs uses it to understand the site structure, installed modules, fields, pages, and configured AI gateway, then uses that context to generate more relevant legal documents. The module can still work without Context, but in that case it falls back to more generic templates. For best results, Context should be installed and configured with AI. Main features: Generates Markdown legal documents with YAML frontmatter Stores files in /site/assets/legal/ Includes dashboard, preview, download, validation, regenerate, delete, and ZIP export actions Supports many privacy/data protection regimes, including GDPR, UK GDPR, CCPA/CPRA, COPPA, PIPEDA, LGPD, APPI, PIPL, DPDP, PDPA variants, and many US state privacy laws Includes settings for owner/company data, DPO, business audience, data categories, processors, analytics, payments, email/marketing tools, cookies, refunds, subscriptions, review status, and optional ProcessWire page publishing Uses ProcessWire admin UI conventions / AdminThemeUikit Requirements: ProcessWire >= 3.0.255 PHP >= 8.3 Context module optional, but recommended for AI generation Let’s take a look at the module interface: Install: Clone into /site/modules/ProcessLegalDocs/ Refresh modules Install ProcessLegalDocs Open Setup → Legal Docs GitHub: https://github.com/mxmsmnv/ProcessLegalDocs Context module: https://github.com/mxmsmnv/Context This is an early release, so feedback, testing, issue reports, and ideas are very welcome.

Hey everyone, MediaHub v1.17.0 is now available and introduces Focus Point support, SVG uploads, Input Field UI enhancements, and improved KONKAT compatibility. Existing customers: visit your account downloads area. New to MediaHub?: visit my in-progress landing page Full changelog: https://www.peterknight.digital/docs/mediahub/v1/changelog/ Release blog post https://www.peterknight.digital/blog/posts/mediahub-1-17-release/ Happy to answer questions here, but in the meantime, here are some screenshots. Focus Point support and focus point aware cropping. In the crop editor, you can now set and change the Focus point target.... As you might expect, crop presets and auto-generated crops snap to the focus point... SVG support Also in 1.17, driven by a request from @Stefanowitsch: SVG support for logos, icons, and illustrations that need to scale cleanly. SVG uploads are off by default. Enable them under Modules → Configure → MediaHub in the new SVG Support section. When turned on, uploads require the native ProcessWire FileValidatorSvgSanitizer module. If the sanitiser isn’t installed, uploads are refused rather than letting an unsanitised file through. InputField UI polishes Detail view is meant to show more per card, but the layout felt cluttered. Detail-mode cards now use a cleaner layout with a Crop · Focus · Edit action strip and inline file metadata. More to come on that front. It's somewhat based on the native Input Field view, but with a few tweaks. Konkat Theme If you run the ProcessWire KONKAT light admin theme, 1.17 includes improved compatibility across MediaHub’s admin screens. The asset detail page gets a cleaner card layout, a Modified column in the Crops table, and usage-aware delete confirmations (not shown) IE MediaHub warns you before deleting an asset or crop that’s still referenced elsewhere. Next up, as promised, I am working on improved support for batch operations, such as bulk upload and getRaw() support for massive libraries. Thans for reading. If you like what you see, I hope you can make MediaHub part of your next ProcessWire project 🙂 P

You won't believe how these changes make my day(s) now! Moving away from ProcessWire to NextJS/AstroJS/HonoJs/WhateverJS just to be able to prove a concept and go live within a super short time using AI/LLMs/Agents was hard but I got things done. I was able to test things, to experiment, to explore, to fail, to succeed. Well... now ProcessWire is back. Back in my preferred stack of tools. Back on #1. I've already moved 2 big projects back from HonoJS and NextJS to ProcessWire. The RSS Monitoring Tool and another one. Cloudflare Workers and Vercel were great hosts with pretty awesome free tiers, yet... at some point I scratched limits big time. Now everything is hosted on H*stinger for a few dollars a month with full CI/CD pipeline, no limits on reads/writes to the database, just a 5GB size limit per database and some other weird limits those projects will never reach. It's unbelievable how fast things turned around and back to a language (PHP) I actually can read and understand and a framework I kind of know how to work with.

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’m happy to share NativeAnalytics, a native first-party analytics module for ProcessWire. The module is now available in the ProcessWire modules directory: https://processwire.com/modules/native-analytics/ NativeAnalytics provides a useful analytics dashboard directly inside the ProcessWire admin, without relying on external analytics platforms, third-party scripts or external APIs. All analytics data is stored locally in your ProcessWire installation, which makes it a good fit for projects where you want a simpler, more self-contained analytics solution. The module currently tracks and displays: page views unique visitors sessions current visitors top pages referrers devices and browsers 404 hits engagement events such as form submits, downloads, tel/mail clicks, outbound clicks and custom CTA events It also includes: charts and trend views comparison between periods custom date range filtering page-level analytics inside the page edit screen optional monthly email reports optional PDF report attachments exports to CSV, PDF and DOCX helper examples and a small snippet generator for custom event tracking There are also several privacy and consent-related options: optional cookie-less visitor/session mode consent-based tracking helper functions for custom consent integrations optional PrivacyWire localStorage consent helper support cleaner behaviour when global tracking is disabled The reason I built this module was that I wanted something that feels natural inside ProcessWire itself, instead of embedding another analytics service into the admin. For many sites, it can be useful to have core traffic and engagement data available right where content is managed. ! If you tested one of the earlier development versions named PW Native Analytics, I recommend uninstalling that old test version first and installing NativeAnalytics as a fresh module, because the module name and structure changed during development. Multi-site analytics is not included yet, but it is something I am looking into. It would need proper per-site separation in the stored analytics data, so I want to approach that carefully rather than adding a quick workaround. Feedback, bug reports and suggestions are very welcome. Get it here: https://processwire.com/modules/native-analytics/ Enjoy!

Hey everyone I'm pleased to report that MediaHub 1.16.0 has been released. Here's a breakdown of the changes. The next release will optimise bulk upload and crops. I will also add integrated focus points cropping. 1.16.0 Changelog Admin navigation Optional MediaHub link in the admin top bar. A new module setting (Show MediaHub link in main navigation) adds Media Hub to the admin top bar. Custom label for the top-bar link. When the top-nav option is on, a new Custom label field lets you override what appears in the top bar. Useful when the localised "Media Hub" string is verbose or when your team prefers a different term (Media, Assets, Library, DAM). Leave blank to keep the localised default. Setup → Media Hub label is unaffected. Library and inputfield Drag-to-reorder thumbnails in MediaHub fields. Just like the native InputField, you can reorder thumbnails to take advantage of first() and last() etc. Works across any view mode (grid, proportional, detail). Master "select all visible" checkbox in the table view header. Tick the column header to select every row currently rendered; untick to clear. "Add more" button now matches stock InputfieldFile Font, colour, hover state, and icon spacing across AdminThemeUikit, Reno, and Default are more consistent Bug fixes Library search now covers Alt/Description, Labels, and Collections. Previously search only matched the asset title and filename. Searching by exact ID is also now reliable. Renamed filename and title in the upload queue are now applied on upload. Editing the filename stem or title in the upload queue rows had no effect; the values were not transmitted to the server. Both fields are now picked up and saved with the new asset. Duplicating an asset preserves its Collections and Labels. Cloned assets were losing the page-reference fields. Both are now copied explicitly to the new asset. The duplicate confirmation message also clarifies that crops are not copied (they can be re-generated on the duplicate). Cleaned up a stray PHP warning in the library view left over from the v1.15.0 Tags → Labels rename. PHP 8.5 deprecation notice in the MediaHub inputfield resolved (explicit nullable parameter typing). Defensive changes Server-side upload batch limit now matches the configured browser-side limit. Previously the server hard-capped to 50 files per request even if Maximum upload batch had been raised higher; both ends now read the same setting. Bulk-import requests are now capped at 500 selections per request. Selecting thousands of existing site images at once was holding a single PHP request open for many minutes with no progress feedback and no resume path on failure. Larger jobs now surface a clear message asking you to import in batches. Upload temp-file cleanup window extended from 60 seconds to 5 minutes, to avoid deleting an in-flight temp file mid-write on slow connections. Container pages at the site root reinforced as hidden + system on upgrade, so the data-tree containers (Media Hub, Labels, Collections, Assets, Crops) cannot accidentally appear in front-end navigation. Security Import-by-URL is now safer on shared and self-hosted servers. Imports from external URLs are now hard-capped at 5 MB per file and refuse URLs that resolve to private or reserved IP ranges (mitigating server-side request forgery), and reject any non-HTTP(S) protocol on the initial request and on any redirect. Cheers Peter

@wbmnfktr Thanks! This is great to hear, this kind of feedback makes my day. 🙂

This will retire my whole set of ProcessWire skills... and I love it! I really enjoy the pace and direction you, @ryan, and ProcessWire are going now. Let alone AgentTools in a fresh installation of ProcessWire does some magic with LLMs (from super cheap Mistral, Deepseek, to great models like Kimi 2.6, MiniMax 2.6, and to Opus 4.6/7 and Codex 5.4/5) which was NOT possible in that way 6 weeks ago. 🥰

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

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.

Hi everyone I've started a new module called SEO NEO It's a new SEO module built for today's SEO, on today's ProcessWire. I hadn’t planned another module, but I keep returning to the same niggling thought: SEO is too important to our clients' sites (and businesses) to depend on modules that are not being actively developed keeping pace with how SEO works today. So that's pretty much it. SEO NEO will be free. An Ultra/Pro version will follow and include genuinely useful additions for industry professionals. I'll have more soon, but if you have any SEO requests, my DMs are open. Cheers Peter

Working with AI in PageGrid Inspired by projects like AgentTools, I began investigating how well an AI could handle PageGrid’s native PW structure (Pages, Templates, and Fields). The results were surprisingly good and with a few targeted optimizations, the workflow has become remarkably solid. With the latest updates, an AI agent is reliably able to create and design PageGrid layouts, create new block templates, or perform content updates. To teach AI how to "speak PageGrid", I created a small AGENTS.md file that acts as a central hub. I’ve then added specific "skills" in separate .md files for various tasks ensuring the AI only loads the documentation it actually needs. This approach is highly optimized to minimize token consumption, allowing even "smaller" models like GPT-4o mini or Claude Haiku to produce error-free migrations. To make this possible, I also introduced dedicated Migration Functions that allow the AI to programmatically add items or set styles. For CLI-based projects, I highly recommend the AgentTools Module to streamline the integration. Beyond CLI support, AgentTools also provides a native AI interface directly within the ProcessWire backend editor. Getting Started Install the lastest version of the FieldtypePageGrid module (try for free). Tell your AI agent to read the PageGrid agent guide first: That file gives the agent everything it needs to understand PageGrid and routes it to the right documentation for your task. What You Can Ask the AI to Do Build or modify a layout Create pages with blocks, apply styles, set up responsive layouts using CSS grid columns. Example prompts: "Create a landing page with a full-width hero section and a 3-column feature grid below it." "Add a text block and an image block side by side inside the first group on my homepage." "Make the hero block have a dark background and white text, with 60px padding on desktop and 24px on mobile." The core advantage here is that the AI doesn't write your frontend code from scratch. The HTML and logic are already defined in your PageGrid Block Templates. The AI simply acts as an orchestrator, assembling these blocks and applying styles. This ensures the output remains clean, semantic, and easy to maintain via drag-and-drop later on. Create a custom block template Define a new block type with custom fields and register it with a PageGrid field. Example prompts: "Create a custom block called pg_testimonial with a quote text field and an author name field." "Create a custom card block with a title, description, and link field, and add it to my homepage PageGrid field." Write a site template Render a PageGrid field inside your own PHP template file. Example prompts: "Show me how to render my PageGrid field inside my home.php template using markup regions." "Generate a site template for pagegrid-page that includes the PageGrid output between the header and footer." Docs Documentaion

Reading through the commits log is like never before. I guess we are going to have a lot of cool stuff we were waiting for happening soon.

Hi everyone, Built this for a financial news site that needed live stock quotes embedded inline in editorial content. Drop a ticker into any text field and it renders as a live badge with price, change, and direction - clicking opens a full detail popup. GitHub: https://github.com/mxmsmnv/Stocks What it does: Live price badges - ticker, price, change amount/%, direction arrow; click opens a popup with open/high/low, 52-week range, P/E, volume, market state Three data providers - Yahoo Finance (free, no key needed), Finnhub, Alpha Vantage TextFormatter with three parse modes: Explicit [stock:AAPL] tags Cashtag/hashtag - $AAPL, #TSLA Auto-detection by company name and aliases in text Company Manager - tracked companies with names, aliases, enable/disable toggles, bulk CSV import Four CSS frameworks - Vanilla CSS (built-in), Tailwind, Bootstrap 5, UIkit 3; auto-detected or manually set File-based cache with configurable TTL and per-ticker clear from admin Circuit breaker - pauses API calls after repeated failures, serves stale cache with ~ marker Custom provider API - add any data source by extending StocksProviderBase $stocks = $modules->get('Stocks'); echo $stocks->renderBadge('AAPL'); echo $stocks->renderBadgeAs('TSLA', 'bootstrap'); Requirements: ProcessWire 3.0+, PHP 8.2+ MIT License.

Yes, I know it well — great Dashboard module! I've used it on almost every project to keep the admin from feeling bare. But as projects grew, I kept hitting the same wall: customizing Dashboard meant writing PHP for each install, and the widget lists got unwieldy. Start (and its companion module Collections) came out of that frustration — the goal was a fully visual, no-code editor where you just drag, drop, and pick icons without touching any config files.

Got my vote. I've implemented https://github.com/php-enqueue in a couple projects. @ryan Nice to se the Cli interface, just wanted to give a heads up of wire-cli and rockshell. These have been around from quite a while, something could be inspired from these libraries or maybe pick up from the current state of the libraries to work on things like scheduling/queue/agenttools

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

Wow. These "ProcessWire as a web application framework"-type updates are coming in strong! Migrations, CLI, Tests, AI. One can wish for a maybe first party queue system too. 😄

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/

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.

With all of the advancements in AI, and other technologies not slowing down, it's getting even harder to feel like I'm staying relevant. Add to that the pressure to exercise and stay fit, work outside or around the home, and to be sure to retain some amount of leisure... How do you all do it? I see my gaming buddy logging hours of a video game. He works in defensive cybersecurity, so he makes quite a bit and is on-call. Thankfully for him, he works remote (I do not). But he has a family with tweeny triplets (!). He's just this past week mentioned ripping up carpet, last week he ran a trench to run electrical for a man-made pond he's installed with boulders that he moved by hand. Meanwhile I want to learn about n8n, take some AI courses (someone mentioned faster.dev here in the forums), work on personal (dev) projects, but also get things done around the house, and make sure to spend time with the girlfriend and make sure she's happy. I have not figured out a good time management scenario to balance these all out: House/property work. Friends and family time. Leisure time. Exerciise Paid work (job / income). Professional improvement and advancement. What are your tricks, or boundaries, to set time aside for each of these? Are you struggling like I am to properly afford time to each thing and not allow them to thoroughly overtake another's time commitment? Looking for revelations that some of you may have had during your careers or lifetimes to help you sort these things out! 🙃

NativeAnalytics v1.0.19 – update This release mainly focuses on privacy/consent handling and admin UI polishing. Added / improved: Added optional cookie-less visitor/session mode for sites that want to avoid browser visitor/session cookies. Added PrivacyWire localStorage consent helper support. Added helper methods for custom consent integrations: window.PWNA.trackIfConsented() window.PWNA.setConsent() window.PWNA.clearConsent() window.PWNA.syncPrivacyWireConsent() Improved consent-based tracking flow, so tracking can start correctly after consent is granted. Tracking-related settings are now hidden/disabled when global tracking is turned off, to avoid confusing combinations like “tracking off + event tracking on”. Added a module settings shortcut button in the analytics dashboard header. Improved AdminTheme compatibility and tab spacing across ProcessWire admin themes. Polished the flat admin UI and removed rounded corners. Fixed panel alignment issues in dashboard grid layouts, especially where side-by-side panels appeared vertically offset. Note: Multi-site analytics is not included yet. It is planned as a possible future improvement because it needs proper per-site separation in stored analytics data. Download is updated in first post!

Hi Mikel and SEO specialist Thanks for taking so much time to list your thoughts. I completely agree, and it's a testament to both SEO Modules and ProcessWire itself that they have worked together for so long. I hope my original post doesn't come across as a criticism of either Module or the developers. Life moves on, and understandably, the developers have new priorities. Yes, agree too. And I don't intend to recreate existing Modules simply for the sake of it. But I also want SEO Neo to rely on other modules as little as possible. So it's likely that SEO Neo will act as an umbrella/coordinating layer for companion Modules. All working together. It's an ambitious task, but I would prefer to build from the ground up with modular components (sub-modules) that can work together rather than end up with a Module which relies on various "3rd party" modules. I realise this somewhat contradicts my earlier statement. But to answer your specific points: SEO health (missing descriptions, duplicate titles, noindex flags) as a Lister-based audit view – this genuinely doesn't exist in the ecosystem yet Yes, this is on the roadmap and has been on my mind for some time. The module should have an SEO health dashboard that can display the basic rolled-up audit of your site. I use SEM Rush extensively (alongside several other SEO tools). SEO Neo won't try to replace them, but will surface critical issues within PW itself. I see this as a big benefit to SEO specialists, developers and editors, even if it serves as a launch pad for deeper investigation via more powerful SEO tools. 404 hotspots from the logger with a "create redirect" action wired into ProcessRedirects Yes, this is being developed currently with a focus on 404 logging. AI crawler activity from Wire Request Blocker Have added to the roadmap. SeoMaestro field status across templates SEO Neo will have a field status overview if that's what you mean? It won't report on other SEO modules' gaps. Native urlSegments support – as psy mentioned earlier in the thread, currently needs a hook in SeoMaestro urlSegments is done and working since my last post. I am stress testing on a larger site shortly. Canonical, og:url, twitter:url and hreflang all preserve $input->urlSegmentStr() natively. I also have a config setting for sites that want segments collapsed instead. The hook needed for SeoMaestro isn't required in SEO Neo. Yoast-style content analysis with traffic-light scoring – tends to produce text optimized for the algorithm rather than the reader. I am keen for SEO Neo not to become a Yoast copy. Schema.org helpers with documented hooks – ready-made generators for the common types (Article, FAQPage, Person, Organization, BreadcrumbList) that developers can call from templates. Not auto-detection (that doesn't work without explicit mapping), but a clean API. Noted. Finally, the rollout of SEO Neo's core module and individual components will likely be phases. The Neo in SEO Neo is more a nod to a new approach rather than Nearly Everything at Once. P

ProcessWire is more alive than ever.

Hi @ryan there are a lot of modules I was working on. I began creating them even before the company project itself got underway (these are apps intended for internal use), anticipating what I would need based on the initial requirements and my prior experience with ProcessWire projects. I wanted to avoid conflating module development with the development of the core application itself. That said, this meant I was able to test some of the modules incrementally, as the need arose; however, a significant portion of the project remains to be completed, and there are other modules—on which I performed only limited initial testing—that I haven't actually put into use yet. In fact, they could be considered by the community as proofs of concept, given that I am not strictly a "professional" developer; I'm a graphic designer, and my role within the company is as Webmaster. Nevertheless—thanks to ProcessWire's ease of use—I have spent years implementing tools that assist the various departments in their daily operations. All these modules were built around a philosophy of "Simple": they get straight to the point regarding my specific needs, though I am not sure whether they would prove useful to others. I have never worked with Git or a version control system, nor have I ever published modules before, so I have no idea what the best way to proceed would be; if you could offer me any guidance, I would be very grateful.

Hi, team. Lately, Claude and I 😁have been working on a series of modules for a new project at my company. This set includes a module for queue management. They aren't finished or ready for production yet; in fact, I’ve had few opportunities to test some of them, as I haven't reached those specific stages of the project yet. With these implementations, I’m not aiming to create anything overly complex—after all, there are already plenty of libraries available for that purpose. The idea is for them to be easy to use, free of external dependencies, and equipped with the basic functionality required for the tasks at hand—always adhering to the language and philosophy of ProcessWire. Would you be interested in having me upload some of them to GitHub for a look?

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

This resonates. 20 years in development, still figuring it out honestly. Current reality: Day job 6 days/week, building PW modules in spare time. Not balanced, but intentional - grinding now to create options later. What actually helps: - Seasons, not balance - some months are 80% work, others need to be 80% recovery - Combine categories - coding for fun = leisure + professional growth - One rule: protect sleep and one full day off. Everything else is negotiable - Physical maintenance - injuries taught me this the hard way The AI/tech pressure to "stay relevant" is real, but burnout is worse. Better to have 3 solid productive hours than 8 exhausted ones. What's working for you so far?

Not yet — currently it renders as a single top-level link. A dropdown listing all collections on hover is a reasonable UX improvement and I'll add it to the roadmap. The main challenge is that collections lists can get long, so it'll need some thought around grouping or truncation.

Hey everyone! I'd like to share Start - a module that replaces the default ProcessWire admin home screen with a configurable personal dashboard. The problem it solves As your ProcessWire install grows, the Setup menu gets long - on smaller screens it overflows and you end up scrolling just to reach the tools you use every day. Start is the fix: think of it as the Windows Start button for your PW admin. Pin exactly what you need - modules, pages, whatever - and get to it in one click from the home screen. The result Features Two view modes - list and icon grid, preference saved per-browser Visual drag-and-drop editor at /setup/start/edit/ - reorder groups and links without page reloads Font Awesome 6 icons - 1887 icons with a searchable popup picker PagePicker - browse the full page tree directly from the URL field Example button - auto-populates with your installed Process modules and their FA icons Widget on the default admin home page Access control via start-dashboard permission Fully translated editor UI — 20 languages including RTL support for Hebrew and Arabic Supported languages English, Russian, German, French, Spanish, Polish, Ukrainian, Italian, Dutch, Portuguese, Chinese, Japanese, Turkish, Czech, Finnish, Korean, Hindi, Hebrew, Arabic, Hungarian. Installation Install like any other module — upload or place in /site/modules/, then install via Modules → Refresh. A Start item will appear under Setup in the admin menu. Make Start your admin home screen (optional) By default Start lives under Setup. To make it open whenever you click the admin logo or navigate to /admin/: Go to Pages in the admin menu Find the Admin page and click Edit In the Process field, select Start from the dropdown Save Links GitHub: https://github.com/mxmsmnv/Start

Six months ago when Ryan was posting once a week, I thought the project was slowing down. Really glad to see the pace pick up! ProcessWire's architecture was always ahead of its time — there's legacy code built up in layers, sure, but the direction now is exciting and hard to keep up with 😄

Super happy with the energy revival of Processwire and the speed at which everything is moving. I feel like moving from a hobbyist to a PRO! This week did my first Claude Design, which I then passed onto Claude Code, with an amazingly simple and smooth workflow. For people into Claude who haven't tried this workflow, please check it out.

There is nothing good about imperial 😜

Hi Ryan, I'll do my best to explain this, but keep in mind my experience with queues / background jobs is only 2 years old. But in short, inspiration would be best taken from the classic, "batteries included" big web application frameworks like Laravel (as Teppo pointed out) and Rails. I like the Laravel page I linked because it gets very in-depth (I've read that page at least 10 times). Let's use a classic example like this: Let's say someone wants to upload a video to a field and we want it to be converted to a different file format (let's say that's being handled by ffmpeg). That's a time intensive task that wouldn't be able to be done within a standard max limit 30 second web request, or even with the memory available to php via php-fpm. It might take minutes or even hours, and even then, things can go wrong and it might fail. So, instead we'd want this to happen independent of the web request, therefore a background job dedicated to that task would have to be made and scheduled to be processed. It could happen immediately, or maybe it can be scheduled for 30 minutes later. This is not related to cron jobs which are a different concept. (Another example is for example in an ecommerce checkout; it's generally better practice to send the order notification email as a background job instead of inline with the code that processes the order after it's submitted). With that, queue systems are typically powered by a different dedicated database or system, with Redis being a popular choice. The reason for this is to limit load on the primary database; many large systems may have millions of jobs per day so offloading that to a separate database saves resources. However the big web application frameworks I mentioned also allow the option for the main database itself to store the jobs (Rails enabled this in Nov 2024), which is typically fast enough and probably good enough for a ProcessWire-based solution. You then have workers which act on the jobs. You can define there to be one or multiple workers. Let's say you have a powerful server and want to transcode multiple videos at a time, then having multiple workers would allow more jobs to be done in parallel and take advantage of your system resources. Obviously you don't want a worker to act on a job more than once, or two different workers to act on the same job. So this gets into jobs have statuses, being locked, and avoiding race conditions. The Laravel documentation gets into all of that, but I think reading up on queues/background jobs/workers and experimenting with it would be tremendously helpful. In regards to my print-on-demand system, I'm not using a queue system as I described above and I did experiment with WireQueue and IftRunner a while ago, but it didn't really... fit? It was a while ago and I was still wrapping my head around queues; also I came to realize that what I needed was even deeper than that (ie, durable workflows, but that's unrelated to what we're talking about here). I eventually put something together that relies on "fake" jobs using cron jobs and progressing through a durable workflow; it's not the most efficient way to do it, but I got it working. I've been meaning to rewrite that part of the system one day and having a native / first-party queue system (which dovetails with the CLI commands), would be the best approach.

@Roych thanks! This is a really nice and clean module that integrates straight into the backend. I just installed it on a client site and its already filling with interesting data. @ai_slop I was able to make this module work together with PrivacyWire since I am inside the EU. If consent is chosen the cookie is set and the module activates.

Hi everyone, in particular @ryan @Peter Knight@ukyo @gebeer @maximus who seem to have been most AI active lately. I've just added dai() and bdai() dumping calls so that objects and arrays are rendered in plain text format more friendly to LLMs, but I am curious what AI/LLM integration features you think would be most useful? Claude suggested an MCP server - here is its plan. Does this sound useful? Any other ideas? Two processes, loosely coupled: ┌──────────────────┐ ┌──────────────────────────┐ │ Claude / Cursor │ stdio MCP │ TracyDebugger site │ │ client │ ─────────────────► │ │ │ │ HTTP + token │ tracy-ai/* endpoints │ └──────────────────┘ ◄───────────────── └──────────────────────────┘ MCP server — a tiny program the agent launches over stdio (the MCP transport). Ships as a sibling module (TracyDebuggerMCP/) or a standalone npm package the user npx's. TracyDebugger HTTP endpoints — new authenticated tracy-ai/* routes inside the ProcessWire site. The MCP server is just a thin translator between MCP tool calls and these HTTP requests. The MCP server holds no site logic. It's a dumb adapter. All the real work (reading panels, redacting secrets, rendering plaintext) stays inside TracyDebugger where the ProcessWire API is available. What the agent sees A handful of tools in the MCP catalog: tracy_export_bundle(preset: "debug" | "performance" | "template" | "full") tracy_get_request_info() tracy_get_last_errors(limit: int = 10) tracy_get_slow_queries(limit: int = 10) tracy_get_template_schema(template: string) tracy_list_dumps() tracy_run_console(code: string) ← gated, opt-in only Every tool returns the scrubbed plaintext/JSON produced by AIExport — same output Phase 2's "Copy" button produces. Config on the site New module-config section: aiExportHTTPEndpointEnabled (default off) aiExportMCPToken — a random token generated once per site, shown to the user to paste into their MCP client config aiExportAllowConsoleExec (default off) — gates tracy_run_console aiExportAllowedIPs — optional whitelist Config on the client User's ~/.config/claude/mcp.json or equivalent: json { "mcpServers": { "tracy": { "command": "npx", "args": ["-y", "tracy-mcp"], "env": { "TRACY_URL": "https://mysite.test", "TRACY_TOKEN": "<paste token from module config>" } } } } The agent launches the MCP server locally; the MCP server talks to the site over HTTPS with the token. Auth Per-site token (generated in module config, rotateable). Token sent as Authorization: Bearer … header on every HTTP call. Optional IP whitelist on the site side. tracy_run_console additionally requires aiExportAllowConsoleExec=true — otherwise the MCP server gets a 403 and reports "console execution disabled for this site" to the agent. Example flow — agent debugging an error User in Claude: "Why is /about/team throwing a 500?" Agent: Calls tracy_export_bundle(preset: "debug"). MCP server hits GET https://mysite.test/tracy-ai/export?bundle=debug with the bearer token. Site responds with scrubbed JSON: request info, PW info, last error with stack, slow queries, recent PW logs. Agent reads the traceback, sees TemplateFile.php:123 Undefined index "featured_image", asks tracy_get_template_schema(template: "team"). Site responds with the template's fields — no featured_image field exists. Agent suggests the fix, possibly calls tracy_run_console (if enabled) to verify. No human pasting. Agent pulls what it needs on demand, scoped by the tool it calls. What ships where In TracyDebugger itself: the tracy-ai/* HTTP endpoints + auth + token config + AIExport (already built in Phase 1, extended in Phase 2). In the MCP server (separate repo, ~200 lines): tool definitions, HTTP calls, response shaping for MCP. This separation matters because the MCP server can be installed independently of the site, and the site is still useful without it (you can hit tracy-ai/export with curl directly). Footprint on production Zero unless you explicitly enable it. The endpoints, token, and MCP config are all opt-in behind module settings. That's the shape. The main design choices worth confirming before building: Token-only auth, or also require the existing Tracy access? — i.e., should the agent's token have to belong to an allowed Tracy dev user, or is a separate machine token fine? I'd lean separate machine token for agents; reusing session auth is awkward over stdio. Read-only by default? — I strongly recommend yes. tracy_run_console is the only write path and should be a separate opt-in. Does the MCP server live in this repo or a separate repo? — I'd say separate. Different language, different release cadence, and the site works without it.

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