Leaderboard

Hi everyone, I'd like to introduce Banana Imagine — a ProcessWire module that brings high-quality AI image generation directly into your image fields using the Google Nano Banana API. Key features: Clean generation interface right below supported image fields Generate 1–4 variations at once Smart subtle prompt variations for better batch diversity Selected images saved natively to the page (with clean naming: [pageID]-[timestamp].jpg) Simple configuration: API key + choose which image fields to enable GitHub: https://github.com/mxmsmnv/BananaImagine This module is a fork / spiritual successor to my previous module GrokImagine (xAI/Grok-based): https://processwire.com/talk/topic/31744-grokimagine-ai-image-generation-via-xai/ Installation & usage instructions are in the README: Just drop the folder into /site/modules/, install, add your Google AI API key (billing required for image gen), select fields → you're good to go. Screenshots: Feedback, bug reports, and feature ideas are very welcome! Thanks, Maxim

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.

Hi @ryan - I mentioned this here: https://github.com/processwire/processwire-issues/issues/2184#issuecomment-3901936805 but I want to make sure it isn't lost. I really think PW needs a $config->cspNonce that gets injected into all core scripts and can be used by all module developers as well. I am doing this in my config.php $config->cspNonce = base64_encode(random_bytes(16)); but if it was in /wire/config.php we could all use it - in modules and template files. Another possibility is maybe have a core method like: function getNonce(): ?string { return preg_match('#^Content-Security-Policy(?:-Report-Only)?:.*\s(?:script-src|script-src-elem)\s+(?:[^;]+\s)?\'nonce-([\w+/]+=*)\'#mi', implode("\n", headers_list()), $m) ? $m[1] : null; } that finds an existing nonce set for either script-src or script-src-elem and use the result of that to add to core scripts (src file and inline). But I don't think PW should set the CSP itself - I think that should be up to us. Please let me know if you have any thoughts or questions - I've been trying to up my game in the CSP area and this would make life a lot easier because at the moment I can't lock down the PW admin without it so I need separate CSP's for frontend and admin.

Hi everyone, I’m excited to share a new module I’ve been working on: GrokImagine. It integrates the x.ai (Grok) API directly into the admin interface, allowing you to generate AI images on the fly for your Pageimage fields. Instead of leaving the CMS to generate assets, you can now do it right where you need them. Key Features: Progressive Loading: Unlike many AI modules that make you wait for the whole batch, this one loads images one-by-one as soon as they are ready. Batch & Variety: Generate up to 4 variations. The module intelligently tweaks prompts for batch requests to ensure you get different angles and compositions rather than duplicates. Aspect Ratio Control: Built-in selector for 16:9, 1:1, 9:16, and 4:3. Model/Resolution Settings: Support for both grok-imagine-image-pro and standard models, plus 1k/2k resolution toggles. Seamless Integration: Enable it only for specific image fields via the module settings. How it works: Enter your API Key from console.x.ai in the module config. Go to any page with an enabled image field. Type a prompt, hit "Generate," and watch the "skeletons" fill up with images. Click the ones you like (blue checkmark) and save the page—the module handles the WireHttp download and adds them to your field automatically. GitHub Repository: https://github.com/mxmsmnv/GrokImagine Installation: Download or clone into /site/modules/GrokImagine. Install via the Admin Modules dashboard. I’d love to hear your feedback or any suggestions for future features! 🍀

Thanks @maximus - looks good so far - I'll keep testing and let you know if I find any other issues.

I wanted to add: This gives you basically something like context7. But locally with your very specific knowledge and not implemented as MCP but as skill which has less overhead in the context window. And you could modify it easily for other knowledge. Different frameworks, whatever.

Yes, very good results. It's fast and pretty token efficient. You can connect it to an already open browser wit a logged in session etc. no need for auto-login route. let your agent read the mcp instructions. mine said to start chrome with a debug flag. Let me pulled that up through my conversation-search MCP quickly. Here it is :-) Launch command (detached from terminal): setsid chromium --remote-debugging-port=9222 &>/dev/null & - --remote-debugging-port=9222 — enables CDP so the MCP can connect - setsid — creates a new session, fully detached from the terminal's process group (plain nohup doesn't survive terminal close because the terminal sends SIGTERM, not just SIGHUP) - &>/dev/null & — suppresses output and backgrounds it That's for Linux but should work on your Mac, too. In that browser you open your PW project, backend and then the mcp can connect. That's the way it's supposed to be done, I guess.

Good news — found the root cause. The fake browser detection was checking for Sec-CH-UA (Client Hints) and Sec-Fetch-* headers, which browsers only send over HTTPS or to public origins. On http://localhost these headers are simply never transmitted, so Chrome was being flagged as headless automation and blocked on the very first request — before any rate limit counter even started. Fixed in 1.3.5 — the module now detects localhost and RFC-1918 private addresses and skips those header checks for local requests. All other fake browser checks remain active. Please update the module and let me know if that resolves it.

SOLVED: force form to scroll to top after submission? I found a solution for me. Pretty simple, feels a bit hacky, but works as intended: // form.php $fbutton = new \FrontendForms\Button('submit'); $fbutton->setAttribute('value', 'Send message'); $fbutton->setAttribute('onclick', 'scrollToTop();'); $form->add($fbutton); // main.js function scrollToTop() { window.scrollTo({ top: 0, behavior: 'smooth' }); } Maybe this can help someone with a similar problem ...

Last week I upgraded all our sites to ProcessWire 3.0.255. Thank you as always for your amazing work @ryan 😄 Also switched all sites to the new admin theme and love it so far. Thank you @diogo and @jploch 😘 One small request: Could you please make the page tree more compact on mobile phones (in this example iPhone 12)? There is some white space that could be removed.

I have more and more customers complaining that they can't upload webp images. I understand that webp is not the ideal master image format, but neither is jpeg. The webp browser support is also so good now that it would not be necessary to generate jpeg/png versions from webp.