Recently Updated Topics

For modules that are not premium/pro modules, I'd love to see if their inclusion in core would be of benefit to the greater community. Many of, for instance, Robin S.'s modules aim to make the interface experience better for the end-user. Even if the code may not be 100% compliant to what the core expects, the very idea of the module may prove useful in improving the total user experience without the need to discover it elsewhere. Some extremely popular modules (ex: Tracy Debugger) may not be directly suited to being added to the core, so thought should be taken over its usefulness to all, not just specific circumstances or groups of people. Alternatively, is there a preferred way to request addition to core via the Feature Requests Github repository?

Thank you @Juergen for the fixes. Sorry not to reply before but I have few free time. ^^ I found more issues: File upload is limited to 500 MB: $zipUpload->setRule('allowedFileSize', '524288000'); But I can add a file larger, the form is valid and the upload starts, but then the server is not happy: With module FrontendLoginRegister, in Account Settings I add Language field. I have 2 languages, french and english, french is default. The form displays the 2 languages only if user is actually using french, when using english, only english is listed in the Select field. If user selects english and save, it works. If user selects french it is not saved. I try to investigate the code quickly, only to find that in Select::___renderSelect(), when user is using english, $option->render() returns an empty string for french.

I've been going crazy for three days trying to figure out how to modify this .htaccess file so that it's acceptable to the server. I took the one generated with the site-blank installation with softeiaculos and transferred it to a site-regular installation. But even then, the site is still not navigable. On permacultura-cattolica.it, you'll see that only the homepage is navigable, not the other pages. For the love of God, isn't there an explanation and solution for this problem in the manual and on the ProcessWire website?

I haven't tried the template caching quite yet but it's on my 'discovery' to-do list for sure!

Thank you so much, you saved my day.

Yep, I confirm this still works today. However, the website in question is still using an earlier version of ProCache. 😄

I completely agree — keeping CSS variables semantically meaningful and scoped at the right level makes a big difference for long-term maintainability. Using names like --muted-color or --masthead-active-color outside their intended context can lead to confusion down the line, especially as the project grows. Your idea of compiling a starting list of variables with clear usage definitions is an excellent step. It’ll help ensure we separate “color intent” (like --text-muted or --background-accent) from “specific context” (like --masthead-bg). Once that foundation is consistent at the root level, we can easily extend or override in components without breaking semantic meaning. Count me in if you start that list — a collaborative approach could really make the design system more scalable and self-documenting.

This is great! The filter feature alone is so good! Will save a lot of time. Thank you very much for this fantastic module!

[Update] More flexible access mails (v 1.0.11) Just pushed a small update to the module — a few quality-of-life improvements for access mails. What’s new Custom intro text for access mails – There’s a new field called Access Mail Intro Text (optional) access_mail_addon_txt added to your product templates. Whatever you put in there gets prepended to the access mail’s lead text — great for short intros, personal notes, or product-specific instructions. Hookable mail variables – PLMailService adds the hookable method ___alterAccessMailVars($vars, $mod, $user, $links) You can now easily tweak mail content in your ready.php, for example "first purchase vs. repeat purchase": wire()->addHookAfter('PLMailService::alterAccessMailVars', function(\ProcessWire\HookEvent $event) { $vars = (array) $event->arguments(0); $user = $event->arguments(2); // check if this is the user's first purchase $purchaseCount = ($user->hasField('spl_purchases') && $user->spl_purchases) ? $user->spl_purchases->count() : 0; $isFirstPurchase = ($purchaseCount <= 1); if ($isFirstPurchase) { $vars['preheader'] = 'Welcome! Your new access is ready.'; } else { $vars['preheader'] = 'New access added to your account.'; } // Hand back the modified variables $event->return = $vars; }); As always, feedback, ideas, and real-world use cases are more than welcome — especially if you’ve built custom hooks for your own onboarding or mail flows. Cheers, Mike

v1.0.2 Bugfix: Fix deprecation warnings in PHP 8.2 (contributed by esszett in #2) Note that the module now extends the WireData class instead of Wire. This is recommended for modules now and shouldn't cause problems, and it gets rid of any warnings because of undeclared property access. If this is causing any unintended side effects, let me know.

With anything new that gets designed (a website, operating system, interface), there's always that initial cringe feeling because it's no longer familiar and comfortable, but after a couple weeks, that goes away. I'm developing a new site and using the new Konkat admin theme, which at first felt totally wrong, but now it feels just right (with 1-2 CSS tweaks, like to make repeaters jump out more). My brain is very picky about adjusting to new fonts... Inter in this case. I like the font a lot, but I just need to adjust to it, get used to the curves. Same thing with new versions of Windows when they change the default font. It's kind of like when Facebook went through a few major design changes at during the 5-10 mark and everyone would complain, then everyone got used to it. Anyway, great work. It's grown on me.

Wow, that was quick. Thanks. Will wait until it goes into main and then update through module interface.

In the “Core” tabs of the “Modules” page, look for the “IMagick Image Sizer” module and check if it’s installed. Is so, try uninstalling it and see if it solves your issue.

Only 4 years later I found the cause for this. It’s an Apache behaviour: Some Apache configurations are just fine with spaces in URL paths. Some force a 404 status code, no matter what you try to do in your PHP. Might have something to do with ModSecurity module, but I’m not sure. Better be safe: If you can avoid spaces or %20 in URLs, do it!

Many thanks @jploch that really helps to start and to find some more orientation how and with what in Page Grid. I have to to dive in...

I just switched to UiKit version 3.24.1 (thanks to RockFrontend to make this easy), and I can reproduce this with the latest version of the Less module... The same errors