First of all i would like to thank Limoengroen for this great module.
We needed it to cope with this bureaucratic legislation.
Issue:
The rijksoverheid-cookie-opt-in library does not respect html5 doctype due to that it does more then it's designed to do.
Therefore it only works on xml:lang document headers
As stated in line 400 of libraries/rijksoverheid-cookie-opt-in/behaviour/cookies.js
langCode = $("html").attr('xml:lang');
this.langCode = langCode.toUpperCase();
This javascript is not escaped and therefore it breaks many other jquery / javascripts
Naturally the same flaw is in the minified version that the module uses.
Temporary fix is use a XML based header:
Copy the html.tpl.php from /sites/all/themes/omega/omega/templates/html.tpl.php to your_theme/templates/html.tpl.php
and change:
html lang="<?php print $language->language; ?>" dir="<?php print $language->dir; ?>"
into
html lang="<?php print $language->language; ?>" xml:lang="<?php print $language->language; ?>" dir="<?php print $language->dir; ?>"
related issues that can be closed when exceptions for this language redundancy for html5 doctype are included / filtered out:
Flexslider stops working and Cookie warning only display when overlay is active
Obviously this issue would be the same with HTML5 themes other then Omega.
Comments
Comment #0.0
florisg commentedmore clarity for temporary fix
Comment #0.1
florisg commenteddouble is
Comment #0.2
florisg commentedcleanup
Comment #1
dbazuin commentedI can confirm this.
Comment #2
marty2081 commentedThanks for raising this as an issue and providing the workaround for Omega-based (or HTML5) themes. I already put a line on the project page saying the RO Cookie Opt-In library expects the xml:lang attribute on the html element. We will contact the developers of the library to inform them of the issue and ask if they can provide a better way of handling this.
Comment #3
marty2081 commentedI added a 'dirty' workaround: before intializing the cookiebar I check if the xml:lang attribute is set. If it is not set, I add it with the value of the lang attribute so that the library keeps working. As soon as the issue is fixed in the library itself I will remove the workaround again. The fix is in the dev branch. Can someone take a look and see if this really works for Omega-based / HTML5 themes?
Comment #4
Anonymous (not verified) commentedI would also like to know if this is bug-free for HTML5/responsive themes.
Comment #5
dbazuin commentedThe dirty workaround works.
Also the change setting block works fine and the other small bug where when accept the wrong text appears.
looks like a winner to me :-)
Comment #6
marty2081 commentedThanks for the review. I just released 7.x-1.2 containing the workaround.
Comment #7.0
(not verified) commentedother omega.