wedevtrust Logo

GDPR-compliant comments with WordPress

WordPress GDPR FuckUp
Image | RF dreamstime

With the 4.9.6 release WordPress has introduced some functions to comply with the General Data Protection Regulation. Unfortunately, the implementation seems rather disgruntled than enthusiastic. In the comments you can now activate a checkbox with which you give permission to save the name, e-mail and website of the commenter for later use in his browser. A cookie agreement, therefore.

The fact that with the sending of a comment

  1. Name, e-mail and IP address, i.e. personal data, stored in our database and
  2. eMail and IP address, as said personal data, without knowledge of the commentator, will be disclosed towards Gravatar

is not treated. And in my opinion this weighs more heavily than setting a cookie with my personal data in my own browser.

The fact that WordPress handles the GDPR so casually has to do on the one hand with the fact that we Europeans are really annoying with our data protection laws, right?! On the other hand, personal data, especially on a large scale, Big Data with referrers, ip- and email-addresses in this case, represent a considerable value. WordPress is distributed by Automattic and Gravatar also belongs to Automattic. To deliver an option with WordPress where Gravatar does not receive any data by default would therefore be bad for Automattic.

But we prefer not to afford the luxury of casual handling of the GDPR. We should improve the comment function of our WordPress page regarding GDPR. First of all, we need a solid strategy.

A solid Strategy

The purpose of the GDPR is to ensure transparency and control of personal data. We therefore want to ensure that our commentators know which data we process and how and why. Let us first take care of the on-board resources.

The option to save names, e-mails and web pages in the visitor’s browser until they are commented on again is a nice convenience function. We should activate this, especially as we can then use this option for our privacy policy consent cookie.

To protect the personal data of commenting visitors from Gravatar, we could use the great Avatar Privacy plugin, which even comes with the beautiful Ringicons, as a ready-made solution.

Last but not least, we should make sure that the user is aware that we keep their name, email address and IP address in our database, why we do this and what we do with it. In addition we let ourselves confirm that it knows our data security explanation. At this point, in my opinion, our legitimate interest (Art. 6 EU-GDPR 1.f) is preferable to the consent of the data subject as legitimation of the processing and sufficient. We should also describe this in our Privacy Policy. We would therefore need an additional checkbox on the comment form with the corresponding text. And that’s what we’re going to do quickly and multilingually with Polylang.

Technical Implementation

For our privacy checkbox, we would like to have the following features

  • Multilingualism
  • Mandatory field checkbox for information on the data protection declaration
  • Is stored correspondingly Cookie checkbox and then automatically set, or even not

Of course, we have been using a Child Theme, in wise foresight for exactly such a case. We add the following code to the functions.php of our Child Theme.


We use the register_pll_strings function in Polylang to register strings for our checkbox, which we can then edit in multiple languages.

The strings can be found under Languages > Strings translations and can be adapted separately for each language.

In the custom_comment_consent_field function, we use these strings by injecting our checkbox into the form.

Stored Confirmation

If a confirmation cookie is set, i.e. the commenter has already confirmed and at the same time given permission to save form entries in a cookie in his browser, we automatically set the checkbox to checked.

Checking the Mandatory Field

Since our confirmation checkbox is a mandatory field, we check in verify_policy_consented before sending the form whether it was also checked. If not, we issue an error message. If already, we write our cookie if the permission for that was given. If the cookie was denied, we delete our cookie for safety’s sake, even if it was not set at all. In terms of processing time, this is often cheaper than checking whether the cookie was set, and only deleting it if it was.


Certainly the whole of Europe laughs at us Germans because we actually take the GDPR seriously. In Germany, however, the situation is special because of our competition law and the resulting warnings. I use comments only again by the, in my opinion, bulletproof variant described here with Gravatar approval and confirmation of the data protection declaration knowledge.

We could now drill the approval procedure further by documenting that set checkbox in the comment metadata in order to be able to prove that the data subject has consented to the processing of his or her personal data (Art. 7 EU-GDPR 1). In my opinion, however, this already happens when the data subject sends the commentary in full knowledge of the data protection declaration. In addition, data subjects can revoke explicitly given consent. In this case, we legitimize the processing with our legitimate interest anyway.

Furthermore, we could work out a procedure which makes it necessary to reset the checkbox again if the Privacy Policy changed and/or integrate our procedure into WordPress’s own Tools to Export Personal Data and Erase Personal Data. The plugin WP Comment Policy Checkbox does a good job in this respect, but relies on explicit consent instead of legitimate interest.

What do you think about GDPR-compliant comments? No problem at all or have you deactivated the comment function? If you’d like to read more about GDPR check out this great article over at Cloudwars!


Related Posts

Time to Update

Maintenance of High Turnover WooCommerce Stores

What to do when plugin updates suddenly cause problems for a high-traffic online store? We were faced with this task when a maintenance interval looked promising at first, but then led to inaccessibility of our client’s high-volume WooCommerce store under load.