Ajax support / Use behaviors

Do not change the g-recaptcha class name or reCAPTCHA may break! CNW therefore. See https://developers.google.com/recaptcha/docs/display

I thought this class is a must. Why are you not implementing it the way Google proposed with a callback? We may also need to fix the captcha on multiple forms per page issue. Is the recaptcha now loading slower than in past?

fearlsgroove, I tested your patch in #9 but it didn't work with ajax and sometimes the grecaptcha wasn't loaded at the time the behavior was called.

The things I changed:

• added the recaptcha api.js in #attached settings
• changed to callback attributes to an onload attribute, as mentioned in the docs

This solution works well for us. I haven't checked the tests though.

When you get an error on the form, the script will try to load the widget again. But it has no css-class when it is rendered through the drupalRecaptchaOnload callback function.

I also tried to fix the tests.

Interdiffs are a cool thing :-)

api.js need to be added with async and defer to the page, too.

1. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +(function ($, window, document) {
   

   - "Drupal" seems missing
   - document seems not required.

2. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +Drupal.behaviors.recaptcha = {
   

   Indention incorrect

3. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +  attach: function (context, settings) {
   

   What is "settings" added for?

4. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +      if (typeof grecaptcha == 'undefined') {
   

   Not eslint safe. Requires "==="

5. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +window.drupalRecaptchaOnload = function() {
   

   Indention incorrect

6. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +    $(this).addClass('drupal-recaptcha-processed');
   

   Why is the class prefixed with Drupal? Do we have a name space collission or just prepare for any possibility?

7. +++ b/drupal-recaptcha.js
   @@ -0,0 +1,28 @@
   +})(jQuery, window, document);
   

   - "Drupal" seems missing
   - document seems not required.

8. +++ b/recaptcha.module
   @@ -118,20 +118,13 @@ function recaptcha_captcha($op, $captcha_type = '') {
   +                drupal_get_path('module', 'recaptcha') . '/drupal-recaptcha.js',
   

   Why is the file named "drupal-recaptcha" and not only "recaptcha"?

This is a patch I did while experiencing https://www.drupal.org/node/1463768 (reCAPTCHA in Modal Forms)

Works against 7.x-2.0. Should work with dev too, but didn't test.

We schould move forward with #12 only.

Does #12 work with ajax forms?

Ported #12 to D8 and fixed the issues. However I have no idea how I can test this with Ajax under D8.

Bug in captcha module

#12 work for me, Thanks!

You need to test the latest version.

#12 is not working correctly with aggregation with some cases. https://www.google.com/recaptcha/api.js needs to be specified as external. Made a small patch for it. This is for D7.

@rang501, Thanks for patch it applies to latest 2.x, but
- should be applicable from the root of the module folder
- needs to rewrite according to the notes from here https://www.drupal.org/node/2493183#comment-10199293

The patch should be fine now.

Change to 7.x-2.x-dev to test latest path. Will be back later to the original version.

The D8 version need to be done very first.

There was an error in tests, I think I was able to fix that.

#19 worked for me, for ctools modal window. Tested extensively.

Tested #51 with with 2.2 and Drupal 7.52

Patch is broken and not against D8. Do not set broken patches rtbc, please.

all patches didnt work for me in D 8.2.4. #22 seemed more responsible, but did not work with
<a class="use-ajax" href="/form/tatata">tatata</a>

anyone have an idea how to fix this?
Please help )

Noted, Hass

Aha:
hass CreditAttribution: hass commented 12 months ago
Version: 7.x-2.x-dev » 8.x-2.x-dev

It was pass for Drupal 7
Tested #51 with with 2.2 and Drupal 7.52

But you moved it to 8.x-2.x-dev

Is it possible to use this issue to fix 7.x-2.x and create a new issue for 8.x-2.x? Maybe you've got a good reason but it seems that the 7.x patch is ready, more or less, and the 8.x patch doesn't exist yet. Aren't they independent of each other?

Using this patch the recaptcha scripts are attached as libraries. For me it's working now, with (modal forms) or without ajax.

Sorry for no interdiff, I had some issues while creating.

#51 is working for me (D7), in a setup where the form is being served via Authcache p13n (Ajax client).

I'm attaching the updated patch with a minor update to 1 trivial failure in tests.

Setting to 7.x-2.x temporarily in order to trigger full testing.

Alright, D7 tests back to green. Didn't fully check if the current tests actually check for compatibility with AJAX, though.

Back to D8.

Updated #68 patch for current 8.x-2.x-dev branch. Worked for me, as well. Thanks!

Can confirm that the last patch work with the latest dev release (on a webform with ajax enabled).

The last patch worked for me except for multilingual websites where the captcha would be displayed in a language the site would be first called. This would happen because recaptcha_library_info_build() function would call only once as a result all the other languages would be ignored. Ive created a patch to fix this

#71 don't work for me.
I use reCAPTCHA 7.x-2.2 with Bootstrap Login Modal module release 7.x-3.2 for create modal registration form. Unfortunately the reCaptcha doesn't display on the registration form until you click registration button, after that the form will be closed and when you reopen it reCaptcha will be dispayed.

Why we are keeping closing the child as duplicated to this issue? That's not the correct flow i think. None of the issues are related to each others, and keep a issue to submit patches from 7.x and 8.x is not a good idea.

#76 is working like a charm when embedding a captcha field in an AJAX webform block.

I ported #76 patch for 8.x-2.2 release.

#76 seems to work but I get the following JS error

recaptcha__en.js:380 Uncaught Error: ReCAPTCHA placeholder element must be empty
    at zr (recaptcha__en.js:380)
    at recaptcha__en.js:385
    at c (recaptcha__en.js:375)

#71 working fine.

Update patch from #76

For some reason patch #85 failed to apply

Adapted this patch for 8.x-2.2 version

Rolled patch for 2.3.

This also seems to fix an issue with Webform where submitting a form that failed validation on another field would cause the recaptcha element to disappear.

@acbramley on my side issue appears before #91 patch. but after patch it is gone. https://gyazo.com/a3dc3e7f1ef3dc0fdaf4598cc8434faf

Unsure why, but the 71 patch no longer worked on 7.x

It was throwing a JS error about an undefined function, `render` to be specific.

Have amended the patch with the following;

if (typeof grecaptcha === 'undefined' || typeof grecaptcha.render !== "function") {

New patch is attached.

@simon.fryer: tried applying your patch but it failed. It works if I re-save (no changes) so that it has a trailing newline at the end.

#91 Works for me with 8.5.3, but a little note about JS file location. I think it would be better to put it into "js" dir.

We're using 7.x-2.x

Our context is a regular form loaded as part of the Document but uses an ajax enabled submit button. Like so

function mymodule_signup_form() {
...
  $form['actions']['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Sign Up'),
    '#ajax' => array(
      'callback' => 'mymodule_signup_form_ajax_handler',
      'wrapper' => 'signup-form',
      'method' => 'replace',
      'effect' => 'fade'
    )
  );
...
}

#95 applied for me with the addition of a trailing newline. However both #71 and #95 have the issue for me where on the initial page load, first the onload fires, and then the behavior's "attach" method was also firing resulting in harmless but ugly errors complaining that "reCaptcha has already been rendered in this element."

Proposing to simply check if the "recaptcha-processed" class already exists both in the attach method and the window.drupalRecaptchaOnload function.

Also moved recaptcha.js into a "js" directory as recommended by @Vladimirrem

I have a custom form that uses AJAX. Specifically, if a checkbox is ticked the form loads additional form elements by AJAX.

Whenever the AJAX callback fires I get an error:

An error occurred while attempting to process /system/ajax: Blocked a frame with origin "https://example.com" from accessing a frame with origin "https://www.google.com". Protocols, domains, and ports must match.

You will notice that both the example.com and google.com domains are https. I guess this being raised by Google's XSS, but not sure. It seems related to AJAX. Putting here in case someone has experienced this as well. I've applied the latest patch in this thread with no success.

To be clear, this is definitely an error caused by Recaptcha, as this form works fine without the Recaptcha enabled. It is a custom form, but it's a pretty straightforward form really - though it does use the addressfield module.

The patch in #98 did not apply for me to Drupal 8.5.4. I manually applied. I continued to experience this issues. I found the new recaptcha.js was throwing a 'jQuery is not defined error". IMO this is because jQuery is not loaded by default in D8. In this AJAX response, jQuery is not available.

I don't mean to take this patch a different direction but the way I know to deal with this is to define the recaptcha.js script as a library with a dependency on jQuery. This is the direction my patch goes.

After I got the recaptcha.js running without error I had errors with the recaptcha.api files from Google. I fixed this by also loading this Google Recaptcha API as a library. Note: My method no longer loads language (en) specific versions of the Google Recaptcha API. I was not sure how to get the site's configured language variable into the library's YML. This probably should be addressed. I believe this patch will only load the english version.

These two libraries are then attached to the form instead of written in the html head.

I adjusted the test to look for these JS files in the manner in which they loaded, as an attached library.

The iFrame Fallback test was also failing for me, unrelated to this issue, but I wanted the test to pass. I traced the issue to the query string part of the iframe URL. I adjusted it to be less specific in the query string. That might be less than ideal as it likely breaks the test's ability to confirm localization. I could not figure out what part of the query string was breaking the test.

Hopeful this keeps the balling rolling.

#98 is for 7.x-2.x
I believe #91 was the last patch submitted for 8.x-2.x in fact your patch is very similar to it @maestrojed :)

---
Side rant...
Reading up I think I might share in a certain confusion... I believe this issue started out as a place to track this problem for Drupal 7, then Drupal 8 kind of showed up and started to share the space around #59

Now, I'm not really sure if this was the right place to submit a patch for 7.x-2.x though one is certainly still needed. It is also a little confusing/time-consuming to tell which patches are for which version unless it is explicitly stated in the comment.

Maybe not a huge deal, but confusing nonetheless.

Thanks @greagseb I missed that. I have seen the D7 and D8 confusion in other issue threads and am not clear on how to keep things straight.

#91 is probably a better option then my #100. @RumyanaRuseva has taken proper care of the localization issues I hadn't solved.

Thanks all!

Re-roll of patch #91 that included localization support.
Changes made:

1. moved recaptcha.js to standard js directory
2. added check for processed class in window.drupalRecaptchaOnload
3. code cleanup: added missing semicolon after window.drupalRecaptchaOnload, removed unused variables from trailing function arguments

An interdiff of the changes to recaptcha.js between #91 and #103 (as much for my benefit as anyone else's).

Minor change so that the tests will pass (does not affect functionality).

Fix a few coding standards errors.

Minor changes so that the tests will pass (does not affect functionality).

Fix a coding standards error.

Reinstate the code that calls drupalRecaptchaOnload, that was lost between #51 and #68.

Just noticed that my last 2 patches included my BrowserTestBase file - that shouldn't have been there!
(see #2987201: Convert web tests to browser tests for more details)

Removed the irrelevant code.

AJAX behaviours may actually remove recaptcha elements from the page, so this patch adds a check for whether they exist or not before resetting/rendering them. (The attach method can still get called on the cached form element, even if it has been removed by an ajax command!)

Oops, sorry the patch file still has '110' in the name.

#110 reroll via latest recaptcha-8.x-2.x-dev

reroll via latest recaptcha-8.x-2.x-dev

Hi,
Patch #116 worked for me.

However, on certain situations it might be confusing. If your Captcha settings for "Persistence" aren't set to "Always add a challenge." it happens that after a correct validation of the reCaptcha, if the form is submitted by AJAX, the reCaptcha is not displayed again, because the Captcha module believes -by the captcha session- that the validation was ok.

Anything still blocking RTBC of this, besides additional manual testing?

Nothing that I can see, except for japicoder's comment 117. Perhaps that would be best addressed in a follow-up though, because 'persistence' could mean different things to different AJAX scenarios, I imagine? If someone agrees, then maybe this can be considered RTBC.

Getting this through would also unblock the confusion in #2852269: Integrate Invisible reCAPTCHA option from Google.

Tested with ajax enabled modal. Without this patch captcha wasn't visible.
After this patch captcha is visible and solvable.

See #122

#114 reroll via latest 8.x-2.x-dev, plus simplify changes to recaptcha.module.

Fix indent from #121.

Need test and review.

@hswong3i Those patches look like a lot more than a re-roll of #114/115. Please can we have an interdiff?

Given that this was already at RTBC, why were further patches necessary at all, let alone additional changes?

@james.williams because the upstream logic changed, so the handling of `https://www.google.com/recaptcha/api/fallback` become difficult, see #2993365: Add an option to use reCAPTCHA globally (i.e. China)

@james.williams I tried for a interdiff with #114 but due to upstream changes original patch can't apply, and so interdiff failed, too.

Notes since #114:

1. NO CHANGE to js/recaptcha.js and recaptcha.libraries.yml since #114
2. Remove the newly recaptcha_library_info_build(), so just simply alter recaptcha_captcha() for the new query parameters
3. Update related test cases, with similar logic and syntax with similar test cases

Test passed locally, need CI check.

@hswong3i thanks for the explanation. I've read the patch, and I think that's all OK. I haven't done any actual testing, but I'm certainly happier now :-)

However, there were mentions previously in this ticket (e.g. comment 100) that gave the rationale for loading the scripts via libraries, rather than directly-included javascript files. I do still think that would be better to do, unless that change in approach can be justified?

Syntax cleanup.

@james.williams since I don't see @hass will accept this patch (nor the the nocaptcha patch, created since 14 Feb 2017) in a short, I would like to suggest keep this patch as similar and little change via upstream as possible. Else whenever we need to rebase the changes the workload will be similar as rewrite entirely...

I read the #100, or let's fix the language problem with other new issue, so let this patch apply as fast as possible?

I don't see @hass will accept this patch

Why not? The patch was still needing work/review until only recently, so of course it wouldn't have been accepted before then. But it did reach RTBC in the last fortnight - as far as I understand, the only reason it isn't still there was because of the changes you had to introduce to adapt for the additional upstream changes due to #2993365: Add an option to use reCAPTCHA globally (i.e. China). So let's get this back to RTBC, then maybe hass might be happy with it?

To get there, I believe we need review from someone other than us two, and/or confirmation from someone other than you that your patch works via manual testing. (Unfortunately I don't have time myself to do that confirmation with manual testing, sorry.)

I read the #100, or let's fix the language problem with other new issue, so let this patch apply as fast as possible?

Yes, I suppose any such language issue can be split out to be dealt with separately. But comment 100 also mentioned that implementing as a library helps with ensuring jquery is available, which it isn't guaranteed to be otherwise. Anyway, I guess that could also be dealt with separately, sure. As long as both of these do get solved one way or another, fine.

From #129:

diff --git a/recaptcha.libraries.yml b/recaptcha.libraries.yml
new file mode 100644
index 0000000..7471b37
--- /dev/null
+++ b/recaptcha.libraries.yml
@@ -0,0 +1,6 @@
+recaptcha:
+  js:
+    js/recaptcha.js: {}
+  dependencies:
+    - core/drupal
+    - core/jquery
diff --git a/recaptcha.module b/recaptcha.module
index 8e31d9f..1d5693f 100644
--- a/recaptcha.module
+++ b/recaptcha.module
@@ -128,7 +128,14 @@ function recaptcha_captcha($op, $captcha_type = '') {
                   [
                     '#tag' => 'script',
                     '#attributes' => [
-                      'src' => Url::fromUri($recaptcha_src, ['query' => ['hl' => \Drupal::service('language_manager')->getCurrentLanguage()->getId()], 'absolute' => TRUE])->toString(),
+                      'src' => Url::fromUri($recaptcha_src, [
+                        'query' => [
+                          'hl' => \Drupal::service('language_manager')->getCurrentLanguage()->getId(),
+                          'onload' => 'drupalRecaptchaOnload',
+                          'render' => 'explicit',
+                        ],
+                        'absolute' => TRUE,
+                      ])->toString(),
                       'async' => TRUE,
                       'defer' => TRUE,
                     ],
@@ -136,6 +143,9 @@ function recaptcha_captcha($op, $captcha_type = '') {
                   'recaptcha_api',
                 ],
               ],
+              'library' => [
+                'recaptcha/recaptcha',
+              ],
             ],
           ];
         }

The problem of #100 should no longer happen, because:

1. Order Independent: Original https://www.google.com/recaptcha/api.js is load with async defer, so it don't care if jQuery load in before nor after it
2. jQuery MUST Exist: The library recaptcha/recaptcha is now attached TOGETHER within the $captcha['form']['recaptcha_widget'], where recaptcha/recaptcha ALREADY define the dependency with jQuery, so once the widget displayed jQuery should already load in

Simple and elegant ;-)

reroll #115 for latest recaptcha-8.x-2.x-dev

@johnjw59 #128 already solve the rebase with upstream issue, plus keeping most existing logic, minimal changeset with upstream, pass test cases with CI, and working well together with #2852269: Integrate Invisible reCAPTCHA option from Google.

Please kindly review #128?

Syntax cleanup for $captcha['form']['#attached']['library'][] = 'recaptcha/recaptcha';, better sync with #2852269: Integrate Invisible reCAPTCHA option from Google style.

Thanks @hswong3i. Patch #136 seems to work fine for me with 8.x-2.x-dev and webform 8.x-5.0-rc21.

I think we can put this back to RTBC then? Thanks @szeidler!

Latest patch LGTM

I just tested patch #136 on Drupal 8.6.2 with webform 8.x-5.0-rc23 and recaptcha 8.x-2.x-dev. It seems to fix all problems with webform ajax and recaptcha. Thank you!

This patch works for 8.x-2.3.0.

Please keep the version set to the latest dev applicable for the issue.

@hass Anything else you would like to see to move this forward?

Sorry about that @bonus. I didn't realize it changed the whole version.

Also, ignore my patch for 2.3.0 at #144. Had a bug I missed. This one should work for 2.3.0.

Back to RTBC for #136.

Hmm maybe I did something wrong, but according to this doc, in drupal 8 webform module, is possible to show this form in dialog window (It works!), but recaptcha does not work, also after apply latest patch. Any idea??

Update:
I think that we should attach globally reCaptcha js if we want to use it with dialog window.

function mymodulel_page_attachments(array &$attachments) {
  $recaptcha_src = 'https://www.google.com/recaptcha/api.js';
  $attachments['#attached']['html_head'] = [
    [
      [
        '#tag' => 'script',
        '#attributes' => [
          'src' => Url::fromUri($recaptcha_src, [
            'query' => [
              'hl' => \Drupal::service('language_manager')
                ->getCurrentLanguage()
                ->getId(),
              'onload' => 'drupalRecaptchaOnload',
              'render' => 'explicit',
            ],
            'absolute' => TRUE,
          ])->toString(),
          'async' => TRUE,
          'defer' => TRUE,
        ],
      ],
      'recaptcha_api',
    ],
  ];
}

@lamp5 That sounds like an interesting discussion for a followup issue. @hass Would you mind looking at #136? It has several RTBCs at this point.

@hass #136 still working fine with latest 8.x-2.x-dev, any else follow up required?

I backported #136 for Drupal 7. I was having some issues and this solved it.

Back to RTBC for #136

Patch #136 reroll via 8.x-2.x-dev...

No interdiff (just diff) could be given due to following error message:

1 out of 3 hunks FAILED -- saving rejects to file /tmp/interdiff-1.5vpeXE.rej
interdiff: Error applying patch1 to reconstructed file

How annoying for a RTBC issue...

Patch #51 solved the issue for me.
Drupal 7.61
reCAPTCHA 7.x-2.2
Webform 7.x-4.17
Webform AJAX 7.x-1.1

Patch #156 solved the issue.
Drupal 8.6.5
recaptcha 8.x-2.x-dev

#98 for Drupal 7.61 with last Webform and Recaptcha works OK, thanks.

Sorry that I keep facing below error message (e.g. at /user/login):

CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists.

Most likely #2893656-8: Getting a "CAPTCHA session reuse attack detected" error. related issue, and so backport changes as below:

diff -u b/recaptcha.module b/recaptcha.module
--- b/recaptcha.module
+++ b/recaptcha.module
@@ -85,9 +85,10 @@
             '#value' => 'Google no captcha',
           ];

-          // As the validate callback does not depend on sid or solution, this
-          // captcha type can be displayed on cached pages.
-          $captcha['cacheable'] = TRUE;
+          // Prevent "CAPTCHA validation error: unknown CAPTCHA session ID"
+          $captcha['cacheable'] = FALSE;
+          $captcha['form']['captcha_response']['#cache'] = ['max-age' => 0];
+          \Drupal::service('page_cache_kill_switch')->trigger();

           // Check if reCAPTCHA use globally is enabled.
           $recaptcha_src = 'https://www.google.com/recaptcha/api.js';

Hopefully this fix the problem :-(

There are a few issues with the latest 8.x-2.x patch in #160:

1. The grecaptcha library is not available when loading reCaptcha through Ajax, causing an early returns in js/recaptcha.js. The reCaptcha is not displayed to visitor. The grecaptcha global needs to be loaded through a library for it to be executed correctly. The last patch that included this change is #111.
2. The issue is tagged as 'Needs tests' to show reCaptcha is now executed in content loaded through Ajax, but the patch does not include a JavaScript test.
3. The current assertion to check if reCaptcha is executed only checks for the existence of the rendered markup where the reCatcha should be loaded, but not if the reCaptcha javascript is actually executed. The existing browser ReCaptchaBasicTest cannot test this, because it does not execute JavaScript.

patch #51 worked for me (D7.60, CTools Auto-modal 7.x-1.1, reCAPTCHA 7.x-2.2 + mailchimp + custom form)
It has only one problem, the recaptcha.js was located in the root folder I had to move it into recaptcha folder manually.
Thanks for it!

There's a typo in recaptcha.js of #115 which ends up throwing an exception in console:

@@ -76,7 +76,7 @@
       });
       if (Drupal.ajax && Drupal.ajax.instances) {
         $(Drupal.ajax.instances).each(function (idx, instance) {
-          if (instance.$form && instance.$form && !instance.recaptcha) {
+          if (instance && instance.$form && !instance.recaptcha) {
             var recaptcha_div = instance.$form.find('.g-recaptcha');
             if (recaptcha_div.length) {
               var existing_beforeSubmit = instance.options.beforeSubmit;

Add grecaptcha library.

Patch #164 resolves the issue: recaptcha is shown after form errors using ajax submission.

The remarks in #161.2 and #161.3 have not been addressed yet.

Reroll of #98 for 7.x-2.3

When I add patch #168 the recaptcha check box is no longer showing up and am seeing the following error in dev consol:

reCAPTCHA couldn't find user-provided function: drupalRecaptchaOnload

Disregard. I see now that the recaptcha.js file needs to be moved to a js folder within the module folder.

For 7.x-2.x
Re-roll of #98

Edit: Gah, sorry, I'm on auto-pilot. Use #168

I've built on some of the updates in #164 / #111 using a library while also preserving the cacheable captcha form element & the use_globally feature. This update uses a ConfigEventSubscriber to rebuild the library_info cache when the use_globally setting is changed. I've also removed the html_head script tag from the captcha element.

I've added a Javascript WebDriver test for a form loaded via ajax and submitted/validated via AJAX. This test also allows testing of the verified recaptcha submission.
Changes in the existing ReCaptchaBasicTest are to errors I was receiving with assertions expecting strings and receiving TranslatableMarkup and using element selectors rather than text search for the g-recaptcha element (fails with twig debugging enabled).

Patch #172 works like a charm! Thanks!

@malcolm_p any chance of an interdiff to aid reviewers please? Or do your changes mean an interdiff isn't really applicable?

@james.williams Sure, I started from # 160 so there are a lot of code additions from #111 merging that functionality as well.

Applied #168 manually on 7.x-2.3 - it worked perfectly! Thanks!

Applied #172 on 8.x-2.4 with git and it works thanks!

I just applied #172 on 8.x-2.4 via composer. Tested on webform 8.x-5.1 everything seems to work. Thank you.

Today I give a reroll to #2493183: Ajax support / Use behaviors again...

Similar as #2493183-180: Ajax support / Use behaviors commented...
I am not a big fans for adding in more fix...
It already get stuck since 22 May 2015...
At least #160 working happily for my client(s) for more then 3 months...
Please kindly let it RTBC...

I have applied #172 on 8.x-2.4 via composer and looks like it solved my problem:

due to BigPipe (enabled by default since 8.5.x in the standard profile) the main document frame (with <head>...<head>) arrives first and blocks arrive later via AJAX. In these cases ['#attached']['html_head'] in recaptcha_captcha() won't take any effect and the required https://www.google.com/recaptcha/api.js won't be loaded at all. That's why the reCAPTCHA widget is not rendered in 8.x-2.4 when it appears in a block.

We also confirm #172 works.

#172 did not apply cleanly for us on 8.x-2.x (see below) however #164 works fine for us.

$ git apply -v recaptcha-ajax-2493183-172.patch
Checking patch js/recaptcha.js...
Checking patch recaptcha.libraries.yml...
Checking patch recaptcha.module...
Checking patch recaptcha.services.yml...
Checking patch src/EventSubscriber/RecaptchaSettingsConfigSubscriber.php...
Checking patch tests/modules/recaptcha_test/config/install/captcha.captcha_point.recaptcha_test_ajax_form.yml...
Checking patch tests/modules/recaptcha_test/recaptcha_test.info.yml...
Checking patch tests/modules/recaptcha_test/recaptcha_test.routing.yml...
Checking patch tests/modules/recaptcha_test/src/Controller/RecaptchaTestAjaxFormController.php...
Checking patch tests/modules/recaptcha_test/src/Form/RecaptchaTestAjaxForm.php...
Checking patch tests/src/Functional/ReCaptchaBasicTest.php...
error: while searching for:
    $edit['recaptcha_secret_key'] = '';
    $this->drupalPostForm('admin/config/people/captcha/recaptcha', $edit, t('Save configuration'));

    $this->assertSession()->responseContains(t('Site key field is required.'), '[testReCaptchaConfiguration]: Empty site key detected.');
    $this->assertSession()->responseContains(t('Secret key field is required.'), '[testReCaptchaConfiguration]: Empty secret key detected.');

    // Save form with valid values.
    $edit['recaptcha_site_key'] = $site_key;
    $edit['recaptcha_secret_key'] = $secret_key;
    $edit['recaptcha_tabindex'] = 0;
    $this->drupalPostForm('admin/config/people/captcha/recaptcha', $edit, t('Save configuration'));
    $this->assertSession()->responseContains(t('The configuration options have been saved.'), '[testReCaptchaConfiguration]: The configuration options have been saved.');

    $this->assertSession()->responseNotContains(t('Site key field is required.'), '[testReCaptchaConfiguration]: Site key was not empty.');
    $this->assertSession()->responseNotContains(t('Secret key field is required.'), '[testReCaptchaConfiguration]: Secret key was not empty.');
    $this->assertSession()->responseNotContains(t('The tabindex must be an integer.'), '[testReCaptchaConfiguration]: Tab index had a valid input.');

    $this->drupalLogout();
  }

error: patch failed: tests/src/Functional/ReCaptchaBasicTest.php:84
error: tests/src/Functional/ReCaptchaBasicTest.php: patch does not apply
Checking patch tests/src/Functional/RecaptchaJavascriptTest.php...

I have applied #172 8.x-2.x and it does not work for me.AJAX recaptcha is still not working.
please kindly let me know how to fix it by apply patch.

#172 works for me. Before applying had problems with displaying Recaptcha on comment form. On Webforms it had worked fine.

I have a form with File field to allow user to attach documents and uses recaptcha module but I can't submit the form. I pass captcha challenge and verify before I submit the form but this recaptcha module keeps blocking and I can't submit the form. This is the error I get in the log.

webform_submission_psa_leads_test_form post blocked by CAPTCHA module: challenge reCAPTCHA (by module recaptcha), user answered "Google no captcha", but the solution was "4b4ec7d3ccf0422bb4b865b1a0a554d09fcadda0cab4ff1ee04b320b059bead4".

None of the above patches works for me.

The patch #172 works for me, thank you.

#172 works for me as well. Loads with contact form ajax enabled.

#172 is working perfectly for us since several months now. The ones reporting that patch #172 doesn't work for them: Could you please describe in detail:
1. If recaptcha is working as expected for you WITHOUT the patch
2. What's your specific use-case for recaptcha (HOW are you using it)
3. What's the problem appearing and how can we reproduce it?

Thank you!

#172 works fine for us -:)

It would also be useful to hear from anyone who isn't getting #172 to work for them if they are using any other modules or customizations that might interfere with the captcha on the form.

Also any kind of failing tests would be greatly appreciated as it gives us something to work off of to get this issue to RTBC.

Everyone reporting that it works seems to be mentioning that they're applying it to 8.x-2.4 ~ a tagged release. It doesn't apply cleanly to HEAD, it just needs rerolling that's all.

re-roll for 8.x-2.x-dev

Any plans for a new release?

Hi I tried to apply the patch with stable release 8.x-2.4 but patch apply failed. So checked with git apply --check . But it shows ReCaptchaBasicTest file has some error at line 87. So re-rolled the patch for stable version. I know it is working for dev version of module. But it will be helpful for stable release version.

I am using 8.x.2.5 and it still appears to be broken? How can I apply the patch to this version please?

re-roll after 2.5 release

fix imcomplete patch from #197

I have downloaded and unzipped a copy 8.x.2.5 to "C:\Patch\recaptcha", downloaded the patch and am using TortoiseSVN to apply the patch. When i do so it says "C:\Patch\recaptcha" is not a valid working copy? In the folder I have folders like "config", "src" and "recaptcha-php" but the patch seems to be looking for a "js" folder? Sorry, I am new to this!

Ignore me, used git and it worked perfectly. Thanks!

#199 on 8.8.2, recaptcha 2.5.0 and webform 5.8.0 works good!

With patch on #199 form recaptcha (2.5.0) appear on my modal but I trie to submit this I have recaptcha error The answer you entered for the CAPTCHA was not correct. when I checked well recaptcha

#199 works great for me, applied it on top of 8.x-2.5.

My setup:

- reCaptcha v3, using reCaptcha as fallback.
- AJAX-submitted form: #199 gets reCaptcha to show up after a submission fails reCaptcha_v3 validation; without the patch, it didn't show (due to missing Drupal behavior).
-- Submitting without solving reCaptcha shows the proper validation error.
-- Submitting after solving reCaptcha gets the submission to succeed.
- Normally-submitted form: reCaptcha shows up after a submission fails reCaptcha_v3 validation; this was working fine before applying #199.

#199is work for me Thanks!

Thanks! #199 worked for me too.

I've applied the patch in #199 months ago (Can't remember when exactly!) and it worked perfectly, but recently, I'm experiencing the same issue again. I'm on Drupal 8.9.2 using reCAPTCHA version 8.x-2.5.

The ajax submit has stopped working for anonymous users after completing the recaptcha and submitting the webform.

The expected behavior is when I submit my webform the form is replaced with the success message. This happens if I'm logged in or if I submit the form without validation, get the Drupal captcha error, then complete the recaptcha, then submit the webform.

I am using Drupal 8.9.2, webform 5.19, catcha 1.1.0 and tested with recaptcha [2.x-dev, 2.5 and 3.0].

Patch from #199 is working for me with D 8.91, webform 5.18, ReCaptcha 3.0.

For those reporting that it stopped working, can you confirm that the patch was still applied? Could your issue be that you performed an update and for some reason this patch was not reapplied?

@sonfd Yes, I can confirm that the patch in #199 stopped working while it is still applied.

I need to test the patch on Drupal 9, but it wouldn't work due to the missing core_version_requirement in the info file of the test module added in this patch.

Thus here a patch that makes the module with this patch applied work on D9.

Im getting error in console reCAPTCHA couldn't find user-provided function: drupalRecaptchaOnload after patching and recaptcha is in module/js.recaptcha. What could it be?

@s_leu thank you for that update. I can confirm the patch in #212 fixes an issue we were now seeing now running Functional tests in our custom modules:
Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' constraint (9.0.7) requires the 'core' key not be set in modules/contrib/recaptcha/tests/modules/recaptcha_test/recaptcha_test.info.yml

Hi, guys.
I got another take on the problem and kind of applied solution from https://www.drupal.org/project/recaptcha/issues/1463768
It works for us and if you desperate - try it.

confirming that patch #215 fixed the issue for us

Updating the #71 patch to make it work correctly on 7.x-2.3.
I also added a new verification to make sure that the code won't break when some functions are not defined yet.

The patch for D7 from @rafaelrs is a re-roll of #71, but there was a patch in #168 for D7 that added a fix because there were issues identified with #71.

Regardless, given that #2875698: Drupal 7.x: Ajax support / Use behaviors for 2.x and #1463768: reCAPTCHA in Modal Forms exist for getting this kind of functionality into D7, I suggest this ticket should ONLY be used for D8 work?

Meanwhile, I've hidden what I believe are the oldest patches, so just the 'tips' of each 'branch' of work remain shown for review.

To that end I've posted an updated Drupal 7 patch to #2875698-15: Drupal 7.x: Ajax support / Use behaviors for 2.x.

In my case, I needed to "recreate" the recaptcha after my webform validation:

grecaptcha.ready(function () {
        var el = $('.g-recaptcha', context);
        if (el.length > 0 && el.children().length == 0) {
          grecaptcha.render(el.get(0), {
            sitekey: el.data('sitekey'),
            theme: el.data('theme')
          });
        }
      });

By doing this on a JavaScript behaviour that's loaded on the page I was able to make it work.
My recaptcha is currently at version 8.x-3.0

Just an update on patch #199,

It is working for me so far on Drupal 8.9.13, Recaptcha 3, Captcha 1.1

#220 worked for me, I was having problems with Webform + ajax. The Javascript worked perfect for version 2.5.
Thank so much Yuri Morato Duarte, great work around.

#199 worked for me.

Drupal core 8.9.16
CAPTCHA 8.x-1.2
reCAPTCHA 8.x-3.0

Thank you.

#199 worked for me.

Drupal core 9.1.8
reCAPTCHA 8.x-3.x-dev

Thank you!

Drupal 9.1.9
reCaptcha 3.0

$drush updb -y
The 'core_version_requirement' constraint (9.1.9) requires the 'core' key not be set in modules/contrib/recaptcha/tests/modules/recaptcha_test/recaptcha_test.info.yml

Updated patch #199.

Updating #225:

• Remove leftover .patch file
• Add back core: 8.x in the test module, to match recaptcha.info.yml

The interdiff does not include the removal of the .patch file.

This is #199, updated to apply on recaptcha 3.x (3.0 in my case), running on Drupal 9.1.9.