Leaderboard

Field Access A Process module that provides an overview of field access settings, including template overrides. Usage The table has a sticky header so that the columns can be understood when the table is scrolled. The empty space underneath the table is to allow scrolling to the bottom of the table. There are fields for filtering the table by field name or by template name. The field names link to the Access tab of the field settings, and the template names link to edit the access settings for the field in the context of that template. A collapsed field at the top of the page has information about the meaning of the table column headers, and tips for understanding the values in the table: Table column headers Control: Is access control enabled for this field? View: Roles that can view the field Edit: Roles that can edit the field Show: Show field in page editor if viewable but not editable (user can see but not change) API: Make field value accessible from API even if not viewable Overrides: Overrides of the field access settings in template context Tips If the guest role has view access then it means that all roles have view access. You can hover the guest role in the View column to see a tooltip with all the role names if you want a reminder of those. Overrides: when access control is enabled as a template override, the Control, View, Edit, Show and API columns only display settings that are different from the field access settings. If a column is empty it means the field access setting applies. https://github.com/Toutouwai/ProcessFieldAccess https://processwire.com/modules/process-field-access/

AIOM is alive 🙃 I am pleased to announce that the AIOM module will be further developed and supported by @matjazp. My original repository is now archived, and matjazp's fork is now the official one. The forked version is now also listed in the Processwire module directory. This should make it possible for everyone to update the old version to the new one, either manually or via the ProcessWire upgrade module.

This week on the core dev branch there are several new hookable methods added to the Page class. While many of them may be redundant with hooks already available on the Pages class, those on the Page class are more convenient to use in some cases, especially when it comes to using custom Page classes. It's helpful because you can hook CustomPageClass::method rather than Page::method to more easily target specific types of pages. Or you can override the methods in a custom page class, without having to hook them at all. I'll get into this with more details and examples in a future blog post that goes in-depth on using custom page classes. Here's a summary of the methods that were added with links to their API reference documentation pages: Page::addReady() Page::added() Page::addStatusReady() Page::addedStatus() Page::removeStatusReady() Page::removedStatus() Page::cloneReady() Page::cloned() Page::deleteReady() Page::deleted() Page::editReady() Page::moveReady() Page::moved() Page::renameReady() Page::renamed() Page::saveReady() Page::saved() Page::renderPage() The above is just for this week, but there's quite a bit more in 3.0.253 relative to 3.0.252, so be sure to check the last issues from ProcessWire Weekly for more details.

Text Readability A module that uses the PHP Text Statistics class to evaluate the readability of English text in textarea fields according to various tests. The available readability tests are: Flesch Kincaid Reading Ease Flesch Kincaid Grade Level Gunning Fog Index SMOG Index Automated Reability Index Spache Readability Score Dale Chall Readability Score Coleman Liau Index The results of the enabled tests are displayed at the bottom of textarea fields – either when the "book" header icon is clicked, or at all times, depending on the option selected in the module configuration. An interpretive tooltip appears when you hover any of the result values. Requires ProcessWire >= 3.0.246 and PHP >= 7.2.0 Why is readability important? Readable.com says: And: The Wikipedia article on readability has useful information too. Module configuration Select which readability tests you want to enable. For each test there is an "about" link to information about the test. Select whether the results of the enabled readability tests should be shown only when the header action icon is clicked (default), or if the results should always be shown. For multi-language sites, select which ProcessWire language represents English (as the tests are only intended for English text). Advanced If you want to disable the readability test results for a particular textarea field you can hook TextReadability::allowReadabilityResults. Example: $wire->addHookAfter('TextReadability::allowReadabilityResults', function(HookEvent $event) { $field = $event->arguments(0); $page = $event->arguments(1); // Disable readability results for the "body" field on the "home" page if($field->name === 'body' && $page->template == 'home') $event->return = false; }); https://github.com/Toutouwai/TextReadability https://processwire.com/modules/text-readability/

Fix confirmed. Thank you!

@Jonathan Lahijani, I've released a new module that provides an overview of field access settings:

Thanks for reporting this @BrendonKoz. It should be fixed in v0.1.4

I quite agree with your two points above. "Section for practical code examples." They could be added to the method descriptions, and not just sample code strictly related to a given method, but code showcasing typical scenarios with related methods and often used techniques, "coding patterns". "Currently a lot of core features are very fragmented and hard to find if you don't know they exist in the first place." So true! I have some notes of some important settings, which I often set up differently from the defaults, but having to look through them just to find something is time consuming. Some sort of clever way of gathering information and providing it in a categorized and digested way would help, I think.

The following is written in somewhat hurry, but I'm sure most of you get what I mean. What Processwire really needs is: Section for practical code examples. Searching through the forum gets tiresome and sometimes it can take hours to find what you're looking for. The API is good, but sometimes very opaque if you don't already posses good deal of knowledge about it. Admin needs some kind of "settings" page that puts things like "password strength" in one easy to reach place. Basically everything the core modules do, should be here. Then if you want to edit something, it will point you to the right module. Currently a lot of core features are very fragmented and hard to find if you don't know they exist in the first place. I think them being in the modules is great, but one page that gathers all that information is easy to digest form would make it better.

AgeWire is a powerful, fully customizable age verification module for ProcessWire, built with modern web standards and powered by Tailwind CSS. Perfect for sites requiring age gates (alcohol, tobacco, adult content, etc.). Key Features Two Verification Modes: Simple Yes/No buttons Date Picker with separate MM/DD/YYYY inputs (bot-resistant) 13 Stunning Themes: Modern, Dark, Classic, Minimal, Gradient, Neon, Elegant, Corporate, Vibrant, Nature, Sunset, Ocean, Purple 4 Smooth Animations: Fade In, Slide Up, Zoom In, Bounce In International Date Formats: MM/DD/YYYY (US) DD/MM/YYYY (EU) YYYY/MM/DD (ISO) Advanced Security: Secure, HttpOnly, SameSite cookies Configurable lifetime (1 day to 6 months) Bot protection via manual date entry Smart Exclusions: Skip verification on specific templates or pages Admin pages auto-excluded Privacy & Compliance: Optional Terms & Privacy Policy checkbox Custom links to your legal pages Fully Responsive – Mobile-first design Custom CSS support Tailwind CDN integration (no build required) Installation Download from GitHub Place AgeWire folder in /site/modules/ Go to Modules > Refresh Install AgeWire GitHub: https://github.com/mxmsmnv/AgeWire Download: https://github.com/mxmsmnv/AgeWire/archive/refs/tags/v1.0.9.zip Perfect for: Wineries & breweries Vape & tobacco shops Adult content sites Age-restricted events Feedback, bug reports, and pull requests are welcome! If you like AgeWire, please ⭐ star it on GitHub! Made with ❤️ for the ProcessWire community.

Always wanted those on Page. Even before custom classes existed. Great addition! I think that custom classes truly need more introduction and use cases. So eagerly waiting for Ryan's upcoming blog post.

That will definitely be welcome, for sure! Thanks in advance.

Hi everyone! I've started working on a new module that contains development tools like asset minification. Why a new module when RockFrontend and RockMigrations already have similar features? I wanted to start fresh to make the code cleaner, and most importantly make it work properly with template cache! The old implementation in RockFrontend using page render hooks simply couldn't handle that. The module is intended for development-only and should be disabled on production. The idea is to create minified assets while developing and then push the minified assets to production and there just include them in your markup! LiveReload has also been moved from RockFrontend to this module. It's simply not a frontend-tool but rather a development tool! Using RockMigrations, for example, I'm always using the LiveReload feature on the backend, so it does not really make sense to have it in the frontend module 🙂 Download & Docs: baumrock.com/RockDevTools