Toggle on/off doesn’t work

I have the same issue

Thanks for reporting this issue.

I will run some tests on my end.

Same issue, using the gdpr_preferences shortcode, all categories show Off.

I’m back from vacation.

Can you share links where I can see this problem happening?

Right now ours is on a dev site I’d rather not link to long-term, so this is an expiring url redirect to it: https://urlgone.com/f4299c/

Try checking one of the cookie category checkboxes on the initial pop-up, hit “Agree” and then click the “Privacy Preferences” button in the sidebar at the right to open the modal, where you will find all categories are set to Off.

Thanks for looking in to this specifically, and thanks a *lot* for all your work!

Do you have caching running?

From what I see, the problem is not in the plugin logic. The problem is that the gdpr[allowed_cookies] and gdpr[consent_types] are not being updated. My assumption is that the browser is displaying a cached version of the cookie.

If you are running cache, try whitelisting these cookies.

I’m looking into caching issues (the hosting does use varnish, but any response with a Set-Cookie: header should not be cached).

Just a wild guess, but I’ve noticed that gdpr sets 3 cookies, gdpr[consent_types], gdpr[allowed_cookies], and gdpr%5Bprivacy_bar%5D .. likely that last one should be gdpr[privacy_bar] instead. It looks like that error is caused by the js-cookie library encoding the cookie name, which can be fixed by adding 5B and 5D to the regex in line 77 (https://github.com/trewknowledge/GDPR/blob/develop/src/js/public/js-cookie.js#L77).

Howevever even with the corrected cookie name of gdpr[privacy_bar], the “Privacy Preferences” modal still doesn’t work on this site. In the http request when submitting the “Agree” button I see the cookie: header submitted with the correct values (ie. cookies from all selected categories), but the response comes back with the same/default set-cookie: value it had.

I’m fairly sure the response is not cached, as it includes the headers “x-cache: MISS, MISS” and “x-cache-hits: 0, 0”. I have also explicitly cleared the varnish cache between the initial page load and clicking the “Agree” button, with no different results. Browser caching issue? I’m using chrome 66.0.3359.181 on linux, in incognito mode.

In further testing, it sure seems the cookie handling is just off. Eg. when I open the privacy preferences modal, enable the ‘Analytics’ category and hit Save Preferences, the http request has the correct gdpr[allowed_cookies] and gdpr[consent_types] values, but in the response there is a set-cookie for both which sets allowed_cookies to the default and consent_types to empty (also default).

I tried this in firefox, with no differences.

… now a couple hours later I’ve tracked the problem to the update_privacy_preferences function in public/class-gdpr-public.php, it seems that none of the setcookie() calls work there at all. php debugging shows it has the correct data. But a test setcookie() from functions.php works when hitting ‘Save Preferences’, but the identical setcookie() call does not not work from update_privacy_preferences().

Sound like a plugin conflict, with something triggering httpd to send headers before update_privacy_preferences() gets run or ?? I’ll try disabling plugins and testing a default theme.

FWIW, I disabled all plugins except gdpr (including all mu-plugins), switched to twentyseventeen theme, and still see the same problem. So if it works on your server … maybe differences in PHP?

In research I’ve seen cookies not working for people during ajax calls when not using the path and domain parameters to setcookie(), but I tested adding an explicit domain to all setcookie() calls and it did not resolve/change anything.

Also, setcookie() returns true within update_privacy_preferences(), so apparently no output has been sent to the client already.

I’m using php 7.0 (php-fpm mode with nginx+varnish, hosting is with panatheon). Looks like you’re using 5.6, though the manual doesn’t mention any changes for setcookie() since 5.5.

I’m pretty stumped .. any ideas?

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

Problem is most likely caching.
Currently, the plugin handles cookies on the client side and on server side.

Server side is not good because of caching.
I’m working on making a big switch on this.

Do you have a local server, where you have the same configs, except for varnish?

That would confirm my suspicions.

No, I only have apache for local testing, not an nginx+php-fpm 7.0 setup (ie. try to reproduce the hosting setup as closely as I can).

I can’t say it’s not a caching issue, but there are some pretty convincing indications that it wouldn’t be: 1) their documentation says any responses with a ‘set-cookie’ header will not be cached, 2) the http headers in the response say that it was a cache MISS, 3) if I add the same setcookie() from functions.php, it works within the response (ie. I see the set-cookie header), where it is missing if I put that call in update_privacy_preferences(), 4) the test cookie I set was NO_CACHE, which pantheon documents as one means to explicitly disabling caching 5) other headers vary between the first and second request (eg. set-cookie headers with embedded timestamps in the cookie values change on each request, that’s not something varnish would change), 6) I have manually cleared the cache between the two page requests, with the same results. If that weren’t enough, I also tried adding a timestamp to the page content, and it changes on each request, so not only headers but actual page content varies.

See if this is useful; I had functions.php error_log() the request url and the gdpr plugin error_log the funciton name and cookie name/value for each setcookie() call. I loaded /privacy-policy page in incognito mode, then selected all cookie categories, and this is what it shows when I hit ‘I Agree’:

[13-Jul-2018 18:21:07 UTC] https://domain.com/wp-admin/admin-ajax.php
[13-Jul-2018 18:21:07 UTC] https://domain.com/wp-cron.php?doing_wp_cron=1531506067.4314019680023193359375
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies cookie  value:  []
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies cookie  value: ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time}-{uid}","
wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}"]
[13-Jul-2018 18:21:07 UTC] update_privacy_preferences calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:07 UTC] update_privacy_preferences cookie  value:   ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time
}-{uid}","wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}","_ga","_gid","_gat","gadwp_wg_default_dimension","gaddwp_wg_default_metric"
,"gadwp_wg_default_swmetric","comment_author_{hash}","comment_author_email_{hash}","comment_author_url_{hash}","wfwaf-authcookie-{hash}","wf_logi
nalerted_{hash}","wfCBLBypass","ct_checkjs","ct_cookies_test","ct_fkp_timestamp","ct_pointer_data","ct_ps_timestamp","ct_sfw_pass_key","ct_timest
amp","ct_timezone","apbct_cookies_test","apbct_page_hits","apbct_prev_referer","apbct_site_landing_ts","apbct_timestamp","apbct_visible_fields","
apbct_visible_fields_count"]
[13-Jul-2018 18:21:07 UTC] update_privacy_preferences calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:07 UTC] update_privacy_preferences cookie  value:   ["privacy-policy"]

[13-Jul-2018 18:21:07 UTC] https://domain.com/privacy-policy
[13-Jul-2018 18:21:07 UTC] https://domain.com/wp-cron.php?doing_wp_cron=1531506067.8418869972229003906250
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies cookie  value:  []
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:07 UTC] set_plugin_cookies cookie  value: ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time}-{uid}","
wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}"]
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies cookie  value:  []
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies cookie  value: ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time}-{uid}","
wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}"]

[13-Jul-2018 18:21:08 UTC] https://domain.com/wp-json/wordpress-popular-posts/v1/popular-posts/
[13-Jul-2018 18:21:08 UTC] https://domain.com/wp-cron.php?doing_wp_cron=1531506068.7774229049682617187500
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies cookie  value:  []
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:08 UTC] set_plugin_cookies cookie  value: ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time}-{uid}",
"wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}"]

[13-Jul-2018 18:21:09 UTC] https://domain.com/wp-admin/admin-ajax.php
[13-Jul-2018 18:21:09 UTC] https://domain.com/wp-cron.php?doing_wp_cron=1531506069.1654660701751708984375
[13-Jul-2018 18:21:09 UTC] set_plugin_cookies calling setcookie(gdpr[consent_types])
[13-Jul-2018 18:21:09 UTC] set_plugin_cookies cookie  value:  []
[13-Jul-2018 18:21:09 UTC] set_plugin_cookies calling setcookie(gdpr[allowed_cookies])
[13-Jul-2018 18:21:09 UTC] set_plugin_cookies cookie  value: ["gdpr","wordpress_{hash}","wordpress_logged_in_{hash}","wp-settings-{time}-{uid}",
"wordpress_sec_{hash}","wordpress_test_cookie","SSESS{hash}"]

You see 4 requests, with the first two trying to set the same cookies twice. Perhaps the php implementation uses the first setcookie() value on our hosting, but yours uses the second?

Also note that the last two requests, and probably the second as well, should not have any setcookie() calls at all, only the request where the cookie values were changed/updated.

I further trial/testing, I disabled the set_plugin_cookies() on init action if doing AJAX, and that makes the first request to admin-ajax look right (only a single call to setcookie() (from update_privacy_preferences()) for a given cookie), but doesn’t actually fix the problem.

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

Just and FYI, I’m rebuilding the cookie component entirely in javascript to get around caching issues and so on. So when I’m done (hopefully this week) your problem should go away because there will be no syncing between server and client anymore. Everything will be handled client side.