You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are currently in the process of adding CAPTCHA verification into our Custom Policy sign up flow to protect against malicious behaviour.
Following this guide, we have implemented CAPTCHA and it is working, however the side-effect here is that upgrading the selfasserted page version to 2.1.27 (or 2.1.30 which actually seems to be the correct version as documented here, breaks the 'required field is missing' error message that appears at the top of the sign-up form in our UI template if the user attempts to submit the form before filling in all required fields.
I've further narrowed this down to changes in page layout version 2.1.20
i.e. version 2.1.19 shows the error at the top, and version 2.1.20+ does not
Here's what it looks like when it's working as expected (after having attempted to submit the form):
And here's what it does now (i.e. no error, field is focused as that's a new feature since upgrading from our previous version of 2.1.8):
Due to how we've structured the page and hint text, and the large number of fields, we don't show the error for every field as it's very noisy to the end user, and instead just relied on this error at the top to guide the user through the form, which no longer works.
Previous versions of the page layout automatically switched the styles on the #requiredFieldMissing<div> element to show the error at the top (e.g. switch the display and aria-hidden values) but this is no longer the case on page layout version 2.1.20+.
I also looks to be that other 'top level' form errors have the same issue here, such as "fieldIncorrect" and "captchaUnresolved" which should be showing error messages at the top of the form when the form is in the correct state, but are not.
If there's a new setting I should be applying to the technicalProfile to enable this to work again, do let me know, but nothing I've seen in the documentation thus far seems so relate directly to this, and so this looks to me like a bug introduced @ version 2.1.20
The text was updated successfully, but these errors were encountered:
We are currently in the process of adding CAPTCHA verification into our Custom Policy sign up flow to protect against malicious behaviour.
Following this guide, we have implemented CAPTCHA and it is working, however the side-effect here is that upgrading the
selfasserted
page version to 2.1.27 (or 2.1.30 which actually seems to be the correct version as documented here, breaks the 'required field is missing' error message that appears at the top of the sign-up form in our UI template if the user attempts to submit the form before filling in all required fields.I've further narrowed this down to changes in page layout version 2.1.20
Here's what it looks like when it's working as expected (after having attempted to submit the form):
And here's what it does now (i.e. no error, field is focused as that's a new feature since upgrading from our previous version of 2.1.8):
Due to how we've structured the page and hint text, and the large number of fields, we don't show the error for every field as it's very noisy to the end user, and instead just relied on this error at the top to guide the user through the form, which no longer works.
Previous versions of the page layout automatically switched the styles on the
#requiredFieldMissing
<div>
element to show the error at the top (e.g. switch thedisplay
andaria-hidden
values) but this is no longer the case on page layout version 2.1.20+.I also looks to be that other 'top level' form errors have the same issue here, such as "fieldIncorrect" and "captchaUnresolved" which should be showing error messages at the top of the form when the form is in the correct state, but are not.
If there's a new setting I should be applying to the technicalProfile to enable this to work again, do let me know, but nothing I've seen in the documentation thus far seems so relate directly to this, and so this looks to me like a bug introduced @ version 2.1.20
The text was updated successfully, but these errors were encountered: