Encapsulating validation logic in password confirm element

Created on 11 November 2013, over 10 years ago

Updated 7 April 2024, 3 months ago

Hi,
I suggest to give an approach focus in the password element instead of focus on the form for validation.

I suggest to encapsulate the validation logic applied to the password element, in the own element making use of hook_element_info_alter among others.

In this way we achieve a more robust approach because the validation will be always working if you use a password_confirm element in any form, including creation user form instead of having to alter every form.

Attaching a patch for this.
Following this approach it just would have to add the anonymous user in the admin settings. I can work on in that if this purpose go ahead.

Regards.

✨ Feature request

Status

Postponed: needs info

Version

3.0

Component

Code

Created by

🇪🇸Spain Enxebre

Live updates comments and jobs are added and updated live.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 3 months ago →
🇺🇸United States Kristen Pol Santa Cruz, CA, USA
Thanks to everyone for the work on this issue.

I'm going through all the 8.x issues.

As the 8.x is no longer supported, I'm postponing this issue for now and need feedback as to whether or not this issue is relevant to 4.0.x.

If it is, please reopen and change the version, make sure the issue summary is clear and complete, including concrete steps to reproduce, and reroll the patch. If it's not, please close.

If there is no response to this in a month addressing the above, it can be closed.

contrib.social Blog FAQ Discussions

Production build 0.69.0 2024