You are right up to a point, but need carefulness when you apply this approach to others’ sites. What do you think would happen if JavaScript was accidentally deactivated on the site and reCAPTCHA’s JS code that is supposed to retrieve a token couldn’t run correctly? What would happen if the g-recaptcha-response field was always left blank not by spambots but by site owner’s mistake? In fact, there are tons of WordPress sites that have such script failures, and they will lose legitimate messages because they are all marked as spam.
I’m aware that this is a fairly aggressive move in terms of forcing any submission where Recaptcha has not been attempted to be rejected.
However, we know that most spambots will not bother parsing and executing JavaScript, thus will not submit a g-recaptcha-response and therefore at the moment most spam is being let through, where this wasn’t previously the case before 5.1 and the v3 API.
Anonymous User
(@anonymized-1391468)
I have done some testing with and without Javascript enabled to compare the results with V2 and V3 recaptcha. I found that when using V2 with Javascript disabled, the form displays an error message and does not allow the form submission. To have the same behaviour with V3, I suggest making the edit that PeterUpfold suggests, and adding the error message from V2, slightly modified, to the form within <noscript> tags like this:
<noscript><div class=”wpcf7-response-output wpcf7-spam-blocked”><p>Could not connect to the reCAPTCHA service. Please enable Javascript and reload to get a reCAPTCHA challenge.</p></div></noscript>
I placed this code just above the submit button, replacing the old [recaptcha] tag.
I also adding logging to record when the reCAPTCHA response is missing, and the logging lined up exactly with the incoming spam messages I have been receiving.
I have not studied the code in Contact 7 nor reCAPTCHA. With that in mind, the suggestion by Bev seems reasonable.
I wonder if a trap can be set to detect no javascript when the contact form is loaded. If so, perhaps a conditional branch in function wpcf7_recaptcha_verify_response could handle the case appropriately.
I’m using the line 112 code hack because I–and all my clients who complained when I upgraded them to v3 reCAPTCHA–would rather get no spam at all and run the risk of having the occasional user who has javascript disabled be unable to use the contact form.
I think the real problem is that there are a significant number of users out there who run ad-blockers that might block the Google scripts for the reCAPTCHA, and with the hack, they won’t be able to submit the contact form with the hack in place. In my testing, they will get the orange-bordered “There was an error trying to send your message. Please try again later.” So that’s good. They’ll know their message didn’t get through.
Maybe a compromise that wouldn’t require too much work of the developer would be to add an option to the Mail tab to “block mail for which a Google v3 reCAPTCHA token is not set”, which would let the end user decide?
It would be nice to have a message displayed for the user when submission is blocked by an empty token–for the visitors who are human–that says something to the effect of, “The message could not be sent. Make sure javascript is enabled in your browser,” but that’s icing on the cake.
