v5 Confirm field causes 504 error (Timeout)

[vonscriptor]

When I use a Confirm field and set its Target field it will cause the page the form is rendered on to timeout (504 error).

Steps to reproduce

1. Create a Confirm field
2. Set its Target field to another field

Expected behavior
The page should load and render the form.

Craft & Plugin Info (please complete the following information):

• Craft Version: 4.8.1
• Freeform Version: 5.1.2
• Freeform Edition: Pro
• Fresh Install or Upgrade: Upgrade

[kjmartens]

Sorry for the trouble @vonscriptor,

Can I ask what kind of field you're targeting? And what does the error say? (Check the Craft and Freeform error logs to see what shows up there). 🙂

[vonscriptor]

I am using Password w/ Confirm fields. The mentioned issue above by Romanavr might indicate that the field types don't matter though.

[kjmartens]

Hi @vonscriptor,

I can't seem to duplicate this issue on my end. I have set up a User Registration form that contains "Confirm Email" and "Confirm Password" fields, and they both work correctly. Can you confirm what the field handles for your Confirm field(s) are? And by chance, are you mapping the Confirm field to the User element Password field in the mapping table? If so, try mapping the regular Password field instead.

I'm also curious what the 500 error says (check the Craft and Freeform error logs to see what shows up there). 🙂

Thanks!

[vonscriptor]

Sorry I haven't been able to debug more. I see that you're working on the fix for #1130. It seems like that should also resolve this issue too?

[kjmartens]

The issue in #1130 has to do with conditional rules logic, unless that is what you meant with this issue? 🙂

[kjmartens]

I'll mark this as resolved for now, but let me know if you're still experiencing something different.

[vonscriptor]

With all of my issues trying to upgrade from v4 to v5 I did a fresh install and am recreating everything, but am still experiencing this issue.

If my sign-up form has the Confirm field it causes a 504 timeout.

Along with #1178 when I try to remove the confirm field it's deleting my Last Name field too.

I only have the one "Confirm" field (handle: confirm) which uses the Password field I added as its Target field. All form fields are required (First name, Last Name, Email, Username, Password, and Confirm). The Password field is what is set as the User's Integrations for Password (confirm is not mapped).

[kjmartens]

Sorry about this @vonscriptor.

Can you try the following:

1. Update to Freeform 5.1.11
2. Delete that User element integration entirely (from the form inside the builder).
3. Delete the User element integration from inside the settings area of Freeform.
4. Recreate the User element integration and reconfigure it in the form again.

Does that make any difference?

And to confirm, do your Craft logs show any errors about this issue? 🙂

[vonscriptor]

Going to email you some additional information.

[seandelaney]

@vonscriptor

I did some investigating and testing on my end. Looking at your phperrors.log, I spot there was a call to a limitByEmail in the form rendering. I was able to replicate the exact same errors as you in my own error logs if I setup a limit with a date.

Is there any chance that you also have a date setup too?

Can I please see your Limits settings:

[vonscriptor]

Hi @seandelaney, no date set but I do have the Anyone - Once per Email Address.

However, after toggling different settings and options I just realized that only when I set Duplicate Check to Anyone - Once per Email Address is when it causes this error (the date doesn't matter for me). I do need the duplicate check to function properly with the confirm field. I'm glad we've narrowed it down!

Let me know if there is anything else I can help debug. I appreciate the help on this.

[kjmartens]

Thank you for confirming this @vonscriptor. Now that we've figured out the cause of the issue, we can duplicate it on our end and will work on a fix for it. We should have an update early next week. 🙂

Thank you for your patience!

[kjmartens]

This should be resolved in Freeform 5.1.18 now, @vonscriptor.

Thank you for your patience! 🙂