Leaderboard

@The G Your wish is my command ? I just added another config option for an alternative banner template file! In addition (to be even more flexible ? ) I included your idea of the hookable methods for banner template and js file. /** * checks for a alternate banner template path * @return string the path of the banner template file **/ public function ___getBannerTemplateFile() { return (!empty($this->alternate_banner_template) && file_exists($this->wire('config')->paths->root . $this->alternate_banner_template)) ? $this->wire('config')->paths->root . $this->alternate_banner_template : $this->wire('config')->paths->$this . 'PrivacyWireBanner.php'; } So now you have to decide whether you prefer to hook or configurate ? --> 0.3.3 <--

@ngrmm That actually was my first type of implementation (separating css and js), but as the CSS file would be very small (554 Byte), it actually is slower to load these two connections vs. loading only one JS file with the CSS included ( even with HTTP/2 - I tested it alot!). This is the total amount of styles used by PrivacyWire (beautified for better readability): .privacywire { position: fixed; bottom: -250%; left: 0; right: 0; box-shadow: 0 -1px 3px rgba(0, 0, 0, .3); opacity: 0; background: #fff; z-index: 1; padding: 1rem; transition: bottom .3s ease-in, opacity 1s ease-out } .privacywire .privacywire-header { font-weight: 700 } .show-banner .privacywire.privacywire-banner, .show-message .privacywire.privacywire-message, .show-options .privacywire.privacywire-options { bottom: 0; opacity: 1; transition: bottom .3s ease, opacity .3s ease } .privacywire button[hidden], [data-ask-consent-rendered="1"], div.privacywire-ask-consent-blueprint { display: none } You could do the following: 1. Uncheck the config checkbox "Add basic CSS Styling": 2. Add the styles to your own stylesheet.

I fixed these two topics in 0.3.2. @snck: There really was a bug with the "Accept all" Button - thanks for noticing! @ngrmm: You can choose now in the module config which header tag you want ? For keeping backwards compatibility, the default value still is <header>.

After 9 years using ProcessWire I still do multiple times a day a typo writing template as tempalte (probably write it wrong more often than right). I know few of my co-workers does the same. Is this curse for us Finnish people, or is tempalte thing in other parts of the world also?

No issue with "tempalte" but if if ever remember how to write "width" I'm sure I'll pokevolve into a 10x engineer haha.

@ngrmm I had a similar issue and went kind of a different route and added role="main" to my main header and excluded it later on in my PrivacyWire CSS. header:not([role=main]) { // here you go } For the moment that should work out quiet nice without any or at least only minor issues - at least when you are working with less, sass, SCSS and similar.

Gosh, I feel so spoiled now ?

@ngrmm thanks for your input. Semantically header tags are allowed to have multiple instances within one page (e.g. one main page header and one header per <article> etc.). But I see the point - within the cookie banner a <header> might not be the best semantical element to choose. To provide backwards compatibility (if someone has already styled the PrivacyWire <header> via CSS) I will add an option to configure the output tag between <header> and <div>.

Do you mind to tell more about the scope, things and features you need and maybe even hourly rates or budgets you planned to offer for those kinds of projects? What about your website URL/domain to check it up right away. Your phone number results in different results so far which might scare the good guys here. Just asking for others that might be interested.

@Robin S - now fixed, thanks!

Added namespace but sadly it doesn't change the result. [EDIT] I solved it by restoring a backup. Still kinda strange...

Oh, yes - I‘ll add a filter for the leading slash first thing tomorrow morning. Better than this error message ?

So, excited to use the updated version as I was, there was no time for RTFM - even if there was clearly written without leading slash , I merrily entered /site/templates/modules/PrivacyWire/PrivacyWireBanner.php and BANG!, ProcessWire shouted at me for wanting to use a not allowed path (because of the resulting double slash). I'm still trembling! Since it breaks so hard, I'm wondering if the input could be somehow forced to loose the leading slashes forgotten by irresponsible people like yours truly. Sadly, I'm not well versed (yet!) in module configuration input validation/modification. Or at least, write "without leading slash" in bold letters ?

Nice to see ProcessWire being used in the Netherlands. Too bad I live a two hour drive away from you guys (I'm from the south). Is working mostly from home an option? (I am a native Dutch speaker btw.)

Nice work! Question: I'm finding myself in need of many changes in the banner template, so I had to hook-replace the module's 'render' method. Would be useful to isolate the path retrieving code in separate hookable functions? Like this: /** * checks for a banner template alternate path * @return string the path of the banner template file */ public function ___getBannerTemplate() { return $this->wire('config')->paths->$this . 'PrivacyWireBanner.php'; } /** * checks for a javascript file alternate path * @return string the path of the banner template file */ public function ___getJsFile() { return ($this->add_basic_css_styling) ? $this->wire('config')->urls->$this . "js/PrivacyWire.js" : $this->wire('config')->urls->$this . "js/PrivacyWireUnstyled.js"; } Then, I could use it (I am using it, actually) like this (in /site/ready.php): // my front pages are all extending a FrontPage class // see https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes if (page() instanceof FrontPage) { $wire->addHookAfter('PrivacyWire::getBannerTemplate', function ($event) { $event->replace = true; $default_path = $event->return; $filename = pathinfo($default_path, PATHINFO_BASENAME); // my override is in /site/templates/modules/PrivacyWire/PrivacyWireBanner.php $override_path = paths()->templates.'modules/PrivacyWire/'.$filename; $event->return = is_readable($override_path) ? $override_path : $default_path; }); } Or even simpler (for me ?), those could be two new config keys, like 'alternateBannerTemplate' and 'alternateJsFile'. This would also cover the case of needing to change the header tag, so it could be dropped (just a thought, don't hit me in the head, you valiant head tag config defenders ?).

Format Datetime fields as Carbon instances. You can find the latest release and the complete readme on Github. Installation composer require daun/datetime-carbon-format Usage All Datetime fields will now be formatted as Carbon instances instead of strings. Some examples: // $page->date is a Datetime field // Output format: j/n/Y echo $page->date; // 20/10/2020 echo $page->date->add('7 days'); // 27/10/2020 echo $page->date->format('l, F j'); // Monday, October 20 echo $page->date->year; // 2020 echo $page->date->diffForHumans(); // 28 minutes ago Frontend only The ProcessWire admin seems to expect datetime fields to be strings. This module will only return Carbon instances on frontend page views. Date output format When casting a Carbon instance to a string (usually when outputting the field in a template), the field's date output format will be respected. Links GitHub • Readme • Carbon docs PS. I remember reading about a Carbon module in a recent newsletter, but couldn't find it anywhere. Was that you, @bernhard?

Thanks a lot for this wonderful module! It works like a charm, except for one little problem: When I use the "Accept all" button I have to reload the website for the changes to take effect. Selecting specific categories and clicking the "Save preferences" button has immediate effect. Is this an indented behaviour or am I missing something here?

There's a module for that: https://modules.processwire.com/modules/template-tags-edit-list/

@joshua thanks for the module. would you consider changing the header tag into a div? <header class="privacywire-header">…</header> Some might using page header in their css-files without a class. It might get into style conflicts. What do you think?

That's exactly what I was looking for and it works beautifully!! Thank you so much! I haven't done much with multiple roles per user... this is terrific!!

@ryan Well thank you again for all your efforts. It really is a massively useful feature! I still feel like it's worth a bit extra.

@alexmercenary Thanks, glad that you are liking this module (saw your post in the FormBuilder board too). Makes my day actually, thank you. This is a module that I thought was necessary to build before December, when SCA in Europe will apparently be a requirement. I wasn't able to find a way that the existing Stripe Inputfield could be updated to support 3D Secure, at least not in a way that would be reliable with the form workflow. Basically, with 3D Secure, the charge takes place at the time the user inputs the card and an independent popup verifies it. So if the card collection is part of another form (as the Stripe Inputfield is), and someone pays but never submits the form (or submits but never fixes validation errors), you end up with an orphan charge. Stripe's solution to this scenario is that you should issue a refund. I thought that was too much for people to keep track of (charges that are missing a form submission). So thought it was necessary to build this module and include it with FormBuilder, especially for any of those in Europe that might already be using the Stripe Inputfield.

@Roope, thanks for the update. However, the update wasn't encoding email addresses for me. After some debugging I think the problem is that this... "((?:<(?:head|script|textarea|option|output)).*(?:<\/(?:head|script|textarea|option|output)>))" ...and this... if(!in_array(substr($str, 0, 5), array('<head', '<scri', '<text', '<opti', '<outp', '<inpu', 'value', 'label', 'data-'))) { ...result in the HTML getting split on the <header> tag and then email addresses following that tag are not encoded.

@tpr, could you please make the styles that AOS applies to Select2 more targeted so that it's possible to use Select2 separately in the PW admin without being affected by AOS styles? At the moment there are AOS styles like this... .select2-selection.select2-selection--single, .select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } ...which will apply to every Select2 instance and are impossible to override to get back the inline style that Select2 uses to set the dropdown width dynamically. It would be better if these could be something like: .aos-select2.select2-selection.select2-selection--single, .aos-select2.select2.select2-container, span.select2-dropdown { width: auto !important; min-width: 300px !important; max-width: 640px; } See "dropdownCssClass" and "selectionCssClass" in the Select2 options. Thanks!

Since I first rebuilt this site in Processwire, it's had a major overhaul, with all competition data now handled on the site rather than in a separate desktop database app. Members are able to access the admin, but using AdminRestrictBranch, some hooks in ready.php and some custom process modules, logged in users are taken to a dashboard that varies depending on their role, so members can only see their own competition images (in a list via Lister Pro) and submit more, while the competition administrator has a dashboard that allows them to manage all aspects of competitions. Competitions close off automatically once their closing date has passed. CustomUploadNames module is used to automatically rename image files when they are uploaded so that once competition entries are downloaded as a zip file, they can be identified by filename. On the front-end slideshows are generated automatically once competition results have been entered, which is done via Lister Pro.

I added a feature for this in todays 0.3.0 (not pushed the release tag yet, as there was a lot of rewriting to implement this feature). If you want to show an opt-in element instead of the consent-required element, just add a data-attribute data-ask-consent="1". Here is an example: <iframe src="" data-src="https://www.example.com/" data-category="marketing" data-ask-consent="1" frameborder="0" height="400" width="400"></iframe> In this case, the iframe gets only loaded, when cookies of type "marketing" are allowed. If not, the user will be asked for consent. The text of the consent-window is configurable in the module config. The markup of this message also includes an css class with the type of cookie, if you want to style them specifically. privacywire-ask-consent.mp4

Today there are two updates for PrivacyWire (newest Version V0.2.7 ) 1. The update of elements after giving consent now observs more attributes (also srcset for responsive images and width/height attributes - especially good for iFrames) 2. When the user wants to choose the detailled cookies, there is now a option to show another "Accept All" Button instead of the "Toggle" Button - configurable via module config.

I can confirm that 0.2.5 works as expected. Thanks @joshua!

Thanks @wbmnfktr for noticing this! There really was a bug with the version number and async loading of scripts etc. I fixed this in V0.2.5. After changing the version number in the backend (and refreshing ProCache - especially when you have activated the option to minify local Javascript) PrivacyWire will check the version number first before handling the elements requiring consent.

The biggest hurdle of timezones is actually in handling "the future". Timezone rules are in constant fluctuation (be it error corrections or actual changes the IANA timezone database changes a few times a year: https://www.iana.org/time-zones). One prominent example is the EU right now, where DST was ruled to be eliminated in the near future giving each country the option to choose if they want to stay on DST or non-DST offset. Therefore to store a point in time (in the future) you at best store not just a datetime/timestamp, but a timestamp as well as the source timezone and used offset. This allows you to detect if the offset of a timezone did change between the time is was stored to the db until the time of retrieval. Otherwise changes in timezone definition might lead to incorrect results (someone being at a place at 11:00 when the time was supposed to be 10:00 wall time). This blog has a few posts on the topic, even if they're not in php: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html Edit: You can ignore changes in timezone definition by storing datetimes in their source timezone, but this won't let you easily compare multiple values in the db. I've some more interesting things on the topic to share. If you're working with intervals I highly suggest using Allen's Interval Algebra as well as watch this talk by Eric Evans:

Just got a couple of likes from @Knubbi on my posts above which prompted me to note that there is a Search and Replace action for my Admin Actions module: http://modules.processwire.com/modules/process-admin-actions/