Provide a way to show what change occurred to the suggested privacy policy text.

[ssokolow]

Currently, when WordPress notifies me that the suggested privacy policy text has changed, it doesn't provide any indication of WHAT has changed.

Given that I've customized the text I'm actually using, this makes it prohibitively time-consuming to track down what changed (because I'd have to download an old WordPress version, copy-paste out the suggested text, and then run the two versions through a diff utility manually).

As a result, I wind up just dismissing the notification and getting on with my day. (Not to mention feeling irritated by further confirmation of my sense that I spend more time applying updates to WordPress or its plugins than actually posting... something I hope to remedy by migrating to a static site generator like Jekyll or Pelican.)

Given that WordPress already has a diff implementation for showing changes between revisions of posts, it should offer to apply it to the two different versions of the suggested privacy policy, so I can easily know whether I need to update my customized version. (Ideally, it should apply it between whatever version was current when the privacy policy page was last edited and the current version.)

[desrosj]

Hi @ssokolow,

Thanks for the ticket, and welcome to Trac!

I agree that this notice is not very helpful. I would like to get some UI/UX feedback on this to determine the best way to indicate the suggested changes to the user.

[desrosj]

Privacy settings screen after activating Akismet.

[garrett-eclipse]

It might be useful to have that link supply a param to indicate the user is going to look at changes to the suggested privacy text maybe 'update-review=true' and from the Privacy Guide when that param is supplied it highlights all content changes that have occurred. I guess this would require possibly storing the users last time viewing the page so that a diff could be done. or at very least if we can tell if it's core or a specific plugin texts that changed maybe we could just highlight by section.

[desrosj]

Worth noting that when a plugin is disabled, you are informed on the Privacy Guide which chunks may be unnecessary now.

[garrett-eclipse]

Nice, That approach would be wonderful for noting the updates as to what section the changes apply to and when the changes occurred if that information is available.

[javorszky]

@idea15 brought this to my attention while I was working on #44669. My question there was "why are we storing the entire text and everything along with it in meta instead of storing a hash of the last content and comparing that?", however if diffs are an enhancement, then that would make sense.

A few other questions:

• would it make sense to create an internal hidden post type for these and add the different versions of the suggested privacy notice texts to those? That way the built in diff utility that revisions uses could be reused.
• for different plugins an internal taxonomy could be used with taxonomy slugs as the theme / plugin slugs (with a special one for WP internal)
• that also means that we could store the array of IDs of this hidden post type against the privacy policy page on the meta thereby reducing the amount of data that's getting stored in the postmeta table
• versioning could be done according to date, or, potentially according to version number of core / plugins. That way one wouldn't need to figure out "what version of core was installed on 8th September 2018 at 15:43?"

[garrett-eclipse]

Replying to javorszky:

@idea15 brought this to my attention while I was working on #44669. My question there was "why are we storing the entire text and everything along with it in meta instead of storing a hash of the last content and comparing that?", however if diffs are an enhancement, then that would make sense.

This makes sense, maybe as a dictionary of hashes so core can flag/hightlight individual sections that've changed.

Replying to javorszky:

A few other questions:

• would it make sense to create an internal hidden post type for these and add the different versions of the suggested privacy notice texts to those? That way the built in diff utility that revisions uses could be reused.
• for different plugins an internal taxonomy could be used with taxonomy slugs as the theme / plugin slugs (with a special one for WP internal)
• that also means that we could store the array of IDs of this hidden post type against the privacy policy page on the meta thereby reducing the amount of data that's getting stored in the postmeta table
• versioning could be done according to date, or, potentially according to version number of core / plugins. That way one wouldn't need to figure out "what version of core was installed on 8th September 2018 at 15:43?"

I wonder if this advanced functionality of versioning and the ability to diff would make more sense as a plugin.

[garrett-eclipse]

Related - #44669

Additional thoughts & discussion from #core-privacy & summary on related ticket.
Slack Discussion during #core-privacy - ​https://wordpress.slack.com/archives/C9695RJBW/p1553715331537600
Comment on related ticket - https://core.trac.wordpress.org/ticket/44669#comment:26

Summary;
Core already has diff functionality which can be leveraged
Open Question: Should we gather 'all' revisions of the privacy policy guide like proper post types or just compare the previous to the current.
*There's pros and cons to both so feedback welcome either way.

[garrett-eclipse]

Additional feedback from @timhibberd was posted to 44669#comment:28:

My 2 cents worth regarding your open question is as follows:

1) Manually Created Change Excerpt with a link to an auto-generated page delta:

Privacy page administrator should have an excerpt box to manually summarise the privacy page changes from an end-user impact perspective (like a Git Commit comment). It is common in the industry for end-users to receive a privacy document change summary in addition to the revised privacy document. A changed privacy document will show what has changed but does not necessarily instruct the reader as to the impact of the changes...the "why". The change notice excerpt presented to the user would have a link to the auto-generated page delta.

2) Changes should be aggregated from the last time the user logged in. If a user does not log in for a while and multiple changes have occured then the user should be presented with all the changes since they last logged in.

3) I am assuming that the privacy page notice will appear as banner bar and / or via API so the theme designer can present it in a theme-appropriate fashion and in an accessibility conformant fashion? Displaying a notice on the admin dashboard would only be of value to site administrators on a multi-site network. None of the client sites I manage show any of the admin constructs to end-users (e.g. no toolbar). So I would anticipate hooking a callback function to present the privacy change info to the user in an appropriate spot on the page they are looking at when they log in.

Thanks for all your hard work. Much appreciated :-)

[paaljoachim]

What is needed to move this ticket onward?
Thanks!