Cookie Consent

An extended integration of orestbida/cookieconsent with support of the Google Tag Manager.

• :white_check_mark: Easy configurable GTM template
• :white_check_mark: Configurable storages standardized by Google
• :white_check_mark: Possibility to synchronize consents between more storages
• :white_check_mark: Default translations

Table of contents

• Integration into the GTM
• Configuration
• Settings modal trigger
• Triggering tags based on the consent
• Accessing the wrapper in the JavaScript
• Integration with CMP application
• How the GTM integration works
• How to update already published container
  • Migration from v0.4 to v0.5
• Development
• License

Integration into the GTM

Open Google Tag Manager web administration and select a container for your website. Next, go through the Templates link in the left navigation and click on the button New inside a section Tag Templates.

All you need is a file gtm_template.tpl from the root directory of this package. Download the file and import it in the Template editor:

After successful import click on the button Save, leave the Template editor, and go through the Tags link in the left navigation. Then create the new tag with the imported Template, as trigger set an option Consent Initialization - All Pages and save it.

Now you can open a preview of the website and as you can see the cookie widget is here! But let's configure it a bit.

Configuration

:exclamation: Locking the package version is highly recommended (see the field Package version below) after you successfully configure the template. Avoid using the latest version in production containers!

The plugin is configurable using fields inside the tag definition.

Basic options

Consent & Setting modal options

Both sections contain these fields: Layout, Position, Transition. These settings affect where modals appear and what shape they take. The behavior of the consent modal buttons can be configured through fields Primary button role, Secondary button role (accept necessary cookies or open the settings modal), and Buttons order. See the widget documentation for more details.

The consent modal has also an option Show third button that adds the third button to the modal. If the secondary button's role is Open settings the third button's role is Accept necessary and vice versa.

The settings modal has one special option with the name Settings modal trigger selector. A value of the option can be CSS selector for automatic creation of the trigger button that opens the modal. Check the example.

Cookies options

The following strategies are implemented:

1. Clear all except defined^* - All cookies except those you define in the field Cookie names will be deleted when the user denies any storage.
2. Clear defined only^* - All cookies you defined in the field Cookie names will be deleted when the user denies any storage.
3. Use cookie tables - Cookie clearing is based on cookie tables from the original plugin. Integration of CMP application is required for this option.

^* There is no need to define a name from the Cookie name field because this cookie is never automatically deleted.

Storage options

The following types of storage are available:

• Functionality storage
• Security storage
• Personalization storage
• Ad storage
• Ad user data
• Ad personalization
• Analytics storage

Each storage defines the name of a trigger that will be invoked if the user provides consent. It is not necessary to use or display each storage in the widget. Also, the consent for the storage can be synchronized with the consent of another storage.

Event triggers based on composite consent

As mentioned above, each storage can define a trigger that is invoked when consent with the storage has been granted. In some situations, you may want some trigger to be fired only if the user gives consent with multiple storage types. For example, if you have a trigger called fb_pixel_trigger and you want to fire it only if the user gives consent with the analytics_storage and the ad_stroage. Then your configuration may look like this:

Translation settings

The package comes with the default translations for the following languages:

• English - en
• Czech - cs
• Slovak - sk
• Spanish - es
• French - fr
• German - de
• Bulgarian - bg
• Hungarian - hu
• Polish - pl
• Romanian - ro
• Slovenian - sl
• Finnish - fi
• Dutch - nl
• Croatian - hr
• Italian - it
• Norwegian - no
• Swedish - sv
• Ukrainian - uk

Translations that will be loaded and accessible for the widget are taken from the field Locales. Each locale must be defined on a new line. Alternatively, from version 1.0.0, the URL from which the translations are to be downloaded can also be entered.

In the example above, the default translations for the English language are downloaded and the translations for the German language are downloaded from the URL https://www.example.com/public/cc-translations/de.json. A translation file must always be in JSON format and its name must match a locale.

If you want to rewrite default translations, or you want to add translations for a new locale then you can define them in a table Translations.

Locale detection

Locale detection can be affected with the following fields:

How to manage revisions

The default revision number is 0 and the number can be changed through the field Revision. When you change the value the consent modal will be displayed for all users again. You can define a message that will be displayed in the consent modal's description. If you want to do that define custom translation with the key consent_modal_revision_message and rewrite a translation with the key consent_modal_description. The plugin will replace the placeholder [[revision_message]] in the consent modal description with your revision message.

^{Note: the cookieconsent plugin uses the placeholder {{revision_message}} but this notation is used by GTM for variables so the package comes with the placeholder [[revision_message]] instead.}

Stylesheets

Page scripts