Leaderboard

This week we've ProcessWire 3.0.267 on the dev branch, here are some highlights (commits): The entire WireTests module has been moved into the core. All of the tests now live alongside the classes that they test. The WireTests module is used from the command line. Once installed, you can type "php index.php test" for a list of WireTest commands. If you already have the non-core WireTests module installed, I recommend uninstalling it and installing the core version. More than a dozen new WireTests and API.md documentation files have been added this week (this is where the biggest additions of the week are). Many improvements to the CLI "docs" command, especially with regard to chapter retrieval. New faster $modules->refresh() method from @matjazp New HOWTO-API.md documentation that outlines how to write API.md files for your own modules. New getFresh() and getRaw() methods added to $fields and $templates. These do the same as their $pages method equivalents (getFresh and getRaw), except for fields and templates. This was requested by an agent in AgentTools. This week we also have a new guest blog post! Page's best kept secret: the meta() method Thanks for reading and have a great weekend!

Hi @Robin S - sorry for delay in responding, but thanks for the follow up. I haven't used that module regularly in so long. Anyway, glad you figured out an approach that works for you. Cheers.

Hey @jploch Thanks for jumping in and providing your design thinking. All solid reasons.

@Peter Knight The darker color is intentional, there are two reasons why we (Diogo and me) decided for the darker grey: Contrast: Bringing more focus to the white areas even on screens that have bad contrast/color settings. This is especially helpful when input fields are offset from one another; it makes it easier to distinguish between the fields. It also helps to seperate the navigation and content area. The white hover on the page tree is also benefiting from the darker grey. Also like @BrendonKoz says it helps to seperate the inputs from the background. While the borders already enforce this contrast, I feel like the combination of border and background is what makes it stand out more. When putting screenshots from the admin on the PW website we want them to have a different background color so the image stands out better. This is why we choose a lighter background color for the website. While the image usually has a border, the background still improves the contrast, so the two don’t blend together as much. All in all, a lighter color would work too, and I certainly understand that some people might find the grey a bit too “grey.” However, I think the darker grey is a more functional default.

I've heard a few other similar stories, eg

Update (1.1.1) – image downloads and UI improvements Hi all, A couple of releases on from the grid-view update, with a proper new feature this time. @adrian asked for a way to pull images back out of the library, so downloads are in: every thumbnail now has a download button that hands you the original file, not the table thumbnail. Tick a few images first and instead of separate downloads it bundles the whole selection into a single ZIP. It uses the same selection you already use for bulk edits, so it stays consistent with the rest of the module. A few things around it got nicer too. The small per-thumbnail actions (replace, delete, download, select) now use a custom tooltip instead of the browser's native one, and on a multi-selection they tell you what the action will actually do, e.g. "Download 8 selected as ZIP". And replacing a file in place finally gives proper feedback right on the row, success or error, instead of failing quietly. One under-the-hood change worth a mention: the module no longer loads on anonymous front-end requests. There was no reason for it to run on a normal public page view, so now it doesn't, and a guest hit carries zero overhead. Admin, logged-in editors and front-end inline editing all behave exactly as before, and the hourly de-duplication / where-used maintenance still runs. (thanks @adrian for the nudge on that one too) Feedback and bug reports welcome, Cheers, Mike

Hi everyone, Accessibility overlays have a bad reputation — mostly because they're sold as SaaS, phone home to third-party servers, and charge monthly fees for something that should be built-in. Ally is different: self-hosted, MIT, no external requests at runtime. GitHub: https://github.com/mxmsmnv/Ally What it does Adds an accessibility panel to your site's frontend, powered by Sienna (MIT). The JS bundle and OpenDyslexic font ship with the module and are served from your own server — nothing loads from external CDNs at runtime. Font size adjustment Dark, light, and high contrast modes High/low saturation, monochrome Dyslexia-friendly font (OpenDyslexic, bundled locally) Highlight links and headings Letter spacing, line height, bold text Reading guide, stop animations, big cursor 53 languages with auto-detection from html[lang] or browser settings Full ProcessWire multi-language support — maps $user->language to the correct locale automatically Configurable position, offset, button size, and accent color Skips admin pages and Chrome Lighthouse by default No build step — prebuilt JS bundle included. One caveat: the widget is injected via Page::render hook. If you serve pages through ProCache static HTML, the hook doesn't run on cached pages — exclude those pages from ProCache if you need the widget there. Overlay widgets supplement, but do not replace, accessible markup. Use Ally alongside good semantic HTML, not instead of it. Requirements: ProcessWire 3.0.200+, PHP 8.1+ MIT License.