jfeltkamp/cookies_demo

Demo repository as extension of the Drupal module COOKiES.

cookies_demo's Issues

Add / improve comments in cookies_demo.js attach()

https://github.com/jfeltkamp/cookies_demo/blob/master/js/cookies_demo.js

    attach: function (context) {
      var self = this;
      document.addEventListener('cookiesjsrUserConsent', function (event) {
        var service = (typeof event.detail.services === 'object') ? event.detail.services : {};
        if (typeof service[self.id] !== 'undefined' && service[self.id]) {
          self.activate(context);
        } else {
          self.fallback(context);
        }
      });
    }

could need some more comments as explanations what happens when. As this is a starter template, we shouldn't assume the developers knows what happens.

I'd suggest something like this (please see if it's correct or can be improved):

    attach: function (context) {
      var self = this;
      document.addEventListener('cookiesjsrUserConsent', function (event) {
        // cookiesjsrUserConsent event was fired, user made a cookie consent decision.
        var service = (typeof event.detail.services === 'object') ? event.detail.services : {};
        if (typeof service[self.id] !== 'undefined' && service[self.id]) {
          // Consent was given for this service. Heal Knockout:
          self.activate(context);
        } else {
          // Consent was not given or even revoked for this service. Handle Knockout:
          self.fallback(context);
        }
      });
    }

BTW Should there be information on cookiesjsrUserConsent if the consent was revoked not given? Perhaps that might be a separate topic / issue... unsure if it would help to clean up if consent was revoked and for example delete existing cookies etc.

Rename fallback function

Tracking issue for https://www.drupal.org/project/cookies/issues/3293376

Remove jquery from cookies_demo.js

I guess in https://github.com/jfeltkamp/cookies_demo/blob/master/js/cookies_demo.js the jQuery and $ variable can be removed as they are not used.

Instead settings MIGHT be added as second parameter to attach like in the examples here: https://www.drupal.org/docs/drupal-apis/javascript-api/javascript-api-overview to indicate the drupalSettings are available there.

Use text/plain instead of application/jsonto ignore src and its loading?

In
cookies_demo.module

you're using this code:

// The Knock-out. A script tag of type 'application/json' will not be
// executed.
'type' => 'application/json',

to disable execution of an external JavaScript.

I guess it could make sense to use text/plain instead for examples (and perhaps in implementations) like Cookiebot suggests: https://www.cookiebot.com/en/manual-implementation/

As I read here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-type for the "type" attribute:

Any other value: The embedded content is treated as a data block which won't be processed by the browser. Developers must use a valid MIME type that is not a JavaScript MIME type to denote data blocks. The src attribute will be ignored.

This would be nice, if all browsers indeed behave that way and perhaps don't even load the external source.
GDPR hardliners suggest (and I think they're not totally wrong) that you shouldn't even call the remote URL as the remove server could at least track your IP without given consent.

Changing src to data-src doesn't seem possible in Drupals libraries API as it assumes the src to exist.

Before we make that change, we should ensure

1. All / major browsers ignore src if text/plain is used
2. After type is swtched back to application/javascript the code is executed
3. There are no other unexpected side-effects

But if that's the case, it would be a useful change!