Leaderboard

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/

This module is a remake of Ryan's classic Comments module, but uses its own code and is based on the FrontendForms module. This is the third module in the "Frontend" series, alongside the FrontendContact and FrontendLoginRegister modules. To use this module, FrontendForms must be installed. Otherwise, it won't work! If you don't have this module installed yet, please download and install it first! This module has a large amount of configuration settings supports pagination supports UiKit3, Boostrap 5 and Pico 2 CSS frameworks out of the box and a lot more The download link as well as many more images and the documentation for this module can be found on Github. Please note: This is the first version in an early alpha stage, so using it on live sites is not recommended. This module should be available in the module directory eventually, but it still needs a lot of testing. If you discover any issues or have ideas for improving the module, please post them here in the forum or directly on Github. Happy testing!

There is a free online event on ::: June 17, 2025 ::: 13:30–18:30 CET/CEST ::: 07:30–12:30 EST/EDT ::: 11:30–16:30 UTC https://lp.jetbrains.com/phpverse-2025/ @ryan what about taking part as a speaker on such events to make PW more popular?

@ryan I took some time to reflect and let the situation cool down. I'm very interested in keeping up a good relationship with you, which is why I want to address your last post rather than moving on and pretending nothing happened. I think this is neither what I said nor what I did. This statement has really bothered me a lot over the last days. I'm sorry if I made you feel that way. It was honestly not my intention and I apologise for that! I want to add that if you feel that the other person is behaving unfairly, it might be worth considering whether you've given them a fair chance to explain their perspective. I have read this thread again from the beginning, and I see many posts from my side that very much follow your suggested syntax for being taken seriously. However, I didn't feel that my concerns were being heard or addressed. I honestly think we both could have done better. I'm fine with that and I hope you are too! Otherwise please let me know and we can discuss this further.

Hello everyone, I would like to give you an overview of the recent changes and improvements that have been incorporated into the ProcessDataTables module since version 0.6.0. Maybe there is something interesting for you! As we are testing the brand new UIKit style the screenshots are made using that theme. From 0.6.0, the UI for import/export is now clearly structured, visually improved and much more user-friendly. The new pagination (from 0.6.2) ensures better performance and overview for large data records. The value for the rows per page for DataTables is defined in the config area. Before this version there was no native pagination, i.e. all data records were loaded at once - problematic with large amounts of data. Now the navigation is performant and user-friendly, large tables are divided into pages.

@adrian This is something that’s already been there for awhile. From the API side, this is the $inputfield->themeOffset setting, which can be 0, 1, 2, 3, and 0 is the default. From the admin field configuration side, this is found when editing a field under the “Input” tab and “Visibility > Admin theme settings (uikit) > Margin”. These settings are available in all AdminThemeUikit theme variations. Let me know if this is what you were looking for, or if you were thinking of something else? Makes sense to me. Ah okay, I see it now. Adding to our list of updates. @bernhard This is what I was hoping to get more of, rather than saying the theme is fundamentally wrong (unless that's what you actually think). This is a friendly forum conversation from my viewpoint and there are no negative feelings. I just wanted you to know how the statement can be interpreted, because I suspected that’s not really what you meant, as it would seem to undermine your other helpful suggestions. Diogo and Jan have put a lot of work into this (and done a great job in my opinion), but this is also a work in progress, so we need to be fair and patient. If your goal is to suggest that something should be implemented differently, the more specific you can be, the better. But if you really do think that the theme is fundamentally wrong, then that’s also a valid opinion, and your opinions are always welcome. I’m just not sure how to translate that opinion into an item for our list of updates and requests, so I don't find it helpful from that perspective. But since you've been adding issue reports on GitHub, that's definitely helpful, as are many of your other posts here, so please continue, and thank you for doing that.

The send() method in WireMailSMTP is hookable, so depending on how your service's Oauth2 requirement works you might be able to create some sort of supplemental solution.

Thanks Bernhard. I will try it and let you know. It looks interesting, because I need exactly to specify on page I do not want header and footer - so that class "noheader" would be suitable.

Hi @FlorianA Looks like there is some endless loop issue in your php that consume all the memory you allocate to PHP. The first thing I would do is enable PorcessWire debug mode. You can edit your site config.php to enable it by adding this line $config->debug = true You will have more info about what is going wrong.

I'm currently looking at Grav/Kirby/Statamic etc. for certain simple sites where MySql doesn't make sense, but I'd much rather use PW with SQLite.

As our interface test module evolves, more minor bugs pop up. Here we have the toggles: I think there is supposed to be a separator between the two options? Interestingly when 3 options are defined there is a separator between the first two options:

This should be a fairly easy fix. Thanks for reporting it!

One of our test users of the new admin style informed us that there is a minor visual bug on the "close" button of the slide-in pagetree. As I was able to reproduce it, here you can see the issue: Also present when hovering the "close" button

Have you looked at this module? https://processwire.com/modules/wire-mail-gmail/

@adrian I fully support adding whatever CSS vars Diogo and Jan want to add. But I’d hate to throw out the idea of using anything but root-level vars. They seem very powerful to me and a major benefit of using these CSS properties in the first place. I mention it just because my eyes are struggling with it in the screenshots and video above. Especially the white-on-green text. But if the company is used to that usage then I’m sure they’ll like seeing it in their admin either way. I'm not sure. I’ve not had that come up yet, so can’t really well speak to it. But I’m not opposed to it. While very customizable, this admin theme is also something that’s been designed. If “anything goes” and “anywhere” in terms of colors, it’s more of a blank canvas than a professionally designed theme. I don’t think this theme was intended as a blank canvas. So there have to be some constraints in place. Making some things customizable, where planned for by the designers, is great. But other things, like rethinking the foundation of a slightly off-white (or off-black) body background might be going too far, because it changes the whole balance of it. It appears to me the editing tools (Inputfields, etc.) are designed with the idea that they won’t share an identical background color as the body. So if you go pure-white or pure-black with the body background, I agree that it may be problematic. It may be that they can add more CSS vars, but it might also be that it goes outside the boundaries of how the design is supposed to work. But I’m not the designer, so I’m kind of speculating and might be wrong. Maybe so. But I will say that as someone new to CSS variables, it’s been refreshingly easy to change anything I need to with what we’ve already got. There hasn’t been any real fiddling, and the affected markup is not likely to ever change in terms of how it would be identified with CSS selectors. So I'm just trying to say that I think we're already in quite a good spot, being able to do stuff I hadn't thought possible before. But I'm not saying that we should stop there. There's always room for making things better and better, at least where the resources allow.

The latest additions/improvements of the module [v0.5.0]: Template file structure Stubs are now namespaced into subfolders per DataTable (column_templates/<table>/<slug>.column.php) instead of a flat directory. TemplateGenerator::getTemplateFilePath() and createTemplateFile() updated to build and create these subdirectories automatically. Legacy-stub upgrade loadColumnTemplates() now checks each stub for a return function(...) signature. If missing, it archives the old stub (prefixing its filename with _) before regenerating a new closure-based stub. Page-property handling Unified list of core properties driven by getStandardPropertyLabels() (including status). All Page-property stubs now use return …; inside closures and map bitmask flags (status) to human-readable labels. Lets look a little closer at the switch to closures for the column templates and an export/import feature. We planned this from the beginning and now switched over to a slightly different approach for the tiny template files used to display the data in your columns. The mechanism of those templates remains the same, but the performance gain is huge. Especially when dealing with lots of columns and rows: OLD: echo htmlspecialchars((string)$value); NEW: return function($value, $config = []) { return htmlspecialchars($value); }; Anyone who tried to create a DataTable gets column templates automatically created. They support the most common field types in ProcessWire and format the output initially in a simple but (hopefully) useful way. If you then tailor the output exactly to your needs, sometimes it would be handy to just save those micro templates for further use. Well, we are just developing export/import features for that purpose: Just export your global and dataTable settings as JSON and your column templates as ZIP and reuse it, manipulate them, share them 😉 and then use for migrating or easy duplication of tables. Here are some screenshots showing its (yet rather ugly) interface in action. We assume you want to port existing dataTables to another processWire site using the same data structure. Well start with a fresh install of the module We upload our exported JSON file, that contains data like this: { "moduleConfig": { "checkboxYesLabel": "Yes", "checkboxNoLabel": "No", ... }, "dataTables": [ { "name": "orders", "title": "Orders", "data_template": "rockcommerce_order", "data_selector": "", "columns": [ "rockcommerce_paymentid", "status=rockcommerce_paymentstatus", "rockcommerce_paymentdate", "order=meta", "rockcommerce_net", "total=rockcommerce_net" ... After importing we immiatly see the result of the import displayed as DataTable with, at the moment, default fieldtype templates as column templates: But at the bottom of each DataTable there is more: SO in the next step we import our prior fine-tuned column templates and immediately get a much better result: Under the hood the "old" default column templates that were created after importing the JSON config are not deleted, the get prefixed with an underscore in case you already made some adjustments before importing other column templates. Of course one can also manually copy column template files from one install to another but we found it more practical to let the module handle this. Especially when building new sites or testing, be aware that an uninstall of the module always wipes out the entire column_templates directory. So you better export before uninstalling! We are still working on the interface because it hurts my designer sensibilities to look at the UI of the import/export section. 😉 What do you think? What could be further improvements? Cheers to all of you and have a productive week!

So annoying when the web host updates the PHP version and you start getting a strange error in the logs. Google search revealed a [solved] answer in the PW forums that YOU posted 3yrs ago 🤦‍♀️ In case anyone else is getting the same error: class='TypeError', code='0', message='count(): Argument #1 ($value) must be of type Countable|array, string given', location='/wire/core/PagesLoader.php', line='972' Here's the solution: The line number may vary according to your PW version.

Making ProcessWire stronger for full-stack web application development, allowing it to become an unassuming alternative to Laravel and Rails but from the origins as a CMS. ProcessWire is the perfect CMS (there's no doubt in my mind about that), and it's actually already quite good for web application development (both natively and with 3rd party modules), but with some enhancements to make it more "batteries included", enhancing page classes and some tooling, ProcessWire can have its feet in both the CMS and full-stack framework buckets in a way that's perhaps unique. I can elaborate on this further as that sounds a little too generic, but I've been developing a web application with PW for over 9 months (it's a very complicated project and it's replacing an existing, in-production system which makes it even more tricky and high-stakes) and when it's done I can share some ideas. This one enhancement alone moved the needle quite a bit in making ProcessWire more web application friendly.