DivasCookies Plugin for MODX Evolution

DivasCookies EU Cookie Law Policy Banner Plugin for MODX Evolution
http://www.tattoocms.it/extras/plugins/divascookies-plugin.html
https://github.com/Nicola1971/DivasCookies-Plugin


Based on DivasCookies script by Coding Divas
http://www.codingdivas.net/
http://www.codingdivas.net/divascookies/

Plugin Configuration
Divas Configuration Options

Banner Text: text for the Divas Cookies banner
Policy Link: link to the extended cookie policy
Policy Link Text: text for the link to the extended cookie policy
Third Party Policy Widget: if set to "iubenda" tries to use the Iubenda widget
Accept Button Text: text for the close button
Accept Button Src: source for the close button image
Open Effect: opening effect for Divas Cookies banner ["fade", "slideUp", "slideDown", "slideLeft", "slideRight"]
Open Effect Duration: duration of the opening effect (msec)
Open Effect Easing: easing for the opening effect
Close Effect: closing effect for Divas Cookies banner ["fade", "slideUp", "slideDown", "slideLeft", "slideRight"]
Close Effect Duration: duration of the closing effect (msec)
Close Effect Easing: easing for the closing effect
Use Debug Mode: if true, the options are checked and warnings are shown
Save User Preferences: if true, sets a cookie after the Divas Cookies is closed the first time and never shows it again
Cookie Duration (days): number of days after which the Divas Cookie technical cookie will expire (default 365 days)
Block Scripts: set this to true if you blocked scripts by wrapping them with if($.DivasCookies.optedIn())
Page Reload: if true reloads the actual page after opt-in to show the previuosly inline blocked scripts
Accept On Scroll: if true sets the Divas Cookie technical cookie on page scroll for cookies agreement
Accept On Click: if true sets the Divas Cookie technical cookie on click on any in the page except that on Divas Cookies banner for cookies agreement

Additional MODX Evolution Configuration Options

Place Divas js code before closing tag: place divas js inside HEAD or BODY tag
Load jQuery js: load jQuery (if you don't use jQuery in your templates)
jQuery Path: path to jQuery library
Divas Js Path: path to Divas Js
Divas Skin path: path to Divas CSS Skin
Static js Configuration file: Static js configuration file (overwite plugin configuration)
Static Configuration file path: path to js configuration file

Thanks for sharing

I have been playing with this today and came across (in my opinion) a couple of problems:

The plugin package has an install folder, yet there is no installer code - the plugin has to be created per hand using the code found in the "DivasCookies.tpl" - if you don't know what to do with the code you won't know that the plugin configuration has to be copied from the commented out code.

Once the plugin is installed you have to hard code the url for the cookies page - meaning, you can't use MODX link tags in form of "[~1~]", as they are not rendered.

The second problem with the URL: if you are using FURLS, the plugin is site-wide and obviously runs on every page of the site, so you have to use a full URL, as in "h--p://www.domain.com/cookies.html" or something similar, otherwise, depending on how deep you are in the FURLs, you might be taken to a page that doesn't exist, example "h--p://www.domain.com/blog/cookies.html". (-- = tt : removed as the forum creates a full link)

A further problem which should be documented is that the configuration overrides the CSS by adding inline styles. This took me a while to figure out because I simply couldn't find why the CSS didn't work.

If you use the "divascookies_style_custom.css" it is set to have the bar fixed to the bottom of the page, if you configure the plugin to slide from top to bottom (openEffect = slideDown) or vice versa it adds styling inline. So the inline code could be something like:

which is the opposite to that what is pre-defined in the CSS file, which makes life confusing - this obviously also has an effect on the "closeEffect" setting.

My opinion: If one setting is made the other should be automatically set and the styling should not be pre-set in the CSS file if inline styling is being added anyway.

I have removed this plugin from my site and now use the original files from codingdivas. It is less work to add it as hard coded files, rather than having to manualy install the plugin and then have to configure it for each individual site [ed. note: iusemodx last edited this post 8 years, 9 months ago.]

Quote from: iusemodx at Jul 28, 2015, 08:12 PM

The plugin package has an install folder, yet there is no installer code - the plugin has to be created per hand using the code found in the "DivasCookies.tpl" - if you don't know what to do with the code you won't know that the plugin configuration has to be copied from the commented out code.

To install this plugin you need Package Manager! With the package manager, the plugin installation takes a few seconds
Otherwise it is easier to integrate the script jquery

Quote from: iusemodx at Jul 28, 2015, 08:12 PM

Once the plugin is installed you have to hard code the url for the cookies page - meaning, you can't use MODX link tags in form of "[~1~]", as they are not rendered.

Right. There is no support to modx links tags. Sorry

Quote from: iusemodx at Jul 28, 2015, 08:12 PM

The second problem with the URL: if you are using FURLS, the plugin is site-wide and obviously runs on every page of the site, so you have to use a full URL, as in "h--p://www.domain.com/cookies.html" or something similar, otherwise, depending on how deep you are in the FURLs, you might be taken to a page that doesn't exist, example "h--p://www.domain.com/blog/cookies.html". (-- = tt : removed as the forum creates a full link)

Are you sure? It should not happen if you use base_url in your template

Check out the cookie bar on this page http://www.tattoocms.it/extras/packages/seo4evo.html
The path to the policy page it's ok

Quote from: iusemodx at Jul 28, 2015, 08:12 PM

A further problem which should be documented is that the configuration overrides the CSS by adding inline styles. This took me a while to figure out because I simply couldn't find why the CSS didn't work.

If you use the "divascookies_style_custom.css" it is set to have the bar fixed to the bottom of the page, if you configure the plugin to slide from top to bottom (openEffect = slideDown) or vice versa it adds styling inline. So the inline code could be something like:

<div style="bottom: auto; display: block; top: 0px;" class="divascookies">

which is the opposite to that what is pre-defined in the CSS file, which makes life confusing - this obviously also has an effect on the "closeEffect" setting.

My opinion: If one setting is made the other should be automatically set and the styling should not be pre-set in the CSS file if inline styling is being added anyway.

I agree
Yes the script configuration overrides the styles

I think that css styles should not include the position of the banner, but only its appearance (background, fonts and colors)


Quote from: iusemodx at Jul 28, 2015, 08:12 PM

It is less work to add it as hard coded files, rather than having to manualy install the plugin and then have to configure it for each individual site</div>

As I said above: you need Package Manager or Store modules

Quote from: banzai at Jul 29, 2015, 11:18 AM

To install this plugin you need Package Manager! With the package manager, the plugin installation takes a few seconds
Otherwise it is easier to integrate the script jquery

Maybe that should be in the documentation, so that users know they need to have package manager installed first

Quote from: banzai at Jul 29, 2015, 11:18 AM

Quote from: iusemodx at Jul 28, 2015, 08:12 PM

The second problem with the URL: if you are using FURLS, the plugin is site-wide and obviously runs on every page of the site, so you have to use a full URL, as in "h--p://www.domain.com/cookies.html" or something similar, otherwise, depending on how deep you are in the FURLs, you might be taken to a page that doesn't exist, example "h--p://www.domain.com/blog/cookies.html". (-- = tt : removed as the forum creates a full link)

Are you sure? It should not happen if you use base_url in your template

I haven't used base_url in years, I use the Web Root Relative Hrefs plugin - didn't think about that as I posted, so yes, you are right, using the "base href tag" with either "base_url" or "site_url" it would work.

For more info you can take a look here

Quote from: iusemodx at Jul 29, 2015, 12:08 PM

Maybe that should be in the documentation, so that users know they need to have package manager installed first

Done

Quote from: iusemodx at Jul 29, 2015, 12:08 PM

I haven't used base_url in years, I use the Web Root Relative Hrefs plugin - didn't think about that as I posted, so yes, you are right, using the "base href tag" with either "base_url" or "site_url" it would work.

I did not know about this plugin, thanks.

Without base_url, I think you can still use the full absolute url to the policy page in the plugin configuration.
Anyway thanks for your suggestions

I've update the plugin a bit:

New 1.0.6 RC2 with:

* Moved Divas package from assets/plugin to assets/js
I've recently received an alert from Google Wembaster Tools about some styles and js non indexable, because MODX robot.txt disallow assets/plugin folder.

* New plugin option Load Divas Skin css (yes/no) to disable divas ccs skin (so you can add/merge Divas styles inside your default theme css)

* Removed some not needed styles from default custom css (bottom:0;)

Updated docs and download
http://www.tattoocms.it/extras/plugins/divascookies-plugin.html
https://github.com/Nicola1971/DivasCookies-Plugin