Developers guide for Third-Party integrations

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.*VariableComplianz 6.*Variable
cmplz_choiceset,emptycmplz_status_saved_oncetrue, empty
cmplz_consent_statusallow, deny, emptydropped 
cmplz_statistics-anonymousallow, deny,emptydropped 

Cookies in use from 6.0 onward

CookieVariable
cmplz_functionalallow, deny, empty
cmplz_preferencesallow, deny, empty
cmplz_statisticsallow, deny, empty
cmplz_marketingallow, deny, empty
cmplz_policy_idcurrent accepted cookie policy version
cmplz_consented_serviceslist of services which are allowed or denied
session storage 
cmplz_user_databanner configuration for this user
  
Premium 
cmplz_idtracking consent for records of consent, AB testing
cmplz_saved_categoriesused to check if an update signal has to be passed for records of consent or a/b testing
cmplz_saved_serviceused to check if an update signal has to be passed for records of consent or a/b testing
TCF 
usprivacyTC string for US CCPA
  
Local storage 
cmplz_tcf_consenttc string for TCF

New filters

cmplz_statistics_script_classes, array of classescmplz_statistics_category, string category
cmplz_script_classcmplz_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