Leaderboard

I understand the design decisions behind this change, but please consider restoring the showcase section on the home page (even a simplified one). Regardless of the target audience, in my opinion, this is one of the most important sections. Words are important, but for a new visitor, they're just words (any other solution will try to describe its advantages). Visitors need examples to illustrate these words, and in my opinion, the admin panel screenshots at the top aren't sufficient. The showcase provides first rough examples of what can be built and what the user can achieve before they decide to invest their time — for example, downloading and installing ProcessWire. They can also encourage users to dive deeper, reading more, looking for features, etc. Just my 2 cents.

I understand the logic here, but in my opinion that's wrong target audience. How will less technical user build website with processwire as there is no themes and "plug-and-play" plugins? If im a marketeer, or content-editor, why and how would i choose processwire, because there is a text "flexible, stable..."? Or because processwire has great API, and technically built really well, how would i know if im non-technical, how would i evaluate the CMS, based on a big headline? If you are really so confident about target audience, at least there is a need for some really good demo. I believe we need more developers pushing clients to use processwire, not vise versa.

On Windows 11, Chrome/Firefox/Edge all looking good to me now - consistent animations and the aliasing has gone too.

I'm confused. Isn't ProcessWire primarily the tool we want to convince more developers to use in order to gain a larger user base? So this page should primarily be used to convince developers of the advantages with examples (sorry to say that) instead of animations that have nothing to do with ProcessWire. To convince customers of the system, it would be better to provide a good demo that shows how simple ProcessWire is to user. However, this could also be done here, among other places: https://www.softaculous.com/apps/cms/ProcessWire

ProcessWire has always communicated well to developers and they typically aren't the ones that need to be convinced. We always connect with the developers. But the decision makers are more often the clients, designers, marketers, etc. They are the ones that we hope to increase visibility to. Several updates to the new site this week, various minor optimizations and improvements. The biggest additions were made in the API reference, which now covers a lot more methods and has some navigation improvements as well.

Hi @BrendonKoz, brilliant, thanks a lot! "Truncation" and such,- i missed to use those terms. Probably therefore i got no results while searching the forum...

Hi @olafgleba! It looks like others have already solved this for you. I'll let you determine what solution that's provided better suits your need. 🙂

Have you tried sending email via SMTP? Had a similar issue on one site. After switching to PHPMailer with SMTP, sending emails worked. Also ensure the from email uses your domain name.

Thank you for your feedback! And thanks to @ryan for the technical implementation. I am currently on vacation and am only now able to respond here. I understand that it takes some time to get used to change, especially when you are attached to something. And there will always be different evaluations and opinions about design. However, it is important to me to say that there are reasons for our design decisions and that they were not made arbitrarily. Due to time constraints, I will only be able to address a few points here. The overarching theme of the design is “friendly flexibility.” All design decisions were made to emphasize this theme and find a consistent visual language. With the new design, we want to appear less technical and also include user groups other than developers, such as designers, marketers, and editors/content creators. At the same time, we want to differentiate ourselves from other comparable CMS products and highlight PW's uniqueness. The morphing animations are intended to communicate the versatility and flexibility of PW and engage users. For example, we used many adjectives on the old site (flexible, stable, secure, open, free, powerful, etc.) and our idea was to communicate this directly in the first headline. The font (“Apfel Grotesk”) we used has many curves and a friendly character, which is especially noticeable when used in larger headlines. The colors used have been part of PW's branding from the beginning, so we thought it would be good to continue using them. By mixing these colors, we want to communicate versatility again and move away from the rather technical and dominant blue of the old site. We also greatly reduced the amount of text per scroll on the homepage, because we felt the old site was lacking visual hierarchy and felt to crowded. We have a much more guided flow on the homepage now that makes users actually read the text and it's easier to scan the content. We have also improved the visibility of features and modules and adjusted the navigation structure. I can provide more details on this when I have more time. I hope it adds some context to our decisions.

I second that. While I completely appreciate all the work that has been put into the redesign, but I think the "brand spirit" is off. I feel like I've arrived at a typographer's portfolio site. To me, the new design conveys no message other than bold typography. All the messages are explicitly spelled out in writing, which is fine, but aside from that, we have plain, rounded boxes, practically no colors, no images and that is all there is to it.

Thanks you for your opinions and suggestions, they are very welcome! We can always count on this community for engagement 👍 One aspect that we discussed, and that I don't think Ryan mentioned, is that Jan and I had several clients express concern about the tool after visiting the previous website. PW has some recognition among developers, but zero recognition among non technical potential clients, who we need to accept PW as our CMS suggestion. That's also one of the reasons of having "CMS" and not "CMS/CMF" front and center. Design decisions will never please everyone, we were aware of that and decided to go bold anyway. Hopefully it will prove to have been the right decision 🙂 That could be a fun animation to make 😆 Seriously, though, I think we discussed this at a certain point. Not sure why we dropped it, maybe because being headless in PW is a possibility and not a feature, while all the other things on the homepage are inherent to PW. The GraphQL plugin could certainly be on the modules area in the homepage, though.

I've built this over and over in several of my modules (RockDevTools for Livereload, RockCalendar for creating events). Always a lot of work. Always a lot of boilerplate code. Always a lot of issues to fix. I think it's time to bring SSE (Server Sent Events) to everybody. Simple example (Empty Trash): Client-Side: // create stream const stream = ProcessWire.Sse.stream( 'ssedemo-empty-trash', (event) => { const textarea = document.querySelector('textarea[name="empty-trash-status"]'); try { let json = JSON.parse(event.data); stream.prepend(textarea, json.message, 100); } catch (error) { stream.prepend(textarea, event.data); } } ); // update progress bar const progressBar = document.querySelector('#empty-trash-progress'); stream.onProgress((progress) => { progressBar.value = progress.percent; }); // click on start button document.querySelector('#empty-trash').addEventListener( 'click', (e) => { e.preventDefault(); stream.start(); }); // click on stop button document.querySelector('#stop-empty-trash').addEventListener( 'click', (e) => { e.preventDefault(); stream.stop(); }); Server-Side: public function __construct() { parent::__construct(); /** @var Sse $sse */ $sse = wire()->modules->get('Sse'); $sse->addStream('ssedemo-empty-trash', $this, 'emptyTrash'); } public function emptyTrash(Sse $sse, Iterator $iterator) { $user = wire()->user; if (!$user->isSuperuser()) die('no access'); $selector = [ 'parent' => wire()->config->trashPageID, 'include' => 'all', ]; // first run if ($iterator->num === 1) { $iterator->max = wire()->pages->count($selector); } // trash one page at a time $p = wire()->pages->get($selector); if ($p->id) $p->delete(true); else { $sse->send('No more pages to delete'); return $sse->stop(); } // send message and progress info $sse->send( $iterator->num . '/' . $iterator->max . ': deleted ' . $p->name, $iterator ); // no sleep to instantly run next iteration $sse->sleep = 0; } Code + Readme: https://github.com/baumrock/SSE/tree/dev What do you think? Would be nice if you could test it in your environments and let me know if you find any issues!

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.

@taotoo Thanks, fixed the animation in Firefox. It turns out Firefox needs the SVG filter to be visible, so had to remove the "hidden" attribute and move it off screen with absolute position. I don't know what's up with the MS Edge appearance (I don't have that environment to test in) but if you find what it is, please let me know. @poljpocket I prefer to stick with the term CMS and guide folks into the CMF side of things, since the term isn't so widely known/used. Though I'll continue to use it, just not front and center. @adrian Blur issue should be fixed. The large text size on the homepage is intended. @Alexander That assertion is incorrect. The metrics say this redesign was long overdue. But you are right about a performance issue with the desktop version of Safari (only) related to not using the GPU, I'm working on it.

I have built a custom page-builder module 'ProcessMotif' (to be released if I ever get it working to my satisfaction!) and have hit a small snag with permissions. The module is a process module and has a page that I want to appear on the main menu and be available to certain roles. The only way I can seem to get it to appear like that is to set the permission 'admin-motif' in the module info and assign it to the relevant roles. Without that permission set, the page is only visible to superusers. However, the module also has a whole bunch of methods that need to be executed by guest and other users to navigate the site. If I give the module a permission, then I need to assign that permission to the guest role otherwise they can't see anything. I don't want to have to do that. I get the feeling that I'm missing something obvious and basic here, but I've read all the stuff about process modules (especially the excellent stuff by @bernhard here and here) but am none the wiser on this point. Anyone got any ideas? Ta.