dotnetic

Dear Ryan, first of all, I want to thank you for your continued work, for making ProcessWire available free of charge, and for everything you have built over the years. I was also sorry to hear about your separation, and I genuinely wish you well personally. Communication, the Konkat theme and the new website I can understand many of the points that have been raised in this discussion. In particular, I understand the concern about how some decisions were communicated and the feeling that parts of the community were not properly included. This also applies to the Konkat theme and the development of the new website. Much of that work was deliberately developed behind closed doors. I respect that there can be practical reasons for working privately, but it reinforces a broader concern about how decisions are made and communicated, especially decisions about what should become part of the core and what should remain outside it. Module discovery and explanation For example, I would have welcomed a discussion about integrating the kind of functionality I built in my Modules Manager 2. It provided a browsable interface to discover official modules, understand what they do, and download, install, update, uninstall and configure them. The central issue is not whether such an experience lives inside ProcessWire—similar to the WordPress plugin screen—or on the website. The important part is discoverability and clear explanation: helping people find the right module and understand why it is relevant. That was never really discussed with the community. A more open process around the new website, the module catalogue and core integration would have made it possible to compare approaches and learn what users actually need. ProcessWire was my dream system For me, ProcessWire is now primarily a system for existing client projects. It continues to run reliably there, and it remains a capable CMS. For new projects, however, I would probably no longer choose it. That is not because I have forgotten what made me enthusiastic about ProcessWire in the first place. For a long time, it was my dream system. Especially in the early days, I kept discovering things that made me think: wow, this is simple; wow, it can do that too; this is exactly how I wanted it to work. It was—and still is—a genuinely great system. Reproducibility and migration However, reproducibility and migration have always been difficult areas. Bernhard's modules made an important contribution here, and they are one reason why I was able to use ProcessWire for as long as I did. For developers building software with AI today, migration workflows need to be improved and expanded further. There needs to be a complete, repeatable initial setup. For example, when implementing a new feature in a Git worktree, an AI agent should be able to execute the full setup directly: create the required database, run the initial migrations, create every required field and leave ProcessWire in a fully runnable state. With DDEV, creating isolated project databases is fortunately straightforward. But that is only part of the solution: the initial migrations must also run reliably, so that every database field and structural dependency is available and ProcessWire actually works in the new environment. AI module and flat-file workflows Before going further: I have not tried AgentTools, the new AI module, yet, so I cannot judge it. Also, whether a flat-file CMS is inherently better than a database-driven CMS is debatable, and I do not think that should be the main criticism of ProcessWire. That said, I personally value flat-file systems because content can live directly in version control. This makes reviews, backups, deployments and AI-assisted editing very transparent. A content change can be a straightforward edit to a Markdown, YAML or other content file, visible in a Git diff and deployable like code. I expect workflows such as these to become increasingly relevant. Community input and core decisions I have also had requests in the past that were similar to Bernhard's: requests that made sense for my own use cases and that, in my view, could have been relevant to a broader group of users. The question is not only whether an idea is technically sound, but also whether there is a transparent way for the community to signal how widely it is needed. At the moment, ProcessWire's relatively small user base and the lack of a strong feedback mechanism make this difficult. A public system for discussing, prioritising and voting on proposals—for example, on feature importance, possible core integration and the direction a solution should take—would provide useful input. You should of course retain the final word; maintaining a coherent core needs clear stewardship. But if the community were larger and its feedback more visible, that feedback should meaningfully influence which features make it into the core and which direction they take. A larger ecosystem and critical mass But the larger issue for me is the ecosystem. It is difficult for commercial module authors to build a sustainable business around ProcessWire. The user base needs to be significantly larger to reach the critical mass that creates a healthy market for extensions, services and commercial products. A marketplace would also make a meaningful difference. With WordPress, Kirby, Statamic and others, commercial authors have a central place to present and sell their work. That creates discoverability, trust, payment infrastructure and an incentive to invest in high-quality extensions. If every author must run their own shop, the barrier is simply much higher. Kirby's positioning illustrates the broader point well: it explicitly addresses developers, designers, creators and clients. Reaching several connected audiences helps create the critical mass that supports an ecosystem, not just a technical product. A fair pricing model as a possible example Other systems also show that an open and approachable CMS can be paired with a fair commercial model. Kirby is a useful example: its discounted Basic license costs €99 per site for individuals, small teams and organisations with annual revenue or funding below €1 million, while its Enterprise license costs €349 per site for organisations of any size. It is a one-time payment rather than a subscription, includes three years of feature updates, and Kirby also provides free or discounted licenses for students, educators, selected non-profits and similar projects. I would of course want ProcessWire to remain free for me and other developers. The point is not to put a paywall in front of development, experimentation or small projects. But a differentiated model could be worth discussing: larger commercial organisations could pay a reasonable license fee, while developers, private users, small projects and community use remain free. That could create more sustainable funding for development, ecosystem investment and the long-term health of the project. Security and the maintenance-business trade-off Security is one of ProcessWire's strongest advantages. As Bernhard pointed out, though, this strength also has a commercial downside for developers: once a site is properly built and running, it tends to keep running. That is excellent for the client, but it does not naturally create a sustainable maintenance business for the developer. A reliable, secure system can therefore reduce the recurring work that often funds long-term care and product investment. Closing thought None of this is meant as a blanket criticism of ProcessWire. It is still a strong and dependable CMS, especially for established installations. But for new projects, I now put more weight on the size and openness of the ecosystem, a viable commercial market for extensions, modern publishing workflows and the ability to build lasting services around the platform. On those points, I currently tend to choose other systems.

Hey @Juergen, I tested the new version with an existing form, which is completely API-generated and everything worked fine so far. Even the Tailwind Custom class still works. I think I will do some more tests and report back on github, if I encounter something. Thanks for your continous work on this great module.

New version just released for actual stable ProcessWire 3.0.256 https://github.com/jmartsch/pw-lang-de/releases/tag/v3.0.256. You are welcome.

Dear @Nomak, your project sounds straightforward and well-prepared. Since you already have a fully completed design and will handle the backend yourself, I can focus entirely on delivering clean, responsive, and high-performance frontend code. Here is why I am a great fit for this project: Location & Legal: I am based in the EU (Germany) and will provide a valid EU VAT ID for proper, hassle-free invoicing. Experience & Modern Tech Stack: I have been working in web development since 1995, meaning I understand the core of the web inside out. However, I always stay on the cutting edge. For modern, responsive, and maintainable styles, I highly leverage Tailwind CSS, alongside clean HTML and robust JavaScript. Efficiency through AI: I actively integrate modern AI tools into my workflow, which allows me to speed up the development process, optimize code efficiency, and deliver high-quality results faster. Responsive Execution: Ensuring a seamless experience across desktop, tablet, and mobile devices is standard practice in my work. You can convince yourself of the quality of my work by taking a look at my portfolio: 👉 dotnetic.de/referenzen I would love to realize this project with you. Let’s connect to discuss the details and the design template. Best regards, Jens

Welcome back Soma, nice to have you here again, after such a long time.

We recently launched the digital home for the TECH.LAND Xperience, a cross-border innovation festival. The project required a robust system capable of handling complex schedules and providing a seamless, app-like user experience. Technical Stack & Advanced Techniques: ProcessWire CMS & RockMigrations: The flexible backbone for managing dynamic content. We used RockMigrations for a completely code-driven development workflow, ensuring that all fields, templates, and configurations are version-controlled and easily deployable. Modern Frontend Workflow: Built with RockFrontend and Vite, we utilized the Latte template engine for clean, secure, and maintainable markup. This setup allowed us to use a modern build pipeline with HMR (Hot Module Replacement) during development. Tailwind CSS & DaisyUI: For a rapid, modern, and futuristic UI. DaisyUI provided the foundation for complex UI components like the Side-Panel drawers. AJAX, Fetch API & HTMX Integration: To keep the user experience fluid, we implemented a decoupled approach for session and speaker details. Instead of traditional page reloads, content is fetched dynamically from dedicated ProcessWire endpoints (/ajax/speaker/, /ajax/event/). Interactivity with Alpine.js: We leveraged Alpine.js for lightweight frontend logic, managing the state of the program filters and the dynamic drawer UI without the overhead of a heavy framework. Dynamic Drawer UI: Speaker biographies and session details are presented in a modern Side-Panel component. This allows visitors to explore details without losing their position on the interactive timeline. Hash-URLs & Deep Linking: We implemented Hash-based URLs for the drawers. This ensures that every session and speaker has a unique, shareable link that opens the corresponding drawer automatically on page load, while also supporting the browser's "back" button functionality. Interactive Program Timeline: A high-performance schedule with four parallel stages. Modular Content with RockPageBuilder: For editorial flexibility, we used RockPageBuilder, allowing the team to create complex landing pages with modular, reusable components. Performance Optimization: Fast loading times were achieved through WebP delivery, lazy loading are integrated into our Vite build process (custom module). Key Modules used: RockMigrations: Code-first field and template management. RockFrontend: Vite integration and Latte support. RockPageBuilder: Modular content blocks for editors. SeoMaestro: Comprehensive SEO management. TracyDebugger: Indispensable for rapid development and debugging. Key Success Metrics: 5,000+ Visits shortly after launch. High Engagement: Seamless navigation through complex datasets with zero layout shifts. Editorial Efficiency: Automatic session-to-speaker assignment and drag-and-drop scheduling. complete case-study in german: Explosives Wachstum: Über 5.000 Besucher für die TECH.LAND Xperience kurz nach Launch Visit our website for more insights: dotnetic.de techland-xperience-dotnetic-referenz.mp4

WSL is not docker. It is a virtualization technique tough.

SSE (Server-Sent Events) would be a game-changer for ProcessWires core, and the trash functionality example perfectly illustrates why: The Current Problem: As you mentioned, the current trash system is painful - deleting hundreds of pages requires multiple confirmations, long waits, and often timeouts. Your clients shouldn't need API knowledge just to empty their trash efficiently. How SSE Solves This: One-click bulk operations: Start deleting 1000+ pages with a single confirmation Real-time progress: "Deleting page 234 of 1000..." instead of a frozen screen No more timeouts: SSE keeps the connection alive, bypassing PHP execution limits Graceful interruption: Users can safely stop/pause operations if needed Beyond Trash - Core Benefits: I have written several converter or importer modules for my clients, that import data and transform them into pages or a payment matcher module, which compares bank statements with invoice pages inside of ProcessWire. For all of these modules I wrote custom SSE Event handlers myself which is much boilerplate and duplicated code as Bernhard mentioned. Imagine every ProcessWire installation having this built-in: Import/export operations with live feedback Batch page operations (move, publish, unpublish) Asset processing (image optimization, file management) Search index rebuilding Module installations and updates Why Core Integration Matters: Standardized approach: All modules can use the same SSE implementation Better UX across the board: Every long-running operation becomes transparent Developer-friendly: No need to reinvent the wheel for each module Professional feel: Matches modern user expectations from enterprise CMS Addressing Adoption Concerns: I can't predict what percentage of users would use this feature - nobody can provide statistics for something that doesn't exist yet. But consider this: every ProcessWire user who has ever dealt with timeouts, batch operations, or large imports would benefit immediately. The feature would be invisible to those who don't need it, while being invaluable to those who do. Your modules already prove SSE works brilliantly with ProcessWire. Making it core functionality would elevate the entire ecosystem.

Great addition @bernhard. I would love to see this in the core. Async and streaming operations are everything, if you do custom programming with ProcessWire. Did you forget to provide a link to the PR or issue on github? I would give a thumb up.

Finally an adjustable theme and dark mode. Can't wait much longer.

I think this is a good idea. While the docs are not in markdown, you could use https://context7.com/?q=processwire as an MCP Server for your coding assistant (like RooCode, Cline, Windsurf, Cursor, etc) for context. Context7 pulls up-to-date, version-specific documentation and code examples directly from the source. Paste accurate, relevant documentation directly into tools like Cursor, Claude, or any LLM.

https://2025.stateofai.dev/en-US/

Instead of switching the whole editor, I recommend to checkout the extensions from https://www.augmentcode.com/ which indexes your codebase, has a memory and your data will never be used to improve the LLM https://roocode.com/ great and free Open Source extension, with custom modes like architect, code and ask or debug. Supports all Providers and even Openrouter. Bring your own keys. RooCode is a fork of https://cline.bot/ which is superior in adding MCP servers, because it has an own marketplace for discovery and installation. My extensions of choice are augementcode and roo. I switch between the two.

For me the following features (in no particular order) set ProcessWire apart from other systems: Easy core upgrades, just replace the wire folder and you are good to go. Low (zero) maintenance costs for core and plugins (with WordPress you need to watch plugins and core every week or day and update them) Free and Open Source Custom fields in core Easy to learn API Multi-language out of the box (which needs support for multi-language images, but that is another topic. I also know they are possible via ugly workarounds) The welcoming and helpful community Custom modules that modify ProcessWire or add new functionality without modifying the core

Hello @Juergen the settings for a custom framework are not working correctly. I am using FrontendForms v2.2.28. I have a tailwindcss.json file in site/assets/files/FrontendForms/frameworks. The Tailwindcss option appears in the Output rendering select field. But when I select it, the output on the frontend uses default classes instead of my tailwind classes. Even if I enter the custom path "site/assets/files/FrontendForms/frameworks" in the corressponding settings field, it doesn't work. If I copy my tailwindcss.json file to site/modules/FrontendForms/CSSClasses it works. Maybe you could look into this issue? Another hint: It would be good to rename the module to .module.php so it get's correct syntax highlighting, and enables static analyzers or Rector to recognize the file. This is also the recommended way of custom modules (don't know where this is mentioned, but I remember reading it). Regards, Jens