Leaderboard

As some of you might know from my monthly newsletter I have been struggling with how to proceed with my commercial modules. It's a long story, but last year I reached a point were something had to change. The main problem is that building and selling modules for ProcessWire has never been sustainable for me. Not even close. It has been a lot of work to build the shop. It has been a lot of work to provide proper docs. It has been a lot of work to create videos about the modules so that interested people can get an idea of my modules. That's fine. I knew it would probably not be easy. But I wanted to try 🙂 You never know if you don't try. And I've had hope that it is possible. Unfortunately I don't have this hope any more and that's why I have to draw a line under it. That's also fine. I've learned a lot and I'm really thankful for anybody that has sent some Euros to a stranger that they have never met in person and that excludes any refund 😄 So for me the decision was taken. It took me quite some time to get there, but here we are. There was just one problem left: My clients. They have put trust in me and I didn't want to disappoint them. Just drawing a line might be a good solution for myself but might be a terrible solution for them (and their clients as well). Just not providing updates and keeping selling them is also not my style. With open sourcing my modules I try to find the best solution for everybody involved and I want to especially thank @FireWire for helping me get there 🙂 What does that mean? I'm using my modules in many of my own projects, which means that I will likely keep them alive for some time. On the other hand I don't plan to develop a lot of websites any more and many modules are somewhat feature complete as @FireWire helped me to realise, so there are no bigger updates planned for any of my modules at this time. Also, none of my modules is tested with the new admin theme. If you want to help out on that front, I'll be happily merging PRs, but as I'm not using it myself I'm not going to fix any issues or adding support for it in my spare time. So if you want to keep using my modules: Go ahead and have fun! 🙂 If you find the modules helpful it's always nice to let me know. Hope this is a good solution for everyone! Thx for reading and all the best.

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

Thank you very much @bernhard! I respect and appreciate your decision. I was always a fan and user of your modules and I will be happy if the module-legacy will live on here and there.

Seems this module has not had its own forum thread. Now it has. https://github.com/baumrock/RockIcons

Dear Bernhard, unfortunatelly my fear about your future activity became true with your post today. Have realized that you almost dissapeared here in the forums after the initial release of the new admin theme and some of the debates assosicated with it. I‘ve always enjoyed your ideas and help here. I wish you all the best for your future both private and for whatever business you plan next. Best regards

Watching this with interest: https://github.com/BitPoet/HannaCodeDialogTiny/pull/7 👀😍

Hi everyone, First of all I had no idea, which category would fit best ... I'd like to share a little tool I've been working on to make the initial setup of ProcessWire even faster, especially when working on remote servers without SSH access. What is it? kickstart.php is a modern, single-file installer/loader for ProcessWire. Instead of uploading thousands of files via FTP, you just upload this one file and it handles the rest. Key Features: Version Selection: Choose between the master (stable) or dev branch directly from GitHub. Smart Multi-Language: Built-in support for English, German, Spanish, and French (with automatic browser language detection). Modern UI: Built with Tailwind CSS, AlpineJS, and smooth animations using Anime.js. Pre-flight Checks: Automatically checks for PHP version requirements and prevents overwriting existing installations. Automatic Cleanup: Removes the downloaded ZIP archive and temporary folders after extraction. How to use it: Upload kickstart.php to your webroot. Open it in your browser. Choose your version and click install. Once finished, click the button to start the official ProcessWire installer. I hope some of you find this useful for your workflow! Feedback and suggestions are always welcome. Cheers, Markus kickstart.php Improved Version now available on GitHub: https://github.com/markusthomas/ProcessWireKickstart

Hi everyone, This module completely replaces the default ProcessWire image sizing engine with the powerful Intervention Image v3 library. The goal was to modernize how we handle images in ProcessWire, bringing in features like AVIF support, superior resizing quality, and strict aspect-ratio handling, while keeping the API compatible with what you already know. 🚀 What does it do? Replacement: It hooks into Pageimage. You can keep using $image->width(300), $image->size(800, 600), or $image->crop(...) just like you always have. Modern Formats: Automatically handles WebP and AVIF generation. Smart Responsive Images: It introduces a configuration-based approach where you define Breakpoints, Grid Columns, and Resizing Factors. The module uses these settings to automatically calculate and generate the perfect srcset for your layouts. ✨ New Methods: render() and attrs() While standard methods work as expected, I’ve added/updated methods to handle modern HTML output: 1. $image->render(string $preset, array $options) This outputs the complete HTML tag. It automatically handles: The <img> tag with srcset and sizes. The <picture> tag with <source> elements if you have enabled extra formats (like AVIF/WebP) in the settings. Lazy Loading & LQIP: It automatically generates a Low Quality Image Placeholder (pixelated/blur effect) and applies a base64 background to the image tag for a smooth loading experience. // Example: Render a 'landscape' preset defined in module settings echo $page->image->render('landscape', ['class' => 'my-image']); 2. $image->attrs(string $preset, array $options) Perfect for developers who use template engines like Twig or Latte, or prefer full control over their HTML. This returns an array of attributes instead of an HTML string. $data = $page->image->attrs('landscape'); // Returns array like: // [ // 'src' => '...', // 'width' => 1200, // 'height' => 675, // 'srcset' => '...', // 'sources' => [ ... ], // Array for picture tag sources // 'style' => 'background-image: url(data:image...);', // LQIP Base64 // 'class' => 'iv-lazy ...' // ] ⚙️ Configuration Strategy Instead of hardcoding sizes in your templates, you configure your design tokens in the module settings: Breakpoints (e.g., 1200px) Aspect Ratios (e.g., 16:9) Grid Columns (e.g., 1-1, 1-2, 1-3) Factors (e.g., 0.5, 1, 1.5, 2 for Retina support) The module calculates the necessary image dimensions based on these combinations. If you request a specific aspect ratio, it ensures strict adherence to it, preventing 1px rounding errors. 📝 A Note on Documentation I wanted to get this into your hands as soon as possible, but due to a heavy workload, I haven't finished writing the detailed README.md yet. Currently, you can grab the code from GitHub (link below). I will submit this to the official ProcessWire Modules Directory after add some other features and after update readme.md Download / GitHub: GitHub Repo I’d love to hear your feedback and suggestions!

@BrendonKoz breakpoint and aspect ratios not comma separated, its line by line config. its a copy paste input field issue. I am using this external library on all my project. I decide to make it a module. Now its a module. There is base Pageimage library problems for me and there is no solution until now: https://github.com/processwire/processwire-issues/issues/2048 https://github.com/processwire/processwire-issues/issues/2016

More or less the same as in 2016. The two best hosting providers for classic PHP websites remain: Metanet (even though they have declined since the takeover a few years ago) and Hostpoint.

You can probably find hundreds more examples, e.g.: https://www.facebook.com/groups/771395196543555/posts/2371859523163773/ or:

Have some swiss customersites by cyon.ch and everything works fine.

Here's another website that i recently made that I would like to share with the community: https://www.w2-ingenieure.de/ W² Ingenieure (which is german and translates to "W² Engineers") is a small office that offers that develops, modernizes, and optimizes living and working spaces in Germany like: Schleswig-Holstein, Hamburg, and Lower Saxony. Whether for private households, commercial enterprises, public institutions, or industrial plants – they plan and implement customized solutions for even the most complex requirements. This project is a redesign of an existing website. While the old website had plenty of good content, there were multiple flaws in the design (especially the mobile version of the website) so my main task was not to make a from-the-ground-new-concept but to give it a better, functional and more polished look based on the CI. As we are talking about an engineering company that offers planning for the construction industry the look of the site hat to be sleek, clean, somehow modern and overall "serious". We are not talking about a design-agency website here. Tech Talk: - UiKit as frontend framework - RockPageBuilder for content creation and editing - TextformatterRockDown to enable headline formatting - RockFrontend for Ajax Endpoints (used in form submissions) - RockDevTools for Asset Management and Minification - SEO Maestro for SEO meta data - PageImageSource for webp image creation - FileMover as a workaround for a global media management solution - WiremailSMTP to handle form submissions So here it is: The website consists of several page templates, including: - Homepage - Content Page - Project Page - Job Page - etc. The Homepage and Content Page templates can be populated with pre-defined content-blocks via @bernhards RockPageBuilder. This is straight-forward and easy-to use. The user can chose between multiple content elements and place those elements in any order they want: For Example we have: - Textfields - Teaser in multiple variants - Description Lists - Hero Title Image Sections - etc. Once added the content can be edited directly in the frontend or inside a convenient popup window (or from the backend page edit view of course). Other templates like the Project Page offer a more strict, predefined, layout to achieve a uniform look throughout any project page that is crated. These type of pages can be populated from the backend more easily: I have to keep my attachment file list small, so please have a look on this site for yourself and don't hesitate to ask any questions if you would like to know more about the tech in the background. Have a great week! Stefan

@ryan, You'd mentioned at some point that existing installs could retain the old theme and perhaps users prompted to update to the new one. At the moment if I upgrade an existing site to the dev branch, the new theme is enabled by default. This breaks any custom TinyMCE styling as the new theme overrides it. Are you planning to implement this prior to the next master version? Ideally for us, given we have several hundred sites which we update to the latest master when it is available, nothing would change for the users. We could then turn on recommending a theme upgrade on a per site basis, or if we choose to, force the upgrade on the users. Cheers, Chris

I hope I suggested aligning css variables and less variables, not uikit classes 🙂 At least that's what I meant! But to be honest I'm not sure about this suggestions either. I think part of the suggestion was to make it feel less wrong. Having css variables and less variables side by side just hurts and having them follow different naming conventions - if any - hurts even more. I probably hoped that having them at least named equally would make it less painful. But if that really worked at all or was even possible to achieve? I don't know. This question should have been asked long time ago. I have raised my concerns regarding css variables right from the beginning by pointing to an open request for UIkit to support css variables from 2021. Anyway - I appreciate your efforts to help to improve the situation! I hope I can add something useful: --dropdown-menu-background-color @navbar-dropdown-background UIkit uses semantic variable names. The component is called "navbar" (not "menu" like you suggest). Here are all UIkit components. Also UIkit uses the term "background" for background colors and "color" for text colors. You are using "--text-color" where - in UIkit - the "text" would be redundant (and thus left away) and the less variable would be something like "@global-color", which would tell any UIkit user that it's the text color from the global component. For an example look here: https://github.com/uikit/uikit/blob/develop/src/less/components/navbar.less @navbar-dropdown-color as another example tells anybody knowing UIkit that this is the variable for the text color of the dropdown (not the background). Now one could argue that this can be confusing for anybody not knowing UIkit, and I agree. I just wanted to mention that these conventions are there and they have been there since 2017, so any change should (have) IMHO be well considered. Following these conventions would make your variable names a bit less verbose (--top-menu-background vs. --top-menu-background-color). Though that alone can be the fuel for a lot of discussion. So I'm not sure what would be best. I still can't believe that we opened this can of worms... On the positive side, what LESS can NOT do: If you have multiple navigations on one page and you want to style them differently (eg one background red and one background blue) you simply can't do that. There is only one variable and that applies to all dom elements using the .uk-navbar class. This is where CSS variables shine! There we could do this: :root { --navbar-dropdown-background: red; } #my-custom-nav { --navbar-dropdown-background: blue; } This could mean that we probably COULD more or less stick to uikit variable names but at the same time have the flexibility to style different sections of the UI differently. Though I wonder how such a setup would be translated to the old LESS based themes. Whatever, it would result in something like this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --navbar-dropdown-background My feeling is that this would make a LOT more sense then what we have so far. But I admit I didn't think that that through, so there might be culprits. Your example on the other hand would result in this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --dropdown-menu-background-color Which does not really look beautiful to me 🙂 But maybe your setup works better in real life. In the rock theme I invented the @rock-primary color that sets several uikit variables once, for example. So I understand that we probably don't need a 100% match. As much as I would have loved to help with this, I just fear that any effort in that direction is wasted love (word pun as we won the ESC with that song recently and I have to take this admin theme stuff less seriously ^^). I guess - like you already mentioned - what is likely going to happen is that the new theme will receive updates, make use of cool new features (why wouldn't we) and then the old ones are going to die, which means many of the 1200+ modules in the modules directory will have to be checked and updated or will sooner or later break or at least look ugly in at least one theme. I think that's the reality that we are facing. To be fair: I have spent many hours already in the new theme and all technical implications and flaws aside I have to say I like it. I like many aspects, and it definitely looks and feels more modern. Maybe this step was necessary and maybe many new users will join our community. Maybe many of them will buy my modules and messing around with those new css variables and overrides will pay off one day. Who knows 😄 It's just that I didn't choose ProcessWire to make a lot of money. I chose it to enjoy my job.

What we are doing here is basically reinventing the wheel. We are trying to invent a new design system that makes it easy for developers to be used and to be customised. But we already have this design system. It is called UIkit. It is in the core. It is built on logical and semantical components (base, text, buttons, background, utilities, ...) and it has thoughtfully defined and well documented (!) variables and concepts. Yes, it uses LESS (or SASS), which is not the coolest technology on earth. But this decision has been taken by @ryan in 2017. If the decision was that CSS variables are superior and we proceed with them: More than happy! I'm using CSS variables all over in my projects (on the frontend). But keeping UIkit/LESS as the foundation and then adding a new theme with 3200+ lines of overrides just does not fit with the genius and beautiful image that I have had of ProcessWire. To me it looks like somebody was decorating a cake here. Adding layer over layer to make the cake look good. For me it just doesn't taste 😞 It never really did (ui-button vs. uk-button-primary, etc), but it was ok. It was the reality that I grew up with. Now it's different. Now things got a lot worse and I think this was not necessary. I guess I was hoping that all the effort that was put into a new admin style would bring some fundamental improvements of the overall situation. @ryan, you have pushed so many great updates over all those years and you have solved so many problems in a way that just left me behind with deep respect and amazement. Now we have yet another layer of complexity to deal with when working on backend modules. I'm not happy this time 😞 I appreciate all the effort that you put into making PW attract new users and I understand that it must be frustrating to get such a harsh feedback by some of us. Especially after putting so much work into it. The thing is: It did not have to be like this. Why not ask the community upfront? Before all the work has gone into it? To have an unbiased view? To keep the risk and emotions low (for everybody)? To hear what others might think of such a fundamental change? To get feedback and maybe even good ideas? Or to explain what is considered to be fundamental and what is considered to be experimental? The question is: What now? The decision was obviously taken long time ago, so I guess we have to deal with it (even though I think it would be the best to take it back completely). If you ask me - as a long term member and contributor - what I'd like to see to make things less painful for now and make things better long term, here are my suggestions: make the css variables used in the new theme be aligned with UIkits less variables (--main-color vs. @global-primary-background ...) remove dark mode completely, or, at least, disable it by default and add a warning that it is experimental - I think it will cause 99% of work for very little benefit add docs for the new theme and the concepts it uses rewrite the whole admin theme/framework from ground up with a modern stack (css variables + Alpine JS + darkmode) as soon as possible Thank you and all the best for the future of ProcessWire