-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further changes required for GDPR compliance #131
Comments
I first raised a request concerning this, perhaps without giving full consideration to GDPR requirements: #23 What I think I'd like to see is:
|
Hmm interesting, so @joepagan and @iparr we'd need something like: $iframe = $dom->getElementsByTagName('iframe')->item(0);
$src = $iframe->getAttribute('src');
$src = $this->manageGDPR($src);
if (Oembed::getInstance()->getSettings()->enableGdpr) {
$iframe->setAttribute('data-cookieblock-src', $src);
$iframe->setAttribute('data-cookieconsent', 'marketing');
} I do a ton of backend the past year or two, ML stuff, so don't follow GDPR much. |
Updated v3.0.3 with new changes with a new setting to support. |
It looks like this update will set 'data-cookieblock-src' in addition to the 'src' attribute, though the Cookiebot implementation removes the 'src' attribute. It would be great if we could also display a placeholder before or after the iframe-tag
This is the original Cookiebot page: |
@paulwaddington is correct RE cookiebot, it would needed to remove the I wrote a solution which removes the public function addConsentChecksToEmbed(string $code): string
{
try {
$dom = new DOMDocument();
// Disable errors - TikTok puts a <section> in a <blockquote> for some reason which raises a PHP warning
libxml_use_internal_errors(true);
$dom->loadHTML($code);
libxml_use_internal_errors(false);
// Ensure there is a root level element
$body = $dom->getElementsByTagName('body')->item(0);
$childNodes = iterator_to_array($body->childNodes);
// Get the nodes under body which are elements
/** @var DOMElement[] $childElements */
$childElements = array_filter(
$childNodes,
fn (DomNode $node): bool => $node instanceof DOMElement,
);
if (count($childElements) === 1) {
$root = $childElements[0];
} else {
// Wrap the elements in a div
$root = $dom->createElement('div');
if (!$root) {
Craft::error('Could not create root element', __METHOD__);
return '';
}
foreach ($childNodes as $child) {
$root->appendChild($child);
}
$body->appendChild($root);
}
/** @var DOMElement $script */
foreach($dom->getElementsByTagName('script') as $script) {
$script->setAttribute('data-cookieconsent', 'marketing');
$script->setAttribute('type', 'text/plain');
}
/** @var DOMElement $iframe */
foreach($dom->getElementsByTagName('iframe') as $iframe) {
$iframe->setAttribute('data-cookieconsent', 'marketing');
$iframe->setAttribute('data-cookieblock-src', $iframe->getAttribute('src'));
$iframe->removeAttribute('src');
}
return $dom->saveHTML($root);
} catch (DOMException $e) {
Craft::error($e->getMessage(), __METHOD__);
return '';
}
} I'm currently using that in a Craft module with {{ craft.videoEmbed.addConsentChecksToEmbed(entry.myField.embed(oEmbedOptions).code)|raw }} |
@MangoMarcus If you have a working local solution please send a PR I'd be happen to give it a look and test. If all good I'll merge it through 🍻 |
Hey @reganlawton Just checking if any progress has been made here? We have several customers complaining about compliance issues |
@D3VM4TT I throw together a quick branch of @MangoMarcus code you can try testing using dev-feature/consent-checks branch in composer. |
Hey, this is a great plugin! I would love to use it but I think some more changes are required to make it GDPR compliant.
It appears the plugin will:
However, these changes do not consider cookies which may load from all over services which your plugin supports like an embedded tweet for example which will also load marketing cookies.
A GDPR setting implies being compliant when it might not be, especially where other services like twitter might be used which may load cookies via a different method.
Suggested solution
Having only really worked with CookieBot as a solution I feel their approach is good, but as it's not a standard approach though giving us access to do the following I think is cookie-blocking service ambiguous enough? Though I can't really comment on what the other services require.
Here is an example that is compliant with CookieBot
Where if marketing cookies are accepted, the
data-cookieblock-src
updates to asrc
attribute.So maybe it would be best to give devs the opportunity to disable the src attribute so they can do this.
RE how to handle other services
If a
script
element is responsible for create an iframe element like a tweet used to (not sure if that's what happens anymore), we can perform a similar change:where the
type
attribute changes on accepting.Though of course this requires extending the twig variables a bit more if that's something which could be considered?
The text was updated successfully, but these errors were encountered: