• The reCAPTCHA itself seems to behave correctly, but it never calls back to WooCommerce.
    Users see the error ‘Please complete the reCAPTCHA to verify that you are not a robot.’ even though they have clearly completed the reCAPTCHA.

    The developer console shows repeated Error: ReCAPTCHA has already been rendered in this element logs
    It appears that something (a callback on the g-recaptcha element itself?) causes the element to render on page paint, so by the time your renderRecaptcha() function is called the element is already rendered.
    Thus your call to grecaptcha.render() fails and the callback is never registered.

    Edit: Looks like this is the same issue reported by another user a few days ago:
    https://wordpress.org/support/topic/recaptch-not-working-on-checkout-page/

    • This topic was modified 1 month, 3 weeks ago by atsam. Reason: Duplicates another issue
Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter atsam

    (@atsam)

    After a while browsing the codebase and the reCAPTCHA developer pages, I wonder if the solution would be to pass the parameter onload=renderRecaptcha to the reCAPTCHA api (as documented here https://developers.google.com/recaptcha/docs/display#render_param) rather than relying on a MutationObserver or wordpress callback to trigger the render.

    I don’t have time to test that today, I’ll give it a try later in the week.

    Thread Starter atsam

    (@atsam)

    I didn’t have a lot of time to experiment in the end, but I found a quick fix that seems to have worked for me.
    I simply added the parameter ‘render=explicit’ to the wp_enqueue_script call in recaptcha-woo.php
    So the line becomes:
    wp_enqueue_script( ‘recaptcha’, ‘https://www.google.com/recaptcha/api.js?render=explicit&hl=’ . get_locale(), array(), null, array(‘strategy’ => ‘defer’));

    I believe this just prevents the recaptcha api from automatically rendering and allows your javascript bindings to run as intended.

    I still think that using the onload=callback parameter might be the preferred method here, but as I say I’m a little short on time and this is outside my normal experience anyway.

    I’ll try to submit a patch next week, if that’s something I can do, but if a developer sees this before I get to it then please do make the change yourself.

    Thread Starter atsam

    (@atsam)

    I’ve now submitted a patch with this change.
    I see that this parameter was removed in V1.4.5, which I think just breaks the plugin.
    It looks like it was removed because of an error about “Incorrect call of JavaScript resource parameter”, I think passing ‘render=explicit’ rather than just ‘explicit’ is the correct way to resolve that error too.

    Hey, found your post while having this same error and tried implementing to our site. This fixed our checkout issue but broke the login captchas.

    From the console I found that the window.wp object is not always available on every page.

    rcfwc.js:17 - Uncaught ReferenceError: wp is not defined

    This causes the JS based render call to be skipped and leaves us with no reCAPTCHA at all. When explicit isn’t used the automatic rendering is making sure it appears.

    What’s not clear to me is if the wp object should always be available or not. The documentation for it is pretty bleak. Wondering if something else in the plugin would be needed to ensure the wp object is available ?

    Thread Starter atsam

    (@atsam)

    I don’t have login captchas enabled so I’m afraid I don’t really know.
    One point that I didn’t mention in my earlier posts is that there is a second wp_register_script call, in admin-options.php

    That line was also changed in V1.4.5
    If the login forms use admin-options.php rather than recaptcha-woo.php (I have no idea if they do) then that could be the solution.
    Same change as before, add the render=explicit argument.

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.