wrigs1

This issue also raised (with answer) here on DFactory forum.

Apparently Cookie Notice will work correctly with WP Rocket Cache.

Comet or WP Super Cache will also work correctly with Cookie Notice if you install the appropriate Caching Extension from the WordPress plugin directory: (for WPSC) (for Comet Cache).

Note: Although these caching extensions are labeled “Country Caching” (I originally created them to enable Comet/WPSC to work with geolocation) they will “fix” Cookie Notice even if you are not using country geolocation.

Hi dredd15

This is a side effect of the method CN uses for consent. Unfortunately, there is no perfect consent plugin.

Most cookie consent plugins (with much additional work by site admins) stop cookies, by either:

i. server side blocking the serving of code/content that sets cookies until visitor consent is given; or

ii. requiring site admins to “hobble” scripts, say by changing the source tag (src=)to something not recognised by browsers e.g. src="https://goog.com/.... edited to cn-src="https://goog.com/.... They are served to the visitor but won’t run. If the visitor has consented to cookies then scripts are “de-hobbled” on browser/client side and executed.

Both methods have pros and cons.

Cookie Notice uses the server-side method. The first page (only) served to a new visitor won’t include the admin identified cookie setting scripts. To enable a new visitor, who then accepts cookies, to see this page with complete content/functionality the page then has to be reloaded from the server with missing scripts.

Cookie Notice settings give you the option of whether this first page a new visitor visits should be reloaded. Currently CCA “tells CN” that this non-EU visitor accepts cookies and the first page must be reloaded with scripts. In the next CCA release reload will depend on your Cookie Notice reload setting. Remember if you are using CN correctly Google Analytics will not have been loaded initially (and will not record the new visitors first page UNLESS it is reloaded).

Its early days for complicated GDPR and you can expect cookie plugins to improve.

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

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.

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.

Hi jspry

I have replicated the infinite refresh loop in a cached environment and uploaded a new version to fix. Cache should be cleared after update. This bug should not affect sites that aren’t caching but hopefully it will solve your issue – thanks for letting me know.

Your issue seems to have all the hallmarks of caching (logged in users are not cached with many of these plugins – and your logged in users do not have a problem).

Caching and geolocation in CCA (identifying whether visitor from Europe):

Wordpress caching plugins: the only ones that will work with CCA are Comet and WP Supercache and you must also have installed the associated Coountry Caching Extension (Comet extension) (WPSC)

If you are using any other caching plugin (I vaguely remember reading WP Engine doesn’t not allow other WP caching plugins but adds its own by default) if so (ignoring the bug) I can’t see how EU/non-EU visitors are being separately cached and served the right content.

If using Cloudflare, its caching should be set as standard.

hope this helps

Have you deactivated Cookie Notice?

I cant see a cookie banner as either EU or non EU and no Cookie Notice cookie is set. Nor does HTML contain CN stylesheets.

Hi jspry.

I’ll start with a bit of background info that may help.

When a browser requests a page Cookie Notice checks if its OWN cookie “cookie_notice_accepted” is installed.
If it isn’t the visitor has not previously made a choice to accept/reject cookie and it serves a “sanitized” page.
If the visitor then clicks to accept, then the javascript CN served to the browser creates “cookie_notice_accepted” with a value of “true”.
If the visitor then clicks to refuse, then it is created with a value of “false”.

Assuming, as you mentioned, that its not cache related then it looks like your browser still has CN’s cookie set to false (it should only be your browser that is affected, not other users – there is no need to rollback your server).

In a real world situation this would not happen, users cannot change themselves fron EU to non EU. However for non EU visitors the CCA plugin does check whether the cookie was previously set to ‘false’ and if so changes its value to “true” and it worked for me; and as yet I don’t know why not for your testing.

What browser are you using? I’ll test my end (unless its Safari – I don’t have an Apple)

Have you tried another browser that has not been used as both EU and Non Eu for testing? It should work fine; if not it may be a caching issue but I can’t see how. The FAQ on the CCA download page mentions that Cloudflare’s “standard caching” option should be used. Do you have a wordpress caching plugin as well as Cloudflare? the same FAQ mentions that if caching it is only suitable for use with WPSC or Comet CAche when the country caching extension is installed.

I was going to ask for site link – but I’ve inly just noticed you provided it. I’ll do some checking.

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

I think I’ve done the workarounds so the CCA plugin can still prevent Cookie Notice and automatically allow cookies for non-EU visitors. The WP plugin dir now contains the updated version of CCA.

However it would still be useful (and popular) if you could provide a do nothing hook, or use of cca_is_EU() function in Cookie notice code, would ensure no issues when the EU next changes its privacy laws!

The new version of CN was released yesterday. I have modified CCA and am currently testing it – it looks like it is working correctly. Hopefully, I’ll update the WordPress plugin directory with the new version later today.

Hi solid_snake

Hardly worth it for the remaining day pre GDPR. But current users of CCA & CN should not be setting the refuse option in CN settings (not needed to meet EU laws pre GDPR) and it works fine with CCA for non-EU. With previous CN releases its “refuse” setting served cookies UNLESS a visitor disallowed; so CCA non-EU also worked fine with this. However; in a recent release CN may have reversed the logic in readiness for GDPR i.e. if you checked the refuse option then visitors not served cookies unless they click ok.

I’m waiting for a response from Dfactory re upcoming changes to CN and its interfaces, before releasing a new version of CCA. If the changes can be quickly dealt with they will be included in CCA and non-EU visitors will continue to receive cookies and not see cookie bar. If changes can’t be done quickly then new CCA release will (temporarily) disable its interface with CN – all your visitors will see the cookie bar with accept/refuse cookie options.

The deadline is tomorrow and as I’ve still not had a response from Dfactory re CN I’ve started to develop an EU visitor GDPR cookie consent plugin myself. If no joy with CN I will probably trial it on my site next week.

If necessary (and if still possible) I will be updating the CCA plugin so Cookie notice only applies to EU/EEA countries. If not I’ll look at alternatives.

Pre GDPR my site stores all cookies (I have not ticked Cookie Notice’s settings to display a “decline” button). This is a personal decision has nothing to do with CCA/CN.

Hi solid_snake. Very sensible questions.

Easy ones first:

2. the site does not currently display a refuse button because it is not required until 25 May. Ironically developing/supporting free plugins for others costs me money. Google adsense offsets a tiny fraction of the cost and I don’t want to reduce it further.

4. option to change consent is a GDPR requirement, and I believe will be included in next release of Cookie Notice ready for 25 May.

Remaining questions: (1 & 3) There are various possible scenarios depending on the new logic in the “GDPR release” of Cookie Notice. (see my own support request in this forum posted 6 hours ago)

Hopefully the new version of CN will work correctly with CCA as is, or with a simple change to CCA plugin that tells CN to treat non-EU visitors as having already “accepted” cookies. When I hear back I’ll post details here.

The CCA plugin’s EU functionality was added in 2015 for the old cookie law. I updated the associated article a couple of days ago to say it may or may not work when CN is updated to be GDPR compliant.

A caveat to my previous answer.

The CCA plugin sets Cookie Notices “cn_cookie_notice_output” filter to prevent display of the cookie bar and blocking of cookies. It works with the current (and previous) releases of Cookie Notice.

However, it is possible that the logic used in the next (“100% GDPR compliant”) release of CN will be so radically changed that the above filter will no longer do the job. I assume that if this is the case then the new version of Cookie Notice will provide other filters that can be used to do the job and the CCA plugin will be modified to use them instead.

Hi,

The “custom” solution you mention in 2 (above) is actually a category/country plugin downloadable from www.ads-software.com. It uses an official documented Cookie Notice (CN) hook; and if the visitor is not from the EU it tells CN not to display.

As the CCA plugin author I can assure you it works. Test using the “wptest” link you quoted above. Go to LocaBrowser.com enter the wptest link. Tick France and USA; and submit. Locabrowser will display a US version of wptest (without cookie bar) and French version (with cookie bar at bottom of page).

I don’t want to preempt Dfactory’s answer; but as far as I can tell Fastest Cache (like virtually all caching plugins) is not designed to work with country geolocation. As explained in the original link: WPSC and Comet Cache can be set to cache by country or EU/non EU. If you are using PHP 7 you may find caching is unnecessary. When I switched from PHP 5 to 7 it as much as halved page load times.

HTH

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

@anevins Apologies. I wasn’t aware relevant external links were frowned upon. I accept the slap on the wrist! In my defence; it was code I published long ago, I only mentioned it as an afterthought when I realised it would be a helpful supplement to my answer. (I’m used to Stackoverflow where inclusion of useful links is common).

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