WordPress.org
Get WordPress

Make WordPress Core

Changes between Version 2 and Version 4 of Ticket #51188


Ignore:
Timestamp:
08/30/2020 01:38:57 PM (5 years ago)
Author:
carike
Comment:

The only use case that is being mentioned here (the offering of a newsletter) will actually not make use of the Consent API.

Not as per current compliance / newsletter plugins, but it is definitely a conceivable use case. One of the core WordPress coding philosophies is extend-ability. We should leave room for developers to innovate, while still respecting user's consent choices.

All the other use cases I can think of, all make use of the 5 initial purposes.

Let's say a site hosts third party videos and offers their registered users the option to subscribe to notifications. But some of these third parties upload ten or fifteen videos a day and this is causing all sorts of issues like e-mails being marked as spam because of the high volume of very similar messages - so they want to give users the ability to have more granular control over their notifications, rather than simply have an AI decide their preferences for them. This isn't quite marketing and it isn't quite functional. I'd personally regard notifications as preferences, but regardless of the classification, a nested hierarchy makes a Consent API much more useful.

We should be future-proofing this feature.

Adding sub-consent types and a nested hierarchy will only add extra complexity to the API and to core .

Could you perhaps give a practical example of this? I do not see how a nested hierarchy would be incrementally significantly more complex than an array of only five consent types - as there already need to be functions to alter the boolean values for the five consent types (add / remove consent), as well as to retrieve a consent value - and the meta value for caps in the db already present a nested hierarchy, but I may be missing something?

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #51188 – Description

    v2 v4  
    3333However, there are certainly use cases in which site owners / admins may need more granular control.
    3434Let's say, for example, that the website offers a newsletter, but also wants user permission for third party targeted advertising on the website. The site owner may not want to exclude everyone who opts out of the latter from receiving their newsletter.
     35Another possible use case may be notifications. A site owner / admin may not wish to exclude someone from setting their preferred admin colour scheme if they do not wish to consent to notifications.
    3536
    3637It seems that the best way to do this would be to provide a function in Core that would allow plugins to register **sub**-consent types.
    … …  
    4849$consents = array(
    4950   'functional' => array(
    50       'comprehensive' => true
     51      'comprehensive' => true,
     52      'remainder' => true
    5153   ),
    5254   'preferences' => array(
    53       'comprehensive' => true
     55      'comprehensive' => false,
     56      'notifications' => array(
     57         'all' => false,
     58         'daily' => false,
     59         'weekly' => true,
     60         'monthly' => false,
     61         'none' => false,
     62      ),
     63      'remainder' => true
    5464   ),
    5565   'anon_stats' => array(
    56      'comprehensive' => true
     66      'comprehensive' => true,
     67      'remainder' => true
    5768   ),
    5869   'stats' => array(
    59       'comprehensive' => false
     70      'comprehensive' => false,
     71      'remainder' => false
    6072   ),
    6173   'marketing' => array(
    6274      'comprehensive' => false,
    6375      'newsletter' => true,
    64       'targeted_ads' => false
     76      'targeted_ads' => false,
     77      'remainder' => true
    6578   )
    6679);