Leaderboard

It's not about adding every new learning into a new skill. It's about updating existing skills with new learnings. For example: in case a modules skill always returns an error when creating backend pages, that skills needs an update and I feed the learnings back into that skill. Yes, but I honestly don't like to have too much external requirements in my projects. I'd like to test Context+ (https://contextplus.vercel.app/) yet the overall setup is way too much hassle. For super big projects maybe, but for all those smaller to medium sized projects that's way off my comfort zone. I tried Gastown, SpecKit, OpenSpecs, Beads, BMAD ... whatever else there was. They always came with some kind of setup and bloat. Taking a day or two off meant I couldn't even remember I installed and used that tool in my projects or forgot to start a new task in a certain way. Skills are always there. They live in my OpenCode config folder now. They are portable, too. Way easier and no headaches. At least for me. Of Course everyone else has their own prefered way of doing things and may have the capactity to remember each tool and setup for each project. I don't. 😂 Way too many things. Way too little hours per day for that. 🙈 I try to solve the knowledge gap that most LLMs have in regards to ProcessWire. There isn't that much of training data for ProcessWire as there is for NextJS, React, Symphony, Laravel, and of course Java and C++. LLMs know the basics or "invent" new ways of doing core things, like URL hooks. PHP itself was never a real problem - just to make this clear. I found that skills are a great way to solve this - for me. I can use way cheaper models, like Kimi K2.5 or Minimax M2.5, with way better outcome using skills. Sure I could just burn through my $200+ Claude Code/Cursor plan but babysitting that agent to fix issues it isn't even aware off while it would repeat those same mistakes over and over again with a smile the next time - I was tired of that. That's why I played a lot with the JS-tools out there. Paying less money and investing less time for a way better outcome. I could run 10 agents in parallel that check each others work and fix issues, report back and forth, and could then somewhat get what I was looking for but it never felt right and looking at the code often even scared me. My skills contain about 80-90% of ProcessWire knowledge. Not perfect in every aspect, maybe sometimes even outdated examples or older PHP code (<8.x) but the results turn out to be great. For me at least it is: SKILLS, plus AGENTS.md thats referencing those skills, concepts/specs/PRDs For now. Maybe next week there is another concept that lives locally without any big setup in a folder that does everything I want and need. I don't know. What's your (daily) workflow? What's ruining your day to day work? What annoys you when working on something? My benefit is: I don't need $200 Claude/Cursor plans to get something done. I don't need Opus/Sonnet 4.6, Codex 5.3-x-whatever-they-named-it. I get MVPs up and running in ProcessWire like it was a NextJS/React project. Look into the ProcessWire skills here and you will notice that it's actually just the documentation - which is missing or is incomplete in so many LLMs. Sometimes with additional details, other code examples, or sometimes it's a missing part of the docs like for URL Hooks - as they actually only exist as a blog post right now - yet I can use them now without issues. That's what I tried to fix and for the moment this fixes it. Is that the best way to go? I don't think so. But I am lazy and tired. And this works. For me. I don't want to learn yet another tool or framework to get things done. Just to learn another framework and tool tomorrow and next week. I don't need 10-20 agents per project to run 24/7. I'm not trying to rebuild SAP/Sage or Asana/Trello/Jira. But let's find out how my (lazy) approach might help you or give you ideas.

I just had time to look at your repo. This is gold. Thanks so much for sharing.

Media Hub update. Just a few small ones. You can rename the asset filename. If you select a folder or Collection, you can upload media / images directly into that I have started using Media Hub in one of my own live sites and it's highlghted some great areas for improvement etc. There's a significant difference between uploading a few Instagram photos and real staff photos, logos, and branding assets, which need to reside in multiple places across the site, yet remain a single image in the back-end. So, thats where I am. Hoping to ask for a few beta testers soon. If you're interested, please PM me.

Yeah, tried to fix that but it's not working out as expected. 🙈 Doesn't matter, the diff shows the changes pretty well: https://github.com/webmanufaktur/pwaiworkflow/commit/f0dba82a796881153ac6140aa9db70fdf2875d3e Updated that skill to have those advanced features.

It was kinda hard to read from the formatting, but it looks good to me.

@wbmnfktr - Thanks for sharing this! I'm learning from your skills documentation. You may also want to note on https://github.com/webmanufaktur/pwaiworkflow/blob/master/.agents/skills/processwire/templates/SKILL.md#markup-regions that <region id="something"> tags </region> are also supported. Here's some more info about it https://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/#defining-regions

I don't know. What's your (daily) workflow? What's ruining your day to day work? What annoys you when working on something? I guess I have experiences something similar. Using Opus 4.6 was really expensive (via Cursor) but then I switched to Auto-mode (using Composer 1.5 mostly) and it was way cheaper! Guess your skills could be helpful here 🙂

I try to solve the knowledge gap that most LLMs have in regards to ProcessWire. Thx. I really didn't get your point but now it makes total sense! Thx for sharing your skills!

Hi everyone, I'd like to share a module I've been working on: WirePDF — a PDF generation module with full UTF-8 and Cyrillic support. What it does Adds a toPdf() hook to any page, so generating a PDF is as simple as: $page->toPdf(['filename' => 'document.pdf']); You can also pass custom HTML, use a dedicated template file, or save the PDF directly to disk. Key features Two engines: mPDF (recommended) and Dompdf Full field support: all native PW fields + ProFields (Table, Repeater, RepeaterMatrix, Combo) Typography: 14 fonts including DejaVu Sans for multilingual/Cyrillic content Headers & footers with {PAGENO}, {nbpg}, {DATE}, {sitename} variables Watermarks, password protection, configurable margins and paper sizes Logging via ProcessWire's built-in log system (Setup > Logs > wirepdf) Installation cd /site/modules git clone https://github.com/mxmsmnv/WirePDF.git cd WirePDF composer install Then install via Modules > Refresh in the admin. GitHub: https://github.com/mxmsmnv/WirePDF Feedback and bug reports welcome!

For those who want to play around with that workflow: https://github.com/webmanufaktur/pwaiworkflow-profile DDEV setup (customise .ddev/config.yaml to your needs) clean ProcessWire installation clean database backup: site/assets/backups/database/clean-start.sql all necessary modules (core, 3rd party) Skills in .agents + custom symlinks for various IDE/tools AGENTS.md ready to go Testing & Demo: Branch: feature-restaurants-directory Specs file: https://github.com/webmanufaktur/pwaiworkflow-profile/blob/feature-restaurants-directory/specs/restaurants-directory.md Ask your agent to run that file and see what happens. Results may vary. Minimax M2.5 was fine, Z.AI GLM-5 did way better. Tell me your results and findings if you like to share. Reference result with Claude Sonnet 4.6 for comparison: https://github.com/webmanufaktur/pwaiworkflow-profile/tree/feature-restaurants-directory-claude-sonnet-46

Hi fellow devs, this is a somewhat different post, a little essay. Take it with a grain of salt and some humor. Maybe some of you share similar experience. I don't really mean to poop on a certain group with certain preferences, but then, that's what I'm doing here. I needed to write it to load off some frustration. No offense intended. Good Sunday read :-) React Is NPC Technology Have you ever really looked at React code? Not the tutorial. Not the "Hello World." An actual production component from an actual codebase someone is actually proud of? Because the first time I did, I thought there'd been a mistake. A failed merge. HTML bleeding into JavaScript, strings that weren't strings, logic and markup performing some kind of violation you'd normally catch in code review before it got anywhere near main. "Fix this," I thought. "Someone broke this." It looks broken because it is broken. That's the first thing you need to understand. JSX is a category error. Mixing markup and logic at the syntax level - not as an abstraction, not behind an interface, but visually, literally, right there in the file - is the kind of decision that should have ended careers. Instead it ended up on 40% of job postings. And here's the part that actually matters, the part that explains everything: Nobody can tell you why. "Everyone uses it." Go ahead, ask. That's the answer. That's the complete sentence, delivered with the confidence of someone who has never once questioned whether a thing should exist before learning how it works. The argument for React is React's market share. The case for Next.js is that your tech lead saw it on a conference talk in 2021 and it was already too late. You're supposed to hear this and nod - because if everyone's doing something, there must be a reason, right? The herd doesn't just run toward cliffs. Except. That's literally what herds do. The web development community, bless its heart, has a category of decision I can only call NPC behavior. Not an insult - a technical description. An NPC doesn't evaluate options. An NPC reads the room, finds the dominant pattern, and propagates it. React is on every job posting = React is what employers want = React is what I need to know = React is what I reach for. The loop closes. Nobody along the chain asked if it was right. They asked if it was safe. Safe to put on a resume. Safe to recommend. Safe to defend at the standup. React is the framework you choose when you've stopped choosing and started inheriting. The 10% who actually think about their tools - they're out there running Alpine.js. Which is 8kb. Does the same job. No build step required. Add an attribute, the thing works. Revolutionary concept. They're running htmx, which understood something profound: the web already has a protocol for moving data, and it was fine. You didn't need to rebuild HTTP in JavaScript. You just needed to reach for the right thing instead of the fashionable one. Let's talk performance, because "everyone uses it" is already bad enough before you look at what it actually does. React ships 40-100kb of runtime JavaScript before your application does a single thing. Your users wait while React bootstraps itself. Then it hydrates - a word that sounds refreshing and means "React redoes on the client what the server already did, because React can't help it." Then they invented Server Components to fix the problem of shipping too much JavaScript. The solution: ship different JavaScript, handled differently, with new mental models, new abstractions, new ways to get it wrong. They called it an innovation. I once worked with WordPress and React together. I want you to sit with that. Two philosophies, neither of which is actually correct, stacked on each other like a complexity casserole nobody ordered. WordPress solving 2003's problems with 2003's patterns. React solving 2003's problems with 2013's patterns that created 2023's problems. Together they achieved something genuinely special: all the drawbacks of both, and none of the advantages of either. The PHP you want but in a different way and the hydration you couldn't prevent, serving pages that load like it's apologizing for something. Twenty years building for the web and I've watched frameworks rise and fall like geological events. ColdFusion, anyone? Remember when Java applets were going to be everywhere? Flash was going to be the web. Then jQuery saved us. Then Angular saved us from jQuery. Then React saved us from Angular. Rescue upon rescue, each one leaving more complexity than it cleared, each one defended by exactly the same people who defended the last one, now wearing a different conference lanyard. ProcessWire. That's what I build with. Most developers have never heard of it - which is not a criticism, that's the evidence. You find ProcessWire because you went looking for something specific, evaluated it, and it fit. It doesn't have conference talks. It doesn't have a VC-funded developer relations team. It has a forum full of people who chose it. That's a different category of thing entirely. The same 10% who finds ProcessWire finds Alpine. Finds htmx. Makes decisions that don't optimize for defensibility in interviews. Builds websites that load fast because they don't carry React around everywhere they go. There's a physics concept called a local minimum. A place where a system settles because the immediate neighborhood looks stable - the energy gradient points upward in every direction, so the system stops. Stays. Convinces itself it's home. Even if a global minimum exists somewhere else, at lower energy, lighter, simpler - you'd have to climb first, and the herd doesn't climb. React is a local minimum. The web settled here when it got tired of looking. Stable enough. Defended by enough career investment. Surrounded by enough tooling and tutorials and framework-specific bootcamps that switching costs feel existential. The ground state - simpler, faster, closer to what the web actually is - sits somewhere else, past a hill that looks too steep from inside the valley. The ground state is always simpler. That's not a philosophical position. That's thermodynamics. They don't want you to know that.

ProcessWire and photo-heavy sites go hand-in-hand. But these sites can also present development challenges, especially when cloning a large site. This post goes into detail about techniques you can use to keep lightweight development sites without all the photo/image overhead. https://processwire.com/blog/posts/developing-photo-heavy-sites/

PromptAI v2.7 released Adds support for the fantastic RockPageBuilder module. Prompts are now usable in all text, file and image fields inside RPB blocks.

PromptAI v2.5 & v2.6 released Two updates for PromptAI: v2.5 adds a new per-prompt option "Ignore field content". When enabled, only the prompt text is sent to the AI — without the current content of the field. This is useful for prompts that generate content purely from placeholders (like »Create a short 400 chars summary of the following text: {page.copy}«) rather than processing existing text. Files and images are still sent as usual. v2.6 improves the prompt configuration interface. Prompts can now be duplicated and reordered using up/down buttons directly in the configuration. This makes it easier to manage larger prompt setups — duplicate an existing prompt as a starting point or rearrange the processing order without recreating entries.

A 100% protection is impossible in a browser environment, what a browser can show has to be local. But you can make it less easy to "steal" the files with preventing direct access and hotlinking to font files <FilesMatch "\.(woff|woff2)$"> RewriteEngine On RewriteCond %{HTTP_REFERER} !^https?://(www\.)?yourdomain\.com [NC] RewriteRule .* - [F] </FilesMatch> The most effective way to protect a font is to make it "incomplete" for anyone who steals it. By using the fonttools library (specifically pyftsubset), you can strip away all characters that aren't needed for your specific site. There is a little benefit too, the filesize shrinks 😉

PromptAI v2.3 — Inline Mode, Streaming, Placeholders, and more Hi everyone, It's been a while since the last update for PromptAI, and quite a lot has changed. Here's a summary of what's new since the last public release. Inline Mode The biggest addition is a new Inline Mode that adds magic wand buttons directly next to your fields. Instead of the "Save + Send to AI" workflow, you can now trigger AI processing on individual fields without saving the page first. The response streams in live and replaces the field content — but nothing is saved until you hit Save. Both modes (Page Mode and Inline Mode) can be mixed freely in the same configuration. Each prompt is configured as either "page" or "inline". Inline mode works with all supported field types: text fields, TinyMCE/CKEditor fields, image descriptions, file descriptions, and custom subfields — including inside repeaters. Streaming Responses AI responses now stream in real-time via Server-Sent Events (SSE). You can watch the text appear token by token instead of waiting for the full response. This obviously only works in inline mode. Placeholder Support Prompts can now reference other field values from the page using `{page.fieldname}` syntax. Inside repeaters, use `{item.fieldname}` to access the current repeater item's fields. Examples: - Summarize the following text to 400 characters: {page.body} - Create an SEO meta description for a page titled '{page.title}' - Write a caption for this gallery item titled '{item.title}' from the {page.gallery_name} collection This makes prompts context-aware without having to send field content manually. Multi-Field Selection Instead of configuring a single source field per prompt, you can now select multiple fields. The same prompt will be applied to each selected field. This replaces the old source/target field concept — the "target" is now only used for subfield options in file/image fields. AI Tools (experimental) The module now ships with three experimental tools that allow the AI to query your ProcessWire installation: - getPages — find pages by selector - getPage — get detailed info about a single page - getFields — list available templates and their fields These are disabled by default and must be enabled in module configuration. They're meant as starting points — their usefulness depends heavily on your use case and I recommend to create your own for each projects specific demand. Other Changes - PHP 8.3 is now required to use this module Important: Backup Before Updating The internal configuration structure has changed significantly. The old `sourceField`/`targetField` concept has been replaced with a multi-field `fields` array and a separate `targetSubfield` option. There is no automatic migration for this change. I'm sorry for the inconvenience — the old structure simply didn't support the new features. I attached two short screen videos showing the prompt config screen with example prompts and one page edit screen where I showcase some of the predefined prompts. As always, feedback and bug reports are welcome — either here or on GitHub. promptai-showcase.mp4 promptai-config.mp4

This works like a charm. Thank you very much, @Robin S! I really appreciate it.