Leaderboard

Well my personal life news has not been getting better. My Mom had a heart attack, which we believe to be from the stress of my wife leaving (she and my wife were very close). But thankfully, my Mom had good and quick medical attention and is now recovering. Despite the news, it was quite a good week for ProcessWire development, with perhaps the most commits we’ve ever had in a week: 41 of them. This week we solved a large number of core issue reports, including a lot of years-old ones. Lots of improvements have been added to the core as well, plus two PRs from Adrian. What I’ve found is that when it’s hard to focus due to so much change on one’s life, solving issue reports is the perfect diversion. Especially with a little AI assistance. So that’s what I did this week… fixing what can be fixed, taking the focus off of what can’t.

Well the good news is that it's been a month since this started and I'm a lot better off than I was. I'm eating more, sleeping more, and can function well enough again, even if still sad. I'm mostly back to work. I'm pretty proud of 41 commits this week. Seems like good momentum, and feeling a lot of confidence and enthusiasm for ProcessWire's future. I really appreciate all of you and your support.

I've not been able to get my focus back just yet, but I am building momentum on a couple of cool things. I could have covered a lot of issue reports this week, but instead decided to build a module that would let AI agents pull issue reports, checkout a new worktree of the core, and submit patches for issues. Each issue resolution stored in a ProcessWire page, waiting for review. Basically, I'm looking to automate the issue resolution process so that I can have a group of round-robin agents working on them at any time of the day, and then I can come in and review them with an overseeing AgentTools agent and tell it to either "apply and reply" or "send back for a different solution". This should enable us to cover issue reports much more quickly, and in much greater quantity. At this point the module is mostly built, but I still have a lot of testing to do. I'm also working here on the business side of ProcessWire. I've been looking at different store solutions, and currently leaning towards staying with IP.Board, but with the newer revamped 5.x version, and with a completely external payment processor that handles the various tax considerations. This better opens the door to supporting 3rd party modules, since we have code-level access to IP.Board, and ProcessWire collaboration, while I've yet to find any external service that would do what we need. That's all for this week, but hopefully back next week with core updates to report. Have a great weekend!

The commits have continued at a fairly rapid pace again this week, which you can follow in the dev branch commit log. I’m not bumping the version number this week, but likely will next week. At this point, my goal is to clear out our processwire-issues repo, so that the majority of the issues in there are solved and those no longer applicable are closed. We still have around ~160 issues open, but since we’re now working on a lot of older issues, as we go through them, we’re also finding a lot are already solved. In an ideal world, we’d not have more than a dozen open issue reports any given time, so we may just get there!

@ryan Regarding the forum's 403 mentioned earlier: It's not a permissions problem on the forum — the request never reaches the forum software. What's happening 403 server: awselb/2.0 /talk/discover/unread/ 403 server: awselb/2.0 /talk/discover/ 403 server: awselb/2.0 /talk/discover/15/ 403 server: awselb/2.0 /talk/index.php?/discover/unread/ 200 server: Apache/2.4.68 /talk/ ← app responds normally 200 server: Apache/2.4.68 /talk/search/ , /talk/online/ 404 server: Apache/2.4.68 /talk/discoverxyz/ ← app responds normally The 403 comes back with server: awselb/2.0 and a bare nginx/WAF-style error page (<h1>403 Forbidden</h1> plus MSIE padding comments) — that's an AWS load balancer / WAF rule, not Invision Community. If it were an IPS permissions denial you'd get an Apache response with the themed "You do not have permission" page. The rule is matching the literal /discover/ segment anywhere in the request line: /talk/discover/unread (no trailing slash), /talk/discover/15/, and even /talk/index.php?/discover/unread/ in the query string are all blocked, while /talk/discoverxyz/ sails through to the app and 404s. It's not user-agent based either — curl, Chrome and Googlebot UAs all get the same 403, and it's independent of login state since cookies never get evaluated. IPS's Discover/activity streams (/discover/unread/, /discover/<id>/) are the most database-expensive pages on an IPS board and a magnet for crawlers hammering every stream permutation. Blocking /discover/ at the edge is a standard load-shedding move. So this is almost certainly an intentional (or over-broad) WAF rule added by whoever runs processwire.com's infrastructure — the collateral damage being that logged-in members lose the "unread content" feature entirely.

@ryan, this all is such an ordeal you have to go through! And I am sorry if some of my recent postings here were not really helping. Do know that you're not alone in this. A lot of people all around the world are thinking and caring about you and your family. Over the years I am here in the forums my family and my friends got to know about not only ProcessWire but you personally as well. Ryan is not a widely used name here in Russia, so they all know exactly who am I talking about when I call it. The kids know your avatar as they grew up seeing it on my screen like every day. So you are an important person in our lives. And of course we all wish you and your family the best. Just know that. It will work out somehow.

I mentioned last week that I was dealing with an unexpected family situation. I wanted to give a little more context, as I don’t want you to think the worst. Though for me, it feels like the worst. My wife and I are going through an unexpected divorce/separation after the best 25 years of marriage I can imagine. She informed me of this for our 25th anniversary, after coming back from our Scandinavia trip, and I didn’t see it coming. Going from the happiest part of my life to the lowest in a week was tough. My life partner, best friend and the person I love most in this world is leaving, and it has shaken me to my core. I thought I had the best marriage in the world and was so looking forward to growing old with my wife. But now it’s like I don't know her, she's a different person. Thankfully my kids and cats aren’t going anywhere, so it won’t be too lonely around here. It has understandably taken a lot of my attention and energy over the last two weeks. It’s hard to eat or sleep when you are in hell. But I managed to get a little sleep last night, and woke up today feeling slightly better. I sat at the computer for the first time in awhile, got some issue reports covered, and it feels like it’ll keep getting better from here. I'm still moving slowly, but it feels like some momentum started today, and my hope is that things will be fully back on track in the next couple of weeks. Our household’s financial stability also made it possible for me to spend a lot of time on open source work without ProcessWire itself needing to carry the full financial load. I was always satisfied for ProcessWire to remain a relatively small open source project and community. Now I need it to grow and flourish in order to survive. If you’ve been waiting for ProcessWire to grow, I think this change will be healthy for the project. But I'll need your help, ideas and collaboration. For the moment, I’m still taking things one day at a time, so development and communication may remain slower than usual for a little while, but the engine is at least started again. I appreciate everyone’s patience, understanding and continued support more than I can say. But also know that amid my bad family news, there will be bright spots for all of us in ProcessWire. That I'm sure of. Thank you for your support and for sticking around. So many of you have shown up for me with kindness and encouragement when I’ve needed it most. You are such good friends to me, and I’m deeply thankful to have you here.

Hi everyone, I’ve released Kern, a ProcessWire module for delegated Page ownership and moderated frontend editing. The practical use case is a directory, marketplace or catalogue where a company owner, author, organization or other authenticated user should be able to maintain their own Page — without receiving normal ProcessWire admin access. A typical Kern workflow looks like this: An administrator defines which templates, users and fields are available. A user requests ownership or redeems a one-time access code. The user submits proposed changes through a project-specific frontend form. Kern stores the changes as a revision without modifying the live Page. A moderator reviews the current and proposed values. After approval, Kern checks for conflicts, updates the Page and records the decision in its audit history. Access rules can target: ProcessWire templates; individual fields; roles or specific users; all authenticated users; users with an active ownership claim. Rules can independently grant or deny claim requests, editing, automatic approval, code management, moderation and history access. Explicit denies always take precedence. Kern supports native ProcessWire fields, multilingual values, Page references, existing file and image references, Rapid, Combo, Table, Repeater and RepeaterMatrix values. Custom field workflows can be added through field adapters. The module deliberately does not impose a public frontend. The site remains responsible for its routes, authentication screens, forms, uploads and presentation. Kern provides the authorization, revision, moderation, conflict-detection and audit layer behind those interfaces. Some important safeguards: frontend submissions never write directly to live Pages; access-code plaintext is returned only once and is not stored; guests cannot request claims, redeem codes or submit revisions; system and security fields are always protected; force approval cannot bypass access that was revoked after submission; module data is preserved on uninstall unless deletion was explicitly enabled. Requirements: ProcessWire 3.0.244+ PHP 8.3+ GitHub: https://github.com/mxmsmnv/Kern The repository includes API documentation, integration examples and guidance for AI agents building ProcessWire sites with Kern. This is the first public release, so feedback on real-world ownership and moderated-editing workflows would be very welcome.

Happy Wednesday, everyone! Does such a thing exist? Such a question is beyond this post's remit. So let me introduce you to MediaHub 1.20.0 to 1.20.1 instead, which features: Field automation (pre-generated sizes, collection filing, labelling) findRaw() variations SVG display in the library Library and picker polish Integrator hooks We're going without screenshots today, since most changes aren't visual. Field automation A collection of field automations that shortens the resize–file–label round-trip after every upload. Pre-generated size variations. Give a field a list of sizes, MediaHub will generate those variations up front on upload and save. The first visitor gets a cache-hot image instead of triggering GD on demand. These are ordinary ProcessWire variations on disk, not separate library items: they do not appear in the grid and do not inflate your asset count. A per-request limit keeps large galleries from hitting PHP's execution-time cap. Automatic collection filing. Point a field at a collection path, static (e.g. /news/images/) or built from the page's own fields (e.g. /news/{title}/{date:Y-m}/), and its assets are automatically filed into that collection when the page saves. Missing collections are created automatically. Automatic labelling. Same idea for library labels: a static list, or labels built from page fields (e.g. {category.title}). Labels are applied on save; empty placeholders are skipped. Slow-save overlay. When automation makes a save take a moment, a brief loading overlay appears in the page editor so it does not look broken. Thanks to @David Karich of Flipzoom for the automation concepts, code samples and testing. Full setup steps and more examples are in the new Field automation documentation. findRaw() variations (1.20.0) findRaw() now accepts an opt-in variations field: name, URL, dimensions, filesize for size variations already on disk. These are read-only and pair with pre-generated sizes for cache-hot galleries without lazy resize on first visit. Docs: findRaw SVG display in the library SVG support arrived in 1.17, but transparent SVGs were still hard to work with in the library. White or light artwork could disappear against the tile background, and the artboard edge was unclear. 1.19.52 treats transparent SVGs properly across grid, list, masonry, and asset detail views: a dot-grid preview behind the artwork, a subtle frame with drop shadow and corner radius, and masonry that no longer upscales icons and logos beyond their intrinsic size (photos still fill the column width). If your library holds brand marks or UI icons as SVG, browsing them should feel much closer to working with raster thumbnails. Thanks to @Stefanowitsch for flagging this. Library and picker polish Bulk delete with usage awareness. Selecting multiple assets and deleting them used to show a generic confirmation even when some were still referenced on pages. The dialog now checks all selected assets in a single pass (one query per field, not one per asset). When any are in use, the message leads with how many are used on pages, matching the tone of the single-asset warning, and the confirm button reads Delete Anyway. Picker sidebar resize. The main library sidebar gained resize in 1.19.51, but the picker modal's handle was visible without doing anything. 1.19.52 fixes drag-to-resize in the picker and remembers the picker's width separately from the main library. Template picker hygiene. MediaHub's internal templates no longer appear in ProcessWire's "Add New Page" template picker at arbitrary tree locations. They are hidden from editors and tagged for clearer grouping under Setup → Templates. Thanks @Didier B. There's a ton of other stuff in 1.20.X spanning a few releases. The Changelog is up to date and a good place to see everything across the releases. Thanks for reading Peter

Hi everyone, I’m releasing the first public version of Files, a ProcessWire module for building a private, self-hosted file library. The module takes inspiration from Seafile, kDrive and MyCloud while staying fully integrated with ProcessWire users, roles and permissions. Main features Private file storage outside the public web root Folders and nested subfolders Large-file uploads using AJAX chunks Upload progress and automatic retry List and grid views Search and file-type filters Authenticated previews for images, PDF, text, audio and video Optional read-only ONLYOFFICE previews Public sharing links for files and folders Direct sharing with a selected ProcessWire user Password-protected links Expiration dates and download limits Revocable sharing links Granular ProcessWire permissions MCPServer integration FileServer migration support Folder shares represent a live subtree. If a new file is added inside a shared folder, it automatically becomes available through the existing folder share. All sharing is currently read-only. Permissions Files provides separate permissions for: files-use files-download files-upload files-folders files-share files-delete files-manage This makes it possible to create roles that can browse and download files without being able to upload, share or delete them. File previews The built-in viewer supports: JPG, PNG, GIF and WebP PDF TXT, Markdown, CSV, JSON and XML MP3, WAV and M4A MP4, WebM and MOV Office documents can optionally be displayed through an external ONLYOFFICE Document Server. The integration uses signed, short-lived source URLs and opens documents in read-only mode. Large uploads Large files are transferred through sequential AJAX chunks sized according to the current PHP limits. Upload sessions are private, bound to the initiating ProcessWire user and protected by CSRF validation. The completed file is size-checked, MIME-inspected and SHA-256 hashed before it is added to the library. A conventional multipart upload remains available as a JavaScript-free fallback. MCP Server integration Files can act as a provider for a compatible MCP Server module. The integration offers bounded tools for: navigating and searching the library; reading metadata and file content; creating folders; uploading files; finding recipients; staging and publishing shares; revoking shares; guarded permanent deletion. Every MCP operation is restricted by both the client scope and the permissions of a dedicated ProcessWire service user. Repository and documentation GitHub: https://github.com/mxmsmnv/Files The repository includes: installation and feature documentation; complete PHP and MCP API reference; Olivia/AI-agent integration guidance; security and lifecycle notes. This is the first public release, so feedback, testing and bug reports are very welcome. Thanks!

Hey everyone, We have been talking and building things together online for years, but many of us have never met in person. What if we organized a small, informal ProcessWire meetup in spring or summer 2027? Nothing too formal — just meet each other, talk about what we are building, share ideas, maybe hack on something, eat good food, have a few beers, go bowling or play darts, and enjoy a weekend together. English does not need to be perfect. If you do not speak it fluently, someone from your country may be able to help, and we always have Google Translate. We will find a way to understand each other, so language should not stop anyone from coming. The location should be easy to reach from both Western and Eastern Europe, and possible for people coming from the US too. Budapest, Frankfurt or somewhere in Turkey could work, but I am open to better ideas. If we choose Turkey, at least we will have good kebabs. 🙂 And a special invitation to @AAD Web Team in Hobart: you have already taken ProcessWire to Antarctica, so maybe your next expedition can be to WireFest in Europe. 🙂 For now, I am just checking interest: 1. Would you come? 2. Which country or city would work best for you? 3. Would you prefer spring or summer? If enough people are interested, we can make a simple poll and take it from there. Let's see if we can make WireFest happen. 🙂

I looked again at Bernhard’s diagrams, and I think they make one important distinction very clear. This was never a request to build Konkat on top of AdminThemeRock. It was a request to let Reno, AdminThemeRock and Konkat remain separate expressions built from the same UIkit foundation. Sometimes ProcessWire reminds me of Toyota: dependable, familiar and repairable. Sometimes it reminds me of BMW: ambitious and innovative, but with several generations of engineering under the hood. Both can be true. The old layers are not simply junk — they contain compatibility, history and many years of work — but they can also make the next innovation harder. A friend of mine named Anatoly, an evangelical Christian, once said something that stayed with me: "I know a person may betray me, but even if he does, I will forgive him." I do not think this is a literal Bible quotation. The closest story may be Peter: Jesus knew Peter would deny him, but after it happened he restored the relationship and trusted him again. I am not calling anyone here a betrayer, and I do not know the private history between Ryan and Bernhard. What stayed with me is the idea that forgiveness is not blindness. You can understand how someone may hurt you, speak honestly about what happened, and still leave the door open. This discussion no longer feels like it is only about CSS or an admin theme. It contains years of work, trust, expectations and disappointment. Technical decisions should still be examined honestly, and the diagrams help with that. But I hope “I don’t think I have anything more to contribute” will not be the final word. ProcessWire would lose something important if a technical and governance disagreement became a permanent separation between two people who have both given so much to it.

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 🙂

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.

@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.

@maximus the problem with the forum software is we don't really have much choice - there are fewer good forum software packages out there and ones like InvisionCommunity here you either upgrade to 5.x finally or you eventually end up with security issues and being forced off 4.x at some point. Migrating is a pain - it really is - I've done it so many times that the easiest path, for now at least, is to simply stick with what we know and accept some annoying changes. I did upgrade a site's forum from 4.x to 5.x and it wasn't that bad once I set the view back to the normal tabular view for forums and topics. That said, I did check out Waterhole after briefly looking at Flarum on another project and it was nice - having heavily worked with Laravel on a complex platform for the past 6+ months where ProcessWire wasn't the right fit, Waterhole actually opens up a lot of doors because if you want to change anything it's just Laravel under the hood and Laravel is also very compatible with AI workloads so... it could be an option in future I guess but too much of a change right now - especially since the forum software here has commerce built into it. @ryan happy to catch up when you have time on a few things I've found on my travels around forums and ecommerce? I think you'd still end up on InvisionCommunity but worth taking a quick look at the other options beforehand I reckon just in case there's something you're looking for that some other packages I've looked at might do differently and perhaps better. Software dev all around is moving at a much faster pace and for me it's meant I'm picking up other tools for projects where I previously didn't have time where I was bending PW a little too much to fit something overly complex for it, but I'm also REALLY enjoying the speed stuff happens now with Agent Tools and the enhanced docs in the dev branch - teaching Claude how to best do things how I want it to is also coming along where it's doing things "my way" with less back and forth, but by default any AI isn't going to read your mind I guess... not yet anyway (not ever hopefully 😅).

My two cents @ryan I think there is a deeper structural change that ProcessWire needs if it really wants to grow. The actions you listed are all good, but for me the bigger issue is making the project less dependent on one person. An open source project really starts to grow when the community can take a more active role in the project itself, not just around it. We’ve seen a few times now that there can be weeks without a single commit to GitHub. Whatever the reason, I don't think the core should depend so much on one person being available. More trusted people should be able to help manage the core, review and merge changes, and keep things moving. I know this is probably one of the biggest decisions you could make for ProcessWire, and I understand why. You’ve built the project and have been guiding it for years. But I really think this is the direction to go. You would still be in charge and set the direction, but there would be other people who could keep things moving and continue your work when you're not able to. To me, that's one of the biggest steps ProcessWire could take toward becoming a stronger and more sustainable open source project.

Ryan, thank you for the thoughtful reply and for laying out such a concrete direction, especially while you are going through such a difficult period. There is no need to respond quickly to any of this. Your point about AI accessibility is exactly where I think ProcessWire has an unusual opportunity. I have been testing a private MCP gateway implemented as a ProcessWire module using the official PHP MCP SDK. I realize that AgentTools now also includes a local MCP server, so I do not mean this as a replacement for it. I see the two at different layers. AgentTools gives a coding agent a broad ProcessWire-aware development toolkit: CLI access, migrations, the Engineer, API and schema context, and read-only local stdio MCP tools. My gateway is for bounded, module-defined operations over authenticated Streamable HTTP. It does not run an AI model and does not expose the full ProcessWire API. This is deliberately not SSH, arbitrary PHP, SQL, filesystem or unrestricted admin access. Modules explicitly opt in as capability providers. The gateway handles authenticated clients, scopes, rate limits, namespaces and audit; each provider module owns its domain rules and exposes only bounded tools with JSON schemas. In the current development proof, Codex can discover the environment, providers, available capabilities and their required scopes, while every other application operation remains unavailable. Read and write capabilities are separate, and mutations require idempotency and explicit confirmation. To me, this suggests a broader direction for ProcessWire: an optional standard contract through which installed modules can describe safe, domain-specific capabilities to AI agents. ProcessWire is already easy for an LLM to write code against because of its API. This would make a ProcessWire application safely operable by agents without teaching them to click through the admin or giving them unrestricted server access. In short, AgentTools helps an agent build and change a ProcessWire site; this pattern lets a remote agent operate only the bounded capabilities that each module explicitly publishes. I am keeping the gateway private while I finish the write-path and security tests, but once the vertical proof is complete, I would be glad to document the architecture and show a controlled demo. I also agree about replacing Skyscrapers and expanding site profiles. I think the strongest new demos should show application patterns, not only themes: a directory, editorial workflow, learning platform, or another small application where people can inspect both the front end and admin. A sanitized version of one of my systems could become such a demo. I can prepare a scoped proposal for one rather than promising a large build before we agree on the smallest useful example. For downloadable profiles, a registry in the installer sounds excellent. I would give each profile a screenshot, purpose, maintainer, ProcessWire/PHP compatibility, last update, documentation, live demo and package checksum. It may also help to distinguish educational demos from maintained starter profiles, so a newcomer understands what is safe to begin a real project with. A yearly ProcessWire Pro plan also makes sense to me if individual Pro module purchases remain available. A bundle of all Pro modules, updates and a clearly defined support level would reduce purchasing friction and create recurring revenue. Proactive monitoring and consulting may be better as a higher agency tier because they create a different operational commitment from software and support. Longer term, I think the existing Store could also support a curated path for independent commercial module authors. It would not need to start as a large commerce rebuild: a modern unified catalogue for free and paid modules, ProcessWire/forum identity, external author checkout where needed, and a small partner pilot could validate demand before adding centralized licensing, payouts and updates. That could create another revenue stream for ProcessWire while making continued module development more sustainable for contributors. I agree with Peter that a private collaborative space would help. I would keep it very small and outcome-oriented at first: demos and site profiles, AI and documentation, marketing and content, and commercial sustainability—with one concrete owner and next deliverable for each lane. I can contribute most directly on the MCP capability pattern, an application-style demo, product/admin UX, architecture and documentation, and the marketplace proposal. I am glad that we are beginning this conversation. @ryan

Hi everyone, I’m releasing MCP Server, a ProcessWire module that connects Codex and other Model Context Protocol clients to ProcessWire through one authenticated Streamable HTTP endpoint. Installed modules explicitly opt in as MCP providers and expose only bounded, documented tools. Each provider keeps ownership of its permissions, validation and business rules, while MCP Server handles transport, authentication, scopes, rate limits, tool discovery and audit history. Main features: Official PHP MCP SDK and Streamable HTTP transport Separate revocable credentials for every client One-time token disclosure with salted, installation-protected hashes Hierarchical read, draft, publish and admin scopes Installation-specific tool namespace Closed JSON Schema validation and safety annotations Per-client rate limiting and Host, Origin and body-size protection Audit records without storing raw tool arguments Admin workspaces for clients, providers, tools and audit history Optional bounded JSON CLI Endpoint disabled by default No arbitrary PHP, SQL, shell, filesystem or generic content API Initial integrations: Tickets, Ichiban, Liora, Olivia, Relay, Vox, Verk, Folio, Resend. Requirements: ProcessWire 3.0.200+, PHP 8.2+, HTTPS for production and a strong $config->userAuthSalt. Install the complete module in /site/modules/McpServer/, refresh modules, open Setup → MCP Server, configure the endpoint boundary, create a least-privilege client and review all discovered tools before enabling remote access. GitHub, installation guide and API documentation: https://github.com/mxmsmnv/McpServer Feedback on the provider contract, MCP client compatibility and security model is very welcome.

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.

@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.

Hi everyone, I’m releasing Relay, a scheduled publishing module and visual editorial calendar for ProcessWire. Relay lets editors plan, review, reschedule, publish and unpublish pages from one workspace—without adding scheduling fields to page templates. Main features Scheduled publish and unpublish actions Publication windows with separate start and end times Relay tab inside the page editor Month, week, quarter and three-day calendars Kanban and timeline views Drag-and-drop rescheduling with undo Complete publication details in accessible popovers Filters by action, status and template Configurable first day of the week and weekend highlighting Reusable publication times Template-linked recurring scheduling rules Quick recurrence presets, including custom intervals Session-only imitation mode for testing without changing pages or database jobs JSON import and export with preview before applying Read-only iCalendar feeds for Google Calendar, Apple Calendar and compatible clients Optional WireMail and TeleWire notifications Optional Squad-assisted publication-time suggestions 48 bundled European translations Execution Production jobs are processed by a bounded, lease-protected CLI worker. Parallel worker runs are safe, failed jobs can retry, and stale locks are recovered automatically. A typical cron configuration is: * * * * * cd /var/www/example.com && /usr/bin/php site/modules/Relay/bin/relay.php --limit=50 >> site/assets/logs/relay-cron.log 2>&1 LazyCron is available as an optional fallback when system cron is unavailable, though request-driven execution cannot guarantee exact timing. Screenshots Safety Relay stores timestamps in UTC while retaining the editorial timezone for each job. Requester, editorial identity and worker executor are recorded separately. Page permissions are checked again when a job runs. External interfaces and integrations are disabled by default. Calendar subscription URLs are revocable bearer secrets, and internal notes or unpublished page content are not included in calendar feeds. Requirements ProcessWire 3.0.244 or newer PHP 8.2 or newer MySQL, MariaDB or SQLite through ProcessWire’s PDO connection Installation Download or clone Relay into /site/modules/Relay/. Refresh modules in ProcessWire Admin. Install Relay. Configure the allowed templates, roles, timezone and planning defaults. Configure the CLI worker before relying on scheduled execution. Please note that uninstalling Relay removes its relay_jobs and relay_presets tables. Export or back up any required scheduling data first. Download and documentation GitHub: https://github.com/mxmsmnv/Relay The repository includes full API documentation, Olivia/AI-agent integration guidance, tests, translations and an MIT license. Feedback, bug reports and real-world editorial use cases are very welcome.

Sometimes bad stuff happens, and the best way through it is often to keep doing stuff for other people, but it's ok and sometimes necessary to take time out. Four years ago I had to deal with dad's rapid decline and eventual death, while at the same time my wife was diagnosed with breast cancer, and I had to give evidence at a really nasty trial of another family member, where nothing was what it seemed, and I didn't know who to trust. I think a common issue open source projects face is how to keep them open source and pay the developers a decent income. I think AI has only further complicated things, as while it enables individual developers to be much more productive, it also makes it easier for people to do things without needing a developer at all, and can make it harder for content sites to pay their way, so I don't have any easy answers in that respect. I know @bernhard was extremely active in the ProcessWire community and developed some incredibly useful modules like RockMigrations, but he's gone quiet, and I saw a post noting that he hadn't been able to make his ProcessWire efforts pay. Clearly all of us have a stake in ProcessWire being financially sustainable both for Ryan, but also for all of us in our own use of it. I think getting more sites using ProcessWire is important. A large price increase in the pro modules might not help Ryan if fewer people pay for them due to cost, but an increase in the number of people purchasing them would keep them affordable while still generating more revenue. One of the things that makes ProcessWire so much better than WordPress, but may also put WordPress users off, is it doesn't assume how you want to structure your data. That means you can't really do an instant install. I've been thinking for a while about how OO programming itself works with extensible classes, and now that the likes of RocMigrations exists, I wondered about the idea of a base site profile that gives you essentially a brochure site, but then modules that do nothing more than install additional fields and templates, that extend the base profile with additional functionality as required. That might need some naming conventions around field and templates, however if you know that a given module is just going to install some specific fields and templates, it's already baked into ProcessWire the ability to have module dependencies, so rather than checking each and every field and template, you can just check whether a given module that installs them is installed, which might allow building ProcessWire websites almost as quickly as WordPress ones, but still with the ability to keep everything readily customisable and with a consistent UI. I like this in some ways more than site profiles, as with a site profile, you get a fixed set of functionality at install time rather than packs of fields and templates that you can install on top of a base model if you need different functionality. eg, if you know that a given set of modules (that are just wrappers for making certain sets of fields and templates available) are installed, it would make it easier for people to 'theme' them. Once you get a known set of field names that will exist if certain modules are installed, it's easier for people to build themes around them. I already found a snippet that I've used when I wanted to update the appearance of a site to allow testing a new look that I could put in init.php if ($user->isLoggedIn() && $user->hasRole('tester')) { $config->urls->templates = "/site/bootstrap5/"; $config->paths->templates = dirname(__DIR__) . $config->urls->templates; } This could quite easily be modified to allow 'themes' ie different versions of templates while leaving official ones untouched, and could include 'pro' themes. So -> get ProcessWire -> pick the components you want -> pick a theme, and done, with all of it still possible to be done manually, but the possibility to get a site up in a few clicks, and pay for premium components, with the modules functionality almost like an app store. I think having the ability to purchase premium modules built in directly to the admin UI might be helpful too, although it should never be the only way, as people who're concerned about security may prefer the requirement to manually upload new modules, as is the option now. I also wonder about official ProcessWire hosting (maybe combined with specific site profile/module packages that will be kept up to date)? Many other open source projects offer something like that with the option to either use the officially hosted plan or run your own, so there's no compulsion, but it's quick and easy for people to get started.

Ryan, I'm so sorry you're going through this. I just want to wish you the very best in the months and years ahead. ProcessWire has had such an enormous impact on my career and life really and I deeply appreciate everything you've done.

With apologies to true poets... The 403 Blues Some fine day I'll wake up and it'll finally be... the forums are free of the dreaded 403 These errors frustrate for months of late as Cloudflare issues have me reaching for tissues A firewall setting? Should I reset DNS? These Firewall rules give me forum blues I thought it was quiet just holiday cheer? but folks are abandoning that much is clear new visitors bouncing right at the door old regulars wondering what the forums are for I've pestered the admins dropped a DM or two left another mention just to bump it through I even set GrokBot to deliver me the news a daily summary of all the things I lose But some fine day I'll wake up and it'll finally be the forums are free of the dreaded 403

Life has got in your way and here you are still smashing it. Good work. You should feel proud.

Hi everyone, I’d like to share my new personal portfolio website: https://mladenmadarevic.com I’m Mladen Mađarević, designer from Croatia. My 9-to-5 work is primarily product design, while in my free time I enjoy designing and building websites. Mostly because I miss creativity of web design. I’ve been using ProcessWire for several years, and I really appreciate its flexibility and how easy it is for my clients to use. For this website, I decided to experiment with a Figma-to-Codex workflow to see how well it could work for fronted part and ProcessWire, partly out of curiosity and partly because of my own programming limitations. I’d love to hear your thoughts and feedback!

Good morning everyone * MediaHub had an update to 1.21.1 and a few quiet releases in between. File Types The sidebar gains a new File Types filter. The file types only populate when a matching item exists. We already have a Types filter on top of your Library, but this is more granular, and I find myself using it much more than its addition suggests. Utilities Someone suggested it'd be useful to see their unused assets real quickly. While I was adding this, I introduced some other useful filters. Here's the full set… Image variations The asset detail page gets an additional image variations table. If you've worked with PW for a while, you know how these can build up, so having visibility on them can illustrate that volume. Upload queue Another good user suggestion. Whan an upload is complete, they wanted a quick way to jump to that asset or back to the Library. Combo fields (fixed) Removing an asset from a MediaHub picker inside a Combo field wasn’t working. Fixed now. Title and alt on field upload. If you upload into a MediaHub field and type a title or alt in the sidebar before you save the page, those values now go onto the library record. Other uses of the same asset inherit them. Promoting custom fields the same way is still on the list. Download MediaHub 1.21.1 is available from your downloads area. Thanks everyone. I didn't @ peoples names in this post, but you'll recognise your suggestions. P * It was actually morning when I started writing this.

Here’s a more concrete example based on an integration I’m working on for Mercato, a ProcessWire-native commerce module. Mercato already has internal services for orders, payments, inventory, fulfilment, shipping labels, tracking, refunds and transactional email. I’m planning to expose selected Mercato operations through an McpServer provider, such as: mercato.get_order mercato.list_orders_to_fulfil mercato.verify_payment mercato.create_shipment mercato.purchase_shipping_label mercato.update_tracking mercato.send_order_email Any MCP-compatible bot, Codex instance or automation platform such as n8n could then operate the store through these tools. For example, when a paid order appears, an automation could verify the payment with the remote provider, check variant inventory, create the shipment, purchase a shipping label, save the tracking information, advance fulfilment and notify the customer. If the payment, stock or shipping data does not match, it could stop the workflow and report the exception to a human instead of silently changing the order. The important distinction is that McpServer is not the workflow engine itself. The bot, agent or n8n controls the sequence. McpServer provides the authenticated, scoped and audited capability layer, while Mercato performs the actual business logic. It also does not have to expose generic operations such as “edit any page” or “modify any template”. A provider can expose only narrowly defined business actions. Each client can have its own credentials and scopes, so one integration might only read orders, another may fulfil them, while refunds or payment reconciliation remain separately protected and may require explicit confirmation. That is how I see the difference from AgentTools: AgentTools is primarily for trusted local development and site engineering. Its CLI/Engineer can work broadly with ProcessWire structure and code, while its current MCP tools are read-only. McpServer is for controlled remote operation of an already deployed application: authenticated HTTP access, per-client scopes, rate limits and audit logs, with each module deciding exactly what external agents are allowed to read or change. So yes, McpServer can be used both to retrieve information and to modify data—but only through explicit operations exposed by installed providers. It does not automatically give an AI unrestricted access to ProcessWire pages, fields or templates.

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 guys, it’s really nice to see my name mentioned here. 🙂 My longer-term goal is not simply to release many separate modules, but to close the full product-development loop: to assemble a ProcessWire backend from small, focused components and use it to power both a website and a native iPhone app. Mercato will most likely become my first real experiment in this direction, which is why I recently rebuilt it around a versioned headless API for iOS clients. Of course, the same general architecture can be created with other systems. What I particularly like about ProcessWire, however, is how naturally it works as a lightweight construction kit: each module can remain a small independent application with a clear responsibility, while several modules can be connected into a much larger product without forcing every project to carry the entire platform. Perhaps the closest analogy is Arduino: the individual board and components do not determine what you must build. You connect only the pieces you need, reuse them in different combinations, and gradually turn a small experiment into a complete system. That is increasingly how I see ProcessWire - not only as a website CMS, but as a modular backend for web and mobile products. @Ivan Gretsky @szabesz

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.

Here is a simple real-world example of where Kern can be useful. Imagine you run a local business directory with hundreds or thousands of company profiles. Over time, phone numbers change, opening hours become outdated, companies move, and descriptions no longer reflect what the businesses actually do. Normally, the site owner has two options: update everything manually or give business owners access to the ProcessWire admin. Neither option scales particularly well. With Kern, a business owner can find their company profile and request access to it. Once the request is approved, they can suggest corrections through a simple form on the website. They might change their opening hours, update the company description or correct a phone number. The public profile does not change immediately. Instead, the site editor receives a clear comparison between the current information and the proposed version. The editor can approve or reject the changes. If someone else has edited the profile in the meantime, Kern detects the conflict instead of silently overwriting the newer content. The business owner never needs access to the ProcessWire admin, cannot edit other companies, and only sees the fields they are allowed to change. The same idea can be used for author profiles, job listings, products, organizations, event pages, property listings or any other content maintained partly by people outside the editorial team. That is essentially the problem Kern is designed to solve: letting people maintain the content they are responsible for while the website owner keeps control over what is actually published.

@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.

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

Ryan, thank you. I’m glad to hear that you are feeling better and that your appetite and enthusiasm have returned. By an “optional standard contract,” I mean a small, consistent interface that any ProcessWire module could optionally implement to expose a limited set of safe capabilities to AI agents. It would not expose the full ProcessWire API. Instead, each participating module would explicitly declare: - its provider namespace and contract version; - the capabilities or tools it exposes; - JSON schemas for input and output; - whether each capability is read-only or mutating; - the scopes required to call it; - whether confirmation and an idempotency key are required; - and the audit information that should be recorded. The MCP gateway would provide discovery, authentication, scopes, rate limits, confirmations and audit logging. The provider module would remain responsible for its own domain validation and execution. Relay provides a simple example. It might expose relay.listScheduled as a read capability and relay.schedulePublication as a write capability. The second operation could require a specific write scope, explicit confirmation and an idempotency key. An agent could schedule a publication, but it could not execute arbitrary PHP, query the database directly, access the filesystem or modify unrelated ProcessWire content. Modules that do not implement the contract would remain completely unaffected. This could begin as an experimental specification and a minimal provider example rather than requiring any commitment from the core. Once I finish the write path and security tests, I can prepare a short architecture note, the proposed contract schema and a controlled example provider. That would make it easier to evaluate the idea based on a working vertical proof rather than only a description. I agree about making the Demo page a Demos page. Multiple small, inspectable application examples would demonstrate much more of ProcessWire’s range than a single showcase. I can prepare a scoped proposal for an application-style demo separately. Moving the Store to a dedicated commerce service also makes sense. International tax collection, author payouts, licensing and refunds are substantial responsibilities. I can research services that support merchant-of-record or marketplace workflows, author payouts, webhooks and external licensing, and prepare a comparison before we assume that a custom implementation is necessary. A small board here on the forum would work well for durable proposals, decisions and deliverables. Slack could be useful later for faster discussion, but I think keeping the initial work visible and organized here may make it easier for the community to contribute without fragmenting the conversation. Thank you for being open to these ideas. I’ll start by turning the capability contract into a concise technical proposal and working example.

Hi @ryan, I’ve recently been in that situation myself, so I understand what you’re going through; it’s tough, and the process can be long or short, but it depends entirely on you—and no one else. You need to reconnect with yourself: who you’ve been, who you are today, and, above all, who you want to be. Ultimately, these things happen because of someone else’s decision, and while it’s not what you would have chosen, it’s something you cannot control. Look at it this way: you have a golden opportunity to show your children that adversity is a part of life and that it can be overcome with the right mindset and personal effort—to show them that the strength to face these situations comes from within and doesn’t depend on anything external. Regarding ProcessWire, the work I do at my company focuses primarily on application development rather than website creation. Consequently, our needs have differed somewhat, requiring features that I implemented in my own way—mostly within the framework's internals. While the code or implementation might not be optimal (I'm a graphic designer), the underlying concepts are sound, and the approach has worked very well for us so far. You might find the documentation more useful than the source code itself, but you may also discover elements that could benefit the framework, helping to expand ProcessWire's capabilities. There are other things I haven't published, but you can check out some ideas here: https://github.com/wirecodex

@ryan, knowing what it feels like, just a quick cheer up. Even though right know it feels like drowning and leave you confused and hurt,- this terrible state your are in will change and you will be able to look at it differently and feel more calm again at the end. You cannot force it, it just happens in the course of time. Even though it seems a faint and plain statement, i know... All the best and take care of yourself!

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?

Nice to see some commits coming in. If you need to talk to anybody I am always here, and I am going through exactly the same thing. 44 years old, been with my wife for 25 years, married 14 of those, 3 girls 9, 7 and 4, and we split up 4 weeks ago. Hopefully soon like me, you will realise that some things are for the best, and you cant force anything in life. I have a great support network and am starting to realise a lot of things with their help. Stay strong, but also if you need to fight your corner then dont be afraid to, that is what I have been very bad at throughout the 25 years. I would be fully on board to help ProcessWire grow. We use it 95% exclusively at my agency for 11 years now I think.

Ryan, this is an incredibly difficult period, but I believe things will gradually find their balance again. It will take time. Please take care of yourself. I am deeply grateful for the opportunity ProcessWire has given me - not only to create modules, but to think and build at the platform level. Recently, I built a learning and examination platform on top of ProcessWire. It consists of two independent ProcessWire applications: a public website and commerce layer for course discovery, inquiries, checkout, orders, and digital access; and a separate Academy responsible for student accounts, course delivery, examinations, question banks, attempt evidence, results, and completion documents. The two applications have separate responsibilities and exchange only signed, minimal events and one-time activation data. This is not simply a content website with a few additional fields. It is a real application platform with domain boundaries, controlled workflows, security requirements, and its own product interface - all built on ProcessWire. This is currently a private implementation, not an open-source release or a product announcement. Its future distribution model is intentionally undecided. I mention it only as a practical example of what ProcessWire makes possible. Since you asked for help, ideas, and collaboration, I also want to respond with something concrete. Today I released Relay, an MIT-licensed scheduled publishing and visual editorial calendar module for ProcessWire. Relay provides publication windows, recurring schedules, month, week, quarter, timeline and Kanban views, drag-and-drop rescheduling, iCalendar feeds, notifications, JSON import and export, and 48 bundled translations. Its production jobs are handled by a bounded, lease-protected CLI worker with retries, safe parallel execution, and automatic stale-lock recovery. It is another example of how a real application requirement can become a focused ProcessWire module without adding unnecessary fields or machinery to page templates. PW ≠ WP — and that difference is its strength. ProcessWire gives us a clean API, a flexible data model, and the freedom to install or build only the modules that solve actual requirements - without accumulating layers of unnecessary machinery. Every serious system I build with PW further dismantles the assumption that WP must always be the default choice. Sometimes it feels as though we are quietly building something capable of genuinely challenging WordPress - not by copying its ecosystem, but by demonstrating a cleaner and more focused way to build. ProcessWire may still be relatively small because it has never had the same marketing reach, but its technical foundation is remarkably strong. With better visibility, real-world examples, and collaboration from the community, I believe it can grow far beyond its current position. I would be glad to help - not only through modules, but also through products, architecture, documentation, ideas, and real implementations. You have created something truly special, and you are not alone in taking it forward.

Hi @maximus, I’d also love to use ProcessWire to build mobile apps, especially with NativePHP, although unfortunately it currently only works with Laravel. I’m actually doing this right now. I’m building a PWA with ProcessWire, and I’m planning to use PWABuilder to package it for the Google Play Store and Apple App Store. Handling Google should be straightforward; Apple will be more of a gamble. Having native SQLite support would be a huge win. But I hope we can eventually move toward a system that gives us all of this, if possible, without losing what makes ProcessWire special in the first place.

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.

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.

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.

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. 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. 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. That's correct. Also correct, growth is now important. See above for what changed. Kind of growth: increase user base. Why? See above. 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. I'm not convinced by that either, and I'm not sure where you got 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. 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. I disagree. With a larger user base, I think it is a great foundation for a larger commercial ecosystem. 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. 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. 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. 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). 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. 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. They will most certainly help. The "who" is already clear, the scale just needs to increase. 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"? 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.

I am available for a chat whenever we can schedule one. School holidays at the moment, a mountain of work and I am having therapy twice a week so I am busy busy but lets get something scheduled in soon. Shoot me a message and we can arrange. I will quote this smaller part of the post. People may not realise how many other people have had a hand in ProcessWire and the Git commits over the years. Whilst Ryan may have the final say there has been lots of collaboration and that has been a good model. I personally dont need commits every week to know that a project is moving forward. Ryan is active on the forums and support forums enough that people should be aware this project is alive and well throughout the year.

The most popular open source software in the world follows this model, and Linus still gets to have (a highly opinionated) say.

Thanks for all the support! I actually started feeling quite a bit better over the weekend. My wife moved out of our house, and into her new apartment, and rather than hitting me hard, it actually made me feel a little better. This situation was so much pain over the last couple of weeks that I reached a point of associating that pain with her, which made me see her differently, rather than my idealized version of her. At least for the last couple of days, I feel better without her here, and a sense of nothing, no feeling at all about the situation... neither bad nor good. Though there is some sense of relief that the worst seems to have past, my appetite has returned, and I'm left with a lot of ambition and real enthusiasm for growing ProcessWire. @Peter Knight Thank you! Great suggestions. I'm such a marketing neophyte, I wouldn't even know how to start. But it sounds like you are on to some really good things here. Something that I can say is that ProcessWire does quite well from the SEO side, thanks to all the content we have here. Though we aren't targeting any specific search terms well, at least from the homepage, I think people are searching for different terms than what we mention. Though I don't know for sure what people are searching for. Any ideas? We probably do need to better target ProcessWire as an AI friendly CMS, but I don't know what searches folks use there. I could be wrong, but currently think being open source is key. I don't think we can really complete with the commercial options (at least on marketing) unless we have an actual business with employees and multiple developers. I think we're better off being the best "open source" option, something that people can use for free. But I can see having a site-licensed "ProcessWire Pro" version that has a broader inclusion of modules (Pro modules), and support built right into the admin. Would this be the sort of thing where there's a set donation amount and by maintaining that amount they get their logo and link in a public-radio style "Made possible with support by..." section on the homepage, footer throughout the site, or similar? I'd be open to it. @maximus So many great ideas! I'm interested in learning more about the "optional standard contract" you mention? Sounds great! Thank you. I think it would be ideal if our Demo page was more of a "Demos" page with multiple examples people could dig into. So there would be an upgraded Skyscrapers example, but there would be others, like what you've mentioned. I'd like to preferably get the store out of IP.Board and into a dedicated service that can handle all the tax rules for different locations around the world. This has been one of the main things holding me back from setting up a ProcessWire store with support for other authors. Between sales, taxes and payouts to authors, it's fairly complicated. If there's an existing service we could use that already has this ability, I think it would be worth spending money on. I do still like the forums, so would use webhooks to handle the management of user roles and access in the forums. I can get a board setup for that here. Or maybe something like a Slack channel would be even better? Thank you, that sounds great!

Looking for testers for the new FrontendForms version 3 The new version of FrontendForms has been completely reworked with the help of AI. Security vulnerabilities have been fixed, bugs have been resolved, and new features have been added. The entire structure has also been redesigned to make the code more organized, scalable, and easier to maintain. This was therefore not a typical refactoring, but almost a complete rewrite of the entire module. More than 1,700 unit tests were also created with the help of AI to help ensure the functionality of the entire module. Nevertheless, manual testing is still necessary. For this reason, it would be great if some of you could test the new version on a test server using your own forms and report any problems directly on GitHub (not here in the forum). I will try to fix the reported issues one by one. Please do not use this version on live sites yet! Once the version has been thoroughly tested, it will be included in the next official update. This version should also be fully compatible with the current versions of FrontendLoginRegister and FrontendContact. The new version can be downloaded from GitHub using the following link: https://github.com/juergenweb/FrontendForms3/tree/main The original version has been updated to the new version, so this repository is no longer necessary. A short installation and testing guide is also provided there. Thank you very much for your help!