Resolved
Reported for: Toolset Forms 1.9
When you set up a Toolset Edit User Form and include the Password fields, on the front-end those inputs are not populated with the user’s existing password but require you to input them.
If we compare this to WordPress’ existing native User Profile, we see that there we do not need to provide this data every single time we update the profile. This is because it is populated with the existing data already.
There is currently no workaround but to provide the password field values again when these are included in User Forms.
🙂 this is such an old bug.
Any chance we could get a fix for this or a workaround?
I am currently using ShortCode to populate the Forms Password Field ShortCode “value” attribute with it, but I do not really like this solution.
In case anyone needs this, the code:
add_shortcode( 'current_user_pwd', 'get_current_user_password_for_forms' );
get_current_user_password_for_forms($atts) {
$atts = shortcode_atts(
array(
),
$atts,
'current_user_pwd'
);
$user = wp_get_current_user();
$user_pwd = $user->user_pass;
return $user_pwd;
}
This is an old issue I’m not familiar with, so I just tested it on a fresh site, and I found that creating a user edit form with the GUI editor, the first password field **is** populated with the existing password, although if you have the option set that users must confirm the password, the second password field is empty. (In the browser inspector, the input appears to have no value, but that is how browsers handle the password type input field for security.)
This appears to be a non-issue which I should close, unless you have some more details…?
Hey Nigel – thanks for the heads up. I use the Advanced editor so I’ll have to check if maybe it’s a issue appearing only in that editor but I see both fields empty on several sites
It’s no big issue, let me make some tests to confirm and I’ll update you back here so you could then close?
I just want to be sure it’s actually populated in the first field when using the builder – as said I use the advanced editor in which case the file stays empty
Interesting enough if I leave it empty and submit the form it doesn’t “destroy” the old password so I guess your findings are correct and I’ll just have to add some nice hint for the user on the specific forms so they don’t get confused
Let me feedback tmrw, I’m on mobile …
Sorry Nigel for the late reply
So, I think this surged perhaps from a misunderstanding of how a PWD field should work in a Edit Form.
Actually, after studying several other such forms, I found that all those forms – in edit mode – say “New Password” and “Confirm new Password”
None lets you actually “edit” the existing password in the sense that it will – if you fill those fields – set a NEW password, logic somehow, but since we’re used to Forms EDITING things, somehow we expect(ed) that field to populate with the existing PWD, which obviously does not make much sense now that I thought a bit about it
It is all a question of the proper labelling of the field, in fact.
If I label it “New password” and “Confirm new Password” the “issue” is basically solved.
I did NOT find that (in advanced mode) Either of the fields is populated in any way, and actually, with above findings I would even consider it weird if it DOES populate such field lol (as you say it does in DnD Mode, but I did not check that, I never use that builder)
So, I think you may close here, perhaps, this discussion will help the one or other confused user – do NOT assume a PWD field in a form to be there to EDIT something, but rather, as it is in core WP and all other common PWD Edit forms/fields, it is assumed that if you fill it out then you want to test a NEW password.
Makes perfect sense, as said, the only question is how we label it.
Cheers.