Category “preferences” missing in the modal for custom consent

Hi @alekv,

Thank you for reaching out to us about this. I hope all is well.

The “Preferences” category will be included on the Complianz banner if any of the following conditions are true.

– Consent per Service has been enabled (Complianz -> Wizard -> Consent -> Services -> “Do you want to use ‘Consent per Service’?)
– Consent Mode has been activated in the Complianz (Premium) Wizard (Complianz -> Wizard -> Consent -> Statistics – configuration)
– The WP Consent API plugin is installed and activated

/**
     * Check if the site uses preferences cookies
     *
     * @return bool
     */
    function cmplz_uses_preferences_cookies()
    {
        return cmplz_consent_mode() || cmplz_consent_api_active() || cmplz_get_option( 'consent_per_service' ) === 'yes';
    }

Let me know what you think.
Kind regards, Jarno

Complianz is setting the preferences cookie even without those conditions enabled.

It sets the preferences when clicking on the Dismiss button: https://cln.sh/prDjHR23

It sets the preferences when clicking on the Dismiss button: https://cln.sh/FhQKFYBP

The same is true for the JavaScript event cmplz_fire_categories that’s triggered when clicking on one of the buttons.

On Accept: https://cln.sh/qC8PHY8r
On Dismiss: https://cln.sh/1QVWGYRn

So it would make sense to include preferences into your custom modal to avoid the inconsistency I described in my first post.

Or, set preferences always to “allow” in case your conditions to include them are not met.

@alekv The preferences option is added when the WP Consent API is installed, Consent Mode is enabled, or consent per service is enabled. Complianz can’t block preference cookies to get set unless there is a dedicated integration (not separately from marketing cookies from example, because you need to block the entire js, or prevent php cookies to get set), but if the WP Consent API is installed, each plugin that integrates with the WP Consent API can check the api if consent is given or not. If consent per service is enabled, the built in cookie shredder can clean up any cookie that doesn’t have consent. Consent Mode has it’s own way of handling categories.

If I’m correct, you currently have an integration with the WP Consent API, so installing it would resolve the issue out of the box.

Another option would be for us to offer the preferences category always, like you suggested, but we have refrained from that, as it in most cases suggests a false control over preferences cookies. Only if a dedicated integration is available, like in your case, would this do anything real.

Let me know what you think.

In addition to the previous: the preferences cookie is always set, because it is part of the default categories structure. As the situation that you describe only causes an issue if there is a direct integration, I’ve never come across this before.

But I will discuss the consequences of setting the preferences cookie to true if the preferences category is not present on the banner. However, this would add complexity to the code that I’m not really fan of.

Isn’t it a better solution to suggest users to install the WP Consent API?

If I’m correct, you currently have an integration with the WP Consent API, so installing it would resolve the issue out of the box.

Yes. But we want to give the website owners the choice to use whatever CMP they like. At least that’s true for CMPs that use a standardized way of handling the consent. For all others, we offer our Pixel Manager Consent API to instruct the Pixel Manager how to handle the consent: https://sweetcode.com/docs/wpm/consent-management/api

Another option would be for us to offer the preferences category always, like you suggested, but we have refrained from that, as it in most cases suggests a false control over preferences cookies. Only if a dedicated integration is available, like in your case, would this do anything real.

Or, you don’t set the preferences cookie at all, and don’t send the preferences signal in the JS event, as long as not one of your conditions are met to enable preferences.

In that case I could make an assumption in the Pixel Manager, and let’s say, always set preferences to “allow”, until Complianz sends that signal.

(You would also have to add a value “allow” or “deny” or true or false to each JS event category. Currently, you add them to the category array but not as key-value pairs. This doesn’t clearly state if preferences have been enabled in your settings or not).

In addition to the previous: the preferences cookie is always set, because it is part of the default categories structure. As the situation that you describe only causes an issue if there is a direct integration, I’ve never come across this before.

Yeah, that’s probably because no one has examined it as closely as I have in the past weeks.
Or they have adjusted their tracking code manager to the specific website.

But for a standardized interface, as we need for the Pixel Manager, you need to standardize the Complianz output just a little more.

• This reply was modified 7 months, 2 weeks ago by alekv.

We’ll look into it. As a major change is coming up in version 8, I’m not sure it’ll be added before 8.0. After that, any integration will probably be updated anyway.

Great. I’m looking forward to version 8.0