Leaderboard

Along with reducing the font size of that title considerably, can you also please consider removing the blur from it - it literally hurts my eyes to read it - they are constantly trying to make it look focused and sharp.

Congrats @ryan on the launch of the new website. I like it a lot! Since everyone else is posting the issues they found here, I will do the same. Thanks for considering! Layering issue on the homepage This is probably best illustrated with this screenshot: You can see I am using the devtools element selector tool and my mouse is clearly over the PW logo yet the morph canvas is focused by the tool. You might need to adjust the z-index of the header. "The CMS" menu item and "A powerful/friendly/... CMS you'll love" I love that ProcessWire used to not positioning itself strictly as a CMS because it isn't. It is so much more. This is also made clear in the introductory text: So the title and the first and most important menu item both tell visitors that ProcessWire is a CMS but then the text immediately contradicts that. I am sure you talked about this. Some ideas to solve this (yes, they have caveats too): The menu item can be called "ProcessWire" or "About" The text can be called "ProcessWire is powerful/friendly/... and you'll love it!"

The text animation on the start page doesn't work very well in MS Edge (on Windows 11 24H2). The edges of the font are not smoothed and the animation also looks better in Firefox.

Cleaning up image variations Warming caches ... e.g. with a clickable button and a progress bar in the PW Admin. Using RockDaemon to manage the process doing it.

The main metric for an open-source website is converting visitors into software users. However, the main issue with the open-source adoption cycle is that there is a years-long gap between users becoming aware of the project and actually starting to use it. Overall, the goal of any rebranding is to maintain recognition while solving new challenges for the brand. The level of visual identity change for ProcessWire would be acceptable in the case of rebranding when a product has totally failed, but that's definitely not the case here. This redesign will likely result in a dramatic failure of adoption for PW among new users because they will not understand that PW is something they were familiar with before. There are hundreds of CMSs and random visitors don't remember ProcessWire by name alone, and all visual branding on the new website has no brand consistency from the dozen years of the previous PW website. The new website (as commenters in other threads noticed) simply "hey what happened to my browser bookmarks, it‘s not PW." It's hard to provide suggestions without understanding what goals the new web design is solving, but I can recommend at least changing the German interface on the first screen to a screenshot with skyscrapers, because they were there all along and are strongly associated with PW even through new designs. @ryan, please don't take my word for it and instead look at the metrics. Something like PW downloads or PW module downloads per month compared with the same period in the previous year should show the real effect of this redesign. Update: there are some performance issues that result in over 200% CPU overload on the first page.

Unfortunately, IMHO the only animation that conveys anything is maybe the one for "Total control over the design". The rest just don't provide any meaning to me. In general animations on websites don't engage me, they distract me from learning what I am there to learn. But maybe I am in the minority, which is fine :)

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!

I would prefer to give it more real world testing before I do that. In my projects I seem to get some blocking behaviour if a stream is running. It has not been an issue with the sse based livereload but I'm working on an sse based page edit lock and I'm seeing some strange behaviour unfortunately.

Further to the above, on Windows the animation is different for me on Chrome vs Firefox [Chrome on left, Firefox* on right] (*The pixelation of the animation is due to it being a gif)

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.

From my research/testing this was necessary to make the SSE stream non-blocking. When using regular url hooks after the session has been started, then you can't open any other tabs while the stream runs. That's one of the caveats that you'll have to fight when developing something from scratch. Thx 🙂 For example?

You should use $pdf->filename, not $pdf->url.

Hi Bernhard, very cool module! I can imagine some interesting use-cases in combination with RockDaemon. I have one question: Why are you using token-based authentication? What's wrong with the session PW provides?

New dev version of Fluency with fixes to address RockPageBuilder compatibility issues. Translating content within blocks should now save correctly. @bernhard @snck @Tiberium If you are able to test it would be a big help so I can merge this into a new release. I've tested this on text, textarea, TinyMCE (normal/inline), CKEditor (normal/inline), as well as image description fields. This should cover all multi-language fields. Download the .zip from dev and replace the entire folder (not copy/merge) in your modules directory. https://github.com/SkyLundy/Fluency/tree/development

Thanks @ryan The subtle nuance of "text-wrap: pretty" is that you won't see it. It stops block elements having an orphan word on its own line at the end of eg a paragraph - jarring if it happens but smooth reading when it doesn't regardless of screen size. Still really need to see the font-size addressed. It's making my eyes bleed on my wide screen with font-size: 14vw 🙏

To clarify and gently push back on this, prefers-reduced-motion isn't just for people who may have a preference for no animation. Personally I'm fine with animations. It's an accessibility feature that allows people who may be affected by animations (e.g. vestibular disorders) to send a signal to websites from their OS or browser. It's good practice to check for that and respect it, when possible, especially if they're non-critical animations.

@ryan - the demo site (still linked from the new site) is still showing that .htaccess needs updating error (has been for a very long time) and running an old version of PW and the old theme. All fields and templates need to either have an icon or no icon - it looks messy with the alignment in those dropdowns when there is a mix. Maybe minor, but these details are what makes a project look professional or sloppy.

Is there any way to adjust the font size to personal preferences? I'm finding headings way too big on my screen resulting in unnecessary scrolling to read anything. The animated heading at the top bring back not particularly fond memories of the <blink></blink> tag. I suspect it may be mobile first, but if I'm accessing the site it's for documentation, and I'm not going to do that on a phone. One of the things I've loved about ProcessWire is it's fairly well documented, but if I have to do extra scrolling every time I want to reference docs because everything is so much bigger, that's not helpful. I realise other people may like the new design, and I don't want to impose my preferences on others, but honestly I can't say I'm comfortable with the new presentation. Sorry, I know lots of work has gone into this. It's why I'm asking, following the ProcessWire philosophy of allowing total flexibility, whether actual site visitors themselves can have some option to select default font sizing, so those who like it big can keep it that way, but those who'd like it smaller can have something more to their liking.

No, it does prevent a bunch of downstream hooks from firing, but specifically it doesn't include Pages::save and Pages::saveField (and I think it should include those methods). And to avoid confusion it would be good if the documentation explained exactly which hookable methods are affected by the noHooks option when it used in any of Page:save(), Pages::save() and Pages::saveField(). I've opened a GitHub issue so that Ryan is more likely to notice the problem and our discussion of it: https://github.com/processwire/processwire-issues/issues/1405

I guess this is a bit of a chicken and egg problem. The admin in processwire is hardly anything special based on what the core knows about it. It's a bunch of pages, which just happens to be tightly access controlled and forwarding their handling to process modules instead of rendering templates. So before knowing the page you're on there's not really a good way to know if the request is going to serve an "admin page" or not. To query the current page a lot of things already need to be started, and I guess you want to hook into those before any pages are queried, at best by already knowing the context, which is not going to work. A good example is the function you've shown in your initial post. It's a good heuristic for determining if the user is in the admin, but also not bullet prove, as there can be normal pages as children of $this->config->adminRootPageID as well. It might rarely happen, but it's possible. The only way to be sure is actually having $page queried.

@poljpocket so you think the current solution for "empty trash" where after clicking it the user gets no feedback at all about what is going on and about the progress is a good user experience? And then if the chunk was not enough you have to click again and again until the trash is empty... And the solution for that is to install the Sse module from baumrock's github profile?