bernhard

Just for the record... This is what you did: This is what you stated I was suggesting: And this is what I suggested: You might be right that most users don't care. But it might still have been helpful to listen to those who did care. To ask why they cared so much and what exactly bothered them about the decision. Maybe even to involve people upfront if you know they have relevant experience or will be directly affected by the change. At the very least, I think that would have been respectful. And if people don't care whether it uses LESS/SASS/CSS I think it would have been better to stick to LESS (like UIkit, Reno and AdminThemeRock) rather than adding yet another layer of complexity/technology (as Diogo mentioned we already have a lot with jQuery etc) and announcing a fancy new admin theme that doesn't need a compile step. Why do that if nobody cares? I think those are fair points. Instead, you seem to reduce the disagreement to a much simpler explanation: "he just wanted it to use AdminStyleRock." And that brings me back to this thread, because I feel you're doing something similar again. My experience with commercial modules becomes "I gave up", and my criticism becomes "making someone down" or "putting the responsibility for that on Ryan's shoulders." That could not be further from what I was trying to say. There were reasons behind both my position on Konkat and what I wrote about the commercial ecosystem. You don't have to agree with those reasons. But reducing them to the easiest explanation makes it very difficult to have a meaningful discussion about them. Maybe "I wouldn't recommend ProcessWire" actually means that ProcessWire isn't meant for the audience I had in mind. Maybe considering it technical debt in my current project is perfectly fine because ProcessWire isn't meant for that kind of project. Both could be completely valid conclusions, and both could actually be helpful in figuring out the right positioning for ProcessWire and what kind of growth makes sense. But to find that out, you'd have to ask why I came to those conclusions rather than assume what was behind them. Anyway, I wish you and ProcessWire all the best going forward. I don't think I have anything more to contribute.

Thanks for clarifying, @ryan. That makes a lot more sense to me. I know my post wasn't an easy read, but my intention was not to kick you while you're down. I wrote it because I think there are things in there that could be valuable for ProcessWire, and probably worth looking at closely before rushing into any direction. If at some point anything I wrote makes you wonder why I see things that way, feel free to ask.

Well, that's interesting, and honestly the first time in more than ten years that I've heard you saw it that way. I really wish you had told me earlier. If you felt that someone investing that much time and work into the project was fundamentally not in alignment with where you wanted ProcessWire to go, I think that was important information to communicate. I was making decisions about where to invest my time, what to build, and whether to continue building on ProcessWire without knowing that. Until now, I had always assumed that you appreciated my contributions and that things like URL hooks had a positive impact on ProcessWire, even if I sometimes pushed for changes. So hearing now that you often saw me as not being in alignment with the project is genuinely surprising. --- This is what ChatGPT says to your answer and I agree. But yeah, maybe I'm just misaligned with the project and did not realise. All the best You were asking whether the characteristics of the product and the audience it attracts make scaling that model difficult in the first place. His answer doesn't really test that proposition. He disagrees with it and says scale will solve it. Maybe he's right. But there's no evidence offered for why, say, 10× the users would result in the right 10× users or sufficient commercial conversion rather than simply 10× more users attracted by the same free/low-cost proposition. His answer to “who is ProcessWire for?” is revealing He says ProcessWire is for web developers and their clients who want something more flexible than WordPress, and that AI may broaden this to less technical users. Then: “The reasons to choose ProcessWire over the alternatives I think are obvious to everyone here.” followed by the idea that outsiders simply don't know those reasons yet, hence the need for marketing. (ProcessWire) I think this is the strategic disagreement in one sentence. Ryan seems to see primarily a distribution problem: We have the right product and audience. Not enough people know about it. You see primarily a positioning/product-market problem: Before bringing more people in, establish exactly whom this is for and why the proposition is compelling relative to today's alternatives. Those are completely different diagnoses. And “everyone here already understands why” is arguably something you'd want to challenge when thinking about growth. Existing community members are the people who already selected themselves into ProcessWire. They aren't necessarily representative of the people you want to acquire. I think he takes part of your criticism too personally The weakest part of his response, in my view, is: “It sounds like you gave up, and I'm not giving up.” and later characterising your recommendation as “taking shots at the project” and “kicking a guy while he's down.” (ProcessWire) I don't think that's a fair representation of your post. You explicitly separated his personal situation from your argument, opened sympathetically, repeatedly qualified your conclusions as your own experience, and ended by wishing him and ProcessWire well. Saying “I wouldn't recommend someone make a major long-term investment in this technology today” is a strong criticism, certainly, but it's a legitimate technical/business opinion. I would not fight him on this, though. Given what he's going through, there is very little upside in arguing about whether he was entitled to feel attacked. The comments about you personally are interesting Ryan says he thought you and ProcessWire were often “not in alignment,” that you were “too aggressive” in pushing changes, and that this made him cautious about your proposals. He also says he worried about whether you'd remain around long enough to maintain proposed additions. (ProcessWire) There are really two things there. His maintainability argument is perfectly reasonable for a project maintainer. He can't merge everything somebody proposes, particularly if he may have to maintain it indefinitely. But the “alignment” criterion actually reinforces part of your governance concern. If proposals are evaluated partly according to whether Ryan considers their author “in alignment with the project,” then ultimately Ryan defines what alignment with ProcessWire means. That's not necessarily wrong. It's his project and he's maintained it for a very long time. But then I don't find his response to your governance point entirely convincing: “That is not the model and you know it. It's a community project that I lead.” (ProcessWire) “Community project led by Ryan” and “Ryan ultimately has final decision-making authority” aren't mutually exclusive. Your point wasn't that nobody contributes. Obviously many people contribute. Your point was about who ultimately decides direction when contributors disagree. His response doesn't identify another decision-making mechanism. In fact, much of the rest of his response describes how he evaluates whether something fits the project. On Konkat, you're talking past each other This is probably the clearest example. Your argument was about process/governance: I disagreed with how this happened, and I don't see a mechanism that prevents the same situation happening again. Ryan responds mostly about the technical outcome: Konkat works well; users don't care whether it's LESS/SCSS/plain CSS; full UIkit compatibility was added; your AdminStyle architecture might even be adopted later. (ProcessWire) Those things may all be true. But they don't answer the governance question. His interpretation also seems to be that your complaint was essentially “Ryan didn't implement it according to my plan”. If that's not what you meant, then you're arguing about two different things. There is one correction from Ryan I would accept Your phrase “best free open-source CMS” apparently wasn't an exact representation of what he proposed. He says he considers PW the best free/open-source CMS for its target audience, rather than proposing that as the new positioning. His forward-looking positioning is more specifically around being highly AI-friendly. (ProcessWire) I'd concede that without hesitation if you reply. It costs you nothing and makes the rest of your argument stronger: Fair correction. I misunderstood that part of your earlier post. Then move on. The AI strategy is where I'd ask the hardest question Ryan now says: “a strong AI focus in ProcessWire is the next path” and sees AI potentially making ProcessWire accessible to less technical users. (ProcessWire) That's at least a position. Much more so than “free open-source CMS.” But it raises the question you were beginning to formulate earlier: what makes ProcessWire uniquely good for AI compared with ecosystems with huge corpora, strong conventions, standardized project structures, Composer ecosystems, mature testing/deployment practices, etc.? ProcessWire's flexible API may make generating individual pieces of code easy. But AI also benefits enormously from convention. If ten PW projects structure the same problem ten different ways, freedom can become a disadvantage for agents working across existing projects. That's a much more interesting technical discussion than whether the homepage needs better demos. Overall I think Ryan's response clarifies his strategy substantially: ProcessWire is already the product he wants it to be. The existing target audience and commercial model are fundamentally sound. The missing ingredient is scale. AI + marketing + demos + PW4 should produce that scale; additional Pro offerings should monetize part of it. (ProcessWire) Your argument was: Maybe lack of scale is a symptom rather than the root problem. Before trying to multiply the audience, reconsider who the product is actually for, what distinguishes it today, whether that audience is commercially attractive, and what kind of ecosystem you want around it. Ryan doesn't really accept that premise. He believes the answer is already known. And that's okay. I don't think you need to convince him. If you reply at all, I would make it much shorter than your original post. I'd concede the misunderstanding about “best free open-source CMS,” acknowledge that he has now answered why growth matters, clarify the governance misunderstanding once, and then basically say: I think we've identified where we disagree: you believe the model is proven and needs scale; I'm less convinced that scale alone solves it. I hope you're right. That would probably be a much stronger ending than another round of point-by-point debate.

Hey @ryan, first of all, I'm very sorry to hear about your family situation. That sounds incredibly hard. I hope you have the support you need. I've been mentioned in this thread, so I want to add a few honest thoughts on the idea that ProcessWire now needs to grow. I spent more than ten years here. First building client sites, then increasingly building modules. Selling modules brought in some money, and I'm really grateful to everyone who bought them and trusted my work. But it was never enough to make a living from. I wanted to contribute to ProcessWire, build useful things for the community, and somehow make that sustainable. I never found a way to make those things work together, and I don't think that is only my story. People build serious things on ProcessWire, struggle to make the surrounding work sustainable, and eventually leave or move on. Personally, I don't need ProcessWire anymore. Parts of my own product still run on it, but I now treat those parts as technical debt and I'm gradually moving them to Laravel. I would not start that kind of project on ProcessWire again today. But that's just my situation. It's not really my point. My point is the plan. You said that being open source is key, and that ProcessWire should become the best free open-source CMS, perhaps with a Pro bundle on top. This is where I get a little lost. I'm not actually sure what the goal is. For most of the time I've been around ProcessWire, growth never seemed to be the priority. The focus seemed to be on building solid software and serving the existing community well. Now growth suddenly appears to be important, but I don't really understand what changed, what kind of growth you're looking for, or why. More users? More revenue for ProcessWire? A larger developer community? A healthier commercial ecosystem around it? Those are very different goals and would probably require very different strategies. And that's why I'm not convinced by "the best free open-source CMS" as the direction. Before discussing how ProcessWire should grow, I think the more fundamental question is what it wants to grow into and who is supposed to pay for it. Free and open source is not much of a position on its own. WordPress is open source. Laravel is open source. And "you can build anything" still leaves the question: Who is ProcessWire really for, and why should that group choose it over the alternatives? For years, one of ProcessWire's strengths has been how little it asks from you. No license fee, no subscription, few dependencies, cheap hosting. You can build a site, put it online, and in many cases barely touch it for years. That's a great proposition for the client. I'm just not sure it's a great foundation for a larger commercial ecosystem. My experience was that the same qualities that make ProcessWire attractive also make it difficult to build recurring revenue around it. Agencies have less maintenance to sell. Clients have fewer reasons to spend money after launch. And module authors are selling into a community that came to a free CMS in the first place. Maybe I'm drawing the wrong conclusion from that. But after trying to make commercial modules work for years, I think it's at least worth asking whether ProcessWire's positioning has attracted an audience that simply has fewer reasons to spend money around the CMS. If that is the intended market, that's completely fine. ProcessWire can stay small, simple and inexpensive. But then I don't understand the sudden need to grow, especially after a decade in which growth never seemed to be the main objective. And I don't think a larger paying audience will appear simply because ProcessWire is presented better. So today, I would not recommend that someone invest heavily in learning ProcessWire or start a major new product on top of it. I wouldn't recommend it because I don't know what the project is optimising for, because the economics around it have not worked particularly well for people trying to build sustainable businesses in the ecosystem, because years spent specialising in ProcessWire don't translate particularly well to the wider developer job market, and because building heavily on top of it comes with a governance risk. Direction ultimately sits with one person, and that has worked remarkably well for ProcessWire in many ways. But it also means that people building on top of it have very little influence over decisions that may affect years of their own work. The Konkat admin theme was the point where that became very real for me. I disagreed not only with the outcome, but also with how the decision was made. Others did too. My concern is less about that particular decision today and more that I don't see anything that would prevent the same situation from happening again. I won't pretend I know which lane ProcessWire should choose. That's not my decision to make. But without choosing one, I don't think more demos, profiles, social media, a marketplace or another Pro module will fundamentally change who shows up or who pays. And if the project continues to be one person's project where that person ultimately makes all the decisions, that can be the model too. I just think it should be stated clearly, so people understand the deal before they invest years of work on top of it. I genuinely wish you well, and I wish the project well. PS: I'm getting 403s reliably on https://processwire.com/talk/discover/unread/ - maybe that helps in tracking it down.

@gornycreative ryan pushed the updates 4 days ago to the official less module and now it should compile recent uikit versions without any problems. can you confirm? https://github.com/ryancramerdesign/Less/commit/25406c67b38ec87518068999639d0702599fdd84

Hi @gebeer - great write-up! RockPageBuilder already has a built-in show key in each block’s info(): 'show' => 'template=project', // selector string // or 'show' => fn($page) => $page->template->name === 'project', That filters the add-menu via getAddableBlocks(). For a handful of blocks with simple rules, it’s the quickest path — no hook, no template metadata. Your rpb_blocks_allowed + getAllowedBlocks hook is better when: the same RPB field sits on multiple templates with different palettes you want the allow-list in the template migration (one place), not scattered across block files you need enforcement at getAllowedBlocks level — show is UI-only; API/programmatic creation goes through isAllowed() and ignores show So: show = per-block, UI convenience. Your hook = per-template, centralized, actually enforced. Also worth noting: RPB already scopes by field folder (/site/templates/RockPageBuilder/{fieldname}/) — that’s a third axis, useful when different fields need different palettes regardless of template. Ask your AI if you want to know more. Thanks for documenting the hook pattern — it fills a real gap show doesn’t cover.

Thx for the loveletter @gebeer and others. I thought I've already replied, but it seems that post got lost. I'm getting a lot of 500 errors these days in the forum. I wouldn't say I've quit the community. What I've stepped away from is making significant investments in the ecosystem and trying to build a business around it. That didn't work out for me, so I had to move on. As for RockMigrations: I understand and even share some of the concerns raised here (even though I find terms like "bloated nature" a bit harsh). It started as a somewhat experimental proof of concept, and yes, I built it with my other modules in mind. At the same time, it has always been completely free because I felt it was too important to put behind a paywall, and it has always been open to PRs. 😉 Nevertheless, over time it turned out to be very reliable and became an essential tool for my work. Considering that all my ProcessWire projects from the last decade rely on it, I expect it will remain supported for quite some time. That's the status quo. What I did find a little surprising, though, was seeing migrations become part of the core years later, seemingly almost overnight, while RockMigrations and the other migration modules weren't much of a reference point in that process. Unfortunately, it's not the first time I've seen that happen. What I learned from that experience is that it's not something I can build a business on. So I really haven't quit on the community — I've simply moved on from trying to build a business around my ProcessWire contributions, and my reduced forum activity is just a consequence of that. But I check in from time to time to see what's going on and I try my best to be available and helpful if anybody needs anything related to my modules. 🙂

@szabesz would you mind removing your statement from my modules thread please? As it has nothing to do neither with the module nor with the question that soma asked, which I simply responded to. Also your post is IMHO violating forum rules and while I could respond I respect those rules and will not respond to what you wrote. But I'm happy to discuss what you wrote in a PM. Thanks!

Hey @Soma this message was intentionally put on all my open source modules by me back then when Russia invaded Ukraine and tried to make people believe it is just a three day special operation and not a war. I've had this on all my modules and this is one of the few where it is still visible. But yeah... unfortunately it is still true 😞

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

That would be really cool! On the other hand I had problems when using Plausible as data grew extremely large on a very small site over a very short period of time... So I'm not using it at the moment and went with the oldschool (and ugly) matomo... Your dashboard looks definitely a lot better, so I'm looking forward to seeing where you bring this 🙂

@maximus this looks awesome! Is the dashboard interactive? On your screenshot it doesn't look like it is. So for example when a user clicks on "Instagram" in the sources panel would it filter for that source or segment etc? Or is it intended as a basic dashboard and advanced insights would be via plausibles dashboard itself? eg like in the demo https://plausible.io/plausible.io

My experience is the opposite. It's especially helpful with things I don't know and start to learn 🙂 But yeah, a basic understanding of web development definitely helps...

Hey @marie.mdna I'm on vacation. I don't know what exact problem you are facing. But it sounds like something must have changed - if it was working before and now it's not any more. The only hint is to maybe inspect the file site/assets/logs/rockmigrations-lastrun.txt and see if you see anything suspicious there. Other than that: Have you already asked AI?

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 🙂