WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 3 months ago

Last modified 2 months ago

#43436 closed enhancement (fixed)

Add opt-in for commenter cookies

Reported by: azaozz Owned by: xkon
Milestone: 4.9.6 Priority: normal
Severity: normal Version:
Component: Privacy Keywords: gdpr commit fixed-major
Focuses: Cc:

Description

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.

Attachments (12)

43436.diff (3.6 KB) - added by lakenh 5 months ago.
43436.1.diff (3.6 KB) - added by lakenh 5 months ago.
comment-consent-1.png (6.7 KB) - added by azaozz 5 months ago.
comment-consent-2.png (7.8 KB) - added by azaozz 5 months ago.
43436.2.jpg (297.7 KB) - added by xkon 4 months ago.
preview
43436.2.diff (8.7 KB) - added by xkon 4 months ago.
css fixes on all bundled themes
43436.3.diff (9.9 KB) - added by laurelfulford 3 months ago.
43436.4.diff (9.8 KB) - added by xkon 3 months ago.
43436.5.diff (1002 bytes) - added by allendav 3 months ago.
Updates text per today's office hours chat
43436.5.png (97.0 KB) - added by allendav 3 months ago.
Updated text from 43436.5.diff
43436.6.diff (9.9 KB) - added by laurelfulford 3 months ago.
43436.7.diff (9.8 KB) - added by laurelfulford 3 months ago.

Download all attachments as: .zip

Change History (81)

#1 @azaozz
5 months ago

Good text for that would probably be:

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

This ticket was mentioned in Slack in #core by azaozz. View the logs.


5 months ago

@lakenh
5 months ago

#3 @lakenh
5 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

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
5 months ago

#4 @lakenh
5 months ago

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

#5 @xkon
5 months ago

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.

#6 @birgire
5 months ago

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 ;-)

Last edited 5 months ago by birgire (previous) (diff)

#7 @azaozz
5 months ago

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?

Last edited 5 months ago by azaozz (previous) (diff)

#8 @azaozz
5 months ago

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?

#9 @azaozz
5 months ago

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

#10 @azaozz
5 months ago

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.

#11 @azaozz
5 months ago

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.

#12 @afercia
5 months ago

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.

#13 @wpmarkuk
5 months ago

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?

#14 @idea15
5 months ago

@wpmarkuk Correct: unticked by default.

#15 follow-up: @mikejolley
5 months ago

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

#16 in reply to: ↑ 15 @wpmarkuk
5 months ago

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

#17 follow-up: @lakenh
5 months ago

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.

#18 @mikejolley
5 months ago

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

#19 @azaozz
4 months ago

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.

#20 @xkon
4 months ago

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.

#21 in reply to: ↑ 17 @dejliglama
4 months ago

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
4 months ago

preview

@xkon
4 months ago

css fixes on all bundled themes

#22 @xkon
4 months ago

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.

This ticket was mentioned in Slack in #themereview by xkon. View the logs.


4 months ago

#24 @azaozz
4 months ago

  • Component changed from Comments to Bundled Theme
  • Keywords 2nd-opinion added; needs-testing removed

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

#25 @xkon
4 months ago

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.

#26 @johnbillion
4 months ago

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.

#27 @rabmalin
4 months ago

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.

This ticket was mentioned in Slack in #themereview by rabmalin. View the logs.


4 months ago

#29 @greenshady
4 months ago

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.

This ticket was mentioned in Slack in #gdpr-compliance by casiepa. View the logs.


3 months ago

#31 @desrosj
3 months ago

  • Milestone changed from 5.0 to 4.9.6
  • Owner set to idea15
  • Status changed from new to assigned

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

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


3 months ago

#33 @xkon
3 months ago

  • Keywords has-screenshots added

@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

#34 @laurelfulford
3 months ago

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

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


3 months ago

#36 @desrosj
3 months ago

  • Owner changed from idea15 to xkon

#37 @laurelfulford
3 months ago

@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: https://cldup.com/L4vjllIoS7-3000x3000.png

Twenty Sixteen: https://cldup.com/3FBdTnz8VL-3000x3000.png

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 https://cldup.com/9ZGNN2OzzH-3000x3000.png

Twenty Sixteen https://cldup.com/kvgkTVD6Ot-3000x3000.png

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
3 months ago

#38 @xkon
3 months ago

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! ).

This ticket was mentioned in Slack in #gdpr-compliance by xkon. View the logs.


3 months ago

#40 @johnbillion
3 months ago

  • Component changed from Bundled Theme to Comments

#41 @johnbillion
3 months ago

In 43042:

Comments: Update the inline docs following [42772].

See #43436

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


3 months ago

#43 @laurelfulford
3 months ago

  • Keywords commit added

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

This ticket was mentioned in Slack in #core-committers by laurelfulford. View the logs.


3 months ago

#45 follow-up: @johnjamesjacoby
3 months ago

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

Last edited 3 months ago by johnjamesjacoby (previous) (diff)

#46 in reply to: ↑ 45 ; follow-ups: @azaozz
3 months ago

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.

#47 in reply to: ↑ 46 @johnjamesjacoby
3 months ago

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.

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


3 months ago

#49 @postphotos
3 months ago

’“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.

This ticket was mentioned in Slack in #core-committers by laurelfulford. View the logs.


3 months ago

#51 in reply to: ↑ 46 @helen
3 months ago

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
3 months ago

Updates text per today's office hours chat

@allendav
3 months ago

Updated text from 43436.5.diff

This ticket was mentioned in Slack in #gdpr-compliance by allendav. View the logs.


3 months ago

#53 @laurelfulford
3 months ago

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

#54 @laurelfulford
3 months ago

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.

#55 @iandunn
3 months ago

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.

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


3 months ago

#57 @iandunn
3 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#58 @iandunn
3 months ago

  • Keywords fixed-major added; has-patch 2nd-opinion has-screenshots removed

Reopening for backport to 4.9 branch.

#59 @SergeyBiryukov
3 months ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

#60 @iandunn
3 months ago

:laugh: You beat me by 3 seconds :)

#61 @SergeyBiryukov
3 months ago

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.

#62 @SergeyBiryukov
3 months ago

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.

#63 @SergeyBiryukov
3 months ago

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.

#64 @SergeyBiryukov
3 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

This ticket was mentioned in Slack in #gdpr-compliance by desrosj. View the logs.


2 months ago

#66 @desrosj
2 months ago

  • Component changed from Comments to Privacy

Moving to the new Privacy component.

#67 @superpoincare
2 months ago

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.

#68 @xkon
2 months ago

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

#69 @superpoincare
2 months ago

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

Last edited 2 months ago by superpoincare (previous) (diff)
Note: See TracTickets for help on using tickets.