All Activity

Another behaviour change to be aware of coming from this commit: https://github.com/processwire/processwire/commit/a8ed4d3b#diff-7bf8b3ff2a160688d91f86d0da53350f83e10520af659edfc48da1a0d1cf80a8 If you were adding an array of items via the API you used to have to reverse them first to get them in the order you wanted. Now because of the change from prepend() to add() they will be added in the order in the array you provide, rather than in reverse. I used to reverse before adding so had to remove that step and now things are fine again.

We might have a minor misunderstanding here. Building modules, tools, apps, anything with little to a lot of logic and functions is not the issue here. My problem is not that there are functions or config fields (Admin UI) missing or not working in a way or form I imagined them to work. The problem is that the Agents and LLMs are not ready yet to build module backends (Admin UI) - even when outlined in high detail. Sometimes they are almost there or at least it looks like it, sometimes they invent something totally new and won't even use existing field types, wrappers, and classes. Having an existing module, adding new functionality, new config settings, or even pages works incredibly well. That's because the Agent/LLMs can re-use existing structure of backend code. Besides that I totally support your step-by-step process and workflow. You can't just throw a vague idea towards whatever tool and expect a wonder. That's for sure. Little side note: I asked Kimi and Opus to build a module that's only purpose is to showcase module pages, all sorts of inputs and outputs. So I have a working base for interfaces I can point at later on. The prompt for those interested:

Hi @maximus, I have been testing your module, and so far it’s really impressive! The only problem I’ve found is how to map an image field that lives inside a combo field to an og:image. I’ve tried combo:image, combo.image, and {combo.image}, but none of those have worked. I also want to take the chance to thank you for your recent modules, you’ve been on an impressive productivity streak and personally I’m using several of your modules in production

For this, I recommend: https://buildermethods.com/prd-creator Quote: "PRD Creator is just markdown — not Claude Code-specific. If you’re using Codex, Antigravity, Cursor, or another agentic tool, download the bm-prd-creator folder from the bm-skills repo and install it as a custom skill, command, or rule per your tool’s convention. The workflow is identical." These are the actual files: https://github.com/buildermethods/bm-skills/tree/main/plugins/bm-prd-creator/skills/bm-prd-creator You may also want to watch this from the author: https://youtu.be/g6VvvS46uCM

Work in progress, but in this version, clicking the title takes you to the module config page. You can upgrade dev to the latest commit, which also works for modules. Uninstalled modules are only updated/downloaded, but not installed.

You are right. Ok. You are violating forum rules with this one too. "modules thread" Have you missed an apostrophe perhaps? I am asking this because "module's thread" would make more sense to me. Am I missing something perhaps? Anyway, I deleted my comment above. Cheers.

@szabesz would you mind removing your statement from my modules thread please? As it has nothing to do neither with the module nor with the question that soma asked, which I simply responded to. Also your post is IMHO violating forum rules and while I could respond I respect those rules and will not respond to what you wrote. But I'm happy to discuss what you wrote in a PM. Thanks!

I’m late to the Konkat theme but having used it recently, I really like it. It seems without any major UI adjustments that it’s just a nicer experience and if I’m not imagining things, a little faster? Nice job @diogo and everyone. If you’re open to feedback, can I add the following. First, the main grey background is a touch too dark for my personal preference, and interestingly a client mentioned the same, describing it as too industrial. They’re marketing. They like their UI to be friendly and approachable. The issue is a practical one: a heavy base grey compresses the tonal range before we placed a single element on the page. To make cards or panels register visually at all, you have to resort to strong contrast because a nice, subtle layering just disappears. Alternatively, with a near-white base you have room to step up gradually, building visual hierarchy through gentle increments. A heavy base leaves nowhere to go without things feeling either too dark or muddy. This isn’t a design lecture… just trying to pinpoint the particular issue. And I agree it only really affects module builders but interestingly, a client recently remarked that they found it a little industrial and unwelcoming compared to the previous theme. Next up, buttons… I find that buttons with 100% border radius never appear as truly aligned as flat side buttons with a subtle border radius. We switched to rounded buttons years ago on an enterprise project, everyone loved the change ( yay, jelly beans!) and now we’re going back to traditional 4px border radius throughout because everything just looks better aligned. It seems the beauty of using the css vars is I can easily tweak these things myself but wondered if at least the grey background was under consideration? Otherwise and honestly, it’s a great theme and I’m looking forward to using it more.

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

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

I agree it's confusing and it only works for the core, not for modules.

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

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

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

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

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

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

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

Thank you very much. Unfortunately, I dropped the whole topic a few days later so I do not have the Azure setup data anymore. It was really, really complicated so we solved the problem otherwise.

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.

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

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

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

🤯 this might actually be the solution to everything wrong in my modules. I am not sure if I already read about it here somewhere but couldn't find it when looking up module theming/styling. I will give this a try. Might have to try a few variations as most projects, even new ones, still use the old styling.