v1.2.2 -> introduces a failure case (WP_CACHE==true)

Hi Paul,

I don’t have access to Varnish and don’t make use of Analytics, so I’m not completely clear as to the issue. I assume you have removed GA to “script blocking” box in CN’s settings.

My understanding of Cookie Notice is that: scripts that ought not be run until cookies are accepted should be removed (including Google Analytics) from plugins/code and pasted into the “script blocking” text box in CN’s settings.

A “new” visitor (not previously accepted/rejected cookies) is served the page without Google Analytics and any other scripts pasted in CN’s settings. If the visitor then accepts cookies an automatic reload ensures CN re-serves the page with the missing scripts and cookies are set.

Under CCA 1.2.2 if WP_CACHE is set true then the the page is re-requested with “cache busting” query string “cn-reloaded=1” added. Under CCA 1.2.1 which you say worked correctly, the page was still reloaded for all new non-EEA visitors but using the original unaltered URL so:

In “/wp-content/plugins/category-country-aware/cca_textwidget.php“: try replacing the check for WP_CACHE on line 119
$cca_iscached = ((defined( 'WP_CACHE' ) && WP_CACHE) || !empty($GLOBALS['comet_cache_advanced_cache']) ) ? '1' : '0';

with:

$cca_iscached	= ( (defined('WPCACHEHOME') && realpath(WPCACHEHOME)) || !empty($GLOBALS['comet_cache_advanced_cache']) ) ? '1' : '0';

does that solve the issue?

I’ve been rushed and short of time so I’ve still to properly work through CN (not CCA) code and see how (if?) Cookie Notice really works with page caching plugins e.g. if visitor “A” visits uncached page “1” it will be page cached without “blocked” scripts, and on visiting uncached page “2” it will be cached with scripts included(?). New visitor “B” then first lands on page “2” and should be served a version of the page without blocked scripts – but I assume the cached page generated by visitor “A” includes scripts as “A” had already accepted cookies???

• This reply was modified 6 years, 6 months ago by wrigs1.

Thanks for the reply.
Within the staging environment, the replaced line WP_CACHE vs WPCACHEHOME
appears OK. aka, the cn_reloaded=1 only appears on EEA case (initial request). And Analytics’ records OK

Additional information:
– this environment is *not* using CN blocking script facility for GA, perhaps it should
– this environment is using MnnsterInsights Pro (incl. new EU compliance addon)
– this environment is using Autoptimize (excludes inline JS)
– regardless of version, cca_is_eu cookie is *not* set for EEA test case (MAC, Chrome/Safari). On MAC, I am using a VPN for EEA testing.
– regardless of version, cca_is_eu=true cookie is set for USA test case (PC)
– regardless of version, cookie_notice_accepted=true cookie is set for USA test case (PC)

Later today, I will focus some tests on the caching aspects. I am able to bypass the Varnish cache. My previous tests used different URLs, to purposely bypass the cache. But this needs another careful look, as I am concerned about cookie handling for both CN and CCA, and JS handling for Monster and Autoptimize. Lots of places can go awry…

Hi Paul

Thanks for the update.

1. “this environment is *not* using CN blocking script facility for GA, perhaps it should”. From what I’ve read – my understanding is that you should.

In theory users must consent to cookies (including GA) before you serve scripts etc that set cookies. By removing GA code from WordPress and pasting it into CNs text box you ensure it is not served to a visitor who has not consented to cookies i.e. it doesn’t run, set cookies or gather stats. If the visitor then accepts cookies the page is reloaded with GA it “runs” and cookies are set. (use dev tools in your browser to view cookies as they are being set standard CN (EU) ga cookies not set until click accept button – EU cookies not set, blink, cookies set.

Additionally if you are not “script blocking” by relocating GA script to CN settings text box then you are running GA twice, once on first load and again on reload. I assume this will result in double counting and may be the reason for the issue you reported??? (as said before I’m not clear on what you are reporting I don’t make use GA or Varnish). Not for EU visitor CCA has to “force a reload” so CN then serves the scripts pasted in its script blocking settings.

2. “cca_is_eu=true” In the rush to get CCA out I gave this cookie a confusing name it would better be named “cca_NOT_eu” – however it is being set as expected on your site.

3. The CCA plugin’s info page states it won’t work with most caching except Comet/WPSC with CC. Like other plugins, you should not assume CCA will work with every possible configuration of Intermediary server/CDNs/reverse proxy/http cache/Varnish. They are not used in my environment and I cannot support them.

4. Issues arround caching from WP nonce to WP dynamic scripts are a real pain for plugin developrs. I started to write a new GDPR Cookie consent plugin whilst waiting for the new release of CN. It works without requiring reload, I may end up resurrecting it for those who use caching.

Thanks for the thoughtful remarks. I recognize the caching complication. And I will not assume CCA will work out of the box.

Luckily, for sites that I develop / maintain, there is no geolocation dynamic requirement beyond GDPR. Any/all geo centric logic is client based (namely Adsense).

For my limited requirement, it seems like a client-only solution is doable, assuming Cloudflare, deliver back the org. request SERVER variable within client scope and set cookie/present dialog accordingly. I believe AMP (together with amp-consent and amp-geo) presents a parallel solution for mobile content. AMP for WordPress is not amp-geo aware as yet, but it will be for their next release.

I will now attempt to distill the GA script code into the CN blocking dialog. I never really wanted to use the cn_reloaded hack; it sort of worked for our 10% EU traffic case. And then I found CCA where I would only want to show CN to our 10% EU traffic, and here I am today…still probing for a good solution.

Given that the site uses MonsterInsight Pro along with the newly released EU compliance addon (to cleanse GA privacy/demographics), I had hoped it would cover the most important GA case, initial request when CN/notice is shown, well it does not. Last week, I asked Monster Tech support for this base feature, and they claimed it was a CN/notice issue, and not theirs. But they said they would consider addressing it.
…Monster claims its EU compliance addon is both Cookie Notice and CookieBot aware.

Update on issue and “fix”.

I mentioned I suspected CN may not allways work correctly with caching (whether using CCA or not) this has been confirmed. This issue can be fixed using the Country Caching Extensions (even for those not using CCA and geolocation) – as a byproduct there is no need for CCA to add the cnreloaded query string for reloads (next release of CCA) your original issue.

Had some thoughts; and it is also possible for CCA to serve Analytics without the need for any reload and provide correct data for your non-Eu visitors. See new documentation. Currently CCA will still reload on first visit but in the next release it will only reload if you have opted to reload in CN settings.

Hope helps.