Yaron Guez

What should everyone else do who is also encountering this same issue? There used to be a link that said, “run update now” to get around this. But now that’s gone. It’s been “updating” for days and re-activating the plugin doesn’t fix it.

Is that allowed under the GDPR? I thought all the cookies had to be set to opt-in rather than opt-out. If your approach is compliant then we should be fine.

Geolocation can be tricky and unreliable. I’m just referring to a simple prompt, “Are you a European Union natural person?” If the user chooses “no” then either everything else could be bypassed or all of the cookie includes could be changed to “opt out” instead of “opt in”.

Thanks for developing this plugin! It’s incredibly useful.

It would still be a nice feature to have so website owners can decide when to display the cookie bar. Many users find these sort of popups annoying and distracting and they’re only required within the EU.

I second this request. You may be blocking Uptime Robot as well and they provide a large list of IPs to whitelist:
https://uptimerobot.com/inc/files/ips/IPv4andIPv6.txt

My admin dashboard seems to get hung up a lot on pixel.wp.com as well. Any solutions in the past 6 months?

Some additional details that might be helpful:
– within function, the $_POST data has the correct new value, but the $field->value is the old value.
– Fetching the field data with get_post_meta within the function also loads the old data
– Fetching the title of the post yields the CORRECT title. So the caching bug only affects custom fields.
– The new field does get persisted to the database and does show up correctly in the dashboard after saving. It’s just this hook that has the old data. On the next change of that field to another value, the last value flows into the function again.

SiteGround would be receptive to fixing any issues with their memcached implementation if I can illustrate that the issue lies with them and not CMB2. Have you tested the cmb2_save_field hook with memcached before?

Have you experimented with memcached specifically? SiteGround is a pretty massive hosting platform so a memcached implementation error would be far reaching. I’m not saying that’s not the case, but the more proof or information I could provide them to help track down the problem would be helpful.

Several updates later and STILL getting these emails with no way to turn them off in settings. Lockout notifications are turned off. Database emails are turned off. What are we all missing here?

A fix was provided in this other thread:
https://www.ads-software.com/support/topic/warningdeclaration-of-wedevs_wc_tracking_integration/#post-8353809

It’s a very simple change to make so hopefully the author will incorporate it soon.

I’m running 5.7.1 and have no way to distinguish between a digest email when something is wrong and a daily digest email that amounts to spam. A simple toggle for daily report would solve this.

Advanced WordPress Facebook to the rescue! I needed to wrap [external_url] with single quotes. All set.

It’s been a couple weeks without a reply. Would you mind lending a hand?

I understand. What about my follow up question, above?
https://www.ads-software.com/support/topic/how-can-i-disable-cron-output/#post-8277627

I don’t want to output to /dev/null because I want to capture errors that occur with other plugins. I’m okay with changing the backup to an external URL and creating another cron job that runs it with curl [external_url] but, for some reason, this doesn’t work. It does work if I go the external URL in a browser. Am I using curl incorrectly here?

If it’s not possible to turn this output off, I can kick the job off manually with curl or wget. However I haven’t been able to get this working. When I call the external URL in a browser the job runs fine. When I try running curl [external_url] it doesn’t. Is there more to kicking this job off with curl then the above command?