Leaderboard

This week on the core dev branch, the biggest addition was the upgrade from FontAwesome v4 to FontAwesome v6. This greatly increases the number of icons available in the admin. And while the new icons are in the same family as the old ones (still FontAwesome), they have a little bit different personality too. You can still use the v4 icons if you want by setting $config->adminIcons('version', '4'); though I recommend leaving it at the default, which will use v6 icons for AdminThemeUikit and v4 icons for older admin themes. There were several other updates this week to the core, which can be found on the dev branch commit log. The AgentTools module also received some significant updates this week: New scheduled tasks feature (this one is my favorite). Enables AgentTools to run tasks automatically at scheduled times or intervals. Improved Agents/models management screen (see screenshot). New tabs navigation makes it easier to get around in AgentTools. New debug and traces feature to track what agents are doing behind the scenes. New persistent memory feature, enabling agents to save a permanent memory across all sessions, when you ask them to. New guards on agent behavior, in case one goes rogue and decides to go places where it shouldn't. Note that SiteEngineer and PageEngineer each have their own persistent memory. SiteEngineer's persistent memory can be modified in the module configuration, while PageEngineer's persistent memory can be modified in your engineer field(s) settings. @wbmnfktr let me know about OpenCode Go last week, which I think is amazing. It provides you access to a whole bunch of AI models and a ton of usage for $10/month ($5 for first month). I have found most of the models to have very good ProcessWire knowledge. I think it's a perfect match with AgentTools because OpenCode provides you with as many API keys as you want. Whereas Anthropic and OpenAI don't include API keys with their monthly plans (Anthropic and OpenAI make you pay by the token with API keys). If you want an extra $5 credit for it use this link and it'll give both of us $5. I'm only posting that because it gives you extra credit, I don't need the extra credit so if we can get @wbmnfktr to post his link, use his instead since he's the one that told me about it. OpenCode also comes with a terminal app that is basically identical to the Claude Code and Codex terminal apps. They apparently have a desktop app too, but I've not yet tried it. If any of you do end up getting OpenCode I'd be curious what models you enjoy the most. So far I'm having a hard time deciding, as they've all impressed me in different ways. Yesterday I setup a scheduled task to "write blog posts" as just an AgentTools test, and do a round robin between the agents, writing blog posts and having different agent proofread them, every 15 minutes. I went to lunch. Then I started getting emails from the agents that they'd finished blog posts. Look at what they came up with (screenshot below). I started reading them, and they are actually fantastic posts. They are so good in fact that I'm tempted to post some of them on the site here, but I've never used AI generated content for this stuff before so am still debating that. What would you do? Thanks for reading and have a great weekend! Blog posts that agents came up with: AgentTools tasks: New AgentTools agents configuration screen: Background scheduled jobs in AgentTools: New icon selection in the core (InputfieldIcon, like used in the Field edit screen) replaces the "show all icons" grid of icons with a search box. FA6 comes with far too many icons to show a grid of them all at once, plus the search is a lot more useful and easy to use.

The posts I'm talking about are legitimately good, reminding me of features l'd forgotten or just better at communicating a part of processwire than me. Maybe it's in part because they'd gone through a round of proofing from another agent before I'd seen them. Though there was one about using CB radios that was completely off topic and also hilarious. And there was another one where DeepSeek (I think) describes how it experiences the world, which I thought was fascinating, and it somehow also made it about PW. As far as coding errors in the posts, I didn't find many. There was a hallucination in a post about markup regions by Opus 8, but it was something I read and thought "oh yeah we should support that". The hallucinations sometimes point to obvious things that should have been there already. One reason I like using Claude Sonnet so much is that its hallucinations are more often than not: good ideas that just haven't been implemented yet

I’m loving how fast all of this is happening, @ryan, even as I’m struggling to keep up. Don’t slow down! This is good for us all! <pant, pant! 😅>

Hi everyone, I've been building this for a while - a full genealogy system inside ProcessWire. Family trees, people, relationships, sources, documents, DNA kits, research workflow, and GEDCOM export. All inside the PW admin. GitHub: https://github.com/mxmsmnv/Arbor Status: Beta. Usable on a test copy. Always backup before installing. Screenshots: Why ProcessWire for genealogy? Genealogy data is complex, relational, and research-driven - not a blog. ProcessWire's flexible data model and custom DB table support make it a natural fit. Everything in Arbor lives in arbor_ prefixed tables, completely separate from the PW page tree. What it does Multiple trees - owner/public settings per tree Person profiles - names, events, notes, sources, photos, relationships Family/union management - partners, parents, children, relationship types Interactive tree viewer - main person panel, selected-person panel, agenda, legend Places & repositories - archives, sources, citations, documents, document leads Research workflow - questions, tasks, search log, proof conclusions, next actions DNA - kits, matches, segments GEDCOM 5.5.1 and GEDCOM 7 export GEDCOM import foundation (in progress) AI helper via AiWire-compatible providers - research suggestions, name analysis REST API via ArborApi submodule Three submodules: Arbor - schema, models, configuration, permissions, shared services ProcessArbor - admin UI under Setup → Arbor ArborApi - optional REST endpoints Requirements: ProcessWire 3.0.200+, PHP 8.1+, MySQL/MariaDB with InnoDB MIT License.

Thank you @ryan. I really appreciate it. But in case anyone wants to try OpenCode Go, please use Ryan's link so ProcessWire development will benefit from it.

What I really like about this coming of AI to ProcessWire is the discussion, the human communication it brings. Ryan is active and passionate in the forums like we hasn't been for a while. We all are once again experimenting and regaining faith in that our beloved computer thing will not stagnate but make its way onto the next level. I do not want that to end in no way. The same time I am too a bit afraid of AI lowering the quality of content here and the product itself. Too much enthusiastic awe and uncontrolled trust in AI could lead us there. So our collective goal is to balance things up. I can see you Ryan delighted to share the cool things you've built with AI with us all. And I personally want to read those blog posts. But if they get published alongside with your content unchecked or even checked but still containing some mistakes, that could not only turn away human readers, but also be the source for future less good answers from AI itself, as it is reading its own writings for sure. We could create a dedicated site section or dedicated forum section for AI-written articles. And maybe make it non-indexable by search engines. We should add an explicit warning like @Peter Knight suggested for sure. And maybe propose a game/challenge for the forum members to read them critically and comment on them. Maybe establish a workflow for AI to respond to those comments and to correct the text. We can really come up with something quite good in the end. Not only better texts that could be published. But also smarter AI and a more cohesive community. What do you think? P.S. We probably should also limit the amount of those articles. Humans are not as capable of reading as AI is of writing. The new era of a consumer rule is already here - it is harder and harder to find a good consumer for your stuff, especially something like a blog post)))

Whether in the forum or in a blog post or anywhere, I wouldn't post anything that I knew contained incorrect info. The API.md files I've been adding to the core are started by claude sonnet, and it uses my phpdoc and the method implementations to craft the text. After that I spend quite a bit of time fixing details, changing wording, creating better example code, etc. Then after I finish with my changes, I send them to Codex GPT 5.5 to test all the examples and make sure everything works as written. So when I mentioned AI generated content I suppose I should say that it's much more collaborative than that. If I were to post one as a blog or forum post then it would go through the same process and scrutiny. The main thing is that I don't have as much bandwidth as I'd like for writing blog posts, so they end up being very occasional. But I think having more regular blog posts could be helpful for attracting new users. Maybe I should just make the weekly posts blog posts. But I like posting in the forum because it's not as formal, and of course more likely to spawn good discussions, like here.

I think you should. You can always refine the prompt, seed it with some samples of your own writing style and tweak over time to create an editorial style. In my own case, I wouldn’t consider myself a great writer so I rely heavily on AI but I include this at the top of my blog posts. I always enjoy your posts and Like your writing style. So while I don’t think you need help writing, AI can be brilliant at generating topics you might want to explore further. And you can always review posts before they go live.

I personally wouldn't let AI write blog posts on here without heavy redaction. As @Kiwi Chrissaid, you need to fact check carefully. And, what bothers me most, is the writing style. After some time, you can immediately see if something is written by AI. Same phrases, sentence structures are repeating. The writing is mediocre at best. Unless you put a lot of effort in to avoid that. You can churn out more content with AI, sure. But imho quality beats quantity anytime.

I'd be careful to proofread any blog posts. This week I received an automated email asking me if I'd like to advertise a service I've never offered (but I could see how an AI might infer that I offer it), on a website purporting to be a guide to my region. What the person behind the site didn't know is that I own a site about my region (using ProcessWire obviously), so it was very easy to fact check the new site, and it was immediately obvious it had been entirely AI generated as it was so full of factual errors and included overly enthusiastic promotional styles of writing and checklists that simply didn't read credibly like a human wrote it. Coding with AI is different: You can test whether it does what it's supposed to, but with blog content where it doesn't have to execute, just be read by humans, it pays to check it carefully to ensure it doesn't produce something that's plausible but plain wrong, or worse, a mix of truth and mistruth that can make spotting the mistruth difficult. Using AI to suggest topics for blog posts and give some content ideas is safer, and can be helpful.

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

I've been meaning to raise this for a few years, and ironically, anytime I went to highlight it, I didn't know where to post it. Would it be worth adding a General Discussion area under Community Support for ProcessWire-related topics that aren't support questions? The gap I keep running into is topics that are clearly on-topic for PW but don't fit any of the support categories and aren't off-topic enough for the Pub or Dev Talk. Here are three sample posts to illustrate the issue: 1. "How do you pitch ProcessWire to clients who only know WordPress?" - not a support question, not off-topic, not a tutorial 2. "What's your experience of the PW community compared to other CMS communities?" - clearly PW-related but doesn't belong in any support board 3. "I'm seeing more agencies adopt PW in Germany - anyone else noticing regional growth?" - on-topic community discussion with nowhere to land I recently spoke with three PW users, and one told me they don't visit the forums at all because there's nowhere to simply chat about ProcessWire. Another wasn't aware of many of the recent Module developments because module-related content gets buried within Modules rather than somewhere more visible. I suspect both of those things would improve with a single well-placed General Discussion board. Just to recap, I think the boards are structured very well and cater for *most* topics. But has anyone else felt this gap or had posts they couldn't find a home for?

Hi everyone, Every web page has a carbon footprint. Most developers have no idea what it is. This module measures it. GitHub: https://github.com/mxmsmnv/PageCarbon What it does Tracks response size, PHP execution time, and peak memory per front-end request, then estimates CO₂ using the Sustainable Web Design Model v4 (Wholegrain Digital, 2024). Results appear in a dashboard under Setup → PageCarbon. Admin dashboard: Per-page ratings: 🟢 A (< 100 mg) / 🟡 B / 🟠 C / 🔴 D (≥ 700 mg) 24-hour hourly CO₂ bar chart Top 50 pages by average CO₂ with exec time, response size, and hit count Real-world analogies - all-time total translated into 12 everyday equivalents: car km driven, espressos brewed, Netflix hours, Google searches, short-haul flights, trees needed for a year, and more DOCX export - zero-dependency, pure PHP via ZipArchive Screenshot: Performance-first architecture: WireCache buffer - metrics accumulate in memory, batch INSERT once per hour (zero per-request DB writes) Bot sampling - only 1-in-N bot requests recorded, human requests always in full 90-day raw retention with permanent hourly aggregates - historical data never lost Frontend API: $pc = $modules->get('PageCarbon'); echo $pc->renderBadge($page); // full card echo $pc->renderBadge($page, 'compact'); // single-line pill $stats = $pc->getStats($page); // avg_co2_mg, rating, hits... The average web page produces ~500 mg CO₂ per view. Most ProcessWire sites do better - now you can prove it.

You are a beast @maximus. The community is grateful to have you.

I wanted to go back and build my family tree again. The last time I did this was a long time ago, more than 15 years ago.So I decided to make it a separate module, open source for others, since this is sensitive data. Your own solution is always better than others.

That's a good point about discussions. Possibly the only downside of forum-only posting is you're losing the SEO benefits. Google sees the .com isn't updated as much, and people researching the platform might not see how alive PW is at the moment.

Thanks @gebeer! Love is something that unites people. There are different kinds of love and love to a PW module is certainly a valid one. Any kind of love is IMHO an expression of openness to something outside yourself. Willingness to accept and even incorporate something seemingly foreign. Another human being. Another style of writing code. Another vision of the future. Another business model. Another opinion. My relationships with RockMigrations is too of hard road to love. I didn't accept its bloated nature and desire to bring the whole Rock infrastructure with it)) But I learned the way to ignore and work around those. And even built a complex PW scaffolding script using this super module. And I have met its author, a passionate man and developer. I am writing this knowing that Bernhard has almost quit the PW community. I know what brought him to this decision. And that was kind of a lack of love. So I think this post is a great one and I totally agree with it 100%. And I wish that everyone here, including @ryan, @bernhard, @Pete (and actually everyone) would consider finding time, energy... humility and open mindedness to give ProcessWire and its daughter RockMigrations a bit more family love. A love that would raise them both to a greater future. A love that no AI could ever give. A love that is the core of this community which has so much unrealized potential. Peace ☮️

IMHO the categories do not mean much nowadays. At least for an experienced forum user. I never go to categories list first but always start with recently updated topics. Most of the time I do not even know the category the post is in. And when I need to find something I search. I go to the category list when I want to get help on modules, especially Ryan's pro modules. The other case is when I create a new post. And that is when it gets confusing. I can never decide where to put it. I can see not difference between Getting started, General support, API and templates and even Modules/Plugins as any of my questions usually relates to all of them somehow. Not to say there is not such thing as "plugin" in PW. It all might seem quite different for a newcomer though. And if we know for sure that affects the community friendliness we should change that. But I actually do not know how. Just maybe some overenthusiastic forum member can push the changes. Or AI will help) Anyway, anything concerning the forums mechanics should at least mention @Pete))) P.S. I am pretty sure forum engines have some cool features nowadays, like tagging and more. And even though the forum as a communication format seem to vanish, we still can try to use more of those new features here. As we, old school nerds are still using 'em)

Yes, maybe it’s just semantics and labels but it does seem like if a topic is neither support or off topic, its not welcomed or at least has no natural home. I agree Pub and Dev are close. But as Dev itself describes itself as general development and coding discussions and live under a category of Off Topic, it adds to the perceived issue. But I agree that a general bucket called PW topics or whatever will add to moderation issues. Is there a middle ground that doesn’t resort to calling itself General? In my original post, that was just an example label.

This may be my own interpretation of it, but both Pub and Dev are splits of a General Discussion, whereas Dev Talk is generic/general but leaning more towards business and professional areas of discussion, and Pub is the otherwise-named category where non-tech (more-often) conversations would go because, realistically, it needs to be named something else (other than General Discussion) to not be a catch-all for Dev Talk as well. I can see the reason for naming them differently and for separating them out, but I'd imagine they could both be enveloped into a single General Discussion instead. Inevitably people would post technically or professionally-minded conversations in both Dev Talk and Pub, and vice-versa. I'm not entirely sure there's a massive benefit to provide a distinction of categorization here, especially if there are people who explicitly don't converse in the community forums because of the categorization. To clarify: I'm not being critical of the naming, just analytical. As we all know: Naming things is hard!

A big thanks to @@Mikel for flagging some of the items which form 1.19.1. Uninstall (fixed) The safety check that requires you to opt-in via `$config->MediaHubUninstall` in `site/config.php` was firing a beat too late. By the time the error showed, companion modules and their pages were already partially torn down. 1.19.1 hoists that check into a `hookBefore('Modules::uninstall')` so nothing is touched if the flag is missing. Also tightened companion module cleanup, admin page deletion, and crop-field removal so the whole flow is now atomic: succeeds completely or aborts cleanly. Import (fixed) Importing existing images on a non-MediaHub site (Setup → Media Hub → Import Existing) wasn't generating thumbnails. Bonus: retina `srcset` (1x/2x) and lazy loading on inputfield thumbnails. Icons (aligned) The library and the MediaHub inputfield each have view-mode toggles (grid, proportional or masonry, detail or list), but 1.19.0 used slightly different icon sets between the two surfaces. 1.19.1 aligns them on the same Lucide set. Labels bug (fixed) The new Labels section in 1.19.0 shared structural class names with Collections. This meant Labels were incorrectly displayed on some Collections filters nd menus. Labels and Collections are now strictly separate row types throughout the sidebar. Full changelog 1.19.1 blog post 1.19.1 download

Missed the third developer's input. They said they spend 90% of their day working in Processwire, work solo with no real PW interaction apart from the forums. They often wish they could jump into the forums and share PW stuff without feeling like it needs to be support related or forced into off-topic.

New Figma to PageGrid Importer From design to production in no time, with the new Figma to PageGrid Importer. At our studio, Konkat, we do all our design work in Figma because it lets us move and iterate quickly alongside our clients. While AI is great at spinning up generic, cookie-cutter layouts, true professional value lies in creating websites genuinely custom-tailored to a client. For that level of work, pure text prompts simply don’t offer the layout precision you need—writing a description will never match the intuitive control of direct visual input. But as any developer here knows, turning a finished design into a live, client-editable website usually requires a lot of manual layout replication before you can get to the core development. Even though PageGrid is already a massive speed upgrade, manually recreating a canvas layout element-by-element is still a time-consuming assembly phase. It eats up hours better spent on deep development, custom logic, and polished execution. That’s exactly why I (with the help of Claude Code) built the new Figma Exporter plugin and a native PageGrid Importer module for ProcessWire. It compresses hours of manual layout replication into a five-second automated import. By handling the structural translation instantly, it lets you skip the repetitive setup entirely and jump straight into the fun stuff: custom animations, fine-tuning, and high-level development. Instead of just telling you what it does, I want to be completely transparent about how it was built, why we intentionally avoided a "live AI" generation solution, and how it changed my perspective on building dev tools. Why We Rejected Live AI Generation When I started working on this, my first instinct was to leverage the power of AI agents directly during the import process. I tried using Claude via a live Model Context Protocol (MCP) setup to directly read my active Figma canvas and dynamically generate the PageGrid layout on the fly. Honestly, AI is surprisingly good at understanding how to build a layout in PageGrid now, and the initial results were already incredibly close to the original Figma designs. Using MCP is a really interesting alternative, but for daily production work, relying on a live AI connection just didn't make sense for a few major reasons: It was unpredictable: Every single time I ran the generation on the exact same layout, the resulting code structure came back slightly different. It was slow: Relying on live AI cloud prompts meant waiting for the model to think, stream, and process the data. API Bottlenecks: The live Figma API connections generated far too many requests, causing frequent rate-limiting issues. Resource-heavy: Each time we want to create a new layout we have to prompt an AI, which uses extra computing power and adds up in ongoing token costs. At our agency, Konkat, we built PageGrid to power actual production sites for our clients. We plan to use these tools daily to optimize our own studio workflow. In a professional production pipeline, an unpredictable guessing game that changes its behavior on every prompt simply isn't an option. We needed something that was completely deterministic, blazing fast, and independent of live external APIs. So, we changed our strategy entirely. Changing the Strategy: AI as the Engineer, Not the Runtime Since Claude had become deeply familiar with the Figma API, and thoroughly understood the structure of ProcessWire and PageGrid, I stopped trying to use the AI to generate layouts on the fly. Instead, I partnered with Claude to write a dedicated, local compiler. Claude acted as my co-developer. Together, we built a simple, two-part ecosystem: A local Figma Exporter Plugin that reads the canvas instantly and packages the architectural structure and assets into a lightweight .ZIP file. A native ProcessWire Importer Module that unzips that package and handles the rendering locally on your server. Because the final tool runs entirely on pure, local code logic, it requires zero active AI API calls, runs instantly, and produces the exact same, predictable structure every single time. Respecting Layout Intent Without Forcing "Auto Layout" Most Figma-to-code plugins fail unless you have meticulously built your file using strict, perfectly nested Auto Layout components. If you design loosely, those plugins break or output absolute-positioned spaghetti code that is impossible to maintain. As a designer, I know that forcing strict Auto Layout workflows during the rapid, creative prototyping phase can feel incredibly restrictive. That’s why we engineered our importer to give you complete freedom to design your way. Whether you prefer nesting elements using strict Auto Layout, arranging them freely using Figma's native Column Layout Guides, or using a mix of both, the compiler adapts to your workflow. When you run the importer, PageGrid respects your structural intent and translates it into standard web architecture: Native CSS Grid & Flexbox: Elements aligned to your column guides are automatically mapped to precise, responsive CSS Grid positions, while Auto Layout frames are translated cleanly into semantic Flexbox structures. Direct Layer Mapping & Smart Flattening: The importer replicates your Figma layer structure directly in PageGrid by mapping all layer nodes straight to native PageGrid Blocks like pg_group (groups), pg_image (images), and pg_editor (text). At the same time, the parser automatically filters the tree, flattening out any unnecessary deep nesting or arbitrary wrappers when needed so your backend tree stays incredibly clean. Maps Figma API to Modern CSS: It natively extracts typography styles, colors, borders, spacing rules, and effects, turning them directly into clean PageGrid metadata or copyable CSS. 💡 The "Grouping" Pro-Tip: Because Figma group nodes map directly to pg_group container blocks, grouping items that belong together directly shapes your PageGrid backend structure. While the importer can handle ungrouped layers, grouping your elements ensures the highest layout accuracy and keeps complex structures beautifully organized under the hood. Keeping You in the Driver's Seat When the import finishes, you are not left with a static image or a fragile webpage that breaks the moment you edit a line of text. You get a native, fully editable ProcessWire page built out of organized PageGrid blocks. Because PageGrid functions like a precise web canvas, the layout remains rock-solid. Your clients can easily log in to update text and images directly on the live page, but they will never accidentally break the structural layout you designed. The mechanical translation work is completed in five seconds. From there, you take over to do the work that humans do best: adding fine-tuned interactions, implementing custom animations, and binding dynamic backend data fields. How to Try It You don't need a paid plan to use it—the plugin works perfectly on the free version of Figma. Here is how to get started: Get the Figma Plugin: Open the Figma to PageGrid Exporter in Figma. Select your main design frame and download your .ZIP package. Install the Importer Module (Self-Hosted Only): Add the PageGridFigmaImport module to your ProcessWire backend. Upload & Run: Go to Setup > Figma to PageGrid, drop in your file, and watch your layout appear natively. Documentation: Figma Import Documentation. I consider this a beta launch, not every generated layout will be perfect out of the box, but results so far have been quite impressive. I plan to improve this over time. Give it a try and let me know what you think!

Hey everyone, MediaHub 1.19.0 is ready. That is good news for two reasons: you might find it useful, and you might be too distracted to wonder where 1.18 went. 🙂 Anywho, MH 1.19 has two main areas of improvement: the main MediaHub library screen (for editors) a new read API for galleries at scale (for developers). MediaHub Library changes A) Redesigned sidebar The sidebar has been redesigned and refined, with new shortcut filters at the top B) Favourites Mark any asset as a favourite (site-wide) and filter the library to favourites only. You can favourite from the asset detail page, the tile menu, or by dragging tiles onto Favourites in the sidebar. I am still debating Favourite/unfavourite vs star/unstar for the wording. Open to opinions there. C) Recent See your newest uploads and choose what “recent” means: last 24 hours, last 7 days, and other presets. More flexibility planned here soon. D) Filter breadcrumb type thing When you filter the library, a breadcrumb-style trail shows where you are (for example All Assets › Labels: Dublin). Clear a filter with one click instead of guessing how you narrowed the view. E) Labels If you use Labels for organisation, they are now a first-class shortcut in the sidebar, with counts per label. The section collapses when you do not need it. Drag assets onto a label row to assign in bulk; rename or delete from the row menu. F) Hover info on asset cards Hover over an asset to quickly see the title and filename without turning on Details view or opening the full asset page. This way, you get a really clean Library grid and still benefit from an in-betweeny view. G) Favourites (pt2) You can mark an asset as a favourite from the assets card/panel. Admittedly, 'unfavourite' is a little awkward-sounding. How does it read in German, Austrian, Bulgarian, Irish? I'll find out shortly. I might change this to star/unstar. MediaHub - drag and drop Another gap closed. You can drag and drop assets directly onto a MediaHub field. If you want to disable that function, you can do it on a field-by-field basis. You can also re-order assets as per the native input field. And if you're not a drag-and-drop fan, you can use the buttons instead. The MediaHub button will open your Library. Upload button opens your Finder. Uploads and drag-and-drop currently land new files in the root of the library in the background. I am planning more flexibility there soon. getRaw () API (beta) I'll be straight: I have not fully tested this myself on production sites yet, but I did run it through rigorous automated test scripts, and the performance benefits look promising. There is a more comprehensive write-up in the MediaHub docs. And I want to thank @David Karich for pushing this feature forward and flagging the original limitation in the first instance. Not strictly 1.19 related Search the docs The MediaHub documentation has a new search box in the sidebar Limitations and planned improvements Created a page with the known gaps in MediaHub. This is going to be a living (but rapidly shrinking) list as I move towards MediaHub 1.20.X. Get 1.19: About MediaHub: https://www.peterknight.digital/products/mediahub/ Upgrade to 1.19: https://www.peterknight.digital/downloads/mediahub/ Read the blog: https://www.peterknight.digital/blog/posts/mediahub-1-19-release/ Full changelog: https://www.peterknight.digital/docs/mediahub/v1/changelog/ Cheers 🍻 Peter

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

I love this Love Letter! Not only because it's true, but because it showed me something I didn't know about RockMigrations - something I always wanted but couldn't really explain, something that was already there. Or as it is called Config Migrations. Buried deep, somewhere in the docs (at least for me). https://github.com/baumrock/RockMigrations/tree/main/docs/config-migrations I didn't know that. At all. I tried to handle and manage so many site/migrate.php files but it never felt right for me. At some point I lost track of changes, those hundreds of lines of code became unmaintainable for me. Wasn't fun. Stopped using it. One project after the other. Never really tried again. Did it the old way. But this, config migrations, this is a game changer for me. Sure, I quite often sleep under a stone, but this. Thank you @gebeer for making this your example. Thank you @bernhard for making RockMigrations - and this is exact feature. 🤯

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

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 New in the latest version: Goals and conversion tracking event-based goals, for example form submits, CTA clicks, downloads or tel/mail clicks page/path-based goals, for example thank-you pages or booking confirmation pages conversion rate reporting based on sessions and unique visitors a dedicated Goals dashboard with goal cards, goal trends and goal overview easier goal setup with helper text, quick presets and suggestions from already tracked events and pages daily aggregate tables for events and goals raw event retention setting additional database indexes and cleanup helpers for larger datasets 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, engagement and conversion data available right where content is managed. Goal tracking was added because several users asked for a simple way to measure important actions without having to fight with external analytics tools. For example, you can now create a goal for a contact form submit, a CTA button click, a file download or a visit to a thank-you page, and then see conversions and conversion rates directly in the ProcessWire admin. A small note about very large datasets: NativeAnalytics includes retention settings, daily aggregate tables and cleanup tools, and the latest version improves this further for events and goals. For very high-traffic sites, I still recommend using sensible raw data retention and keeping long-term reporting based on aggregated data. I do not want to overclaim without real long-term benchmarks on extremely large datasets, so feedback from larger installations is very welcome. ! 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! If you find NativeAnalytics useful and would like to support further development, maintenance and testing, a small donation is always appreciated. The module will remain free, but support helps me spend more time improving it and adding new features. DONATE

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

I’ve just uploaded a new version of NativeAnalytics 1.0.20. This update mainly focuses on monthly reporting, privacy options, engagement tracking improvements and some smaller admin UI refinements. Added / improved Added optional monthly email reports Added Send test report now option in module settings Added report preview before sending Added optional PDF report attachment Improved page-level analytics summary inside Page Edit Added a setting to show/hide the Page Edit analytics summary Improved spacing and styling of the Page Edit analytics block Improved engagement event tracking, especially form submit tracking Added better cache-busting for updated tracker/admin assets Added module info files so the ProcessWire modules directory and Upgrade module can detect the version correctly Added support links to the module info array The module should now also be upgradeable through the ProcessWire Upgrade module once the modules directory has refreshed the latest version. The current version is 1.0.20. Special thanks to matjazp for testing the module and reporting useful issues along the way. The feedback helped a lot with polishing the module and making it more reliable in real-world use. P

I have been using this module for a long time and it's been incredibly useful so I thought it was time to share. It's great for fields where you want to instruct content creators to reference something about a the page, its template, or its parent, or grand parent, etc Specify fields/properties of the page in your field's Description or Notes content, eg: [page.parent.url] [page.title] [page.template.label] You can also define a str_replace to be performed on the returned value, eg: [page.name.(-|_)] which will return the page name with the dashes replaced with underscores. An option to allow raw HTML is available. You can also use hanna codes within your description and notes fields - big thanks to @Robin S for this idea. http://modules.processwire.com/modules/dynamic-description-notes/ https://github.com/adrianbj/DynamicDescriptionNotes/ Hope you find it useful.