User Profile Update form does not save password
-
The for you created for updating a user profile does not update the user’s password field but does update other fields.
-
Hello,
You have to set a field in the “Password” setting of your “User Action” in order to update the password.
If you’re talking about my test form I shared here, it’s normal, because there is no field set in the “Password” setting as seen on the video demo at 00:06 (set to Default – Nothing).
Thanks!
Regards.
Sorry, I must have added the password field to your field group and form, but as you can see, I cannot assign it in the load or save tabs.
I suppose it’s just me not understanging again, can you have a look at this and let me know what I’m doing wrong please Field-Groups-?-The-Harrisons-Website-—-WordPress.mp4
Mant thanks
BTW, when clicking the drop down for password, I cannot enter anything into that field.
Hello,
Thanks for the video demo.
It looks like you’ve updated ACF to the latest 6.3.2 version. This version has issues with the Form UI, where you cannot find fields like in your video.
Please see my answer on your previous topic about this issue.
Thanks.
Regards.
Thank you Konrad, I did read that but as it didn’t mention fields I was dealing with, I assumed it wasn’t the problem. Anyway, I’ve down graded and it works. Another thing on your list to look at lol
Cheers
I thought it was working, but look at this
Hello,
Note the user won’t be updated if you try to update the email with an address that is already taken by another user account. The email must be unique for all users, this is the native WordPress logic.
Regards.
I suppose my porblem is that I’ve not worked with such a barebones toolset. I’ll have to change my way of thinking.
So, can I check if the email is already in use?
Many thanks
Hello,
You can use the
email_exists()
function (see documentation) inside a validation hook for example (see documentation).You can also update to the latest ACF Extended 0.9.0.6 version. It fixes the issue with the Form UI and ACF 6.3.2. This version now also display an error if the email is already used when you try to update a user (you must enable the “Builtin Validation” setting in your User Action).
Thanks.
Regards.
Konrad, I wondered if you saw my recommendation of your plugin over on the WPTUTS facebook group, an Paul Charlton’s comment about struggling with the documentation and examples?
Well, I’m having the same problem trying to use the validation hook. The example you pointed me to mentions 3 different actions. I’m assuming I should only be using one, but the document doesn’t make it clear. Can you help?
Manyt thanks
Pete
Hello,
Thank you for trying to promote ACF Extended, but this is really not needed, and actually probably counter-productive. The Facebook/YouTube public isn’t really the targetted audience of this plugin.
In fact, most of users there look for a more “What You See Is What You Get” solution with a plug & play experience, where they don’t need to mess with actual code/documentation/hooks/debugging. And it’s perfectly fine. There are plenty very popular front-end forms solutions in the WP ecosystem, for every kind of user.
One of the 3 pillars of ACF Extended philosophy is: made by developers, for developers. And the fact is, Facebook and YouTube aren’t social media for developers, so I would rather prefer stay out of there. Please note this is not gatekeeping or an attempt to set a minimum level entrance. I simply believe that as a professional, it is important to know who you are talking to, and not trying to promote the wrong product to the wrong audience, at least for ethical reasons.
Regarding your question, if you’re trying to implement the “email already exists” validation in your User Action, please note this check has been added in the latest 0.9.0.6 version, as explained in my previous answer.
The form will now automatically display an error in this case (if you correctly enabled the “Built’in Validation” setting). So you don’t need to implement it.
Regarding the ACFE Form Validation hooks, the 3 hooks you see are the available hooks variations. It allows you to target the User Action Validation, in different ways.
For example, this hook will validate any User Action, in any form:
acfe/form/validate_user
This hook will validate any User Action, in the form named
my-form
:acfe/form/validate_user/form=my-form
This hook will validate any User Action named
my-user-action
:acfe/form/validate_user/action=my-user-action
Most of the time, you only have 1 User Action in a form, so it’s common to just use the
/form=my-form
variation. As in the code example in the documentation:add_action('acfe/form/validate_user/form=my-form', 'my_user_validation', 10, 2);
function my_user_validation($form, $action){
// ...
}This logic is inspired by the ACF hooks variation logic, which allow to target fields by their
type
,key
, andname
using the same syntax. See documentation.// Target any field
add_filter('acf/update_value', ...);
// Target field with type "textarea"
add_filter('acf/update_value/type=textarea', ...);
// Target field named "hero_text"
add_filter('acf/update_value/name=hero_text', ...);
// Target field with key "field_123abcf"
add_filter('acf/update_value/key=field_123abcf', ...);Hope it helps!
Regards.
Thanks for this, and I hope you don’t think I was being critical, but even in technical documentation, and I’ve seen a loto of it in my 50+ years in IT, there might be a single line of explaination, which you’ve given here.
I assumed as such, but if then I have a problem, is it my assumption that’s wrong.
In the main I agree with you that FB an YT are not the best place for a developer, although there are people with a lot more development experience that use and contribute to these platforms, and ‘birds of a feather, stick together’ and I’ve found a move towards more developer solutions.
Anyway, thanks for the clarification, and your great plugin.
Regards
Pete
P.S, Is there a way to render a field ‘disabled’?
Sorry, also, when I try and ‘render’ the password field it does noth show on the form.
Hello,
There are ~40 hooks (x3 variations) scattered throughout the form module solely, so I think you can understand why I cannot provide such level of detailed explanations on each page, for each hook, as it would make the documentation unbearable. Additionally, the hook variations logic is based on the ACF core hook variations, which is widely adopted in the ACF developer community.
Indeed, the documentation is not perfect, and is constantly improved when I find the time to do so. There’s certainly areas which could be improved. As you can see, this support forum isn’t that active despite the number of active users, which means the documentation seems effective. Last time I’ve read questions about the hooks variations was maybe last year, from a user which wasn’t used to ACF. Which also explains our conversation about the audience.
Regarding the password field, this field works like any other field, and should be rendered. I would recommend to check the syntax of your “render” settings, and make sure you correctly set it up, just like your other form in your other thread here. Please refer to this topic to make sure everything is in order.
If the field is still not rendered on the front-end, please try to create a new simple “test form” with a “test field group”, just like what we did in your previous thread where I provided “my-form” test form with a video demo.
Note that if you try to “load value” and load the “user password” into a text/password field, it won’t display any value. Because the user password is hashed in the database, and has no purpose in a field, so it will be always empty.
Regarding the “disabled” setting, ACF allows to set a field as “disabled” only on few simple fields like “Text”, “Textarea”, “Select” etc… You can directly pass the
disabled
argument to your field inmap
key. Either in theacfe_form()
function (see documentation), or in theacfe/form/load_form
hook (see documentation).Usage example:
add_filter('acfe/form/load_form/form=my-form', 'my_form_load');
function my_form_load($form){
// disable field
$form['map']['field_621a65c15521d']['disabled'] = true;
// return normally
return $form;
}If the field isn’t disabled on the front-end, then it means it isn’t compatible with the built-in ACF “disabled” attribute, and it will require to be disabled in Javascript, using the ACF JS API (see documentation).
Regards.
- You must be logged in to reply to this topic.