The examples show this snippet on the page markup just below the render snippet. For V2 of recaptcha this makes sense as it’s a message for the form user (“Check the checkbox”). But for recaptcha V3 the error that gets printed is not intended for the form user. It looks like this:
timeout-or-duplicate-hostname-mismatch action-mismatch score-threshold-not-met etc
Am I doing this wrong and that error is actually supposed to log somewhere else?
I believe I can check my Google admin to view errors and rejections and so don’t really need it elsewhere. And certainly the legit form users will only be further confused by these messages. So, can I simply remove the error snippet from the page?
Or, even better, can the language be changed to something friendlier? Not sure what exactly it would say as V3 is kind of a one-chance for validation system…
From my understanding it should be working fine if you simply remove the placeholder. What might be more useful is to use something like the Personalize Extra to only show possible errors to admin users for debugging, though.
Thanks, that’s what I hoped.
I just checked my google recaptcha admin page because I thought they would show the errors, but they only report very rudimentary info - you can see the score for each attempt, but not the actual error message. So I might play around with printing the error to a log or db. But for now I will remove the snippet from the page. The form is working well and so far no spam…
I’m having this issue right now and have found that it’s also thwarting my form’s ability to fully submit. The save to database and email are working but the error is still being shown.
I could just remove the error as per the above and create an additional snippet to erase the form at the end but it seems super hacky. Did either of you happen to make any progress with a genuine debugging around this?
Have either of you had any issues in the time that followed your posts here? I don’t see how the form can know if it’s legit spam if it’s failing in some way 100% of the time…
The [[!+fi.error.recaptchav3_error]] placeholder is only filled if the ReCaptcha verification fails.
What is the point of using ReCaptcha at all, if you’re trying to simply ignore the verification result?
Recapcha3 works even if you don’t display the error message. I removed the error message from the form display because the message is clearly not written for the end user. It’s not a helpful “here’s how you can fix your errors” type of message. Having no message at all is not ideal for non spammers who have somehow failed the test, but I’ve never received a report or complaint to that effect.
I never figured out how to log the error message somewhere else that an admin can access. That seems like it would be good to have… But my clients don’t care enough to pay me to struggle with it (especially considering spam protection is a moving target and already takes up dev hours that often feel to clients like an aggravating waste of money.)
I should add that in my very non-scientific assessment, I would say that recapcha3 has gotten slightly less effective over the past 2 years, but still blocks a considerable amount of spam.
My most effective form, the one that literally NEVER gets spam, has no spam blocking on it at all. But has over 20 fields, most of which are groups of radio buttons, and most are required. It clearly found the limit to a spambot’s patience.
There is a property display_resp_errors. If that is set to false, then [[!+fi.error.recaptchav3_error]] should display the lexicon string recaptchav2.recaptchav3_error_message that contains a more general error message (“Sorry something went wrong. Please contact the site administrator.”).
The error is logged in the snippet “recaptchav3” (line $modx->log(modX::LOG_LEVEL_DEBUG, print_r($resp, true));). But the log level is modX::LOG_LEVEL_DEBUG. You could change that to modX::LOG_LEVEL_ERROR to see unsuccessful verifications in the MODx error log (with the standard system setting for log_level).
It’s always best to duplicate the snippet to run a modification, otherwise future updates to the extra that supplied will typically overwrite your changes. If you’re just changing log level it’s not a do-or-die, but best to ‘do it right’ anyway.
Yes that’s why I asked, I won’t modify the Extras snippets because I don’t have the resources to insure against overwriting at the next update. But as Harry mentioned it could be used as the basis for a custom hook so that seems like a good plan.
Returning to close the loop on my issue, I was actually triggering the form multiple times by virtue of a [[+content]] placeholder in a pdoMenu tpl. Completely unrelated to the reCaptcha plugin.
When I removed those calls which would cause content to be rendered the form to be run multiple times, all went back to working beautifully.
A trap for ‘young’ players that I still fell for after 14 years of MODX use. Though I guess 14 years is pretty young right…?
