All Activity

Guys, I don't know where to put this, so I'll post it here. Maybe someone will need the Uikit PW design system for use on your development. Attached file. Online here. AdminThemeUikit-DesignSystemUI.html

Hi everyone, I needed a solid subscription module for a client project — something that handles multiple lists, double opt-in, and plugs cleanly into order and contact forms via a PHP API. Nothing in the directory quite fit, so I built Subscribe. It's been running in production on a few sites since March, so the edge cases are ironed out. GitHub: https://github.com/mxmsmnv/Subscribe What it does: Multiple subscription lists with many-to-many subscriber relationships Double opt-in with configurable HTML email ({confirm_url}, {unsub_url} placeholders) Honeypot spam protection — no CAPTCHA needed IP-based rate limiting (configurable threshold and time window) One-click unsubscribe with unique token per subscription WireMail provider selector — works with default, SMTP, Brevo, or any WireMail module Admin UI (Setup → Subscribers): Sidebar list switcher with subscriber counts Add/toggle/remove subscribers, create/rename/delete lists Search, status filter, pagination CSV import, JSON/CSV export per list Resend confirmation for pending subscribers PHP API — drop it into any template, order form, or contact form: $sub = $modules->get('Subscribe'); $sub->subscribe('user@example.com', $listId); Hookable event for integrations (Telegram notifications, CRM sync, etc.): $wire->addHookAfter('Subscribe::subscribed', function(HookEvent $event) { // $email, $listId, $subscriptionId }); Ships with an Alpine.js form block ready to drop into any template. Requirements: ProcessWire 3.x, PHP 8.0+ MIT License.

Thanks! Yeah I had deleted my first account after I got 100k followers... don't ask why. Then on my second account @somartist2 I tried to leave 2-3 times but then reactivated the account. And finally I did it. I'm on bluesky now, and still on Instagram and other platforms. No I didn't realize, but yeah I was very active for many years answering and helping many. It's great to hear tho. 🙂 Oh @ryan, thanks for the warm welcome back. Yeah I went on a long journey, glad you been following me. Great to see you're still running this thing haha. And now even using llm's! Yeah OMG so many names that I almost forgot about. I'm an old man now hehe.

@Joachim Exactly, when you use wireRenderFile() (or include), the variable $page remains the current page being viewed in the browser—in this case, the Home page. Since your Repeater fields live on the child pages (the modules), $page->introimg_field is looking at the Home page, finding nothing, and returning an empty object. When you loop through your child pages to render them as components, pass the specific child page into the options array of wireRenderFile. foreach($page->children() as $component) { // We pass the $component page object into the file echo wireRenderFile("components/{$component->template->name}.php", [ "item" => $component ]); } Inside the child (module) template: <section id="<?php echo $item->name; ?>" class="module"> <div class="landing_images"> <?php foreach($item->introimg_field as $intro_image): ?> <a href="<?php echo $intro_image->page_picker->url; ?>"> <h3><?php echo $intro_image->title; ?></h3> <img src="<?php echo $intro_image->image->url; ?>" alt="<?php echo $intro_image->description; ?>"> </a> <?php endforeach; ?> </div> </section> This should give you the correct array.

var_dump($page->introimg_field) gives: object(ProcessWire\RepeaterPageArray)#258 (5) { ["field"]=> array(4) { ["id"]=> int(111) ["name"]=> string(14) "introimg_field" ["label"]=> string(13) "Landing image" ["type"]=> string(17) "FieldtypeRepeater" } ["forPage"]=> array(6) { ["id"]=> int(1027) ["name"]=> string(7) "landing" ["parent"]=> string(6) "/home/" ["template"]=> string(16) "module_introImgs" ["title"]=> string(7) "landing" ["text"]=> string(0) "" } ["count"]=> int(0) ["items"]=> array(0) {} ["selectors"]=> string(0) "" } (I've never used this function, so I'm not entirely sure how to interpret this. Maybe ["count"]=> int(0) ["items"]=> array(0)count"=> int(0) is a bad sign?) It seems no matter what I do, the foreach function isn't working—until for some reason the images load, apparently randomly, after which the function works after every reload, suggesting a cache issue, I'm guessing (this is also why I tried loading the images in the main CSS file). EDIT: I am loading children pages as modules into the main pages. Take the following structure, for example: HOME - text - images - marquee - text2 The subordinate pages are loaded into the Home page using echo wireRenderFile(). Could it simply be that I'm referencing $page (in foreach($page->introimg_field as $intro_image), so it is looking for my Repeater Fields in the Home page, while in actuality they are on a child page?

Right, I had hoped loading them through CSS would fix the problem somehow, but forgot about that 😬 That explains that part, thank you, Markus! Locally the page always loaded correctly, but I have sanitised the code a bit and perhaps introduced a mistake, although sometimes the pictures do load fine. I'll try your suggestions and get back to you.

Hi @Joachim the most common reason a foreach loop "fails" silently is that the array/WireArray being looped over is empty. Have you tried to test $page->introimg_field via var_dump? oh and, your images are loaded via css:

I have the following code on a website: <?php namespace ProcessWire; ?> <section id="<?php echo $page->title ?>" class="module"> <?php echo "{$page->text}"; ?> <div class="landing_images"> <?php foreach($page->introimg_field as $intro_image){ echo " <a href='{$intro_image->page_picker->url}'> <h3> {$intro_image->title} </h3> <img src='{$intro_image->image->url}' alt='{$intro_image->description}'> </a>"; }; ?> </div> </section> For some reason, most of the time this code doesn't seem to get executed. The strange thing is, that the referenced images (the $intro_image fields) are being pulled, as they appear in the console: As you can see from the turtle icons, the server response times are very slow (around 650 ms), but then again, the code above is rendered client-side as: <section id="landing" class="module"> <div class="landing_images"> </div> </section> So the $intro_image fields inside the code are read, but the code surrounding it, i.e. within .landing_images, is not rendered at all. Does anyone know what could be the problem here?

Hi all, sorry haven’t been around Processwire in a while as I’ve been doing games and AI ethics work mostly these days. If you want some more things to read and hear then check out my podcast on the subject or my article about the end of programming…. Yep 🫠 Machine ethics podcast Programming is dead, we’re all code engineers now

Update: Improved "Link Module" UX We had an internal discussion about the "Link Module" interface and optimized how the different states are handled: Match found – The repo is resolved and ready to link. The green link opens the repository on GitHub so you can verify it's the right one before linking. This appears instantly when the module declares its GitHub URL in getModuleInfo() or has been resolved before (cached), otherwise after a quick GitHub search. No repo found – ProModules like RepeaterMatrix have no public GitHub repo. GitSync shows a clear "No repositories found." instead of false matches. Multiple repos – When a module exists in several repos (forks, different maintainers), you get a list to pick from. Selected, with "change" – After picking one, a "change" link lets you switch. It only appears when there are actually alternatives. Other improvements: single results are now auto-selected (no unnecessary click), the GitHub search uses Code Search API for exact .module.php filename matching (works even when repo name ≠ class name), and results are cached client-side so re-selecting a module is instant. Cheers, Mike

@ukyo Thanks for your awesome work with those modules, really impressive what you are building, and it's a big help for improving the AI friendliness of ProcessWire. The AgentTools module readme is now linking to your boost project as well. Glad you like the API.md files. Admittedly it was not my idea, but I asked Claude what would be helpful and he said these API.md files, plus an abbreviated sitemap json file so that it can get a big picture overview of a PW installation at a glance. That sitemap feature was actually added to the AgentTools module today. Several API.md files have been added to the core today as well. For Fieldtypes that don't have their own directory, they are in a combined /wire/modules/Fieldtype/API.md file. We're also adding dedicated Field classes specific to each Fieldtype, which will improve field documentation but also allow for custom field API methods separate from the Fieldtype (where useful).

Hey folks, we at frameless Media often develop across multiple devices – laptop, tablet, sometimes even from a phone with an AI coding assistant. Git is our single source of truth, but getting those changes onto a staging or production server has always been annoying. Especially on shared hosting where there's no SSH, no git, and git-based FTP via YAML configs is more hassle than it's worth. We also frequently need to test new modules directly on shared hosting environments where the server setup differs from our local machines. Manually uploading files after every push? No thanks. So we built GitSync. 🎯 TL;DR: ✅ Link any installed module to its GitHub repo ✅ See all branches and their latest commits ✅ One-click sync – only changed files are downloaded ✅ GitHub Webhook support – auto-sync on every push ✅ Works on shared hosting – no git, no SSH, no cron ✅ Private repo support via GitHub Token What's the difference to ProcessUpgrade? ProcessUpgrade is great for updating published modules from the PW modules directory. But it tracks releases, not branches. During development, when you're pushing to `develop` or `feature/xyz` ten times a day, you need something different. That's where GitSync comes in. 🚀 How it works Install the module, add your GitHub Token (optional for public repos) Go to GitSync > Add Module, pick any installed module from the dropdown GitSync searches GitHub for matching repositories automatically Link the module to a repo + branch – done From now on, you can sync with one click. GitSync compares file hashes locally and remotely (using the same SHA1 blob hashing that git uses internally) and only downloads what actually changed. No full re-downloads, minimal API usage. Want it fully automatic? Set up a GitHub Webhook – enter a secret in the module config, point the webhook to `https://yoursite.com/gitsync-webhook/`, and every push triggers an automatic sync. The module overview shows a ⚡ webhook badge on auto-synced modules so you always know what's wired up. The real power: remote development with AI 📱 You're on the train, phone in hand, chatting with Claude via the Claude app. Claude writes code, commits to a feature branch on GitHub. GitSync picks up the webhook and syncs the module to your dev server. Automatically. You open the edited webpage on your phone, check the result, give feedback, iterate. The entire development loop without ever opening a laptop. 🤯 This works just as well for teams: multiple developers push to GitHub from different machines, and the staging server always reflects the latest state – no manual deploys, no SSH sessions, no FTP. We've been using a prototype internally for a few weeks now and it's become part of our daily workflow – especially the webhook auto-sync is something we don't want to miss anymore. As proof of concept we built the public release entirely as described above 😃 Technical details for the curious The differential sync works like GIT itself: every file's content is hashed as `sha1("blob {size}\0{content}")`. GitHub's Trees API returns these hashes for the entire branch in a single request. GitSync computes the same hash locally. Matching hash = identical file = skip. Requirements ProcessWire >= 3.0 and PHP >= 7.4 with cURL Module and Docs 👉 GitHub: https://github.com/frameless-at/GitSync 👉 Module Directory: https://processwire.com/modules/git-sync/ Would love to hear your thoughts, ideas, and edge cases we might not have considered! Cheers, Mike

@adrian noted. For me, the DB abstraction would open a lot of doors for us, special if we could use SQLite. I really want to make an app/desktop using PW and NativePHP.

No plans on that from me - I was just seeing if Claude could do it - I think it would be something that would require core modifications and maybe modules that plugged into the core abstraction layer for each DB.

Is a new module coming up? 🙂

Fantastic, thank you so much ukyo!

Hi @ryan and the ProcessWire community, Thank you for starting this amazing discussion. Like many of you, I've been deeply exploring how to make AI agents more effective within the ProcessWire ecosystem. Hearing about the new Agent Tools and the API.md initiative is incredibly exciting! ProcessWire’s predictability and clear architecture make it exceptionally pattern-friendly for AI agents. Building on this exact philosophy, I have been developing two complementary open-source packages: processwire-console and processwire-boost. I wanted to share my architecture and findings, as they align perfectly with the goals discussed here. 1. API.md vs. AGENTS.md (Data Documentation vs. Orchestration) @ryan your idea of adding API.md files to Fieldtype modules is brilliant and absolutely necessary. It solves the issue of the AI not knowing the exact CRUD syntax for specific module APIs. However, as @szabesz noted regarding directory structures (.agents/ vs global contexts), managing when the AI reads this context is equally critical. If we feed everything to the AI at once, we waste tokens and dilute the context window. I see API.md and AGENTS.md as completely complementary: API.md (The Knowledge): Native, module-level API documentation focusing purely on syntax and dataset interaction. AGENTS.md / map.json (The Librarian & Routing): Placed in the project root, this acts as a trigger-based router. Instead of holding documentation, it lists installed modules and triggers (e.g., "Use when working with HTMX components... read site/modules/Htmx/AGENTS.md" or "Working with Repeater? read site/modules/FieldtypeRepeater/API.md"). mcp.json: The configuration for integrating ProcessWire's context securely directly into Model Context Protocol (MCP) servers locally. By combining ProcessWire's native API.md documents with a root-level AGENTS.md / map.json router, we can keep the AI deeply focused. It drastically reduces token usage and limits hallucinations because the AI only reads the specific API.md when it is actively working on that module's scope. 2. Giving AI "Hands": The Console & Migrations While having readable documentation is half the battle, the other half is allowing the AI to safely interact with the system. I see that AgentTools natively introduces a very cool migration runner (--at-migrations-apply) and a dedicated CLI file for agents. This is a massive step forward to prevent AI from executing dangerous ad-hoc scripts. To build on this paradigm, my processwire-console package reimagines this CLI experience utilizing a full Symfony Console architecture. This gives both developers and AI agents strict, typed, and predictable commands, along with a dedicated migration architecture. Instead of editing a single agent script, the AI can seamlessly run independent commands like: php vendor/bin/wire make:migration AddBlogFields php vendor/bin/wire migrate:status php vendor/bin/wire migrate This provides a Laravel/Symfony-style schema migration system that AI agents understand natively. It allows them to scaffold entire schemas predictably without breaking the production environment. processwire-boost: To give the AI safe, read-only oversight, I integrated an MCP (Model Context Protocol) server over JSON-RPC. Agents can natively execute tools like pw_schema_read (to understand the exact templates/fields currently installed) or pw_query to fetch ProcessWire data securely before deciding how to proceed. Repositories & Working Examples If you're interested in giving these tools a spin or looking at how the AI components communicate with each other, they are open-source here: processwire-boost: https://github.com/trk/processwire-boost processwire-console: https://github.com/trk/processwire-console For a real-world example of a module that seamlessly integrates with this AI context architecture, you can check out the Htmx module. It not only includes its own localized AGENTS.md, but it also actively extends processwire-console by injecting its own CLI commands. For example, AI agents can scaffold native UI components directly from the terminal: php vendor/bin/wire make:htmx-ui Card Htmx Module: https://github.com/trk/Htmx @ryan your approach with API.md in the core modules is the final missing piece. When ProcessWire natively exposes its capabilities clearly through text, architectures like processwire-boost with intelligent context indexing will allow agents to seamlessly crawl, understand, and reliably act upon the CMS with unprecedented accuracy.

I actually played around and got Claude to build an DB abstraction layer for PW that would allow using Postgres etc. Seems like there is definitely potential on this front.

@ryan It seems Claude is your real co-worker now—does that mean we can expect major developments sooner? I’m thinking of things like official nginx support, additional databases, organizing template files into subdirectories, and so on.

And when they do, they treat it as the "global context", while /.agent/ is the "project context". At least that's what Cline does, so ProcessWire should not automatically touch ~/.agents/ and should warn about such an action in the first place. see: https://docs.cline.bot/customization/skills#skills Quote: "You can also create skills manually by creating the directory structure in your file system. Place skill directories in .cline/skills/ (workspace) or ~/.cline/skills/ (global) and Cline will detect them automatically." Since Cline supports both .cline/skills/ and ~/.cline/skills/ the same is true for storing skills in .agent folders as well.

This is a good workaround, I think, especially if the target directory can be configured in the module's settings. .agent/ in the site root could be the default path. BTW, some AI agent tools support both the .agent/ location and have their own preference, like Cline suggests .cline/. I use .agent/ with Cline, and it works well.

I think there is only one thing missing: a screenshot 😉

We made the PR and let you and Claudia decide on how you want to handle a fallback. Also we renamed .agents to agents, so FTP transfer works reliably. It has the format I posted for templates/fields/roles/permissions. And it has various wrapper functions for things like creating pages, roles, install modules etc. These can live in various locations like site/migrate.php or inside a Foo module in Foo.migrate.php or the Foo.module.php itself or anywhere you call $rm->migrate(). It handles dependencies for migrations gracefully. Files it doesn't handle as far as I know. @Peter Knight has a module for page content creation with AI that he is working on. That one does rich text content and images, I think. Yes, that's very unfortunate indeed. I went with .agents because it's supposed to become the standard and many tools already support it. So I do the symlinking ritual until that is sorted out (if ever). Someone made a CLI for this at https://github.com/runkids/skillshare I haven't tried it yet, but looks pretty impressive.

Good morning @Stefanowitsch! Right now, this is possible for all images on a page using the page mode for prompts. I did a short screencast which shows what I mean. This way, you have to open each page, click 'Save + Alt-Text' (or whatever you want to call it), and move on to the next page. You could definitely create a script to process multiple pages at once, but this would require some refactoring of the module – I actually like this idea 😄 prompt-ai-pagemode.mp4

Yes, it's documented in the README under "Best Practices → Session Continuity" section! I've also just improved the AGENTS.md file to make it more prominent with a clear example prompt. The docs now show: At end of each coding session, use this prompt: Update prompts/project-summary.md with current project state. Follow the existing format in the file: - Be concise and factual - Use bullet points - Update in place (don't overwrite history) - Remove any duplication Save the file. The template file itself also has the rules embedded, so AI sees them every time it updates. This is in v1.3.0 which I'm releasing shortly with CLI support for AI agents.