Richard Vencu

OK, my bad, there was no alphabetic order. I could find all email addresses in the 1564, so I guess this is the total number of commenters on my site.

Latest WP Discuzz version has provided a hook for GDPR

COMMENTS – WPDISCUZ V5.0.5
Added: Action hook for General Data Protection Regulation (GDPR) checkbox wpdiscuz_submit_button_before

Thanks. I did not notice but I will give it a try in a couple of days.

Yes, MailChimp is third party too. But, it also depends on the interest. For instance we have patients and request feedback after treatment via MailChimp and this does not require consent, only notification. Adding the email for marketing does requires consent.

One more gray area: the comment itself does not contain personal data and is not subject of consent. However the visitor might have the initiative to write down his personal data inside (maybe just to troll the webmaster) so something must be said. Already the consent information takes more space than the comment form itself, I do not really know where are we going with the UI usability…

As a suggestion I would move the checkbox at the top, to be under the comment form, very close, not after some long paragraph because the user will miss there is another checkbox to take care of…

• This reply was modified 7 years, 1 month ago by Richard Vencu.

I think all texts should be editable. For instance I dropped Jetpack/Disqus commenting systems in order to keep comments locally at all times. So I do not send them to third parties and I do not want this section mentioned. Others will need it.

A particular case about Akismet, the comment (also personal data?) is sent to Akismet servers to process it for antispam purposes. However this would not require consent in my opinion because it is a legitimate interest of protectig the website. But since the transfer is done the transfer must be listed into the Privacy Policy.

There are many many subtle details with GDPR. I would find it useful if we could share our implementation just to see what I missed and offer what I did good to others.

disabling WP GDPR solves the issue, of course…

Yes, we have the same 10 years retention and national laws are stronger than GDPR rules in such cases but while these records must stay email addreses of the customers do not have to stay though. We also process medical info (we are medical services providers) and we must keep this data for a while, still unclear how long.

I was thinking to move logs offsite just to remove them from danger of the online computers. Then I thought what if someone send me an email (I put in my Privacy Policy a statement saying that anyone sending personal data via email is automatically consenting for us to process that data for the purpose stated on that email) then they request to be forgotten it will be a nightmare to hunt all instances of emails sent from that address inside the email server as well as all possible local machines that maybe downloaded it.

There is some DLP software offering (currently we like CoSoSys product) that can be trained to detect content everywhere in the enterprise and do something with that content. Maybe we will be able to add those personal data to a dictionary and destroy all instances of it at the next scan, then keep a log of what it did.

• This reply was modified 7 years, 1 month ago by Richard Vencu.

In the light of GDPR if some user requested to be forgotten what happens with this log made by WP Mail Logging plugin when it still keeps that user email address?

I mean we do not need consent since this is a legitimate interest (keeping logs for legal purposes let say) but then the user is really forgotten or not?

One of my sites has English plus 3 translations… Not possible to add all languages in the same email, is not professional… Adding language as request parameter is only way to go.

And there is a good explanation: the frontend is in the translated language so translation is used properly. The backend is in a single language, English, therefore the processing action triggers emails in that language.

I think the request language should be saved at the visitor/request level. Then send all subsequent emails in that language. I cannot see any other way for multilanguage sites…

Back – the first email is sent in the translated language. The second email (final confirmation) is sent in English even for the subdomain.

Well, something strange happened. I run a network. The main site send emails in English no matter what. One subdomain is sending emails in the current language though…

I will test more and return with my findings.

Thumbs Up.

Yes, I did it already, of course. But the sent emails are still in English. I guess in backend the email sending function has no idea what is the current language at frontend.