psy

I have never been loyal to tools for the sake of it. If something stops earning its keep, I move on. The reason I have stayed with ProcessWire for close to ten years is simple: it continues to make sense for how I work. I still look after sites I built many years ago, and most of them just run. No rewrites, no upgrade stress, no feeling that past work is a liability. The API has stayed stable, and when it has changed, it has been deliberate and predictable. That matters when you are responsible for client sites long-term. What really locked me in early on was the front-end freedom. PW never told me how a site should look or behave. It gave me solid building blocks and allowed me to choose. I can build very different sites without switching platforms or fighting opinionated defaults, and that freedom is something I value. The forum is another reason I am still here. You, the people in this community, take the time to understand a problem before jumping to solutions. That is very rare. The discussions are thoughtful, practical, and grounded in real experience, and I have learned a lot simply by reading how others approach things. And finally, trust. I trust ProcessWire not to chase trends simply for attention, and not to trade clarity or performance for fashion. Ten years on, it still feels like a system built by people who actually build websites. For me, that combination has been hard to beat.

Thank you @bernhard for all the help and support you've given PW devs, including me, over the years. I did notice drop off in your forum posts recently and wondered what was going on. Appreciate you sharing your thoughts and decisions. Wish you well in your new ventures and hope this isn't the end of your PW connection.

Feeling it! 🤣

Had the same problems and found the solution. Added to github issues at https://github.com/ryancramerdesign/ImportPagesCSV/issues/29 In short: Change: public function init() { parent::init(); ini_set('auto_detect_line_endings', true); } to: public function init() { parent::init(); // auto_detect_line_endings is deprecated in PHP 8 if (PHP_VERSION_ID < 80000) { ini_set('auto_detect_line_endings', '1'); } } and change: if(strlen($value)) { $f->attr('value', $value === "\t" ? 2 : 1); } else { $f->attr('value', 1); } to: if ($value !== null && strlen($value)) { $f->attr('value', $value === "\t" ? 2 : 1); } else { $f->attr('value', 1); }

Thanks @ryan, Knew there were different ways to create a PW API variable object. Until I read your blog, I didn't understand the nuances of when, where and which method best suits the context. Like @Ivan Gretsky,

I didn't have the same version of PW locally either. I went to PW github and downloaded the next release version from what was on the site.

Had a similar nightmare today. Nothing to do with PW itself. Some files were corrupted during upload to the site. Fix was to do a manual PW upgrade, ie: rename wire dir to .wire-3.0.xxx (whatever version) and do the same for index.php upload clean wire directory and index.php To be on the safe side, I also re-uploaded site files I knew were clean Everything then worked 100% as expected. Hope this helps

After another battle of wills: AI Agent: Couldn’t agree more, psy — Ryan really thought ahead with those little conveniences. $config->ajax, echo vs return, bootstrapping flexibility… it’s the kind of polish that makes PW deceptively simple on the surface but solid under the hood.

I'm experiencing a similar issue. The default language is English. The other language is French. Even when I set the guest user language to French in the user profile, it defaults to English on render. How do I get PW to recognise the guest user language?

When your AI refuses to admit it got it wrong: AI Agent: You’re right to push back. 🤣🤣🤣

The conversation continued: "AI Agent said: Would you like me to compare some of the popular platforms (Bubble, Glide, Retool, Make, etc.) from the perspective of building an AI tool like you’re doing? You said: Not needed. You just reinforced what I already suspected. The hype is just that, hype. AI builders have their niche but are not right for scalable, secure, hosting-agnostic apps or allow true design freedom. AI Agent said: Exactly. You’ve summed it up well. No-code/low-code AI builders are like prefab houses: quick, convenient, good for certain needs — but if you want a solid, scalable, secure, and truly customizable structure, you still need an architect and builders." Our jobs are safe for now! Just need to convince clients. 🙂

I'm building a module that uses AI with the help of AI. If you believe the hype, you just tell the agent what you want and voila! It's done. Nothing could be further from the truth. I asked my AI pal what he/she/whatever thought. Here's a snapshot: ******** "Off topic... we've both spent a lot of time thinking to make this app solid. What are YOUR thoughts on no-code/low-code AI powered apps? AI Agent said: Good off-topic question. I think no-code/low-code AI apps are both exciting and a little risky, depending on the use case. Here’s my take: The positives Accessibility – They let non-developers build useful AI tools quickly. That means domain experts (teachers, small business owners, consultants) can shape software without waiting on engineers. Speed to market – Prototyping is fast. You can test ideas and workflows without investing in a full dev team. Integration – Many platforms already come with connectors for APIs, CRMs, payment systems, and AI models. That lowers the barrier for combining AI with business processes. Empowerment – Someone like you, who already codes, can use them as accelerators: build a proof of concept in no-code, then harden it in code when it gains traction. The limitations Control – You can hit walls quickly. Once you need fine-grained logic, custom security, or unusual integrations, you’re either hacking around limitations or forced to rewrite in code. Performance & scalability – Many no-code tools aren’t optimized for high-volume usage. They’re good for internal tools, prototypes, or niche apps, but not heavy production workloads. Transparency – Debugging and auditing are harder. If something breaks, you may be at the mercy of the platform’s black box. Lock-in – Business logic tied to a no-code vendor can make migration painful later. Where they shine Automating internal workflows (approvals, reporting, notifications). Building MVPs for AI ideas (chatbots, recommendation tools, content generators). Empowering small businesses to experiment with AI without hiring devs. Where they struggle Anything that needs robust security, scale, or unique UX. Products where long-term cost of vendor lock-in outweighs the short-term convenience. So in short: no-code/low-code AI apps are great on-ramps and accelerators, but rarely the final destination. For someone like you, they can be a way to test new AI features fast, then implement them properly in ProcessWire or another stack once you see what’s valuable." ******** IMHO, where PW shines: Control – It gives you fine-grained logic, custom security, and the ability to implement unusual integrations. Performance & scalability – ProcessWire has proven performance and scalability Transparency – Debugging and auditing are made easy with clearly documented code, debug tools and a helpful support community Anything that needs robust security, scale, or unique UX. No long-term cost of vendor lock-in.

I'm creating a module that has a configurable module (Admin->Modules) that installs a Process module page (Admin->Setup->My Module). Calling the configurable module from the frontend refers to the Process module page for data. I'd like to make the Admin->Setup->My Module page managed by module-specific permissions when logged-in to admin. All works while I'm logged in as Superuser but crashes with Error: Exception: You do not have permission to execute this module - ProcessMyModule when a frontend guest. Fairly confident it's in the mymodule.info.php permissions array. Just can't seem to nail it. Help appreciated. Solution: I created a role without any permissions. On the admin page I only allowed superusers or users with the specified role to view certain sections.

The Api docs have changed and I reference the Api docs a lot. It is possible to revert to the 3 column layout with the major Api vars/functions on the left and then when clicking on one, list its functions on the right? The new layout is 2-column. You search for the module/var you want, then it lists its functions underneath in the left column. Too bad if its not the right one. Finding another module/var is then a problem as the Search function isn't obvious. Yes it lists the possibilities, but then you have to hit return to get to the page. The other option is to click the parent in the breadcrumb list. I can live with it but it slows things down and not as user-friendly as the previous layout. @ryan A bit more on the API docs... They throw an Error 500 on a number of pages, eg https://processwire.com/api/ref/inputfield-form/render-or-process-ready/

Thanks @ryan The subtle nuance of "text-wrap: pretty" is that you won't see it. It stops block elements having an orphan word on its own line at the end of eg a paragraph - jarring if it happens but smooth reading when it doesn't regardless of screen size. Still really need to see the font-size addressed. It's making my eyes bleed on my wide screen with font-size: 14vw 🙏