Add opt-in for commenter cookies

[azaozz]

The commenter cookies are a good example of data stored for "convenience". They are not essential, used only to pre-fill the name, email and URL fields of the comment form when the commenter intends to post another comment.

We should add a checkbox to the comments form that will inform the commenter about the cookies and act as opt-in.

[azaozz]

Good text for that would probably be:

Save my name, email and site URL in my browser for next time I post a comment.

[lakenh]

I have just attached an initial patch implementing this feature. There are a few problems that we probably want to discuss. One problem is that without cookies, there is no way for the user to delete their comment. In addition, there is no visual cue that their comment was submitted.

[lakenh]

Attached another patch (sorry ticket watchers!), which makes the cookie opt-in the default state of the checkbox.

[xkon]

It does work as supposed to, but I'm not sure the idea of having it 'pre-checked' is correct here. The point is to ask the user'if' he wants to opt-in for the cookie etc.

By having it pre-checked it goes against that idea.

It's the same principle as when you are to agree with Terms etc none of the checkboxes should be pre-checked. You only check what you want after reading what it is going to happen, we can't force checks as it's like forcing the opt-in itself in my opinion. We could ask this on the #gdpr-compliance though just to be sure.

[birgire]

I agree with @xkon that it makes sense to have this un-checked by default.

@lakenh: In 43436.1.diff​ we should be able to simplify:

$cookie_consent = ( isset( $_POST['cookies'] ) ) ? true : false; 

with

$cookie_consent = isset( $_POST['cookies'] );

as isset() is already boolean.

I also wonder if name="cookies" is too general name. What about e.g. name="cookie_consent" ? But then again, the other comment form names are pretty general too ;-)

[azaozz]

I also wonder if name="cookies" is too general name.

I was thinking the same. It's true the other form fields have very generic names, but they have been like that for... ages. Perhaps the name and id of the checkbox should be specific, for example wp-comment-cookies-consent.

@lakenh thanks for the patch. Looks good except perhaps replacing the name (I'll do that).

I don't have strong feelings whether this is opt-in or opt-out. Seems both make this GDPR compliant (inform the user and ask for consent). These cookies are purely for convenience and are "always on" at the moment. Perhaps having an opt-out is more logical?

[azaozz]

Running into some styling problems. In most themes a <label> inside the comments form is set to display: block;, see the above screenshots. The way to fix this is to move the <input type="checkbox"> inside the <label> element.

In addition the labels in the comments form are styled for shorter text: usually bold, allcaps, larger font, etc. Don't see a good way to prevent that for the checkbox label. The only way seems to be to not use a <label> element at all. Can be a span with ID and aria-labelledby on the checkbox, but that will make the text "non-clickable", i.e. to toggle the checkbox the user will have to click exactly on it.

Seems this will need some updates to the themes that would take ages. Alternatively we can add one line of CSS to reset the label text to initial but that may still bring visual bugs in some themes.

Any other ideas/alternatives?

[azaozz]

Going to commit this for easier testing and leave the ticket open for eventual improvements of the styling.

[azaozz]

In 42772:

Add a checkbox to the comment form so logged out users can opt-out of commenter cookies.

Props lakenh, xkon, birgire, azaozz.
See #43436.

[azaozz]

That should read "...logged out users can opt-in for commenter cookies". The checkbox is unchecked by default as discussed in Slack: ​https://wordpress.slack.com/archives/C9695RJBW/p1520175245000016?thread_ts=1520122616.000026&cid=C9695RJBW

Also, when the users have opted out, existing cookies are deleted.

[afercia]

move the <input type="checkbox"> inside the <label> element.

If possible, a non-wrapping label would be greatly preferable. See the ​WordPress accessibility standards. The reason is non-wrapping labels associated with for/id attributes are the most supported ones by assistive technologies, especially old AT/browsers combinations.

Seems some styling will be necessary anyway, so I'd propose to use an explicitly associated label to follow a11y best practices and then find a way to use some tiny styling.

[wpmarkuk]

Is the plan that this would be checked by default? I ask only because I am pretty sure that with GPDR consent works the other way and you have to actively consent by clicking checking the checkbox?

[idea15]

@wpmarkuk Correct: unticked by default.

[mikejolley]

In the age of browser autocomplete, how useful is this cookie anyway?

[wpmarkuk]

On reflection I agree - I think we could just not use a cookie here at all and not have this tbh.

[lakenh]

The cookies do have a use though, for more than just autocomplete :)

The cookies allow you to delete your comments if they are not approved yet, and preview it as well.

[mikejolley]

Thats fair, I didn't notice that feature. Need to weigh the usefulness of that against a checkbox for all :)

[azaozz]

In 42815:

Respect the commenter decision when they have checked the checkbox to consent to cookies, and keep it checked when they reload the page or post another comment.

See #43436.

[xkon]

fyi, I'll make a pass from all bundled themes this within this week and provide screenshots + a patch for @afercia 's comment so we can close this asap.

[dejliglama]

Replying to lakenh and @azaozz

The cookies do have a use though, for more than just autocomplete :)

This should probably be part of a policy text on this particular feature:

The comments cookie is used to pre-fill the name, email and URL fields of the comment form when a commenter intends to post another comment. It also allows you to delete your comments if they are not approved yet, and preview it as well.

[xkon]

preview

[xkon]

css fixes on all bundled themes

[xkon]

43436.2.diff​ moves the <input> outside of the <label> as @afercia mentioned on a previous comment and adjusts the css on all bundled themes to display the checkbox properly as seen on 43436.2.jpg​ .

Note: @azaozz if this is ok and goes forth to commit I guess we can close it as well. If there's a new issue we can create an extra ticket in the future, just to keep trac clean for easier access + track of what's needed.

[azaozz]

@xkon thanks for the patch! Looks good.

The last thing I'm thinking about is if we should add an inline style display: inline; for the <label>.

I know, --everybody-- hates inline styles, but really don't see good way to fix this for all themes.

Alternatively can output a <style> tag in the head with something like:

#commentform .comment-form-cookies-consent label[for="wp-comment-cookies-consent"] {
    display: inline;
}

Which is the "lesser evil"? :)

Moving this to the "Bundled Themes" component as it mostly concerns the theme.

[xkon]

The lovely folks from #themereview after a little chat we had told me that we can create a Make post informing the authors of this change so we can spread it a bit, but apart from that it'll be up to the authors to take care of it at the end.

If in any case we 'have' to add something I'd personally go for the inline even if I'm not a fan as well. I don't like the idea of outputting a full extra <style> in the header no matter how small it could be at all.

[johnbillion]

Looks good. I think site URL in this message should say website URL so it matches the phrase used for the Website field in the comment form.

[rabmalin]

I understand that this checkbox is important but lets try to avoid breaking themes. We are not talking about few default themes only, we are talking about thousands of themes. And, unfortunately we are breaking themes in the minor release of WordPress. Like everyone, expectation is that there wont be any breaking changes in the minor release and I believe that is the philosophy of releases of WordPress also.

[greenshady]

Announce it on the Make Themes blog with plenty of advanced notice. Within the next week is fine. This is set for a 5.0 milestone. That's plenty of time for theme authors to get on board. If a theme looks a little off, WordPress.org has a built-in forum and ratings system for users to communicate with theme authors.

But, for the love of all that is holy, please don't add any extra styles (inline or otherwise) that I have to disable in my themes.

[desrosj]

Moving to the 4.9.6 milestone after consensus was reached in the most recent GDPR chat (​https://wordpress.slack.com/archives/C9695RJBW/p1524063200000304).

[xkon]

@laurelfulford, @davidakennedy could you please take a look at this as well so we can get it committed also before beta? ( I forgot to send a ping :S ) Ty!

Last patch is 43436.2.diff​ and preview 43436.2.jpg​

[laurelfulford]

@xkon Absolutely! :) I didn't get to this today as I had hoped, but I will post some feedback tomorrow!

[laurelfulford]

@xkon I reviewed this update in all of the themes, and it looks good!

The only thing that stood out to me was in Twenty Fifteen and Twenty Sixteen, the default label styles — bold and all-caps — made the checkbox labels tricky to read:

Twenty Fifteen:

Twenty Sixteen:

Those styles work well for the one-word labels, but they weren’t really made for longer strings of text. I tried changing the styles to match the .comment-note at the top of the form, and I think it helps — for each theme, it would look like:

Twenty Fifteen

Twenty Sixteen

I’ve updated these styles in 43436.3.diff​ in case anyone else finds it’s easier to read. Let me know what you think!

[xkon]

Thank you so much for the quick review and the changes @laurelfulford !

Extra small change:

43436.4.diff​ is based on 43436.3.diff​ and changes site URL to website URL as @johnbillion mentioned in comment:26 above ( good point! ).

[johnbillion]

In 43042:

Comments: Update the inline docs following [42772].

See #43436

[laurelfulford]

I checked over 43436.4.diff​ again and everything looks good! It gets a thumbs up from me.

The changes include a file outside of the bundled themes (wp-includes/comment-template.php) so I can’t commit the changes myself, but I'm adding the keyword "commit".

[johnjamesjacoby]

“Save my name, email, and site URL in my browser for next time I post a comment.”

Should probably be:

“Save my name, email, and website in this browser for the next time I comment.”

Or:

“Save my name, email, and website in this browser for when I come back.”

Even better would be:

“Use a cookie to remember my information in this browser for the future.”

——

The original text uses “site URL” instead of “website”, which is considered jargon. It also is missing a “the” which is necessary to not sound like it was written by a non-native English speaker. “Post a comment” is overly verbose because “comment” can already be used as a verb.

My alternative text suggestion is shorter, more accurate, and plugin friendly. For example, many plugins add fields to this form that would also be remembered, and bbPress uses this same cookie when anonymous posting is turned on, as do other plugins that enable “guest” users to do things.

Because more fields can be used for more than just post-comments, I strongly prefer not accidentally misinforming users, and think something more like my final suggestion covers more conditions.

Edit: typos, missing words, and pre-coffee changes.

[azaozz]

Replying to johnjamesjacoby:

Yep, replacing site URL with website makes sense.

My alternative text suggestion is shorter, more accurate...

However many (current and future) cookies laws require the websites to explain why they use the cookies and what's in them. General terms such as "my information" won't cut it.

[johnjamesjacoby]

Replying to azaozz:

However many (current and future) cookies laws require the websites to explain why they use the cookies and what's in them. General terms such as "my information" won't cut it.

If that’s true, then core will need to loop through the fields in this form and generate a string using the label contents. That seems redundant (and quite stupid considering the proximity) but so be it.

Hardcoding the 3 core fields only, will leave plugin authors without recourse. And folks modifying this form should not need to add more and more check boxes for their additional fields; that would be terrible.

[postphotos]

’“Save my name, email, and website in this browser for the next time I comment.”

Capturing what was agreed upon in today's office hours.

[helen]

Replying to azaozz:

However many (current and future) cookies laws require the websites to explain why they use the cookies and what's in them. General terms such as "my information" won't cut it.

If that's the case, and I think I saw this mentioned in Slack, wouldn't the message need to also explain that the cookie is used for you to be able to view and modify any of your own comments that are still in moderation?

[allendav]

Updates text per today's office hours chat

[allendav]

Updated text from 43436.5.diff

[laurelfulford]

43436.6.diff​ combines @allendav's label update with the default theme style updates from earlier iterations.

[laurelfulford]

Apologies for the back-to-back patches! 43436.7.diff​ is a de-fuzzed version of 43436.6.diff -- I created the original in too much of a rush.

[iandunn]

In 43123:

Privacy: Use "website" in comment cookie consent text for clarity.

The term "URL" is technical jargon which will not be familiar to all commenters. "Website" is more universal, and matches the label on the url input field.

Props johnjamesjacoby, allendav, azaozz.
See #43436.

[iandunn]

In 43125:

Comments: Move comment consent input outside the label for a11y.

Non-wrapping labels are more widely supported by assitive technologies. The CSS changes account for the element re-ordering, and tweak the formatting for improved readability.

Props afercia, xkon, laurelfulford, azaozz.
Fixes #43436.

[iandunn]

Reopening for backport to 4.9 branch.

[iandunn]

:laugh: You beat me by 3 seconds :)

[SergeyBiryukov]

In 43127:

Add a checkbox to the comment form so logged out users can opt-out of commenter cookies.

Props lakenh, xkon, birgire, azaozz, johnbillion.
Merges [42772] and [43042] to the 4.9 branch.
See #43436.

[SergeyBiryukov]

In 43128:

Respect the commenter decision when they have checked the checkbox to consent to cookies, and keep it checked when they reload the page or post another comment.

Props azaozz.
Merges [42815] to the 4.9 branch.
See #43436.

[SergeyBiryukov]

In 43129:

Privacy: Use "website" in comment cookie consent text for clarity.

The term "URL" is technical jargon which will not be familiar to all commenters. "Website" is more universal, and matches the label on the url input field.

Props johnjamesjacoby, allendav, azaozz.
Merges [43123] to the 4.9 branch.
See #43436.

[SergeyBiryukov]

In 43130:

Comments: Move comment consent input outside the label for a11y.

Non-wrapping labels are more widely supported by assitive technologies. The CSS changes account for the element re-ordering, and tweak the formatting for improved readability.

Props afercia, xkon, laurelfulford, azaozz.
Merges [43125] to the 4.9 branch.
Fixes #43436.

[desrosj]

Moving to the new Privacy component.

[superpoincare]

One thing I see with this new behaviour is that if comments are held in moderation and a user makes a comment, and doesn't tick the box next to "Save my name, email, and website in this browser for the next time I comment.", then after he/she clicks comment and the page reloads, the comment is not seen.

In that case, the user is confused as to whether the comment was posted and could attempt to rewrite post it again unnecessarily or get frustrated.

There should be something to indicate that the comment was posted.

[xkon]

hi @superpoincare ! This is already tracked on #43857.

[superpoincare]

Thanks @xkon. I downloaded @imath's plugin at Github and works well! Hope the patch in that ticket is added to 4.9.7

Also, isn't it necessary to tell the commenter of this behaviour?

For example, moderation might take, say a day or two and if the commenter visits the site again and finds that his/her comment isn't there (since the cookie isn't stored if he/she doesn't opt-in)?

I know how to do it myself---have already done for my site. I am suggesting it for all Wordpress sites.

Something like:

"Note: If you do not opt-in to save, and click the submit button below, and if your comment goes into moderation, it may appear only once in your browser—after this page reloads—not subsequently or till the comment is approved."

[desrosj]

Dev note: ​https://make.wordpress.org/core/2018/05/17/changes-that-affect-theme-authors-in-wordpress-4-9-6/.