Ajax support / Use behaviors

#258 worked for me.

Drupal core 9.5.3, Ajax Comments 8.x-1.0-beta5, PHP 8.0.27.

Thank you!

💬 Any active maintainer left here? vs. frequently used module Fixed
Nothing more to say? Any candidates?

re-roll #258

#273 Patch can't be able to apply.
kindly,rework on this

Patch #273 applied successful for me. Thanks.

Patch #273 looks good to me as well. Thanks @slasher13!

Patch #273 applied successfully for me. Thanks.

Thanks @slasher13, patch #273 works fine for me

patch #273 works with me

Patch #273 was applied successfully and it works fine for me. Thanks.

Patch #273 🐛 Ajax support / Use behaviors Fixed worked perfectly, with this patch recaptcha in modals was solved. Thanks.

Patch #273 tests good

Patch #273 was applied successfully and it is been working fine for the webform in the modal!

Thanks @slasher13

Patch looks good to me and has been successfully tested by all the above; marking RTBC.

Patch #273 works.
+1 RTBC

Patch #273 was applied successfully and it works fine in drupal ajax modal.
Thanks @slasher13

Hi,

Fix for the issue of Unable to install modules: module 'recaptcha_test' is incompatible with this version of Drupal core. Please review.

Thanks.

The last submitted patch, 288: recaptcha-ajax-support-2493183-288.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Hi,

Fix for the error The 'core_version_requirement' constraint (^8.9 || ^9 || ^10) requires the 'core' key not be set in modules/contrib/recaptcha/tests/modules/recaptcha_test/recaptcha_test.info.yml. Please review.

Thanks.

Back to RTBC for #273 with many RTBC votes.

#288 + #290 seem unrelated to this issue.

Anybody → closed merge request !9

Anybody → closed merge request !23

@all: Please help testing and reviewing MR!24 based on #273 so we can hopefully end this never ending story soon. Thank you!

eslint and phpcs are unhappy, but tests are green now. Could someone fix that finally?
https://git.drupalcode.org/project/recaptcha/-/pipelines/63104

Manual testing is still welcome!

I'm update module in 3.2.0 version with patch #273

#273 fixed the initial issue of the captcha being unusable on a multistep form, but the captcha module persistence settings do not appear to be honored. The recaptcha appears on every step of the multistep form regardless of the persistence settings.

@matthewmessmer thank you! Can you elaborate, if it worked as expected without the patch? Then we should add a test for that and fix it. Would be super nice to have more community contribution here to get this finished!

I found this issue because I was experiencing an issue on a multipage form with AJAX enabled for validation. I installed the patch #273 and now it's working, but not ideally.

To resolve the issue with the form not recognizing multipage and putting captcha on every page, I moved the captcha inside the last page, where the submit resides. It's interesting that the "I'm not a robot" is showing but not the reCAPTCHA logo on the bottom of the page. All of my other forms do not require human interaction.

Therefore, I don't know if #273 totally solves it because it appears a backup form is placed on the page, and the reCAPTCHA button is not showing on the bottom right of the page. I prefer the checkbox to a math quiz, so I'm keeping this in place, but it's my understanding there shouldn't be a form input at all.

Adding to the discussion, it appears that the persistence settings were previously overlooked #3363653 🐛 reCAPTCHA ignores “Omit challenges in a multi-step/preview workflow…" setting Needs work and not related to the patch.

#273 worked for me also, Thanks @slasher13. Is there anyway we can commit this and fix the issue with multiform AJAX as a followup ticket

I have tested patch #273 Thanks @slasher13

Environment tested on:
Drupal 10.1.6
Php 8.1.21

Version: Recaptcha 8.x-3.2

Issue prior to patch:
We were using a basic webform with all fields required, with ajax enabled (not multi-step) in a block to collect anonymous user feedback. With persistence set to: "Omit challenges in a multi-step/preview workflow once the user successfully responds to a challenge." and captcha added directly to the webform rather than as a captcha point within the block (however adding the captcha point within the block had the same result). If the anonymous user failed to enter one of the required fields or pass the captcha, the captcha would not display post initial submission. Disabling ajax resolved the issue but was not an option in this use case.

After applying the patch:
The captcha was shown as expected post failed webform submission within the webform block.

One issue I've now encountered with the patch in #273 is that it adds a new functional test, but the setUp function there does not have the void return declaration, which results in throwing an error if I try to run any functional tests. See https://www.drupal.org/project/recaptcha/issues/3446000 🐛 Functional Tests: Declaration of Declaration of Drupal\Tests\recaptcha\Functional\RecaptchaJavascriptTest::setUp() Closed: duplicate . I added that to an updated patch here.

My editor (VS Code with a Drupal formatter) is pointing out other issues with that file, but those ones don't stop me from running other tests, so I'll leave that to those who are working on that test.

I have the #273 patch installed in a multilanguage website. The webform loaded using ajax works correctly in all languages. But a new webform was created in the website and that form doesn't load with ajax. The result is that the recaptcha loads in english but not in other languages. And is something in this patch because, if I remove the patch, the recaptcha in the non-ajax webform works correctly in all languages and the recaptcha in the webform loaded using ajax stops working.

MR24 works well for me too; thanks all!

The change added in the latest patch in #313 is already included in MR24 (it's just https://git.drupalcode.org/project/recaptcha/-/commit/e1e62e0a3fdabfb4f0...), so can be ignored as we should all be working with the merge request, not patches, nowadays. (Which is why I've also hidden all the previous patch files to try and give more prominence to the MR instead.)

@sebasgd thanks for reporting your issue about languages in #314. Please can you confirm what the language codes you have configured in Drupal are, which incorrectly showed the recaptcha element in English on your non-Ajax form? The work here assumes the language codes configured in Drupal match those that Google expects, so I wonder if it could have just been due to them not matching up? Google's documentation does say that they can auto-detect the user's language; I wonder if they do that slightly differently between the non-ajax recaptcha widget rendering, and the new explicit rendering through javascript. So could you also let us know which language(s) your browser is configured to use, to help diagnose the issue?

@Anybody thanks especially for having taken on maintainership of this module. What would you like to see happen here before merging it? Do you feel the languages issue is a blocker? I could believe it is; but otherwise maybe we need to be really strict that further change should be dealt with in follow-ups rather than drag this issue out any further?

@james.williams thank for your feedback! What would you think about a new 4.x branch starting with the changes from this issue?

It would be great if we could fix the language issue, of course, and hopefully it's not too hard? But I wouldn't see it as a hard blocker looking at the relevance and history of this issue. I very much hope it won't have a 10 years anniversary ;)

Great! Yes, I'm all for this being in a new release soon please :) I would just stay on the 8.x-3.x branch though, it's not a backwards-compatibility break is it? If you're thinking of jumping just for the sake of using semantic versioning, I'd counter that with the fact that anyone using standard composer constraints (e.g. ^3) has to manually change their constraint, which isn't ideal - especially if there was a later security update that came with more urgency. But of course I'm not aware of your plans; maybe you have other reasons to look to break backwards-compatibility?

Current state of the MR as static patch attached for the time being.

@S_Bhandari deleted the issue summary in #287!
But it was poor in general, so could someone please create a helpful issue summary based on the template?

If someone would like to finish this, please find a fix for #314, so we can finally merge this.

I've had a go at setting the issue summary, hopefully it's sufficiently accurate. Setting back to 'needs work' though to investigate/resolve that remaining possible multilingual issue then. Although as I wrote in my comment, I do wonder if it's just down to a misconfiguration which is probably out of scope to resolve here. I'll try reaching out to @sebasgd by other means to see if we can get feedback!

Very nice work! Looking good! 🙂👍

I agree with @james.williams, since we do not introduce any breaking changes here, I'd say we can safely merge this in 3.x (once the multilanguage issue is fixed).

I'll see if I can properly reproduce it.

Ok, the multilanguage bug is quite minor in my opinion. Once a new language is added and set as the default language, the recaptcha won't appear. We first need to clear all caches before the captcha appears (with the correct language set. Tested it with spanish, german and french as both the default language and per url language prefix).
Switching the default language to an already added language works flawlessy and without clearing any caches.

I tested this through the login captcha endpoint (no ajax) and through our test endpoint (/recaptcha-test) both use the currently set language as expected.

Furthermore, this little newly added language bug is also happening in 3.x, so it's unrelated to this issue anyway. Cleaning up the code a bit now.

Re #323 thanks @Grevil!

Could you then please create an issue for that? Sounds like cache tags or contents are missing then, but I agree it's an edge-case and unrelated then. No blocker for this issue.

Oh no, the fact that we are using external scripts hosted by Google probably makes this not DSGVO compliant...

Let's see what @Anybody has to say about this.

@Grevil: No, recaptcha is external 3rd party by definition. There's no way around the external script loading. Not related to this issue and if someone needs a solution, there's COOKiES recaptcha submodule for example.

People using recaptcha have to be aware of the data privacy consequences generally!

Ah, of course, my bad.

Alright! Everything else is fine! Fixed the remaining js and phpcs issues. Tests are good and all green! Couldn't reproduce the multilanguage bug after extensive testing. All good from my site!

RTBC!

Thanks all! Okay then let's do it! I'm going to merge this one after 328 comment. I hope this doesn't only feel great for all of us, but also works well! 🎉

Thank you so much!

Will this be in a stable release within the next few days?

We're close to deploying an update to production, and the patch doesn't work against the stable release anymore, so I think I need to put the dev release into production if there isn't stable soon, which I am generally not eager to do.

@ryanrobinson_wlu yes, let's do it! No complaints since merge, I'll tag a new stable release containing this.

Thank you!

Patch was working for me on 10.2.6 php 8.1 however, none of the patches or module versions apply for 10.3.2. Beware if invisible captcha is placed on login pages, user will be locked out and have to disable or uninstall via drush/db.

@xeiro I don't really get your point.
This issue is fixed in recaptcha 8.x-3.4! No more patch needed for this.

@Anybody, sorry, I posted to the wrong issue. 2852269 - "Integrate Invisible reCAPTCHA option from Google" was my issue and I posted the relative info there. All good now, thanks.

Automatically closed - issue fixed for 2 weeks with no activity.