On Thursday, December 13, 2018 there was a new version (5.1) of Contact Form 7, one of the most popular WordPress plugins with over 5 million installations, released. The author/developer, Takayuki Miyoshi, decided to abandon Google ReCaptcha V2 and adopt Google ReCatpcha V3. You can learn about the versions here https://developers.google.com/recaptcha/docs/versions.
This implementation forced anyone who updated the plugin to also regenerate the Google Captcha keys so that they had the new V3 keys. There was no option to keep using V2.
AUTOMATIC UPDATES
Anyone who did the update automatically would be unaware of this and all SPAM blocking ceased. They will not know this until they start getting SPAM or log into the WordPress admin panel. However, that was NOT the biggest issue.
SWITCHING TO CONTACT FORM 7 RECAPTCHA V3
Anyone who did the update automatically or manually, created the new keys, thought that their SPAM blocking was intact, when in reality it was gone completely. The developer (Takayuki Miyoshi) made the choice that if a visitor was blocking JavaScript (intentionally or through some ad blocker), that the ReCaptcha feature (which requires a script) would simply be skipped. Unfortunately, nearly all SPAM bots do not execute scripts and were allowed to submit the forms. Millions of SPAM emails starting flooding the web universe. As of December 19 this was still happening for millions of domains.
DEVELOPER RESPONSE
Takayuki Miyoshi was asked directly about this choice in the support forums but refused to compromise on this issue. He was also asked to add an option to allow the administrators to choose either V2 or V3. He has not responded to that. What was more interesting was that there was virtually no communication from him for 72 hours after his first response defending his decision. You can read his response on that here: https://wordpress.org/support/topic/recaptcha-v3-if-g-recaptcha-response-is-empty-submission-never-be-verified/#post-10985662
OPTIONS FOR FIXING THE CONTACT 7 RECAPTCHA ISSUE
The WordPress developer community eventually came up with several options:
- Revert back to an earlier version of the plugin and re-establish the V2 keys and revert to the prior methodology. This effectively cuts them off from any future plugin upgrades (undesirable).
- Make a one line fix to the code in the plugin so that anyone who has disabled Javascript (including bots) is blocked. This also cuts them off from any future upgrades. This is undesirable but workable, if the developer concedes and eventually addresses this (see below for instructions).
- Add this plugin https://wordpress.org/plugins/advanced-nocaptcha-recaptcha/ so that Contact Form 7 is still used and ReCaptcha V2 can be implemented (possibly the best solution for those who want to keep using V2 – more below on this).
- Switch to a completely new contact form plugin such as Ninja Forms or Gravity Forms (requiring significant reconfiguration).
- Update the plugin to version 5.1 initially available on December 18. This is now the best solution.
If anyone has an additional solution, please contact us and we will update this post!
PLUGIN HACK TO FIX RECAPTCHA V3 IN CONTACT FORM 7
Please note that is specifically for Contact Form 7 version 5.1.
Change line 112 of wp-content/plugins/contact-form-7/modules/recaptcha.php
from: return $spam;
to: return true;
This will make sure that any visitors or bots that have disabled Javascript will be unable to submit the form. This hack will be overwritten the next time the plugin is updated. Some visitors use ad blockers that disable Javascript. They will be unable to submit the form and will see a message letting them know the submission failed. In our opinion this hack should be part of the plugin along with a message letting legitimate visitors know they need to enable Javascript to use the form.
UNDERSTANDING RECAPTCHA V3 – GOOGLE SCRIPTS LOAD ON EVERY PAGE
It is important to understand that the Google V3 methodology relies on tracking the visitors behavior across the entire site. This is why the script is being loaded on every page. There are code hacks that would allow you to only load the script on a page/post with a contact form but that makes no sense. It defeats the intent of V3 which is tracking the visitor throughout the entire site and it also doesn;t take into account any contact forms that are in sidebars, header, footer, pop-ups, etc. We recommend you do NOT do this. Either use V3 as it was intended by Google or do not use it all!
ANNOYING BADGE FROM RECAPTCHA V3 ON EVERY PAGE
Read the previous section to understand why the script is needed on every page before continuing to read here. Google wants you to display the badge on every page or at least have some statement that it is in use. This creates an issue because the badhe interferes with the visitor experience (espeically when it ocverlays critical content or controls). This badge can be removed everywhere by adding the following CSS rule:
.grecaptcha-badge{
visibility: collapse !important;
}
KEEP CONTACT FORM 7 WITH RECAPTCHA V2
This is probably the best solution (before the 5.1 version of the plugin was released on December 18). It allows you to keep Contact Form 7, but also use the V2 methodology. Here are the steps for implementation:
- Add and activate this plugin https://wordpress.org/plugins/advanced-nocaptcha-recaptcha/
- Go to the settings of the new plugin and insert the Google ReCaptcha V2 keys (you can also edit other settings there)
- Remove any v3 Google keys from Contact Form 7 > Integration and remove the Contact Form 7 shortcode
[recaptcha] - Add the shortcode
[anr_nocaptcha g-recaptcha-response]that is supported by the new plugin and save the form.
If anyone has an issue with this fix, please contact the plugin developer. There is also an alternate similar solution here: https://articles.runtings.co.uk/2018/12/how-to-fix-contact-form-7-v501.html
THE LAST WORD
Here is the most disturbing takeaway; There was no quick resolution here. A single developer basically allowed millions of SPAM emails to happen. This is still happening for many domains. Worse, the moderators of the critical WordPress support forum were spending most of their time addressing “forum guidelines” rather than facilitating the flow of information amongst developers and domain owners/administrators. Several prominent developers (including our CEO) had their posts removed and/or were accused of hijacking the forum sub-topic. Fortunately, enough information got through that with some digging an affected developer or domain owner could address this.