Leaderboard

On the dev branch this week we have a good collection of issue fixes and feature requests. The dev branch commit log has all the details. One feature added this week which I think could come in very handy is #520 (via @Jonathan Lahijani) which adds the ability to hide individual images in an images field. When an image is hidden, you can see and work with it in the admin, but it gets removed from the field value on the front-end of the site at runtime, effectively hiding it. I know I'll use this a lot, particularly on photo galleries where I may want to remove an image or two from appearing in the grid of photos, but don't necessarily want to delete them. Images can be hidden (or unhidden) from the Actions select of each image, where you'll see a "Hide" option (or an "Unhide" option if the image is already hidden). Hidden images are also dimmed out when viewing the images field in the admin. On the API side, you can hide or unhide images and files using $image->hidden(true) to hide, $image->hidden(false) to unhide, and $image->hidden() to get a true or false as to whether or not the image is hidden. Though this will only be useful on unformatted field values, since hidden images are automatically removed from formatted field values. The same can be used with regular file fields, but we don't currently have a UI/interface for hiding or unhiding items from regular (non-image) file fields. Likely we'll add one soon, but I figured it's likely to get more use with image fields than file fields, so figured we'd start there. More next week. Thanks for reading and have a great weekend!

Obviously you should try and educate your client into the advantages of building in PW (and in the difficulties of designing a pixel perfect site that works across all browser and devices) but if they really insist on being able to fiddle then WebFlow is probably the kind of thing they want. Not a PW solution, but it does work well once you get the hang of it. We lost a client of 20 years to it last year ?

Thank you @Stefanowitsch for mentioning RockPageBuilder! However, it appears that what they need might differ from what RockPageBuilder offers. @FireWire eloquently highlighted this distinction recently: So, RockPageBuilder is more about helping developers to build content elements quickly and easily. These blocks enable clients to populate their websites with content seamlessly, without the need to think too much about the technical and visual aspects (because this is our job as web professionals). It's less about designing and more about managing content, which is something I love about ProcessWire and where it really shines. In RockPageBuilder the design is done in code - CSS, Less, Tailwind, UIkit, Bootstrap. You can choose whatever you like best. If you want a no-code page designer there are plenty of options out there, but RockPageBuilder is likely not your first choice ?

I use three. Central one 24”, sides 17”. I find that much better than one big one. Typically, the central one for code, one side for displaying the output and the other side for reference. Probably cheaper than one big one as well.

I eventually tracked down the issue, it related to a historical version of proDrafts. Once draft was unticked front-end editing worked ?.

@fruid Use custom page classes. In site/classes: <?php namespace ProcessWire; class UserPage extends User { public function getMessages(): PageArray { return wire()->pages->find('template=message, receiver=' . $this->id); } } Be sure to enable it in site/config.php: $config->usePageClasses = true;

There are some videos on YouTube about that aka "TV as PC monitor". Like this one: There are a few things: from input lag, connections, colors, to refresh-rate and even things I didn't even know existed. I don't know if the video above answers all your questions but maybe it gives some more insights - I remember LLT (Linus) made a similar video a while back, but coulnd't find it.