Upgrade document developers – Complianz 6.0
This document will explain our migration towards a new consent structure, and what you can do as a developer to integrate with Complianz 6.0 and/or change current integrations already developed.
Current Consent Management
Complianz prefers to handle all consent actions with javascript functions and/or hooks. Using PHP has the risk of issues with cached pages, where the PHP is not executed.
There is also a shortcode , which contains the option to redirect with a parameter, fixing any caching issue that might occur.
Since 6.0, several hooks have been renamed or dropped. You can find all dropped or changed hooks in cookiebanner/js/migrate.js. Since 6.0, more info is passed to these hooks, and several new functions have been made available to third parties.
By default, Complianz will activate the complianz migrate.js shipped with the plugin if the plugin was used with a version < 6.0. If a user does not need any of the integrations, or if you have upgraded your integrations, they/you can disable migrate.js in the settings.
New Consent Management
Below you will find the new set-up for Complianz 6.0. It focuses on developing an integration directly in Complianz whereby you can configure a placeholder, detectable service, dependencies and add the desired scripts to a block list that get fired based on the appropriate category.
We recommend not using cookie variables to handle consent. Cookies can have different prefixes (e.g. on multisite root, a cookie may have the cmplz_rt_ prefix). For good measure this the mapping of old and new cookies:
Complianz 5.* | Variable | Complianz 6.* | Variable |
cmplz_choice | set,empty | cmplz_status_saved_once | true, empty |
cmplz_consent_status | allow, deny, empty | dropped | |
cmplz_statistics-anonymous | allow, deny,empty | dropped |
Cookies in use from 6.0 onward
Cookie | Variable |
cmplz_functional | allow, deny, empty |
cmplz_preferences | allow, deny, empty |
cmplz_statistics | allow, deny, empty |
cmplz_marketing | allow, deny, empty |
cmplz_policy_id | current accepted cookie policy version |
cmplz_consented_services | list of services which are allowed or denied |
session storage | |
cmplz_user_data | banner configuration for this user |
Premium | |
cmplz_id | tracking consent for records of consent, AB testing |
cmplz_saved_categories | used to check if an update signal has to be passed for records of consent or a/b testing |
cmplz_saved_service | used to check if an update signal has to be passed for records of consent or a/b testing |
TCF | |
usprivacy | TC string for US CCPA |
Local storage | |
cmplz_tcf_consent | tc string for TCF |
New filters
cmplz_statistics_script_classes, array of classes | cmplz_statistics_category, string category |
cmplz_script_class | cmplz_service_category |
Data attributes for services requiring consent
In the previous version, services requiring marketing consent got the class “cmplz-script”, and services requiring statistics consent got the class “cmplz-stats”. Scripts that should not get blocked got the class “cmplz-native”.
As of 6.0, this has changed to a data attribute with the category that is required. Additionally, a service can be enabled by service, if the service name is available. This means that the classes are changed as follows:
class=”cmplz-native” | data-category=”functional” |
class=”cmplz-stats” | data-category=”statistics” |
class=”cmplz-script” | data-category=”marketing” |
Some examples:
// Consent Attributes