[wp-trac] [WordPress Trac] #43620: Privacy Policy page design

[WordPress Trac]

#43620: Privacy Policy page design
------------------------------------------+--------------------------------
 Reporter:  melchoyce                     |       Owner:  xkon
     Type:  enhancement                   |      Status:  assigned
 Priority:  normal                        |   Milestone:  4.9.6
Component:  General                       |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  gdpr has-patch needs-testing  |     Focuses:  ui,
                                          |  administration
------------------------------------------+--------------------------------

Comment (by postphotos):

 Replying to [comment:44 grapplerulrich]:
 > In `class WP_Privacy_Policy_Content` I found the variable `$plugin_name`
 and the documentation geared towards Plugins only. I find that mentioning
 only plugins in the documentations and the variables confusing that the
 function can only be used in plugins. This is not the case as
 `wp_add_privacy_policy_content()` is being used for WordPress itself.

 > I could imagine a scenario where a plugin may have multiple privacy
 policies depending on the features enabled. I feel that the adding privacy
 policy content should not be coupled so strongly just to plugins.
 >
 > Instead of plugins terms like application or extensions could be used.

 Hi @grapplerulrich - @xkon pinged me on this and I want to add a few
 thoughts.

 I agree with you both - `$plugin_name` is a little vague if a theme or
 core developer wanted to hook into this, and it's still not really
 addressing the extendability question: A  forms plugin might have a myriad
 of innocuous questions that collection of could be pretty safe, but
 dealing with personal (email, phone, etc.) or financial data (credit cards
 as processed through a third-party, thinking about Gravity Forms for
 example) might have multiple versions of a policy based on what a user has
 already completed. While we don't have to build this complex tool, we
 should support this kind of flow by default.

 ''Outside of the scope of this conversation - we should encourage creative
 usage of this for this kind of scenario: A user may not realize how
 sensitive the data they collect or process is.''

 I propose we rename `$plugin_name` to `$policy_name` (also matching the
 pattern of scope varible `$policy_text`): A slight difference, but makes
 this feel more holistic by terminology. (I feel the terms "extension" and
 "application" is too vague here, so call it what it is.)

 I also suggest we register a `$policy_kind` to specify whether it's a
 `theme`, `core` or `plugin` making this request for future organization in
 UI if we ever choose to do so and is just a bit cleaner architecturally.
 :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43620#comment:49>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform