Weekly update – 14 August 2026

[Peter Knight]

I’d settle for simply getting these forum 403 errors fixed 😜

[ryan]

@Peter Knight Are you still getting 403s? I thought I'd fixed it. At least I haven't had any in awhile. If you all are still seeing them, let me know and I'll dig in further to figure out what's up. 

[Peter Knight]

Yep, every day 😕
It's quite random too. Is it filtering by IP or location?

[matjazp]

me too, every day, multiple times

[Klenkes]

me too, daytime doesn‘t matter.

[HMCB]

@ryan, I was hoping this was not the case. Separation and divorce, when you don’t want it, can be devastating. Especially when children are involved. As someone who went through this 13 years ago and am still recovering, in some ways, I encourage you to not push yourself too hard as if to plow through this period. I wish I had sought professional counseling to better cope and retain a measure of self-worth. As men, its not in our nature to ask for help, but it could very well be the best medicine as it can help not only as you undergo this, but for your long-term mental health and outlook.

Cherish moments of peace. They will come. Only you can go through this on your own terms, but know we have your back.

Much love.

Edited Saturday at 05:59 PM by HMCB

[HMCB]

On 8/16/2026 at 10:27 AM, ryan said:

When I say I have to find ways to grow and make ProcessWIre more sustainable, that doesn't mean changing the model of ProcessWire itself, as an open source project. The ProcessWire core is not a business. Instead what I think is needed: 

1. Take all necessary steps grow ProcessWire's user base.

• The Skyscrapers demo site is ancient--it needs to be updated or replaced. I think it's so old right now that it turns people away. I have started working on this already. But I think we need more demos too. Is anyone willing to create demo sites that we can link to from ProcessWire.com? Ideally ones that people could see how it works both on the front-end and the back-end.  I remember that @bernhard had done a great job of this to showcase some of the modules that he has built, and I think we need more of that kind of thing. 

• The current blank site profile is great for most of us here, but for new users, it's just not enough to show what ProcessWire can do. We need more compelling site profile options available from the install screen. I'd like a lot more site profile options available. I'd like our installer to be able to pull a list directly from ProcessWire.com and download the site profile as part of the installation. Would anyone be interested in building more starter site profiles for ProcessWire? We need to find the right balance between functionality and keeping the template files simple enough to be easily understandable. Though with so many now using AI, maybe being compelling and showing a lot of functionality carries more weight than having the simplest possible template files. 

• Much of the recent changes in ProcessWire have been aimed at increasing AI accessibility and discoverability. ProcessWire has 16 years worth of content on the internet, making it especially well known by many LLMs. I think we need to keep directing towards ProcessWire as the ideal CMS to use with AI. We've been building in API.md documenting into all key classes and modules in ProcessWire, we've now got a built-in test suite, and the API has been evolving quite a bit towards making it even simpler for AI agents (and humans) to work with. I think we need to keep this going, but I'd also be interested in any other ideas that you have in this area?

• We need a stronger social media presence. We need a lot of help here. For example, there regularly CMS and framework discussions on Reddit's r/webdev and other boards, plus the "looking for alternatives to WordPress" type of threads that appear on Reddit and around the internet. Maybe more needs toe done from the processwire twitter. Can anyone help with the social media side of ProcessWire?

• Recent contributions from Konkat for our site and admin theme have helped out a lot recently. I think we'll soon be in in good spot to re-launch ProcessWire with version 4. 

• Ideally the forums and store should be updated for the new/current PW site design. 

• What other steps should we take?

2. Improve and expand the services available for ProcessWire that produce income 

I don't make enough from Pro modules to survive without also doing a lot client work. Compared to client work, they don't add financial stability, though I enjoy the work and think they are useful services. But I need to either: 1) reduce focus on them (perhaps avoiding building new ones) and focus more on client work; or 2) Expand the commercial support and service options (like Pro modules) for ProcessWire. My preference is of course to put my efforts towards expanding Pro stuff if at all possible, sticking to the original mission, but I'm looking for feedback. Pro modules will continue either way though. 

• If we're successful with #1 above, then this could solve itself over the long term. But I need to make steps for the short term too. 

• Another thought is to have a new option, a "ProcessWire Pro" yearly plan that includes all of the Pro modules plus commercial support, consulting, proactive monitoring, and more? Not to replace the current Pro modules options, but as an additional option for those that want to use ProcessWire AND have guaranteed support and services (like Pro modules) included. I'm leaning in this direction. What do you think?

• What else?

 

 

 

 

 

 

@ryan, just some food for thought…

I have 30 years of brand-building experience. I have assisted companies of various sizes with positioning, strategy, and design. I have always thought that PW needs a more thoughtful approach to marketing. PW is so fundamentally sound, but it needs more than a little eye candy. And more eyes than what appears to be mostly developers who work with it. It needs more nuance and a deeper strategy. It pains me when I’m on Reddit and everyone speaks of all the CMSs out there with essentially no one knowing about PW.

[bernhard]

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.

[maximus]

[szabesz]

10 hours ago, bernhard said:

PS: I'm getting 403s reliably on https://processwire.com/talk/discover/unread/ - maybe that helps in tracking it down.

On my end, it is 403 all the time.

[ryan]

Quote

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. 

It sounds like you gave up, and I'm not giving up. For me this has always been a long term project, and now it's ready to scale up. But it's a long term project for me either way.

Quote

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.

I don't think ProcessWire was a good fit for you, and I felt like you were regularly proposing stuff that wasn't a good fit for ProcessWire. So I always felt like you and I were not in alignment, and I totally understand why you'd want to move on to something else. But there were exceptions, like the work you did with the Uikit admin, and of course I know that your RockMigrations is very well liked in the community, among other great modules you've built. I always had to look at the core from the bigger picture, and I hope you can understand that. I have to maintain this project long term, so have to look at feature additions through the lens of whether it benefits the project in that long term, and whether you were someone that would stick around long enough to continue maintaining what you were proposing. You were always a bit too aggressive in pushing me to do this or that, and so I sensed that you were not someone that was a good fit, which made me cautious about your proposals. Just being honest. But I also like that you challenge me, and I think you and I would be great friends in person. 

Quote

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.

Just to be clear, I have not suggested that ProcessWire should "become the best free open-source CMS". I think it already is the best free open source CMS, but for our target audience. I don't believe there is a best free open source CMS for everyone, as it depends entirely on one's needs. Now I have suggested that ProcessWire is on track to be the most AI-friendly open source CMS, and might already be. 

Quote

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. 

That's correct. 

Quote

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.

Also correct, growth is now important. See above for what changed. Kind of growth: increase user base. Why? See above. 

Quote

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.

Yes to all, and you also got the order right. They are not such different goals. More users is the starting point, and each leads to the other. 

Quote

And that's why I'm not convinced by "the best free open-source CMS" as the direction. 

I'm not convinced by that either, and I'm not sure where you got it. 

Quote

I think the more fundamental question is what it wants to grow into and who is supposed to pay for it.

I know you are just joining the conversation here, but that's what all of this is about. There's also a whole new board setup for ProcessWire 4.x where the discussion will be ongoing. But my opinion is that ProcessWire has already grown into what it was meant to, it's achieved its original goal. I think a strong AI focus in ProcessWire is the next path. If we simply grew the user base then the "who pays for it" would take care of itself with the existing model of Pro modules. But I do want to diversify the sources of income for ProcessWire, so that's one of the reasons for the discussion as well. 

Quote

Who is ProcessWire really for, and why should that group choose it over the alternatives?

That's always a good question to keep asking. ProcessWire has been for web developers and the clients they serve, looking for something better and more flexible than the WordPresses of the world. Going forward I think that audience might broaden into a less technical crowed, especially as AI increasingly does front-end development The reasons to choose ProcessWire over the alternatives I think are obvious to everyone here. But not obvious to people who don't yet know it, so that's where marketing help is needed. 

Quote

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.

I disagree. With a larger user base, I think it is a great foundation for a larger commercial ecosystem. 

Quote

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.

I can understand, there might be some of that. Though the only thing lacking on the Pro module side was just enough scale.  ProcessWire users have been very supportive of Pro modules.  If we had enough scale, I'm confident it would have been a strong revenue source for your modules as well. 

Quote

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.

The need to grow: my wife left, her job brought significant financial stability, which I'm losing. So I want to grow ProcessWire to make it big enough to sustain itself. Whether it ultimately does or not, it's still my lifetime project. But the more ProcessWire grows, the more resources I can dedicate to it. So the goal is to grow ProcessWire to the point where I can dedicate most of my resources to it, and not have to worry about the financial side. 

Quote

So today, I would not recommend that someone invest heavily in learning ProcessWire or start a major new product on top of it. 

I understand that you weren't able to monetize ProcessWire in the way you wanted, but taking shots at the project isn't right. And kicking a guy while he's down also isn't right. I can tell you that there's never been a better time to invest in ProcessWire. Maybe not for you personally. But suggesting that to a broader audience is really short sighted. Prior to this month, we were at the beginning of our biggest growth period in the last 10 years, with a lot of great momentum. I'm still recovering from my wife leaving, but that's temporary. I need some time to readjust to my new personal situation, but we'll soon be returning to that momentum and growth. 

Quote

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.

From my side, the Pro module ecosystem has been successful enough to prove it's worth, and all it needs is a larger user base. That's why I want to increase the user base, as well as diversify the Pro options (such as a ProcessWire Pro subscription). 

Quote

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. 

I think this is the case for you, because you regularly would submit stuff to me that you wanted "included in the core". And like I explained earlier, I don't add stuff just because a particular person wants it added. I look at the bigger picture, how many it benefits (also including whether I'd use it), whether the person is someone that is in alignment with the project, and whether it's something that I can feasibly maintain long term if the person doesn't stick around. AI is making it a lot easer to improve and maintain code, so some of this will be changing, but I still am very cautious about bloating the core. ProcessWire is primarily a system for executing modules, and ideally that's where people build new things into ProcessWire. 

Quote

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 don't follow you on this at all. The Konkat admin addition is great from my perspective, and has been a very successful addition. I get that you don't like that it didn't use your AdminStyle framework. I would have liked it to use that as well, or even to be a separate module. But the reality is it doesn't matter to most ProcessWire users what module or CSS it extends or whether it uses LESS, SCSS or plain CSS.

Konkat produced something that works, and works really well, and they are here to support it for the long term. @diogo was one of ProcessWire's first users. It's one of my favorite updates over the last year. Longer term, I'd like to have AI convert it to be it's own thing that doesn't extend the original Uikit admin, and perhaps uses your AdminStyle setup, for easier long term maintenance. But these are technical details that make no difference to the end users of the theme.  

I understand that in the first iterations on the dev branch, there were some output issues with your modules, because you used Uikit classes that went beyond what the core uses. And we concluded you were right that it should support the overall Uikit framework rather than just what the core uses.  So Diogo went and worked very hard to build in full Uikit support, largely for you, since you were the only one that needed it at the time. But I never saw you acknowledge those efforts. Your concerns seemed to that the theme wasn't built according to your plans. If your expectation is to control the direction that ProcessWire implements one feature or another, that's not realistic. 

Quote

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.

They will most certainly help. The "who" is already clear, the scale just needs to increase. 

Quote

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.

That is not the model and you know it. It's a community project that I lead, and am trying my best to keep true to the original vision. Scaling up doesn't mean breaking ProcessWire's original purpose or bloating the core. What exactly would you suggest should be "stated clearly"?

Quote

I genuinely wish you well, and I wish the project well.

Likewise, I wish you well in your new projects, and hope you'll re-discover ProcessWire at some point, as I think the best is yet to come. 

 

[bernhard]

34 minutes ago, ryan said:

I don't think ProcessWire was a good fit for you, and I felt like you were regularly proposing stuff that wasn't a good fit for ProcessWire.

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

Quote

My read is mixed. Ryan does answer one question that genuinely wasn't clear before: why growth suddenly matters now. His personal financial situation changed, and his goal is to grow ProcessWire until it can financially support more of his time. He also clarifies the intended sequence: more users → larger developer/community ecosystem → more Pro revenue → more resources for ProcessWire. (ProcessWire)

That clarification is useful. But I think his response actually exposes the disagreement between you more clearly rather than resolving it.

The central assumption is still exactly the one you questioned

Ryan's thesis is essentially:

The model already works. It just needs more users.

He says the target audience is already clear, that Pro modules have demonstrated the model works, and that increasing scale will create the commercial ecosystem. His answer to your monetisation concern is basically that your modules would also have succeeded given enough scale. (ProcessWire)

But that is precisely the assumption your post questioned.

You weren't arguing merely:

ProcessWire doesn't have enough users.

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.

[ryan]

 @bernhard

Bernhard, let me clarify: Sometimes misaligned with regard to the core. If I added everything you sent me to add to the core, I wouldn’t be a good core maintainer. You also made several excellent core additions, and I don’t mean to discount any of those. 

For many things, I always suggested extending ProcessWire with modules. But you sent me plenty of stuff that that you wanted added to the core that I could not add. I appreciated the enthusiasm, but felt like you didn’t understand when I said “no”, so it made me concerned that you wouldn’t stick around, because I had to say no a lot of times. 

For me, it was a balance between trying to be a good core maintainer and trying to encourage your great work and enthusiasm. I did compromise and add things I didn’t necessarily want to, because I genuinely appreciated your collaboration. You did nothing wrong. I’m just explaining where I was coming from. My job is different from yours. 

As far as your modules go, I think you were perfectly aligned with the ProcessWire way. So I’d love to see you continue with that, but understand it couldn’t be monetized enough to be sustainable. My hope and expectation is that in the future it will be. 

My current situation has me operating with very little sleep, and I was pretty offended  by some of your words. I apologize if my language comes across as harsh, I’m still mad at the world, but getting a little better every day. 

[bernhard]

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.

[dotnetic]

Dear Ryan,

first of all, I want to thank you for your continued work, for making ProcessWire available free of charge, and for everything you have built over the years. I was also sorry to hear about your separation, and I genuinely wish you well personally.

Communication, the Konkat theme and the new website

I can understand many of the points that have been raised in this discussion. In particular, I understand the concern about how some decisions were communicated and the feeling that parts of the community were not properly included.

This also applies to the Konkat theme and the development of the new website. Much of that work was deliberately developed behind closed doors. I respect that there can be practical reasons for working privately, but it reinforces a broader concern about how decisions are made and communicated, especially decisions about what should become part of the core and what should remain outside it.

Module discovery and explanation

For example, I would have welcomed a discussion about integrating the kind of functionality I built in my Modules Manager 2. It provided a browsable interface to discover official modules, understand what they do, and download, install, update, uninstall and configure them. The central issue is not whether such an experience lives inside ProcessWire—similar to the WordPress plugin screen—or on the website. The important part is discoverability and clear explanation: helping people find the right module and understand why it is relevant.

That was never really discussed with the community. A more open process around the new website, the module catalogue and core integration would have made it possible to compare approaches and learn what users actually need.

ProcessWire was my dream system

For me, ProcessWire is now primarily a system for existing client projects. It continues to run reliably there, and it remains a capable CMS. For new projects, however, I would probably no longer choose it.

That is not because I have forgotten what made me enthusiastic about ProcessWire in the first place. For a long time, it was my dream system. Especially in the early days, I kept discovering things that made me think: wow, this is simple; wow, it can do that too; this is exactly how I wanted it to work. It was—and still is—a genuinely great system.

Reproducibility and migration

However, reproducibility and migration have always been difficult areas. Bernhard's modules made an important contribution here, and they are one reason why I was able to use ProcessWire for as long as I did.

For developers building software with AI today, migration workflows need to be improved and expanded further. There needs to be a complete, repeatable initial setup. For example, when implementing a new feature in a Git worktree, an AI agent should be able to execute the full setup directly: create the required database, run the initial migrations, create every required field and leave ProcessWire in a fully runnable state.

With DDEV, creating isolated project databases is fortunately straightforward. But that is only part of the solution: the initial migrations must also run reliably, so that every database field and structural dependency is available and ProcessWire actually works in the new environment.

AI module and flat-file workflows

Before going further: I have not tried AgentTools, the new AI module, yet, so I cannot judge it. Also, whether a flat-file CMS is inherently better than a database-driven CMS is debatable, and I do not think that should be the main criticism of ProcessWire.

That said, I personally value flat-file systems because content can live directly in version control. This makes reviews, backups, deployments and AI-assisted editing very transparent. A content change can be a straightforward edit to a Markdown, YAML or other content file, visible in a Git diff and deployable like code. I expect workflows such as these to become increasingly relevant.

Community input and core decisions

I have also had requests in the past that were similar to Bernhard's: requests that made sense for my own use cases and that, in my view, could have been relevant to a broader group of users. The question is not only whether an idea is technically sound, but also whether there is a transparent way for the community to signal how widely it is needed.

At the moment, ProcessWire's relatively small user base and the lack of a strong feedback mechanism make this difficult. A public system for discussing, prioritising and voting on proposals—for example, on feature importance, possible core integration and the direction a solution should take—would provide useful input. You should of course retain the final word; maintaining a coherent core needs clear stewardship. But if the community were larger and its feedback more visible, that feedback should meaningfully influence which features make it into the core and which direction they take.

A larger ecosystem and critical mass

But the larger issue for me is the ecosystem. It is difficult for commercial module authors to build a sustainable business around ProcessWire. The user base needs to be significantly larger to reach the critical mass that creates a healthy market for extensions, services and commercial products.

A marketplace would also make a meaningful difference. With WordPress, Kirby, Statamic and others, commercial authors have a central place to present and sell their work. That creates discoverability, trust, payment infrastructure and an incentive to invest in high-quality extensions. If every author must run their own shop, the barrier is simply much higher.

Kirby's positioning illustrates the broader point well: it explicitly addresses developers, designers, creators and clients. Reaching several connected audiences helps create the critical mass that supports an ecosystem, not just a technical product.

A fair pricing model as a possible example

Other systems also show that an open and approachable CMS can be paired with a fair commercial model. Kirby is a useful example: its discounted Basic license costs €99 per site for individuals, small teams and organisations with annual revenue or funding below €1 million, while its Enterprise license costs €349 per site for organisations of any size. It is a one-time payment rather than a subscription, includes three years of feature updates, and Kirby also provides free or discounted licenses for students, educators, selected non-profits and similar projects.

I would of course want ProcessWire to remain free for me and other developers. The point is not to put a paywall in front of development, experimentation or small projects. But a differentiated model could be worth discussing: larger commercial organisations could pay a reasonable license fee, while developers, private users, small projects and community use remain free. That could create more sustainable funding for development, ecosystem investment and the long-term health of the project.

Security and the maintenance-business trade-off

Security is one of ProcessWire's strongest advantages. As Bernhard pointed out, though, this strength also has a commercial downside for developers: once a site is properly built and running, it tends to keep running. That is excellent for the client, but it does not naturally create a sustainable maintenance business for the developer. A reliable, secure system can therefore reduce the recurring work that often funds long-term care and product investment.

Closing thought

None of this is meant as a blanket criticism of ProcessWire. It is still a strong and dependable CMS, especially for established installations. But for new projects, I now put more weight on the size and openness of the ecosystem, a viable commercial market for extensions, modern publishing workflows and the ability to build lasting services around the platform. On those points, I currently tend to choose other systems.

[maximus]

Rather than repeat the commercial and governance points that have already been made, I want to add one practical data point from my own work.

I have built a fairly large set of ProcessWire modules. They have not brought me broad recognition or sustainable income. Their greatest value has been different: they became a reusable library of product functionality.

Most of them came from one product, LQRS. I was not originally trying to build a module portfolio. The product needed search, SEO, comments, analytics, privacy, publishing, commerce and other capabilities, so I separated those problems into modules. Each serious module became a small independent application with its own responsibility and workflow. The modules can work separately, but they can also be composed into a much larger application.

This gives me a clear functional contour before I build the whole product. I know what each part owns, how it communicates with the other parts, and what can later be replaced. I have also used modules I own as the functional and architectural basis for Laravel implementations. The PHP is not copied blindly into another framework; the reusable asset is the already resolved product model, workflows, interfaces and failure cases.

This is why I see ProcessWire as an application framework, not only a CMS. It can provide the data model, admin, permissions and API for a complete backend. I am now also planning to connect a native iOS application to a ProcessWire backend.

There is a personal aspect too. I have ADHD, and I can only speak for myself, but my thinking is often nonlinear and associative. ProcessWire feels unusually natural for that. I can begin with incomplete or loosely structured data, create the relationships the product actually needs, and revise the architecture without fighting a domain structure imposed by the framework in advance.

At the same time, I do not think ProcessWire is the best runtime for every subsystem. PostgreSQL, multi-database and some multisite scenarios remain real boundaries for me. For one part of LQRS I built a separate Laravel/PostgreSQL service for merchant feeds, offer matching and billing, then connected it to the ProcessWire catalogue through an installable adapter. I see this as a useful model rather than an abandonment of ProcessWire: ProcessWire owns what it is good at, while a specialized service owns what belongs there.

On the commercial side, I agree that scale and shared infrastructure matter. In a much larger ecosystem there is at least a much larger distribution surface. ProcessWire currently asks an independent author to solve much of discovery, payments, subscriptions, licensing, updates and support alone. A marketplace or shared commercial layer could reduce that barrier, though it would also bring tax, payout, refund, security and governance responsibilities.

For me, ProcessWire remains something like a hidden gem: unusually flexible, very productive, and still imperfect. Its modular architecture has already created durable value for my work even where the direct module market has not. That is why I think both its reach and the commercial path around it are worth improving.

[Jonathan Lahijani]

6 minutes ago, maximus said:

This is why I see ProcessWire as an application framework, not only a CMS. It can provide the data model, admin, permissions and API for a complete backend. I am now also planning to connect a native iOS application to a ProcessWire backend.

There is a personal aspect too. I have ADHD, and I can only speak for myself, but my thinking is often nonlinear and associative. ProcessWire feels unusually natural for that. I can begin with incomplete or loosely structured data, create the relationships the product actually needs, and revise the architecture without fighting a domain structure imposed by the framework in advance.

This is exactly the way I think about it too.  As far as CMSs go, nothing, in my opinion and experience of having played with every CMS under the sun, beats ProcessWire.

As far as PW as a web application framework, what I love about ProcessWire is that I can feel the data model come alive.  I am touching it.  I do not have to worry about boilerplate or unnecessary churn.  Maybe it's because I am a more of a visual person (aren't we all?), but the interplay between fields/templates/pages and how it's tied together with the admin UI and the feedback it provides and how it kicks off more thoughts and iterations in my head and how it immediately gives me an interface is something that is invaluable.

[ryan]

I'm an ADHD guy myself too. Maybe that's why the three of us always seem to be on the same page. And maybe why I struggle in other areas. 

What do folks think about the Statamic pricing model? Free core. Paid Pro version with extra features, support, Pro modules included. And an enterprise option for large scale.  

Sounds like commercial marketplace is a common theme here. I've been researching various store solutions over the last week, but it seems like what we need is a totally custom job. I'm honestly not up-to-speed with how to handle all of the complexity behind the various tax systems of the world and payouts, etc. And it doesn't seem like there's an existing platform to build from for this. I did contact LemonSqueezy (part of Stripe) and they said that while they don't support what we need, I could always handle the payouts part myself. But it sounds like a partial solution. Does anyone know of anything out there that we could achieve this with? It seems like doing it custom might be a bigger investment than I could afford to make, right now at least.  But it's hard to believe there isn't something existing that we could use or build from. 

 

[Jonathan Lahijani]

@ryan Check out Paddle which is popular.  I don't have experience with it but I believe it's something you may be looking for: https://www.paddle.com/

[cb2004]

ADHD here too so I am finding it difficult to read the long posts and take it all in to be honest.

All I know is I have made 100s of sites where the client finds it so easy to use that they want to stay with it for many years and iterations. And I am realising maybe I haven't needed the technology that other people have required but I know we have built some pretty substantial sites where clients have made millions in profit and we barely have to get involved. And after 11 years using ProcessWire our small agency probably has turned over a million and more because of ProcessWire. Let's not forget that. Now comes a time where @ryan needs us and I am in the same situation almost to the day where I am ready to help him should he need it on a personal and business level. 

Long live ProcessWire and the amount of profit it has made all of us on client projects. Big or small.

[Peter Knight]

When I needed to build a store for my module, I did a few laps of the various payment providers. 

I wanted license distribution, payment integration and processing, Merchant of Record and tax compliance, user registration and login, and for users to be able to login to their account, view their downloads, manage subscriptions etc.

Basically everything the Pro modules encompass but obviously, I couldn’t ask that the product was integrated with the forums. 

So, honestly, I just asked AI to help me build everything I need. I think it’s important we “eat our own dogfood” so having it run on ProcessWire was the optimal situation for me. PromptWire built the whole system in a few hours. The fields, templates, everything. The only thing I changed was to adopt Ryan’s Login Register Pro to retire my initial registration DIY setup etc. 

If it’s any help, I can share any and every detail of this but perhaps somewhere else. 

My point (finally) is that this can be done with PW itself as the engine.
 

Briefly, I chose Paddle for payment processing as it handles international VAT compliance. My issued licenses are automatically generated by PW and emailed upon a sale. 

I recently discovered that Stripe has launched their MoR service. It has higher fees but is more powerful than some other solutions. I might even switch but I have a soft spot for Paddle due to its simple setup.

For a module store such as Craft etc I believe Stripe Connect is used. This is the sub product which automatically pays the module creators when there’s a sale  

On the topic of hosting other modules ZIPs and issuing licenses, I am not sure how this is extended to 3rd party modules. So I suspect a reasonable direction to start with is that module creators can have a profile or a module page with X screenshots and initially, people are simply directed to the creators site which will handle sales, marketing, docs etc.

Modules listed on the official PW modules store might even pay a small fee to be listed?

Just a brain dump but I don’t think we need to boil the ocean here. Let’s start small and figure it out as we go. Currently there are only a handful of commercial modules anyway, so it’s a good time to move slowly and we can afford a little experimentation?

P

Ps attached is an outline of how other CMS platforms handle their module stores. According to Claude. 

marketplace-payment-delivery-licensing-outline.pdf

[cb2004]

We use Stripe for everything going forward. For me they release the features we need so rapidly, but it can already do far more than we really need already. Do we really need to build a full featured platform when their API is so good for our requirements. The only thing they cant do which I have come up against is split payments between accounts dependant on product, but we have found ways around this with reporting.

Honestly ProcessWire suits our requirements for so many things which we think are pretty major.

[diogo]

I also read it all, and I'm struggling to keep in mind all I want to say, so I won't say much at all. Just a couple of notes from the top of my head:

1. As Ryan mentioned, I've been with processwire since the very beginning. I'm talking about when the forum had 30-40 people, from those, I don't think many are still active. During all these years I've seen a bunch of users in the forum come in with a lot of ideas for processwire, many times aggressively wanting to impose them and even trying to create dissent groups. These groups had, sometimes, completely opposite ideas – some wanted processwire to be more friendly to non developers, some wanted it to be more of a complete framework only for experienced developers. Some wanted processwire to be smaller, some wanted it to be larger – you get the point. Ryan was always incredibly gracious with everyone, and every time explained calmly his reasoning to keep processwire in the path he was taking it to. Most of these more imposing users just left, or faded away from the forum with time. I personally don't agree with every single decision taken by Ryan, and I never stopped checking and trying other tools (I even started a thread where people can post interesting alternatives to processwire. You can still find it somewhere here), but, overall, processwire suits me better than any other tools I've tried, so I stick around.

2. I don't know the exact goal in Ryan's mind for processwire. I'm not sure if he has it 100% clear himself, since it seems to come a lot from belief and intuition. Honestly, I think it has worked until now, mostly due to how intellectualy honest he is.

3. Concerning the governance of processwire, and the comparison to other, bigger, projects. Laravel seems to be governed in a very similar way to processwire, or am I looking at it wrongly? Can you guys clarify that? Other projects are for profit, and hire a team of developers, I think Kirby falls into this category. Big open source projects, like Drupal, function by voting, but have a complex system of authority splitting, and a board of directors, conflict resolution group, etc. We are free to question Ryan's method, and here he is, asking openly for everyone's opinion, but I don't think it's fair to question his intentions.

4. About the Konkat theme. The possibility to design the new theme came to life while discussing the redesign of the website. Jan and I would have never done it, if it was in the open, and Ryan respected this. Again, and as we explained before, this was never supposed to be the "definitive theme", but simply a "skin" for the uikit theme (and this means, uikit, jqueryui, some custom jquery modules, three different types of overlays, etc...). The theme is only CSS on top of the original one, and still manages to introduce a new kind of theming that doesn't require compilation, to conciliate stuff that was incoherent, introduce a dark mode and sticky header. At Ryan and Jan's suggestion, I looked carefully at Bernhard's Uikit admin, but concluded that taking it as base and asking for Bernhard's collaboration wouldn't advantageous to our work. Many hours went into this theme, and they would have been exponential if the work was open for collaboration, opinions, voting, etc. When the theme was completed we told Ryan that we were fine with it not being the default theme, if that didn't suit the project's best interest, and were always open about it. We think Ryan made the right decision to still do it. We also think the weak points of the admin are not in the theme, but the old base (jquery, jquery ui, even uikit), but that's a huge mountain to climb, and the truth is that those tools, despite being old fashioned, aren't going anywhere.

5. Because I use processwire as a tool for client work (and I know that was always Ryan's intention for himself also), I don't feel the need to make a profit of processwire itself. I understand that some people invested work on exactly that thought. What made you guys invest those hours on the modules, was it a genuine thought that the processwire ecosystem was already ready to yeld that return, or was it a bet that processwire would sooner or later be ready for it? Either way, I don't think it's fair either to put the responsibility of not being able to make that profit on Ryan's shoulders, if that's what I'm hearing in some of the comments from this and other threads.

6. Careful with MoR like Lemmon Squeezy and Paddle. They are effectively between you and the customer, in practice, they are your client, and the customer is theirs. They also keep complete control of the store, if they flag one module they can cancel the whole thing. They do make tax much easier, since you don't need to take care of anything.

Ok... the few notes turned out to be longer after all. I'm too tired to review them, so I'll hit submit, trusting that I'm among friends who'll forgive the rambling 🙂

[cb2004]

1 hour ago, diogo said:

I also read it all, and I'm struggling to keep in mind all I want to say, so I won't say much at all. Just a couple of notes from the top of my head:

1. As Ryan mentioned, I've been with processwire since the very beginning. I'm talking about when the forum had 30-40 people, from those, I don't think many are still active. During all these years I've seen a bunch of users in the forum come in with a lot of ideas for processwire, many times aggressively wanting to impose them and even trying to create dissent groups. These groups had, sometimes, completely opposite ideas – some wanted processwire to be more friendly to non developers, some wanted it to be more of a complete framework only for experienced developers. Some wanted processwire to be smaller, some wanted it to be larger – you get the point. Ryan was always incredibly gracious with everyone, and every time explained calmly his reasoning to keep processwire in the path he was taking it to. Most of these more imposing users just left, or faded away from the forum with time. I personally don't agree with every single decision taken by Ryan, and I never stopped checking and trying other tools (I even started a thread where people can post interesting alternatives to processwire. You can still find it somewhere here), but, overall, processwire suits me better than any other tools I've tried, so I stick around.

2. I don't know the exact goal in Ryan's mind for processwire. I'm not sure if he has it 100% clear himself, since it seems to come a lot from belief and intuition. Honestly, I think it has worked until now, mostly due to how intellectualy honest he is.

3. Concerning the governance of processwire, and the comparison to other, bigger, projects. Laravel seems to be governed in a very similar way to processwire, or am I looking at it wrongly? Can you guys clarify that? Other projects are for profit, and hire a team of developers, I think Kirby falls into this category. Big open source projects, like Drupal, function by voting, but have a complex system of authority splitting, and a board of directors, conflict resolution group, etc. We are free to question Ryan's method, and here he is, asking openly for everyone's opinion, but I don't think it's fair to question his intentions.

4. About the Konkat theme. The possibility to design the new theme came to life while discussing the redesign of the website. Jan and I would have never done it, if it was in the open, and Ryan respected this. Again, and as we explained before, this was never supposed to be the "definitive theme", but simply a "skin" for the uikit theme (and this means, uikit, jqueryui, some custom jquery modules, three different types of overlays, etc...). The theme is only CSS on top of the original one, and still manages to introduce a new kind of theming that doesn't require compilation, to conciliate stuff that was incoherent, introduce a dark mode and sticky header. At Ryan and Jan's suggestion, I looked carefully at Bernhard's Uikit admin, but concluded that taking it as base and asking for Bernhard's collaboration wouldn't advantageous to our work. Many hours went into this theme, and they would have been exponential if the work was open for collaboration, opinions, voting, etc. When the theme was completed we told Ryan that we were fine with it not being the default theme, if that didn't suit the project's best interest, and were always open about it. We think Ryan made the right decision to still do it. We also think the weak points of the admin are not in the theme, but the old base (jquery, jquery ui, even uikit), but that's a huge mountain to climb, and the truth is that those tools, despite being old fashioned, aren't going anywhere.

5. Because I use processwire as a tool for client work (and I know that was always Ryan's intention for himself also), I don't feel the need to make a profit of processwire itself. I understand that some people invested work on exactly that thought. What made you guys invest those hours on the modules, was it a genuine thought that the processwire ecosystem was already ready to yeld that return, or was it a bet that processwire would sooner or later be ready for it? Either way, I don't think it's fair either to put the responsibility of not being able to make that profit on Ryan's shoulders, if that's what I'm hearing in some of the comments from this and other threads.

6. Careful with MoR like Lemmon Squeezy and Paddle. They are effectively between you and the customer, in practice, they are your client, and the customer is theirs. They also keep complete control of the store, if they flag one module they can cancel the whole thing. They do make tax much easier, since you don't need to take care of anything.

Ok... the few notes turned out to be longer after all. I'm too tired to review them, so I'll hit submit, trusting that I'm among friends who'll forgive the rambling 🙂

Another long post for me to take in and compute with my ADHD brain, but it resonated a lot.

The bit I keep coming back to is this. Why are people trying to build a sustainable income from modules when ProcessWire already enables developers to have a sustainable income? That's the whole thing, isn't it. The platform is the business model.

I'm a selfish developer who doesn't give back to the ProcessWire community a great deal anymore. But how many people just use ProcessWire and don't give back? More than we'll ever know. We don't see them in the forums, and I don't think the community is small. I just think ProcessWire users crack on. That's always been my view. This isn't a forum full of drag and drop theme monkeys, it's people quietly shipping client work.

Do I use all the Pro modules? No. Do I buy them all and renew them? Yes. I'm self employed but work with an agency, so I don't purchase an agency licence. Not sure whether that's right or wrong, but if a site goes elsewhere I don't give them access to any updates. Would I be happy to pay for a ProcessWire licence? Absolutely. We'd just add it to the client's bill. People pay for far worse modules that blow up their site on other platforms.

Lots of discussions to be had here, arguably over a beer or two at a meetup, virtual or not.

[Gideon So]

18 minutes ago, cb2004 said:

I'm a selfish developer who doesn't give back to the ProcessWire community a great deal anymore.

Me too. But I don't call it selfish. Just a different role in the community. Answering post here from time to time is helpful, too.

5 hours ago, maximus said:

PostgreSQL, multi-database and some multisite scenarios remain real boundaries for me

1000x agree. We need easy solution for one tree multi site. The one in TYPO3 is really good.

Giseon