pressidium

Hey, @bfx72!

It seems likely that the issue you’re encountering is due to your theme’s stylesheets overriding the plugin’s styling.

Would you mind switching your theme temporarily to Twenty Twenty-Four, or a similar one, and letting us know if the problem persists?

Hey, @zudie!

It sounds like gtag.js is completely blocked because it’s listed under the “Blocked Scripts” tab.

To use the advanced version of Google Consent Mode, ensure gtag.js is not blocked. This allows the Google Tag to load with defaults set to denied, or as specified in the “Consent Mode” tab, and adjust its behavior based on user consent.

Try removing the Google Tag from the “Blocked Scripts” tab while keeping Google Consent Mode enabled. Then, use Google Tag Assistant to check your configuration.

Let us know if this resolves your issue.

Hey, @allmyhoney!

?? Wiki docs: https://github.com/pressidium/pressidium-cookie-consent/wiki

how to find and fill in the right cookie information under cookies tab?

We’re in the process of documenting that. I’ll keep this topic open and keep you in the loop.

Also how the blocked scripts tab works?

Take a look at the Blocking scripts page of our wiki. If you have additional questions, please let us know so we can update our docs.

Hey, @valentinanamorphik!

The plugin doesn’t currently support blocking iframes. However, it’s something we’re considering for a future iteration.

You can stay up-to-date on the progress of this feature, by checking #38 (Manage iframes) on the plugin’s GitHub repository.

Hey, @otma77!

It seems likely that the issue you’re encountering is due to your theme’s stylesheets overriding the plugin’s styling.

Would you mind switching your theme temporarily to Twenty Twenty-Four, or a similar one, and letting us know if the problem persists?

Hey, @karolina01!

This is currently not supported by our plugin, but it’s on our roadmap. You can follow its progress in issue #62 on the plugin’s GitHub repository.

I’ll keep this topic open, and I’ll make sure to keep you posted along the way.

Hey, @allmyhoney!

I’ve checked your website on both Firefox and Google Chrome, but I couldn’t reproduce the issue. It’s possible that a browser extension is interfering with cookie settings.

Would you mind testing it on a different browser, ideally without any browser extensions installed?

Hey, @smartjb!

This is already on our radar. We’re tracking its progress in #61 on the plugin’s GitHub repository.

We’ll refine the options available within the language select field in a future iteration of the plugin.

Thanks for your understanding and patience.

Hey, @alexgraphicd!

There is no way to “scan” the cookies your application might set to clients […]

You need to either know the full codebase […]

No external “cookie scanning” tool can ever be 100% correct.

still messes up the scanning, identify them properly or even have proper translations – i.e. there’s no 100% perfect scanning tool, it’s just not how it works.

As both @ianap and @nikodemsky correctly pointed out, no external tool can ever be 100% accurate. Though, there are tools available that can identify the majority of, if not all, cookies for some websites — their effectiveness may vary depending on the specific website in question.

it doesn’t help us identify cookies accurately

We recognize the potential benefits of a cookie scanning mechanism and we’ll explore implementing our own in a future iteration. For now, you could use your browser’s DevTools to manually list cookies.

or at least suggest a 3rd party tool

Given our limited exposure to third-party automated cookie scanning tools, we’re unable to provide a specific recommendation.

how the heck do I know which way to categorize them in Pressidium settings? Necessary, Analytics, Preferences etc.

For cookies set by the developer of the website through their code, they’re likely familiar with their intended purpose and the appropriate category they belong to.

For cookies set by third-party plugins and/or services, you could consult their documentation (e.g. WooCommerce maintains a dedicated page on its docs about its cookies), or search online for the cookie name to gather relevant information.

There are many cookie collections online that cover the most commonly used services like Google Analytics, Facebook Pixel, etc., which can assist in identifying the cookies they set.

By the way is there a proper documentation for this plugin?

Sure! Take a look at the wiki at https://github.com/pressidium/pressidium-cookie-consent/wiki.

What is the ‘Regex’ toggle option in settings?

Check out the “Cookies” and “Blocked Scripts” sections, under the “Configuration” page of the wiki:

• Cookies
• Blocked Scripts

From the plugin’s documentation:

Note that the cookie names can be either exact matches or regular expressions (if you select the “Is Regex?” toggle).

You could also use a regular expression. For example, to block any script on the *.google-analytics.com domain, you could use:

^(?:https?:)?\/\/(?:www\.)?google-analytics\.com

Regular expressions are strings of characters used to define a match pattern. Writing a pattern allows you to match multiple cookies and/or script URLs, which can be quite helpful. However, they do require a certain level of technical expertise, and if you’re not comfortable with them, you don’t have to use them.

Note that regex101 is a great resource to test and understand your regular expressions.

I hope that answered your questions. If there’s anything else you’d like to know, feel free to create a new topic or open an issue on GitHub.

Thanks for following up! It’s good to know that everything is resolved.

REST API namespace? What is it?

Our plugin’s REST route namespace is set to pressidium-cookie-consent/v1. You may also consider using the broader pressidium-cookie-consent.

Hey, @ashishtiwari27!

As mentioned before, our support scope doesn’t include site-specific assistance.

However, I took a look at your website and it seems that the REST API has been disabled.

When our plugin sends a request to the POST /wp-json/pressidium-cookie-consent/v1/consent endpoint, your installation responds with a 401 Unauthorized error.

{
    "code": "rest_authentication_error",
    "message": "Sorry, you do not have permission to make REST API requests.",
    "data": {
        "status": 401
    }
}

I noticed that you’ve installed the “Perfmatters” plugin, which includes a “Disable REST API” option. It’s possible that either that plugin, or another third-party plugin, has disabled access to the REST API for non-logged in users.

This leads me to believe that the issue extends beyond just clicking the “Reject all” button, but rather, there are no consents being recorded for users who aren’t logged in.

Given that this appears to be an issue unique to your particular setup, I’ll mark this as resolved.

If you come across any other issues, feel free to create a new topic or open an issue on GitHub.

Hey, @ashishtiwari27!

Hi, when a user press or clicks on Reject All button, this rejection is not recording in the backend admin panel (but rest others are saved)

Even when clicking the “Reject All” button, the necessary cookies are still accepted, so the consent should still be recorded.

I’ve just tested it and couldn’t replicate the described behavior. Could you please provide the exact steps needed to reproduce the issue?

Further its user’s choice whether he want analytics or advertisement – he can uncheck that later. Why I give him unchecked?

Among others, consent must be freely given, must be granular (i.e. users must be able to consent to some cookies rather than others), and it must be unambigious.

According to GDPR Recital 32:

Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. Consent should cover all processing activities carried out for the same purpose or purposes. […]

GDPR Recital 32 (emphasis mine)

So, using a pre-ticked box won’t be enough to comply with the General Data Protection Regulation (GDPR).

how to make Analytics and Advertising checkboxes default ‘Yes’ enabled, as currently only strictly necessary box is enabled by default

Our plugin requires “Opt-in consent,” meaning users have to actively and explicitly agree to data collection and processing.

We could provide an option for “Opt-out consent” instead, which wouldn’t require users to provide explicit consent before their data is collected and processed. However, implementing this would necessitate more granular settings to allow for different consent modes—opt-in or opt-out—depending on users’ regions. Currently, our plugin doesn’t offer this feature.

I’ve opened an issue on the plugin’s GitHub repository to consider implementing that in a future iteration of the plugin. You can stay up-to-date on the progress of this feature, by checking #62.

(Because it impacts analytics)

If you’re using Google Analytics (GA), you could enable Google Consent Mode (GCM) which is going to use cookieless pings while consent is denied.

Hey, @alexgraphicd!

We haven’t had the chance to test automated cookie scanning tools, so I’m afraid we’re unable to suggest any at the moment.

I’ll mark this as resolved, since it’s a bit out the plugin’s current scope. However, you’re welcome to discuss potential cookie scanning tools that may work for you.

If you come across any other issues, feel free to create a new topic or open an issue on GitHub.

Thanks for following up! It’s good to know that everything is resolved.

If you come across any other issues, feel free to create a new topic or open an issue on GitHub.