Leaderboard

There has been a lot of ProcessWire work covered this week! Here's a summary: 1. AgentTools module has been upgraded with "Site Engineer", an AI agent now built into your admin, and you can ask it questions, create migrations, or have it make other web development updates to your site by going to Setup > Agent Tools > Engineer. To enable the Engineer, you need an Anthropic API key, an OpenAI API key, or an OpenAI compatible API key (apparently several others use the OpenAI key standard). You can optionally put Engineer in "read-only" mode, which is what I do for production sites. In read-only mode, it answers questions and provides you with code for making updates yourself. But if read-only mode is not enabled, then it can act as your web developer and make changes directly, which is what I use with development sites. AgentTools provides full context to Engineer on your site's pages, fields and templates. If using ProcessWire 3.0.258 (or newer) it also provides the new API.md files to help AI know how to best work with all of ProcessWire's Fieldtypes. If you are having Engineer create or manipulate Fields on your site, it's a good idea to have 3.0.258 for the API.md support. Engineer also supports prompt caching for up to 1 hour in order to limit token usage. 2. The AgentTools now has JSON site-map generation features for AI agents. This enables an AI agent to see the full scope of your site. A second site-map feature focuses on all your site's templates and fields, essentially providing the full site schema to the AI agent. 3. In the core, we've added API.md files for all 18 of ProcessWire's core Fieldtypes, except for the comments and cache Fieldtypes, so far. In order to facilitiate this, and to facilitiate AI agent accessibility, all of ProcessWire's Fieldtypes now have their own directories as well. 4. After looking at all the API.md files, it became clear that there was plenty of room for improvement in the APIs of several Fieldtypes, so there have been major core updates to several Fieldtypes, as well as the Fields, Templates and Fieldgroups classes. 5. A Fieldtype testing framework has been built, which tests the full scope of 20 ProcessWire Fieldtypes (all the core ones, plus FieldtypeRepeaterMatrix and FieldtypeTable). It tests field creation, manipulation, traversal (where applicable), sorting (where applicable), searching with selectors, and more. I'll be uploading the testing framework to GitHub soon as well. 6. The new testing framework identified some bugs, which have been fixed. Most notable were selector matching bugs in FieldtypeFloat and FieldtypeDatetime. 7. There has been some refactoring in ProFields FieldtypeRepeaterMatrix and FieldtypeTable, plus API.md files have been generated for both. New versions should be ready soon. In fact, that applies to all of the ProFields, and I hope to cover FieldtypeCombo and FieldtypeCustom next week. 8. ProcessWire 3.0.258 has a whole lot of improvements, changes and fixes in it. Here's the commit log: https://github.com/processwire/processwire/commits/dev/ 9. Back to working on PagesVersionsPro (and have been for a few weeks) but more on that later. 10. There's probably more, but that's all I can remember at the moment. 🙂 Thanks for reading and have a great weekend! Basic examples of using Engineer for migrations:

Welcome to the dedicated MediaHub community support and discussion forum. Big thanks to @ryan for setting this up. Really appreciate it! 🙏 This will be the main home for MediaHub support, discussion, feature requests, and general chat. If you have a question, spotted a bug, or simply want to share how you're using it, please post here. I hope that it'll help build up a searchable knowledge base for everyone. Other ways to get support: Private email (for anything sensitive or account-specific) GitHub issues (coming soon - dedicated repo for confirmed bugs and feature requests you'd like tracked) Looking forward to the conversations ahead. And thanks to everyone who's been testing and giving feedback so far.

Very interesting module, thank you @ryan. 🙂 Would it be possible to support API keys from OpenRouter? We use OpenRouter to switch between many models. Regards, Andreas

Hi guys, I've been working on a full EditorJS integration for ProcessWire and it's reached a point where I'd like to share it and get some testing feedback before calling it stable. GitHub: https://github.com/mxmsmnv/FieldtypeRapid This is a development preview. The core functionality works, but I'm looking for testers on different server configurations and ProcessWire setups before a stable release. Please report issues on GitHub. Why EditorJS instead of CKEditor or TinyMCE? CKEditor and TinyMCE are document editors — they produce a single blob of HTML. That HTML is hard to restructure, style consistently, or repurpose for different output targets (web, mobile, PDF, API). EditorJS is a block-based editor. Every paragraph, heading, image, and quote is a separate JSON object with a type and structured data. This means: Content is stored as clean JSON, not tangled HTML Each block type can be rendered differently per context Easy to add, reorder, or remove blocks without breaking surrounding content Output is fully controlled server-side via PHP renderers — no frontend JS required It's closer in concept to Notion or Gutenberg than to a traditional WYSIWYG. What Rapid does: 17 block types: paragraph, header (h1–h6 with auto anchor IDs), quote, nested lists, table, code, delimiter, warning, checklist, raw HTML, image (WebP convert + resize), file attachments, YouTube/Vimeo embed, alert (8 color variants), toggle/accordion, link preview with OG metadata Inline tools: bold, italic, underline, inline code, marker, link Template API: echo $page->body; // render all blocks echo $page->body->toText(); // plain text for meta/search echo $page->body->renderWith($renderer); // custom renderer 4 CSS frameworks — Vanilla, Tailwind, Bootstrap 5, UIkit 3 Frontend editing — inline editor on frontend for authorized users No build step needed — pre-built js/dist/editor.js included. Requirements: ProcessWire 3.0.200+, PHP 8.2+ Any feedback on installation, rendering edge cases, or block behaviour is welcome!

@ryan this is beyond amazing. It’s hard to put into words. Thank you!

Okay multi-model support is now ready and in the current posted version (v5) of AgentTools: Multi-model support — configure additional AI providers/models beyond the primary; each uses its own API key and endpoint Additional models textarea in module config accepts one model per line in pipe-separated format: model | api-key, model | api-key | endpoint, or model | api-key | endpoint | label; provider is auto-detected from the key prefix (sk-ant-* = Anthropic, all others = OpenAI-compatible); whitespace around pipes is optional; lines beginning with # are ignored Control room collapsible fieldset in the Engineer form with model selector and context options; auto-expands when non-default settings are saved Context selector radio in Control room: All (site maps + API docs), Custom (choose individual items), or None (no extra context, useful for general questions or token-limited providers) There's still about 2-3 hours left on the memory feature, which I don't have today, so that'll be in a day or two. If anyone wants a free AI tool (api key) to use with AgentTools, Groq ("groq" not "grok") seems to do fairly well with ProcessWire: https://console.groq.com/home -- note however that on the "Engineer" screen in AgentTools, you'll want to select "Extra content to include: None" because the free Groq doesn't not accept a lot of data in the submitted prompts. But it can still query your ProcessWire installation for all of that info, so it works just fine.

In Kilo Code there is this: You can set a model for each mode.

I like that idea, maybe a select/drop-down under the engineer prompt box where you can select the model to use? And we should be able to share memory between them too, once it's added.

What about being able to configure multiple models and then selecting the one for each specific task? Planning: Opus 4.x (or GLM 5.1, Kimi K2.5) Workload: MiniMax, Qwen, ... Most plans (I use) support Anthropic-, OpenAI-compatible, and custom endpoints. Right now we have Anthropic and OpenAI available (should cover 90% i guess).

Btw, one feature that wasn't quite ready this week for AgentTools was Engineer memory. Currently every prompt is like a new thread. But next week we'll enable memory, so that it has context of all your previous prompts.

Thanks Jonathan! I appreciate the kind words. I also feel like this is the beginning of the next era of ProcessWire, so much fun stuff lately on the way! Really cool project you are working on there! Also, I'm thrilled to see the AgentTools module working with another AI Agent. I've only been able to test with an Anthropic API key so far, so nice to see it's working well with Z.ai.

Holy... this feels like a bit of Christmas and Easter on the same day during summer holidays. Just plugged Z.AI GLM-5.1 into this and ... From the side notes:

@AndZyk OpenRouter is already supported. Here's how you'd configure it in the AgentTools module configuration (as an example): google/gemini-2.0-flash | sk-or-YOUR_KEY | https://openrouter.ai/api/v1 | Gemini via OpenRouter anthropic/claude-sonnet-4-6 | sk-or-YOUR_KEY | https://openrouter.ai/api/v1 | Claude via OpenRouter @HMCB Thanks! 🙂

Hey @Ivan Gretsky, that does sound like a potential bug, but I haven’t ran into it before and I know that I throw 404 exceptions from controllers time to time. I’ll try to do some testing too, but could you describe the context a bit; in what method / in what circumstances does this happen? Does it make any difference if you use wire404() instead of directly throwing 404?

So Canva seems to be shaping up to be a real challenge to Adobe in some ways after acquiring Affinity's design suite, and now Cavalry. I haven't tested Cavalry yet but I didn't think it had any web animation capabilities until I came across this beta web-player integration (?) Have any of you tried Cavalry? https://docs.cavalry.scenegroup.co/web-player/ It looks like it's available for free now. https://www.canva.com/newsroom/news/cavalry/

It's nice to see that there are more alternatives now. Maxon released Autograph for free too recently. Not sure how they are going to monetise though. https://www.maxon.net/en/autograph

Late to the thread, but wanted to add a real-world data point. I run a spirits/wine catalog (~12,000 products) and a chocolate e-commerce store on ProcessWire. Both are in production and both have maintenance contracts attached. What I've found: the "update treadmill" problem simply doesn't exist with PW. Core updates are rare and painless. Module updates — same. That frees up retainer hours for things clients actually care about: new filters, catalog improvements, performance work. My maintenance plans now look like this: Backups + uptime monitoring (minimal time, easy to automate) A fixed block of hours for small improvements, content ops, or feature requests Reduced hourly rate for anything beyond that block The key insight for recurring revenue: clients with active e-commerce always have a backlog of small improvements. The retainer becomes a comfortable way for them to drain that backlog without opening a new project each time. For simpler marketing sites, the retainer is lighter but still justified by the "someone is watching this" peace of mind. SEO and analytics reporting also fit naturally into retainers — especially if you're running something like Plausible and can send a monthly digest.

Ahh ok. So 150 million of it is cached and therefore not charged. Makes more sense.

Had to pull the raw data for each session to answer this, but overall about $30 based on their (Z.AI) API pricing and the current free cache hits. I paid around $120 for one year of their Pro plan in a Black Friday deal. That's even sweeter.

AgeWire has been updated — here's what's new since the original release. Multi-framework support The module now supports four CSS frameworks. You pick whichever one your project already uses: Vanilla CSS — fully self-contained, no dependencies, no CDN required Tailwind CSS — the original experience, 13 themes and 4 animations (unchanged) Bootstrap 5 — renders using native Bootstrap card, btn, form-control and alert classes UIkit 3 — renders using native UIkit card, button and grid components Each framework has an independent CDN toggle. If you already load Bootstrap or UIkit in your templates, just uncheck it and the module won't load anything extra. Security fixes CSRF token is now validated on every verification POST Fixed a bug where ProcessWire would render the full page HTML after the JSON response, causing JSON.parse errors in the browser. The AJAX handler now calls ob_clean() before sending JSON to discard any buffered output Strict date parsing with DateTime::createFromFormat — relative strings like "tomorrow" or "-18 years" are rejected Redirect URL validated to http://, https://, or site-relative paths only Custom CSS field sanitized against </style> injection JS console.log output is now gated behind $config->debug — no noise in production Admin UI The config page is now a two-column layout. General Settings and Framework & Theme are open side by side on first load. The rest (Modal Content, Date Picker, Agreement, Exclusions) are collapsed into logical groups — much less scrolling. PHP 8.2+ The module now requires PHP 8.2 and uses typed return types, match expressions, str_contains, str_starts_with, and unnamed catches throughout. GitHub: https://github.com/mxmsmnv/AgeWire Feedback and PRs welcome as always!

Btw, in addition to the memory/conversation history feature coming in the next version, we're also adding a sub-agent feature, so that your selected agent can launch other sub-agent instances of itself or other agents you've defined. Like maybe you've got different agents that specialize in one thing or another, or cost less for specific tasks, it can launch the best agent for the job. In this case, you've got a main agent that's in charge, but it can delegate tasks to other agents. Example would be using Claude Opus 4.7 for main agent but it delegates to Haiku or Groq or another for tasks that don't need as much horsepower, though that may be just scratching the surface on what's possible.

That's amazing!

@wbmnfktr Okay we've got support for multiple models now. I'm just working out some details, but should have the AgentTools version updated today with that feature.

Context Module v1.4.0 - Pure UIkit Design System 🎨 Complete dashboard redesign following ProcessWire standards! What's Changed 100% UIkit Compliance Removed ALL custom CSS Removed ALL inline styles Pure UIkit components throughout ProcessWire CSS variables for theming Dashboard Components: Cards: uk-card-default / uk-card-primary Tables: uk-table uk-table-divider uk-table-small Labels: uk-label uk-label-success/danger/warning Alert: uk-alert uk-alert-success Buttons: Clean HTML with uk-button classes Visual Improvements: Templates/Fields/Pages: Light cards Success metrics: Brand color cards (green) Adaptive grid: 2 cols mobile, 3 tablet, 6 desktop Automatic light/dark theme switching UI Cleanup: Removed "NEW!" label Removed version footer Removed "Edit configuration" link Consistent spacing and typography Bugfix: Removed duplicate formatBytes() method Why This Matters: ✅ Matches ProcessWire admin design ✅ Automatic theme support ✅ Zero maintenance CSS ✅ Better accessibility ✅ Mobile-first responsive Install/Update: cd /site/modules/Context/ git pull Then: Modules → Refresh

I am now playing with HTMX for building something like that

@szabesz TinyMCE support is on the list! CKEditor conversion was the first priority since it's still widely used, but TinyMCE is the logical next step given it's now the default RTE. I'll add it in an upcoming version. @Sergio Great suggestion! A /md/ URL segment or .md extension that returns the Markdown version directly would make the module much more useful for static site generators, AI pipelines, and content migration workflows. Added to the roadmap.

Great work! It's exciting to see a solid EditorJS integration for ProcessWire. I actually started working on a similar Fieldtype a few years ago and got it nearly production-ready, but I had to shelf it due to a heavy workload. I’ve recently been re-evaluating whether to pick it back up, especially because I agree that building page builders with PageTable or RepeaterMatrix can become quite complex and difficult to maintain/update over time. While thinking about the architecture, I had a question: Have you considered using FieldtypeMulti instead of a standard Fieldtype? Since EditorJS essentially stores "version" and "time" (which aren't always critical for the PW side), I’ve been wondering if storing each block as an individual entry in a multi-value field would be more efficient. For example, you could store the main block content in a data column and other attributes/settings in a props column. This approach might make it easier to handle multi-language support on a per-block basis within ProcessWire's native logic. I’d love to hear your thoughts on this, though I understand if you’ve taken a completely different architectural path for specific reasons. I’m looking forward to testing your module and providing more feedback soon. Thanks for your hard work on this!

YES!

I can't wait to play with all this stuff. I love that ProcessWire was envisioned over 2 decades ago, yet is adaptable with the cutting edge in web development. This just speaks to how well it was architected when it was publicly released. This feels like the next era of ProcessWire!

In case it helps anyone, these are the settings I've been using for while which I believe make a huge difference to how it looks and its usability: And then in custom CSS section: :root { --pw-text-color: #444; --pw-muted-color: #999; --pw-button-radius: 10px; --pw-main-background: #fbfbfb; --pw-menu-item-background-hover: #EEEEEE; } html { font-size: 15px; } .PageList .PageListItem:hover { box-shadow: inset 0 0.5px 0 0 #ccc, inset 0 -0.5px 0 0 #ccc; } h1, .uk-h1 { font-size: 1.6rem; } .uk-card :is(a, .uk-link) { text-decoration: none; } .InputfieldHeaderHidden { --pw-border-color: transparent }

I'll see if I have time to do a full case study. The map is easily explained though: Since Switzerland is a very small country, stretching it onto a 2D plane can be done without much distortion. That's where the LV03 and LV95 coordinate systems come into play. They are centered at the observatorium of the ExWi building of the University of Bern (where I studied CS :P). From there, you count the meters to the north and the east (and add some offsets so there are no negative coordinates). Using Switzerland's official map service, you can easily come up with LV95 coordinates for any address. These are then added to the locations in the PW admin. The map thus is just an SVG and placing the dots is just simple LV95 coordinate to pixels interpolation. No external services needed, no privacy concerns.

If you love the simplicity of ProcessWire's API but want the reactive, SPA-like feel of modern frontend frameworks without writing complex JavaScript, this module bridges that gap. It brings native Server-Side Component state hydration, Out-Of-Band (OOB) swaps, and strict security to your ProcessWire application using HTMX. 🚀 What does it do? This module transforms how you write frontend components in ProcessWire: True Stateful Backend Components: It introduces Component and Ui base classes. Your PHP components automatically rehydrate their state (variables, dependencies, $page assignments) between HTMX AJAX requests! No need to manually parse POST payloads. Auto-Discovery: Just place your components in your site directories. The module automatically discovers and securely namespaces them (Htmx\Component and Htmx\Ui). Zero-Javascript Reactivity: You can handle form submissions, counters, validation, and multi-field updating dependencies directly from PHP using HTMX attributes. Cryptographic Security: The module uses strict HMAC-SHA256 signatures with TTL (Time-To-Live). This guarantees that bad actors cannot modify state payloads or trigger invalid endpoint logic in the browser. WebSockets & SSE Ready: It has built-in helpers to easily hook Server-Sent Events (SSE) and WebSockets onto your templates without exhausting PHP-FPM pools globally. 🛠 How it looks in your code You simply create a PHP component class, define some public properties, and write an endpoint action: <?php namespace Htmx\Component; use Totoglu\Htmx\Component; class ClickCounter extends Component { public int $count = 0; public function increase() { $this->count++; } } Then, you can render it anywhere in your site with a single line: /** @var Htmx $htmx */ echo $htmx->renderComponent(ClickCounter::class); View the documentation and examples on Github Feel free to try it out, run the tests included in the repo, and let me know your thoughts or feedback! htmx.mp4

Hey everyone, on a recent client project we had to deal with a large number of Markdown files that needed to end up as regular HTML content on ProcessWire pages. Converting them manually or piping them through external tools wasn't an option – too many files, too tedious, and the content had to be stored as actual HTML in rich textfields, not just formatted at runtime. So we built a small module that handles this directly inside ProcessWire. How it works The module creates a file upload field (md_import_files) and a Repeater field (md_import_items) with a standard title field and a richtext body field (md_import_body) inside. The body field automatically uses TinyMCE if installed, otherwise CKEditor. You add both fields (md_import_files,md_import_items) to any template, upload your .md files, hit save – each file gets converted to HTML via PW's core TextformatterMarkdownExtra and stored as a separate Repeater item. The source filename goes into the items title, processed files are removed from the upload automatically. Template output The Repeater items are regular PW pages, so output is straightforward: foreach ($page->md_import_items as $item) { echo "<section>"; echo "<h2>{$item->title}</h2>"; echo "<div>{$item->md_import_body}</div>"; echo "</section>"; } Tag mappings One thing we needed right away: control over how certain Markdown elements end up in HTML. For example, #headings in Markdown become <h1> – but on most websites <h1> is reserved for the page title. The module has a simple config (Modules → Configure → Markdown Importer) where you define tag mappings, one per line: h1:h2 h2:h3 strong:b blockquote:aside hr:br This performs a simple 1:1 tag replacement after conversion, preserving all attributes. Works well for standalone or equivalent elements like headings, inline formatting, blockquotes, or void elements like hr:br. Note that it doesn't handle nested structures – mapping table:ul for example would only replace the outer <table> tag while leaving thead, tr, td etc. untouched. Requirements ProcessWire 3.0.0+ FieldtypeRepeater (core) TextformatterMarkdownExtra (core) GitHub: github.com/frameless-at/MarkdownImporter Modules Directory: https://processwire.com/modules/markdown-importer/ Happy to hear if anyone finds this useful or has suggestions for improvements. Cheers, Mike

Hi, everyone! While working on a client project we were looking for a way to let editors apply CSS classes to individual images in rich text fields — quickly, visually, and also in the frontend editor. ProcessWire already has several ways to get CSS classes onto images, so it's worth being precise about what this module does differently: TextformatterFluidImages adds one class to all images automatically — great for img-fluid across the board, but there's no per-image choice. TextformatterImageInterceptor is more powerful: editors tag images in the image field, and the Textformatter applies the corresponding classes at render time. The logic is developer-defined and centralized, which is exactly right when you want consistent, rule-based image treatment. But the class is invisible in the editor, applied only in the frontend output, and editors have to set the tag in a completely separate place from where they're actually working. TinyMCE's built-in styleFormatsCSS is the closest thing to what we wanted. You write CSS, ProcessWire turns it into a Styles dropdown. It works, but the dropdown is generic — it shows all defined styles regardless of what's selected — and there's a known accumulation issue where nothing prevents float-left float-right ending up on the same image. And it doesn't work in the frontend editor. What we needed was simpler: editor clicks an image, picks a style, sees immediately which styles are active, can combine them or remove them individually. No dialogs, no separate fields, no render-time magic — the class goes directly into the <img> tag in the saved HTML, visible and editable right there in the editor. That's what this module does: It registers a context toolbar in TinyMCE that appears as a floating "Image Style" button when an image is selected. For CKEditor the same options show up in the right-click context menu. The class list is defined once in the module settings and works across both editors — no separate configuration per editor type. Each entry shows a checkmark when active, clicking it again removes it, multiple classes can be combined freely. Works in the admin and in the frontend editor. Complete Readme on GitHub: https://github.com/frameless-at/ProcessImageClasses and the module directory. Any thoughts on further improvements welcome! Cheers, Mike