ceberlin

To ask differently - is someone caring it remains up-to-date with PHP and PW? (This is one of my favourite modules I use)

utf8_encode and utf8_decode functions are deprecated in PHP 8.2 Hi, I am curious if this module still actively maintained?

Update: in my case the issue was not language related. This code snippet helped to identifying a broken display condition for a field in the template: So it's worth looking in all directions. I wonder why PW does not show such issues more precisely by default.

@louisstephens Do you remember what you did in the database? I have the same problem after removing languages and cannot find possible issues in the database.

We try to switch from MATOMO direct embedding to the MATOMO tag manager. I am wondering right now how to use the Matomo Tag Manager correctly. Has anyone expericence with this already? We intend not to block the Tag Manager itself but want to be able tags (like Facebook) inside of it. I don't believe right now that the Tag Manager is a GDPR / DSGVO problem itself. And if this one is blocked, every tag inside is blocked too, which makes a fine-grained selection not possible to the user. But I need to be able to set up rules in PrivacyWire that toggles activation of used tags inside of the Tag Manager. But how?

I run into a problem when removing a cropppable element from the image setting: hauptbild,900,600 quadrat,900,900 Expected: The info for the "quadrat" cuts are removed. No change for anything related to "hauptbild" What happens (latest PW dev and module 4 version, using WebP): All crop settings are lost, including "hauptbild". And the default value is not a largest possible crop from the middle (so a 1800x1200 source would produce a proportional small version without crops). Instead a 900x600 upper-left crop from the original image gets cropped. Basically, this means all fine-tuned settings are lost, and the default worsens it.

I stumbled upon another issue: a.f.a.i.k. the IMPRINT and PRIVACY pages should not be covered by this modal. Otherwise, you cannot read what you are going to decide (if you followed the privacy link in the module, for example). But I am not a lawyer, it is just how I think it should work logically, especially thinking of the very strict German laws about the IMPRINT page accessibility. - Any oppinion? I am looking for an easy way. Right now, I am using CSS to hide .privacywire and its wrapper on those. But since the links to those pages are stored in the modules settings, why not excluding them automatically? Just an idea. In this context, it would be cool if the module did some quick checks to assist the webmaster if those linked pages actually exist and are viewable.

That's a little bit like Christmas for me. So useful! An additional reminder under the PW hints for the field might guarantee that this handy option is remembered when the module is active? • validate: Validates that Pages in value matches your selector on page save. • selectOnce=1: Each option can only be selected once per table

great idea. I could really use it. In my case I have an Autocomplete instead of a Select for the page reference (too many targets) and unfortunately, there double entries are still selectable. But intercepting here, might be another level of complexity. But I might soon find a use case where this fits in well. Thanks for the module!

Thanks again for providing this module and keeping it up-to-date. This module is so useful for me.

Today I also got the class "RuntimeMarkupUtilities" does not exist error. (At a very harmless unexpected spot, when trying to edit a simple body textarea in a template: some local field settings). I love the RuntimeMarkup Field, never had the problem with it before and did not want to give up easily. The only difference with my other PW installs: this PW install was brand new straight from the PW github beta repo and filled with a couple of modules, including this one. When started setting up my templates, I had activated the RuntimeMarkup Module for latter use already. But had not set up a RuntimeMarkup field yet. Now the interesting part: As soon as I had my first RuntimeMarkup field set up (just with the default settings) the "RuntimeMarkupUtilities missing" error mentioned above was gone. Maybe the observation gives you some indication about the possible nature of the bug. Maybe there is nothing wrong with the RuntimeMarkup module code, there might be just a timing problem, or the module is looking for a class of some target code not running because not in use at that point. Just guessing.

Hi, ProcessWire 3.0.175 + PrivacyWire 104. On this occasion I wish to thank you for the really helpful module contribution and all your support!

Silly me. I was using the example from here (https://processwire.com/modules/privacy-wire/) without looking for type errors in there. (The example code could be updated?) I fixed it and cleared the cache. Still not working. A minification issue maybe (semicolons)?

I started having trouble with <script type=text/plain" data-type="text/javascript" data-category="external_media" class="require-consent"> I get a JS error and the element isn't shown (any more?) on consent. Anyone else sees this too? Or did I use this in an unintended way? (Example)

Maybe a bug: I cannot set "Bytes" in the module settings to anything else than 0 - It resets to "0" after saving.

Can be an essential element of a GDPR data protection strategy. Very useful. Thank you!

Hi, today's 2.0 update killed the backend here on some installs... Reverting to 1.2.7 fixed it: PDOException #42S22 SQLSTATE[42S22]: Column not found: 1054 Unknown column 'field_phits.last_hit' in 'field list'

I can confirm that this method of replacing the decimal field worked on my e-commerce-Project where I tried this. No problems.

I think that PW could have a stronger GDPR support out of the box, including comments. There are already some consent plugins available (one of those pretty good), but there is still much efforts needed (like the unnecessary complicated recommendations for fixing comments). For us Europeans, it is so important, to have things right there from the beginning, and GDPR should not be rocket science to fully implement.

Hi Joshua, just an idea. If there were a counter for all closes of all finished user decisions and a separate one only for the "accept all" decisions, it would give me a perfect idea of the accept ratio of the specific site. Either generally (probably enough), or even per month in a table (to monitor changes in behaviour). In the module, or in logfiles or a CSV file with a row limit? Basically, sort of mini-statistics. I have guesswork right now regarding Analytics' / Matomo's result changes and of how many users (in percent) those analytics results represent?

Just a searchable note here in case s.o. else runs into the same problem ? You suddenly cannot log in any more with TFA/2FA (Two Factor Authentification)? After the step two (inserting the 2FA code) the server responds with an ERROR 500? There is no corresponding entry in the server logs? Check this: Open your site files with FTP, go to /site/assets/logs/ and look into the file exceptions.txt If you find an entry there, like so: ... Invalid base32 string (in /site/modules/TfaTotp/TwoFactorAuth/lib/TwoFactorAuth.php line 190) This indicates that the 2FA code got messed up. Two ways to fix this: Via FTP, move TfaTotp out of /modules/ Login and go to User/Profile While the login session is active, via FTP, move TfaTotp back to /modules/ Disable TfaTotp - and then save your profile page Re-enable TfaTotp - and then save your profile page again. …or (tip from @adrianj): Create a new superuser via the API and login via that and then disable and re-enable 2FA for the affected user via Access > Users. --- More in depth info from @ryan at Github: 2FA login error 500.

Joshua, first, thank you for all your work. It looks like that we need a good solution for compliance also in Germany now (after the BGH ruling) and I am glad, that your plugin is close to what we need already. After comparing existing tools and reading more about the requirements I thought of the following strategy to add to the compliance: (My source of information: https://www.activemind.de/magazin/cookie-consent-banner/) 1. we probably need another category. "Functional" for settings that are not "essential", like settings, example use: remember that a certain popup was closed. Comes after "essential" (or better the order of the selected categories from the backend is remembered) 2. Details collection. This info should to be collected: name of cookie, issuer, purpose, functions, privacy links. Example: name: '_ga, _gid', issuer: 'Google Universal Analytics', purpose: 'Collect statistical data for service improvement.', functions: 'Number of pageviews, link clicked etc. ', privacyLink: 'https://policies.google.com/privacy?hl=en' Some vendors like cookiebot overload their popup with information. I think this confuses more than it helps. Setting content should not be rocket science to average users. Instead, I thought of having the details on a special (manually filled?) compliance page, sorted into category blocks. That means that means another optional link (next to imprint and privacy) in the settings could be useful. If this strategy makes sense, then it would be fancy if your textformatter could handle the consent from there: [[privacywire-category-settings category="statistics" ]] and display a toggle for on/off for that category. (But this has no priority) 3. Styles / Popup responsive? Right now the popup is not working correctly on mobile phones. It is not scrollable, and with lots of description and selections it easily has more content than fitting on a small screen. We need another wrapper div tag for the element and another wrapper div tag with a class for the links - and add classes to all elements like the lists - so this is easier to style. Also the body text is maybe not needed right away so there should be an option in the backend to display that only on the page which opens, when "select" is choosen? Maybe add a field in the backend to drop all the CSS so it is easy to maintain at one place? 4. External media. Can you explain what happens in that case? How can your code handle iframes, e.g. YouTube, Vimeo and maps? What happens if one of the existing video plugins are used? 5. Cookie lifetime of this plugin max 7 days? In Safari and Firefox JavaScript cookies have a short lifetime, even if the cookie is set with a very long expiration date. A user has to opt-in again every 7 days. Is this correct? and is an alternative? Source: https://alightanalytics.com/alight-insights/safari-first-party-cookies/ --- Before a line of code is written, I would ask everyone for feedback and ideas for this concept... --- By the way: here is a nice layout example with a consent banner with kind of your feature set - they also follow the route to move all complicated cookie details to a separate cookie consent page: https://www.osano.com/cookieconsent/download/

Hi Joshua, yes, in Germany, this is not mandatory at the moment - in other EU countries the situation might be different. All German lawyers online with lots of drama about the subject offer - surprise surprise - their own commercial solutions. I have not read any neutral position/comment on the subject yet. As I understand it, the tenor from the BGH is that the user should be able to know exactly what he or she agrees to. According to this, the webdesigner would have to name names. The BGH ruling is still too recent (end of May 2020) and has not yet been implemented in German law. I just want to be prepared. I am irritated to I see the free KLARO goes the same route, listing all the little details. I am not prepared yet to fork and PR. I am thinking about possible concepts right now. Maybe just adding an optional data-attribute with some line of text or a link which is is dispayed with a "read more" in the module's output, so the module does not need to handle every little detail? I am curious about other opinions from EU developers here. (I am also checking out the KARO module for WordPress right now to see how they are managing the information there.) Cheers, Carl

Isn't it required in the new word of EU web bureaucracy to list every single cookie on demand (by category) and explain what is does, where it's from and can set it individually? So, for example, in the same example category "my user settings" I can agree to remember a "my selected language" cookie but not another cookie with "my last page visited"? As Borlabs cookie does it, or Klaro (kind of)? Am I wrong with my understanding of the current GDPR law situation? Or is this implemented already and I just did not find it? (Right now I am evaluation this module against using KLARO directy)

great - I was just preparing a report here just now. Here's a demo video: bug-aos-cke-sourceeditor.mp4