dukeo

Nevermind, I found the fix. If anyone else is having this issue, paste the following code in the functions.php file of your WordPress theme:

add_action( 'wp_enqueue_scripts', 'wps_deregister_scripts', 100 );
function wps_deregister_scripts() {
	if ( !is_page('contact') ) {
		wp_dequeue_script( 'google-recaptcha' );
	}
}

Please note that if the slug of your contact page isn’t “contact”, you will need to edit the 3rd line.

No problem, I got the receipts.
In your installation flow, I hit the “Skip” button and didn’t give the access you were asking.
After a few minutes of exploring the plugin settings, I uninstalled the plugin.
I was never asked for a permission to be added to an email list after that.

Around 24 hours later, I received an email from [email protected] titled “??Get your link mojo back” to try to get me to give feedback / re-install the plugin / get the premium version.

The email recipients make it clear that you pulled the admin email address as well as the first name from my WordPress blog without any permission, added me to an email list, and started sending your emails to said address.

This is the very definition of spam.

I stand by my original review.

• This reply was modified 3 years, 5 months ago by dukeo.
• This reply was modified 3 years, 5 months ago by dukeo.

@aqyn, this might hide the badge, but this doesn’t stop the script from tracking ALL your visitors on ALL pages.

Hiding the badge without adding the proper legal notice from Google to still advertise the use of Recaptcha is a breach of their terms of service.

Also, tracking your visitors’ activity at all times is a breach of GDPR unless you’re specifically asking your visitors for their consent.

@locascioa while updating your forms is enough for Google, it’s not enough regarding GDPR. All the people who don’t visit your form pages are still being tracked across your websites. To be compliant with the law, you need to add some information about the constant tracking to all your Privacy Policy pages.

@squarecandy as a matter of fact, even with the ugly Google notice, you still need to update the Privacy Policy of your website. The badge covers Google’s responsibility, it doesn’t cover your own website’s responsibility.

@locascioa are you also updating your privacy policy on 200 sites to indicate that Google Recaptcha now tracks users on all pages (without asking for consent, so not-GDPR compliant)?

To be clear, by using Recaptcha v3, your current Privacy Policy becomes invalid because Google is now tracking your visitors, and analyzing their behavior, on every single page of your website.

If you’re based in Europe, you’re basically breaking the law since this is not GDPR-compliant and doesn’t ask for any consent for the constant tracking.

The “workaround” with CSS only hides the badge so visitors can’t see it, but they’re still being tracked on every single page.

PS: As an extra bonus regarding page speed, it loads some extra resources on every single page of your website.

1) Technically you’re right you can hide the badge… But only if (1) you advertise them “visibly in the user flow” and (2) add 2 do-follow links to Google.

Plus, to be clear, all visitors are still tracked across your entire website. CSS is not going to stop the tracking.

Finally, to respect the law in most countries, you need to alter the Privacy Policy of all your websites to indicate that users are now being tracked by Google Recaptcha across all pages of your website.

Altering or hiding the recaptcha badge is against Google Recaptcha TOS. (which is why I was inquiring about simply not loading it on pages it’s not needed).

v2 has always been fine. People are now used to having to check an extra box before sending a contact form.

If the badge needs to be there on all pages at all times, I guess it’s time to find an alternative to CF7 and Recaptcha…

Recaptcha is a tool to protect contact forms from spam. I don’t want it to track visitors everywhere and see everything they do on my sites. That’s a massive invasion of privacy from Google. And the underlying excuse to track everyone everywhere is that it will help protect forms? No thank you. I’ll use another contact form that doesn’t reach beyond what it’s supposed to do.

And in the meantime, roll back to a previous version of CF7 until Rechaptcha v2 gets entirely removed by Google.

Just imagine the outcry if WordPress was saying: “If you use WordPress as a CMS we will add our own analytics to every page on every website you build”. That would send shockwaves across the entire web…. Or if it was coming from every plugin publisher… “you want to use our plugin to change your header color? We can do that, but in exchange we will track all your visitors everywhere.”

tl;dr: I don’t mind using the v3, but load the google script inside wpcf7_load_js so we can disable it on pages where there is no contact form!

I just tried the beta.

Here is what happens:
– wpp_get_mostpopular() works correctly (i.e. the list displays correctly based on historic data),
– when a page is set as homepage, the WPP javascript does not get added to the header,
– on regular pages, the console reads “WPP: Oops, could not update the views count!”

Completely uninstalling this plugin from our website at this point.

So, in case people are wondering why their server is getting bogged down, I woke up to a 100MB error log. 100% from WordPress Popular Posts.

The plugin is still not working for multisite, and causing a ton of errors.

I have updated to 4.0.6. Still not working.

2 cases:
1. when using a page as front page, no WPP code in the source code.
2. on regular pages, the javascript is there, but I get the following message in the console: “WPP: Oops, could not update the views count!”

Moreover, the list of popular posts is still empty.

I did not try to clear tables because I’m not sure the tables are actually deleted. I suspect the path to the tables for each subsites are incorrect but the data might still be there.

I don’t want to risk deleting all the page views’ data I’ve been storing for the past 3 years.

Waiting for an update from the plugin creator. Hopefully it’s just a matter of fixing the paths to subsites’ db tables.

You’re right, I enabled categories for pages with a snippet of code in my functions.php file.

Maybe instead of having the plugin auto-detect if the post type in the query has categories enabled, you could add a variable to the query… For example: taxonomy=1 that would disable the 2 lines of code around line 873.

The problem with commenting the code is that I’ll lose the mod when you’ll update the plugin..

Anyway, thanks a lot for the tip. It will do just fine for now.

@héctor Cabrera the_content() is not called when pages are cached.

Moreover, I have some custom pages on my blog that do not use the_content() since all the content of the page is hard-coded in the page template. (Maybe I’m not the only person who’s doing that)