neroavorio

Thanks for the workaround, but I’d strongly suggest to add it as an option in the plugin settings, since the new Italian Law REQUIRES that the Close button doesn’t accept anything by default… it’s an important part of the new italian privacy law.
BTW: the new law will become effective by Jan. 9, 2022. Just a month from now.

Just to point out that I had the same exact request from a client, and anyway, it would be indeed a very useful feature. Just a “permanent” flag in addition to the other settings.
I hope you’ll consider it for the next releases

@daobydesign I didn’t mean to sound too critic ?? Your suggestion was surely good. My surprise was referred to your question about someone “being stuck” with an old CF7. It’s a very common issue, that’s all.
Anyway, I can confirm that even the latest release of your useful plugin works with CF7 4.x, as long as the shortcodes are written “manually”.

rwhirn, I was on the same boat, CF7 4.03 on an old WP installation.
I’m a bit surprised by Ryan’s answer. The latest version of CF7 is NOT compatibile with older WordPress versions, so the only way to install the latest CF7 (and any recent related plugin) is to update WordPress too. With all the much likely issues involved.
Anyway: rwhirn, you’re right, there’s no “honeypot” shortcode in the “generate tag” menu, but if you write the shortcode directly ( simply [honeypot honeypot-123] anywhere in the form, possibly with a random number as ID) the plugin works as expected. At least on my version.

Thanks, that’s exactly what I did (after realizing looking at the source code that an option was already there). This one works ??

The breadcrumbs setting doesn’t change anything (it was already set to “none”, but I tried switching it just in case).
I’ll think about deactivating some plugins, but my main goal was to make slider filters work, and I’m understanding they won’t anyway.
I think I’ll be forcing (someway) the product pages to be open in a new tab as a workaround.

…any clue? Should I just forget about this option and tell my client to live with that?

That’s weird. I assume you enabled the RELOADING option. If you see the cookie but you don’t see the analytics script nor the ga-gat-gid cookies, I’m out of suggestions ??

Wait wait. Now I saw the code you wrote above… it’s NOT ok ??
you mixed PHP and Javascript!

The snippet should be like this

<?php
if ( function_exists(‘cn_cookies_accepted’) && cn_cookies_accepted() ) {
?>
<!– Global Site Tag (gtag.js) – Google Analytics –>
<script async src=”https://www.googletagmanager.com/gtag/js?id=xxxxxxxx”></script&gt;
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments)};
gtag(‘js’, new Date());

gtag(‘config’, ‘UA-xxxxxxx’);
</script>
<?php
}
?>

No, I leave the “script blocking” field empty, I never tried to use the built-in function.
Your code seems to be ok.
Did you remove ALL the cookies (including analytics and cookie_notice_accepted for your site before testing?

I can’t answer about the second part of the message, but I use the plugin on many sites blocking Analytics code “manually” using the suggested

if ( function_exists(‘cn_cookies_accepted’) && cn_cookies_accepted() ) {
// Your third-party non functional code here
}

It’s really a piece of cake, just edit the header php file of your theme/installation and add the Gtag code inside the if statement.
It involves editing the source, I know, but it’s really an easy task (use a child theme, if possible).

I made several tests showing all field types. See link above.
The “maintain filter” doesn’t seem to work at all.
Something happens when I switch the option on/off, but it’s pretty useless and bugged. The only difference I see is when (with option enabled) clicking on the BACK button of the browser (tested on FF & Chrome): it retains radios, checks, text search and category dropdown (no subcategories here, I wasn’t precise in my first post). The sliders remain always unchanged. BUT the list isn’t filtered! The fields look selected, but no real filter occurs (all product of the catalog are showed).
If the option isn’t enabled, even this type of “partial memory” (useless, anyway) doesn’t occur.
NOTE: I use three catalogues on the site. The link above is for one of them, the other two are easily reachable via the CATALOGO menu button. The catalogues contain just a bunch of test products.

I already considered this possible “legal” issue.
The cookie denial can’t be logged, legally (IMHO).
The consent can (and must!) be logged, but the IP has to be retrieved and stored AFTER the click. For example by an ajax call prior to page reload?

Just to add another dismayed note here. I use many CF7 instances on several sites, mainly to keep track of events during PPC campaigns. I didn’t read anything of the EXTREMELY useful on_sent_ok setting being deprecated…today I checked the suggested updates on one of my sites and saw the CF7 5.0 alert. Usually I update CF7 without particular worries, it never gave me any issue, but being a major version update, I (wisely) decided to check the changelog. This particular decision is INSANE, for two reasons: 1) it completely breaks ALL forms using the old setting, without giving ANY warning (I checked)
2) it absolutely doesn’t provide any serious viable alternate solution. The suggested “direct functions.php edit” solution looks like a temporary workaround. If security issues are at stake here, it DEFINITELY should be provided another built-in solution, without any plugins (it’s a basic, and I’d say FUNDAMENTAL feature, not a strange rare specific need!!).