• Resolved pzh20

    (@pzh20)


    The for you created for updating a user profile does not update the user’s password field but does update other fields.

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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.

    Thread Starter pzh20

    (@pzh20)

    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.

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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.

    Thread Starter pzh20

    (@pzh20)

    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

    Thread Starter pzh20

    (@pzh20)

    I thought it was working, but look at this

    ACC-edit-–-The-Harrisons-Website.mp4

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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.

    Thread Starter pzh20

    (@pzh20)

    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

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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.

    Thread Starter pzh20

    (@pzh20)

    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

    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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, and name 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.

    Thread Starter pzh20

    (@pzh20)

    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.

    • This reply was modified 3 months, 3 weeks ago by pzh20.
    • This reply was modified 3 months, 3 weeks ago by pzh20.
    Plugin Author Konrad Chmielewski

    (@hwk-fr)

    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 in map key. Either in the acfe_form() function (see documentation), or in the acfe/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.

Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.