🇺🇸United States @greatmatter

Please try out the dev version and let me know if it's working the way you intended.

Ok, it's all fixed in 1.1.17. Thanks, everyone!

Hm. I wonder why it's working in our sites. We're behind Cloudflare, but don't use RocketLoader. We also have SameSite=Lax - so I'm wondering if that plays a role. I'm open to ideas of how to make this work.

@keiserjb - what errors are you getting in the console?

The big change between versions was how the main Cloudflare Turnstile script was being included. We could add to the turnstile_library_info_build() the defer and async attributes--would you mind testing that to let me know if that changes anything? I'm not going to make a patch before knowing if it works for you.

I cannot seem to replicate this issue. The code you sent will likely break the Form/AJAX functionality (using EventSubscriber) introduced in 1.1.10.

I'm wondering if, for some reason, the

Please try resaving your keys--I'm wondering if something weird happened with the upgrading/downgrading.

How odd--I've tested it across our sites--would you mind clearing your caches (including edge caches, if any)?

Would you mind letting me know if 1.1.16 fixes it for you?

I think I got it--I've just pushed a hotfix to 1.1.16

What error (if any) are you receiving?

Is this backwards compatible with D10?

Turnstile has a "data-callback" parameter, however, it could potentially auto-submit the form before the user is ready.

Unfortunately, I'm not sure what's causing your issues. We have several sites that are running this module without any issues.

This appears to be an issue with Turnstile, and not the module. We don't use eval(), new Function(), setTimeout([string], ...) and setInterval([string], ...) in the module itself, but it's present in the hosted file from Cloudflare.

Is the actual CAPTCHA working as expected, or is it just in this demo screen that you're seeing the issue?

Thank you @guilhom - composer dump-autoload -o did the trick.

You got it! It's in 1.1.13 now.

Apologies; the latest release should have all of these patches.

Thank you for your work on this--will test & review!

@parisek I was just trying to troubleshoot the other issue (we don't utilize it this way). I'll probably have to refactor the module, but since so much of it was taken from the reCAPTCHA module, I'll hold off until it supports ^11.

greatmatter → created an issue.

Ah, it looks like it's an AJAX form. This may be a duplicate of https://www.drupal.org/project/turnstile/issues/3330710 🐛 Turnstile's api.js is not getting loaded when form is loaded through Drupal dialog Needs work - would you mind having a look at that, please?

On what kind of form has it been placed (custom, Webform, node, etc)?

@seonic I hope things are going OK for you.

Do you have plans to add Drupal 11 compatibility?

Hi! Have you considered using

$config['turnstile.settings']['site_key'] = $_ENV['YOUR ENVIRONMENT VARIABLE NAME'];
$config['turnstile.settings']['secret_key'] = $_ENV['YOUR ENVIRONMENT VARIABLE NAME'];

in $settings.php, or am I missing the point?

We enabled the "Allow your users to save and finish the webform later" and "Automatically save as draft when paging, previewing, and when there are validation errors" to help track issues, but honestly, we still can't seem to replicate the issue consistently.

I'd feel a lot more comfortable adding a settings option with separate testing keys; would that work for you?

Hrm--I wonder if the issues are related. (I did have AJAX enabled on my form)

Unfortunately, I'm not sure--my own use cases don't use AJAX, so my testing is a bit limited.

This patch doesn't work when AJAX is not enabled, unfortunately, including other non-webform forms.

Sure thing, I've attached it here → .

Of course. Here's the form:
https://sanmarinomotorclassic.com/vehicle-application

The payment is on the second page.

Regarding Drupal: Latest (10.2.4), Webform is latest stable.

Note that this hasn't happened again since 2024-02-27 - so maybe it was temporary? I wish I had more to give you.

Thank you, Stefanos! I've merged it, and added it to a dev release for testing. Once it's RTBC, I'll make it a supported release.

An update: the payment is not being stored, and the browser is receiving an error:
"Oops, something went wrong. Check your browser's developer console for more details."

The console:
"Failed to load resource: the server responded with a status of 500 ()"
and
Drupal.AjaxError

This is no corresponding error message in watchdog, despite this being a 500 error.

The server log is showing an "out of memory" error, with 256MB allocated via php.ini.

Apologies--this is on the 3.0.x branch.

I believe we are experiencing the same issue, albeit extremely intermittently:

Clearing the caches immediately fixes the issue for at least 2 days; but it inevitably crops up again, albeit inconsistently. (Unfortunately, it's always the client who lets us know there's an issue, and it's always after hours, of course!)

While we haven't tried disabling aggregation yet, we have tried disabling Redis, as it seems this happens when it's at its maximum size. I'll report back to let you know if this works...

greatmatter → created an issue.

greatmatter → created an issue.

Hi--I didn't get a notification on your reply, sorry!

Multipage IS enabled, AJAX IS enabled.

@scottsawyer - Thank you--this did the trick--found a custom module doing just that. I owe you a beer...

@cilefen - First and foremost: thank you for your guidance! This issue is obviously not a bug. And I learned something new today about SameSite. (For anyone else landing here for whatever reason, read this article about Same Site cookies, as I had no idea this setting impacted referred links.)

Back to the solution: Following your steps:
SameSite=Strict is on the session cookie (I stumbled across this thread while quadruple-checking things, heh)

After setting SameSite=Lax, the link is working as intended.

The access log shows the correct link (though it doesn't matter, as the SameSite setting was causing the issue):
/user/login/?destination=/protected-page

Thank you again!

It's the same exact link; I even looked at the email source and pulled the link directly.

I then tested by putting the link into another website, clicking it, and had the same issue.

greatmatter → created an issue.

@cilefen Possibly, though I don't have IMCE on any of my sites.

This might play a bigger role:
https://www.drupal.org/node/3363700 → - file_validate and related functions are deprecated and replaced with file.validator service and Constraint plugins

@cilefen thank you. I don't have anything like that in the config folder, but I do see the following in my site filebase:

[ROOT]/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php:245:    // Define 'webform_file_validate_extensions' which allows file
[ROOT]/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php:247:    // 'webform_file_validate_extensions' will be ignored by file_validate().
[ROOT]/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php:251:    $element['#upload_validators']['webform_file_validate_extensions'] = [];
[ROOT]/modules/contrib/webform/includes/webform.theme.inc:665:  if (isset($upload_validators['webform_file_validate_extensions'])) {

While this is probably not the long-term fix, I commented out line 251 of [ROOT]/modules/contrib/webform/src/Plugin/WebformElement/WebformManagedFileBase.php:251

And this error goes away... But I'm worried that I'm opening a can of worms.

greatmatter → created an issue.

greatmatter → created an issue.

greatmatter → created an issue.

No--I don't have a stack trace, but because the site is in prod, I don't have a good way of debugging it that deeply. I'll check out our other sites and let you know if I see anything that points to Simple XML sitemap...

Is this solvable?

...oy. There's the problem. I chose the wrong version for the issue. We're using drupal/address 1.12.0.

I'm sorry...

Understood, and agreed. I wasn't sure where the issue originated. Thank you!

@kashalinka: My pleasure. Question: did you install the module via composer? I ask because when I ran the update via composer, it automatically added the drupal-superfish folder.

@mingsong: Are you saying that this is an issue with the Smart Date module, or that the Fullcalendar View module is simply incompatible with the Smart Date field? I ask because we utilize the functionality of the Smart Date module, making it hard to move away from it.

It appears the latest Webform RC has broken this--I'm not entirely sure why, however...

Of course:
commerceguys/addressing:1.4.2
doctrine/collections:2.1.4

Line 47 of superfish.js has an error:

o.$path = $('li.'+o.pathClass,this).slice(0,o.pathLevels),

should be

o.$path = $('li.'+o.pathClass,this).slice(0,o.pathLevels);

Wonderful, thank you!

We're running Drupal 10.1.5, and we installed Address via Composer.

Thank you! Do you know when this is going to be pushed to release?

greatmatter → created an issue.

greatmatter → created an issue. See original summary → .

greatmatter → created an issue.

Thank you for a fantastic module! Do you know when this patch will be added to the release?

greatmatter → created an issue.

@lendude - It's hard to say, because I was notified by a volunteer. If I had to guess, it was around the time we updated the site to Drupal 10, but I can't be sure.

This issue has reappeared. I'm not 100% sure when it cropped up--but definitely within the last couple months. Is there a chance to reopen this?

In case anyone lands on this, our workaround is to enable "rewrite results" for the field, and use twig:
{{ created__value|date('D, d M Y H:i:s O') }}
This "fixes" it.

greatmatter → created an issue.

Reviewed, committed, and pushed. Thank you!

Bob--we've added most of the new attributes; please let us know if you see any issues!