Leaderboard

Hi @Ivan Gretsky and @FireWire, Sorry it took me so much time to respond to the big Fluency update. To be honest, I already refactored my module a couple of months ago to work without any dependencies (except the DeepL API), so Fluency is no longer necessary to use it. Since I only did this refactor for one client, I need to remove some customizations before I can push the new version to Github. I don’t expect this to take too long, so I’m hopeful that I’ll be able to release Version 1.0 for you to test tomorrow or thursday 😊. Thanks for your patience!

Assuming that the field would be changed in Page Edit rather than as result of some other API code, you can validate the user input in a hook to InputfieldText::processInput. Example: $wire->addHookBefore('InputfieldText::processInput', function(HookEvent $event) { $inputfield = $event->object; $input = $event->arguments(0); $field = $inputfield->hasField; $page = $inputfield->hasPage; // For a particular field name and template name if($field && $field->name === 'text_1' && $page && $page->template == 'events') { $old_value = $page->getUnformatted('text_1'); // Return early if the old value is empty if(!$old_value) return; $new_value = $input[$inputfield->name]; // If the first three characters have changed if(substr($new_value, 0, 3) !== substr($old_value, 0, 3)) { // Show an error message $inputfield->error('You are not allowed to change the first three characters of the "Text 1" field.'); // Replace the hooked method so the new value won't be saved to the field $event->replace = true; } } });

Thanks for all the feedback on the new admin design last week. Based on the amount of feedback and requests we’ve received, it sounds like there’s a lot of interest and enthusiasm in the new design, which is fantastic. I’ve been making note of all the suggestions and will talk through them with Diogo and Jan at KONKAT Studio next week. There have been several good ideas mentioned. I was able to implement a couple of them already, including separately configurable light/dark mode main colors, and inline embedding of custom SVG logos (so the color can be styled). Personally I’m loving the new dark mode and have been spending most of my time in it. But I’m really digging the new light mode too, so I suspect I’ll settle into the “auto”, getting the best of both worlds according to the time and/or daylight. If you’ve not yet upgraded to ProcessWire 3.0.248 you are in for a treat when you do. Like anything new and on the dev branch, there may be some things yet to add and fix, but even in this initial release, I think you’ll find the new admin design to already be a beautiful and refreshing upgrade. At least that has been my experience. Thanks again to @diogo and @jploch for their great work with this. Have a great weekend!

This week ProcessWire has an awesome new admin design thanks to the work of @diogo and @jploch of KONKAT Studio. You can get it now on ProcessWire’s dev branch! Read the latest blog post for details, screenshots, Q&A with the designers, and more: https://processwire.com/blog/posts/new-processwire-admin-redesign/

--- Module Directory: https://modules.processwire.com/modules/privacy-wire/ Github: https://github.com/blaueQuelle/privacywire/ Packagist:https://packagist.org/packages/blauequelle/privacywire Module Class Name: PrivacyWire Changelog: https://github.com/blaueQuelle/privacywire/blob/master/Changelog.md --- This module is (yet another) way for implementing a cookie management solution. Of course there are several other possibilities: - https://processwire.com/talk/topic/22920-klaro-cookie-consent-manager/ - https://github.com/webmanufaktur/CookieManagementBanner - https://github.com/johannesdachsel/cookiemonster - https://www.oiljs.org/ - ... and so on ... In this module you can configure which kind of cookie categories you want to manage: You can also enable the support for respecting the Do-Not-Track (DNT) header to don't annoy users, who already decided for all their browsing experience. Currently there are four possible cookie groups: - Necessary (always enabled) - Functional - Statistics - Marketing - External Media All groups can be renamed, so feel free to use other cookie group names. I just haven't found a way to implement a "repeater like" field as configurable module field ... When you want to load specific scripts ( like Google Analytics, Google Maps, ...) only after the user's content to this specific category of cookies, just use the following script syntax: <script type="text/plain" data-type="text/javascript" data-category="statistics" data-src="/path/to/your/statistic/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing" data-src="/path/to/your/mareketing/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="/path/to/your/external-media/script.js"></script> <script type="text/plain" data-type="text/javascript" data-category="marketing">console.log("Inline scripts are also working!");</script> The data-attributes (data-type and data-category) are required to get recognized by PrivacyWire. the data-attributes are giving hints, how the script shall be loaded, if the data-category is within the cookie consents of the user. These scripts are loaded asynchronously after the user made the decision. If you want to give the users the possibility to change their consent, you can use the following Textformatter: [[privacywire-choose-cookies]] It's planned to add also other Textformatters to opt-out of specific cookie groups or delete the whole consent cookie. You can also add a custom link to output the banner again with a link / button with following class: <a href="#" class="privacywire-show-options">Show Cookie Options</a> <button class="privacywire-show-options">Show Cookie Options</button> I would love to hear your feedback ? CHANGELOG You can find the always up-to-date changelog file here.

As promised some feedback. The easiest thing I came up with was a saveReady Hook, where I fetched the previous page state from the database and compared the fields needed with the actual values. However the code became a bit messy, as I have two templates one with three input fields one with two, ending in a gigantic switch block hard to maintain. What worked too, was the proposal from Robin S. However fetching the actual values from Inputfields of various types (text, datetime, select array, page select) needs some custom tweaks here and there to get the field values. Things can get tricky very fast, when using multiple hooks, which interfere with each other. Here it‘s key to understand what hooks fire first etc. At the end, I managed what I had in mind, but it indeed was a long way with lots of trial and error, reading the tutorial over and over again and inspecting the inputfield classes and with quite a lot of life debugging using Tracy. Without Tracy and the ideas and snippets found in the forum, I wouldn‘t be able to solve what I had in mind. So yes, managing hooks is still on my todo list, even after one year using ProcessWire for two part time projects.

@nbcommunication Hello! It's me once again. After excessive testing I found out that the modules webp quality settings were never applied to generated webp iages when outputting the srcset like this: <img srcset="<?php echo $image->size($imgFormat)->srcset ?>" ... The webp versions that were created always used a quality setting of 90%, no matter what I entered as value in the module settings. The solution: I had to place this line in my config.php to kind of "override" the default webOptions of ProcessWire: $config->webpOptions = array(); By the way the default options are set to this: 'quality' => 90 'useSrcExt' => false 'useSrcUrlOnSize' => true 'useSrcUrlOnFail' => true Only then (when the 'quality' option is missing) the entered value from the module settings is applied correctly. I did not test this with the $image->render method, though. Can you confirm if this is the intended behaviour?

@bernhard that was it, thanks a lot!

Maybe it's a caching issue. The navbar in the backend has unfortunately very aggressive caching built in, so you need to either log out and log back in or you use tracydebugger:

Interesting topic! I don’t know guys how you acquired this mastering of PW hook. I’d be struggling like @cwsoft 😅. It would be very useful to have some deeper documentation / tutorial about using hooks in PW.

@bernhard @Robin S: Thank you very much for your code suggestions. Looks very promising. Will try both tomorrow and then report back. Giving an additional hint/warning directly to the corresponding inputfield like robin suggested seems a good idea in terms of usability. The idea of a temporary field is also a need trick. Tried with saveReady before, which seems to work, but felt a bit hacky to me, as I needed to fetch the uncached old value to check for potential changes in the text field. Always good to learn something new. Your answers are highly appreciated. Made my day.

You can use the "fields-" key instead of "fields" and then it will even remove that field from your template without writing another migration. They are extremely cool 🙂 And can be used alongside or alone. However anyone wants.

I think the changed hook is not meant to revert any changes but only to listen to changes and trigger actions. But you can do this (not sure this is the best solution) - example using the title field in /site/ready.php: wire()->addHookAfter('Page::changed(title)', function (HookEvent $event) { $old = $event->arguments(1); $new = $event->arguments(2); $oldStart = substr($old, 0, 3); $newStart = substr($new, 0, 3); if ($oldStart === $newStart) return; // save old value to a temporary property that will be used // in the saveReady hook to revert to the old value $page = $event->object; $page->revertTitle = $old; }); wire()->addHookAfter('Pages::saveReady', function (HookEvent $event) { $page = $event->arguments(0); if ($page->revertTitle) $page->title = $page->revertTitle; });

@Ivan Gretsky I'm stuck under a lot of work and deadlines. If you are able to test and provide any info that would help me debug that would make a fix much easier on my part. See if there are any logs generated, dev tools console errors, or share any exceptions you're receiving when attempting to translate. Is your issue related to the potential namespace issue that is noted under the comments of the PR? I missed the Github notifications on that so I'm just becoming aware of it now.

I'm clearly in a minority but I personally feel like the redesign is not very attractive.... To me, completely flat single colour panels with single relatively high contrast borders does not look clean and I don't enjoy the use of a mid grey as a base colour for light mode at all. The new font looks bold and blocky to me and again too intense in its contrast. I'm sorry to say this because I can tell a lot of work has gone into it, but I personally hope the Uikit theme doesn't go anywhere, if I put them side by side the Uikit one looks like the more modern and finished one to me. Also to add to the bug reports I'm getting white text on a white input when filling out the db details on a fresh install of the new dev version (dark mode/Chrome/Windows) which made installation quite difficult

hi, having a look at the console, you'll see a missing image https://silcar.ro/site/assets/files/3713/sediu_silcar.1846x0-is-pid1143.jpg maybe the blank one...? the name of the image may let think it's a variation generated by a module or an image resized on the front side using php or js, can you see the original image in the page admin? apart from this (and all the things blocked by ublkock), i can see a problem with a base64 request that doesn't seem to be well formatted, and thus having a CORS issue in case it helps have a nice day

Hey, it seems to me that there is a wrong thinking or understanding to the whole subject that leads to the confusion. (?) If your comparison are between the compressed image from a third party tool, e.g. photoshop or others, and ONLY the webP output from GD or imagick, then this is comparing apples with bananas. If that's the fact, please read on. If that's not true, please excuse my post and my misunderstanding and forget / don't read the rest of the post. ? EDIT: maybe of additional interest:

I suggest you try the simple thing first: Replace <a><?php echo __("Ver detalle"); ?></a> by <a><?php echo \ProcessWire\__("Ver detalle"); ?></a> Let me know if that works - then I know we have the same namesapce issue as I have already reported

Update - Version 0.0.6 Minor CSS-Debugging (hiding the choose button when no cookie group is selected) Added ProCache support for the script tag, when ProCache is installed

I today integrated the multi-language support for all the config fields.