Leaderboard

Seriously? Is this why you're disappointed with our community? Are you even an adult person? If you're so worried about the environment, you should start by quitting programming yourself, dude. Producing a single new laptop generates approximately 331 kg of CO2 emissions, while desktops create up to 948 kg of CO2. The manufacturing process accounts for 75%-85% of this impact, consuming 1,200 kg of water and 239 kg of fossil fuels. Globally, electronics contribute significantly to 62 million tonnes of annual e-waste. The software industry, part of the broader ICT sector, is responsible for approximately 2% to 4% of global greenhouse gas emissions, a figure comparable to the entire aviation industry. These emissions stem from both the energy consumed during software operation and the "embodied carbon" from manufacturing hardware. Key Environmental Impacts of Laptops, PCs, and Software Development: Carbon Footprint: Manufacturing a new laptop produces over 300kg of CO2 Resource Intensity: Creating one computer requires 1.5 tons of water, 48 pounds of chemicals, and 530 pounds of fossil fuels. E-Waste Generation: Small IT equipment (laptops, phones) generates 11 billion pounds of global e-waste annually. Toxicity: Improperly discarded computers leak toxic heavy metals, including mercury, lead, and chromium, into the environment. Manufacturing vs. Use: For battery-powered devices like laptops, 80% of total emissions occur during production, not during usage. Industry Impact: The ICT sector is responsible for roughly 3.7% to 3.9% of global greenhouse gas emissions, a figure comparable to the entire aviation industry. Growth Projection: Emissions from this sector are expected to rise significantly, potentially reaching 14% of global emissions by 2040. Development Impact: Creating a single, light software feature can produce about 60 kg of CO2, while a "heavy-duty" feature can generate 300 kg or more. Key Drivers: Major contributors include data center energy consumption, network infrastructure, and the energy used by developers' machines. The rapid replacement cycle (typically 3 years) is driving these figures, with e-waste expected to reach 82 million tonnes by 2030. Only 17.4% to 22.3% of global e-waste is formally recycled, with the rest ending up in landfills, often polluting soil and groundwater in developing countries. Ryan's reasoning makes much more sense than yours. We should repeat politically correct slogans less like a parrot and use a little more common sense and human reasoning.

This week on the dev branch we've got several commits with various core improvements and fixes. @adrian has been using Claude Code to suggest core optimizations (focused mostly on the PageFinder) and so he sent the suggestions to me. (PageFinder is the brains behind the $pages->find() method, and many others). I took the suggestions and coded them into our PageFinder, but didn't want to mess with what was already working well, so put them in a new class named PageFinder2, at least temporarily. If running the latest dev branch, you can enable PageFinder2 by adding the following to your /site/config.php: $config->PageFinder('version', 2); The most significant changes are: using subqueries for subselectors rather than separate independent queries; Reusing PageFinder instances (keeping a pool of typically 1-3 PageFinders rather than creating a new one for each $pages->find() operation); and lots of in_array() calls have been converted to isset() lookups, which should technically be faster (still the case in PHP8?, I'm not sure). There were some other changes as well. Theoretically these changes should make PageFinder even faster than it already is. I did quite a bit of testing and found that for the most part it performs the same as PageFinder v1. But then I came across a rather complex selector that translated to a much faster PageFinder operation, nearly twice as fast, and that convinced me it was worthwhile. While PageFinder v2 is not consistently faster than v1, there are some situations where it can be a lot faster. I'm not totally clear on what those situations are just yet, but I'll be doing more testing. In other situations it also can use a lot fewer queries, though that doesn't necessarily translate to a performance difference. But on the whole, all of Claude's suggestions were quite good, regardless of performance improvements. I was pretty impressed with what Claude Code had suggested, so decided to install it on my computer too. I've found it's particularly good at finding bugs. I'll ask it to do a code review on a core file, and it always has good suggestions. It uses ProcessWire terminology too. For instance it pointed me to an object that wasn't properly "wired to the ProcessWire instance", and that's something you'd only ever hear in ProcessWire land. Claude code also helped with improvements to our DatabaseQuery* classes, PagesVersions module, Wire base class, NullPage class, and minor updates to the PagesLoader* classes. I'm not having it write any code just yet, but am having it suggest where improvements can be made. I like to code. I asked it how it knew so much about ProcessWire, and it said that it stays up-to-date with the forums, the website, API docs, and GitHub repo. Thanks to @adrian and @Jan V. for recommending it to me (Jan V. uses it to manage this webserver), I can see how it's going to be a big help to ProcessWire with its suggestions and ideas, I'm already learning a lot from it. And if you get a chance to try the updated PageFinder, please let me know how it works for you. Thanks for reading and have a great weekend!

Thank you! Works perfectly 😀

Hello @adrian that's great, I had an older version (from 2022) on my machine, so I installed it on my local ProcessWire which I use for my French translations (so it's not necessarily representative of all situations, as it's always up to date with the latest version, ProcessWire 3.0.256 © 2026). then I commented out the module folder and replaced it with the namespaced version folder. After a short normal update time, the only thing visible was a small alert ModulesInfo: Upgrading module (TracyDebugger: 4.23.40 => 4.28.0) the site is still up and running, no errors, and Tracy seems to be working fine. tried on a php 7.4.9 and 8.1.31 hope this may be somehow useful have a nice day

@mattgs Like Adrian, I also consider myself very environmentally conscious. I've not spent much time learning AI in part because I thought it was problematic for a lot of reasons. But I don't think we're likely to stop these AI companies so that's why I thought I should try things out with a company that seems to have more ethics than the others. Anthropic seems to have a mission for AI safety and sustainability. I hope it's legit. And as far as I can tell, the other companies don't, which I find concerning. But I'm also not as up-to-speed as you are on the on the issues you brought up, so I'll have to look closer as well as check out the video you mentioned (do you have a link?). I'm also aware that a project like ProcessWire gets executed millions upon millions of times every month (or day?) throughout the world, and every execution consumes energy. So I've always been very interested in optimization and making ProcessWire use as little time and energy as possible to do its work. The updates that we've been focusing on here are aimed directly at that. So perhaps AI is using a little energy to find optimizations and bugs in PW, but that single brief code review session reduces the energy usage of every ProcessWire execution going forward. This is a case where AI is likely saving a lot more energy than it consumes, indirectly by making ProcessWire use less energy. Some of the optimizations and bugs its found have been there since the beginning, and likely would have never been identified otherwise.

Some updates to the Processwire / Cursor MCP Module. But first a recap (composed by Cursor) ProcessWire MCP — 360 Content Sync Between Cursor and Any ProcessWire Site With this Cursor MCP module for ProcessWire, you can say "Pull the about page, update the intro, and push it to production" — and Cursor does exactly that. No CMS login, no FTP, no copy-paste between environments. The module gives Cursor full read and write access to any ProcessWire site — local or remote — via a secure API. Pull pages down as editable YAML files, make changes in your IDE, and push them back. Or go the other direction: scaffold new pages locally and publish them to production in bulk. Fields and templates sync the same way, with diff previews and dry-run support before anything is written. The practical result is a genuine 360 workflow — content and structure moving freely between your local dev environment and any live site, driven entirely by natural language prompts in Cursor. What's new in this release: Remote site connection Cursor can now connect directly to any live ProcessWire site over HTTPS. Previously all MCP tools only worked against your local database — remote changes meant logging into the CMS admin manually. Now a single configured API endpoint is all that's needed. Schema sync — push, pull, diff Field and template definitions are exported as versioned JSON files. Compare your local schema against production, see exactly what would change, and push with a single prompt. Think of it as Prisma migrations for ProcessWire. Previously adding a new field to production meant recreating it by hand in the admin and hoping it matched local. Page content sync — pull Any live page can be pulled down to a local YAML file. Your content is now code — version-controlled, editable in your IDE, and diffable like any other file. Previously content only lived in the database and the only way to edit it was through the CMS. Page content sync — push Edit content locally and push it back to local, production, or both simultaneously. Dry-run is on by default so you see exactly what will change before it's applied. Cursor writes directly to the ProcessWire database via the API — the CMS admin is never involved. Create and publish pages remotely — without touching the CMS Scaffold a new page in Cursor, write the content, and publish it directly to production in one step. Template, parent, name, fields, and published status are all set via a single prompt. This is the foundation for more powerful automated workflows — bulk landing page generation, scheduled blog publishing, or programmatic content pipelines driven by keyword data or external feeds. Cross-environment page reference resolution Pages that reference other pages (a homepage featuring service pages, for example) previously stored those relationships as raw database IDs. Those IDs differ between local and production, so pushing a page reference to a different environment would silently link to the wrong page — or nothing at all. References are now stored with their URL path and resolved correctly on whatever environment receives the push. Pre-push reference validation Before any push, a new pw_validate_refs tool scans every synced page and checks that all page references actually exist on the target environment. It reports missing references (which would blank the field on push) and unpublished references (valid but hidden) separately. Previously a broken reference had no way to surface until it caused a visible problem on the live site. Coming next The next phase adds a staging environment tier (local → staging → production promotion), matrix and repeater item sync, and autonomous content publishing — where an external scheduled process generates and publishes SEO-optimised content directly to ProcessWire without Cursor or the CMS admin being open at all.

@mattgs - I am very environmentally conscious (it was my career in a previous life). The decisions we make in life are hard and never black and white. If AI can make us be more effective developers so we can create things faster and better, then we might actually be able to help people and the planet in the process, or maybe volunteer for good if we have more spare time available. Maybe AI can help us to figure out ways to get off oil faster, or preserve species on the brink of extinction. I really don't know and I have a lot of concerns about AI in the bigger picture, but we're definitely not going to stop it at this point, so let's try to use it for good as best we can.

@teppo Thanks, good to hear the more I use it, the more I'll be blown away. I've been using AI ever since ChatGTP first came out, but primarily just for technical questions and such. For instance, a couple months ago Claude helped me figure out how to reduce static pressure in our HVAC system by rebuilding (DIY) the return plenum and filter rack, and it was super helpful. I posed the same questions to GPT and Gemini but they weren't nearly as helpful. This week is the first that I've gotten into collaboration with the actual code. Adrian showed me all the things Claude Code had recommended for the PageFinder, and I found myself really liking what it had found and suggested... Seemed like we were on the same page, just like with the HVAC work. The other thing is that I've found it a little overwhelming with all these models (GPT, Grok, Gemini, Claude, etc.) with big changes almost weekly, and if these companies were ethical and ones I'd even want to be putting money towards. Then I learned about why they created Anthropic in the first place, and last week heard how they were sticking to their ethics and wouldn't cross their red lines despite government pressure. Sounds like integrity to me, something that is hard to find with big companies. That opened my comfort level and clarified for me that Anthropic's Claude Code was a good place to dive deeper with this stuff.

@ryan - In case you missed it, there’s a thread about how people are using AI with ProcessWire here if you’re interested?

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.

i use infomaniak.ch for couple projects

It depends on what you want to achieve but basically with lazycron you specify a time interval target and whenever someone loads a page the lazycron checks if the interval has passed and then triggers its function. This means that depending on where you put the hook, it may check more often or not: if you put the code in a template, then the lazycron is checked only when a guest is visiting a page with this template. However if you put the hook in init.php (or ready.php) then the lazycron will be checked for every pageview, even the admin ones.