joshua

If enabled in the TextformatterPrivacyWire settings, yes. But it's disabled by default.

Hi @The G, thanks for noticing this behavior! During the development of PrivacyWire I never thought of showing or hiding divs or "regular" elements - only thought of scripts, videos, media ... So, good catch! I refactored that part of the priw_updateAllowedElement function to fix this bug. Cloning is required for everything, where media, scripts or other external stuff gets loaded... Waaaait a minute... While I was writing these lines of nonesense, I realized that this idea is wrong! ? You're right - keeping the elements alive and just update the attributes works for scripts, images, iframes and of course divs and other elements, too. I refactored again and tested the new version with all kind of elements and media... Only script tags need to be a new added element, as they will not run otherwise: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model 0.4.2 fixed it!

Hi @ceberlin, sounds like an good idea to me. To allow this kind of "tracking" we would need to send this decission via JS to an endpoint which connects to the ProcessWire API. I will think about an way to implement this feature. I'm also open for a PR, if you already have an idea how to realize this feature.

@teppo Thanks alot for your PR with the TextformatterVideoEmbed integration! I tested and merged your PR today. I like the idea of adding more and more integrations with other modules like TextformatterVideoEmbed.

As we often use Matomo (former known as Piwik) instead of Google Analytics we wanted to embed Matomo not only in the template code but also via the ProcessWire backend. That's why I developed a tiny module for the implementation. The module provides the possibility to connect to an existing Matomo installation with the classical site tracking and also via the Matomo Tag Manager. If you have also PrivacyWire installed, you can tell MatomoWire to only load the script, if the user has accepted cookies via PrivacyWire. To offer an Opt-Out solution you can choose between the simple Opt-Out iFrame, delivered by your Matomo installation, or a button to choose cookies via PrivacyWire. You'll find the module both in the module directory and via github: ProcessWire Module Directory MatomoWire @ GitHub MatomoWire @ Packagist ->installable via composer require blauequelle/matomowire I'm looking forward to hear your feedback!

Thanks @teppo! I will look into this and will merge your PR then ? Sounds like a very useful addition to me

I could no longer concentrate on my actual work in the knowledge that this bug existed. So I fixed it directly instead ? 0.3.8 contains the bugfix.

Hey @teppo, this sounds like a bug. I will take a look into this during the weekend. Thanks for noticing!

That's right - you cann add a button (or link, whatever you prefer) with this css class and the data-consent-category attribute. PrivacyWire will handle it ? I definetely have to update the documentation with all the added features - will do that in the next weeks.

Hi @ngrmm, I just wanted to reply the exact same thing - the data-category and data-ask-consent should be at the iFrame tag directly, as you figured out ? Best, Joshua

Hey @teppo, thanks for your input - sounds good! I just added the project to packagist and activated the webhook for auto updating: https://packagist.org/packages/blauequelle/privacywire

@The G There you go ;-) Fixed in 0.3.4

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

@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>.

@snck Thank you! Normally the "Accept all" button should do the exact same thing. I'm looking into this right 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>.

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.

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.

Thank you for reporting this bug / weird behaviour @wbmnfktr! I just looked into this topic and discovered two typos which have produced this buggy behaviour. The new release 0.2.4 fixed this.

The config option for this duration is now included in 0.2.3 ?

Thanks for your input, @The G. There actually already is a way to solve this, thanks to the previous input from @horst: In the PrivacyWire Settings you can find the "Trigger a custom js function" field: Just add a function name there, which you want to get triggered (in this examle the function is called reloadAfterConsent ) Then somewhere in your code add the relevant function, e.g.: <script> var reloadAfterConsent = function() { window.location.reload(true); } </script> And voilá - your page reloads after every consent saving. One could make this configurable, of course. Would you like to set the duration or something else of the setTimeout?

I had the same problem recently and discovered the bug: When there also is a normal Repeater field above the RepeaterMatrix field, the js bug occured. You could try, if this version works for you. If so, I'll create a PR