vivalis

Sure, here’s the code:

$($field).change(function() {
    if ($(this).data('oldVal') == $(this).val()) {
        //leave change function if value has not changed
        return;
    }
    
    /*do stuff in case user did select a different option
    your code here
    */

    //store the new value of the dropdown in the jQuery data container
    $(this).data('oldVal', $(this).val());
 );

Explanation: In der beginning of the change event of a dropdown, in order to check if the user has actually changed the selected option, compare the old value in the jQuery data container with the current value of the dropdown. Leave the change function if the selection hasn’t changed. At the end of the change function, do not forget to store the new value of the dropdown field in the jQuery data container. You can use any name for the old value variable in the data container (‘oldVal’ in this example).

Dear Saurabh,

Thanks for your answer. I tested it in the console, and it’s working now. Maybe I did something wrong on my side.

However, there’s another problem with conditionally hidden fields: I have a text field A with conditional visibility. That field A gets filled with a result by JS code. Then, there’s html field B that shows some text and the result from A. When A is hidden by condition, it’s content doesn’t show up in B.

Could you check if you can replicate this problem?

Kind regards, Roger

Thank you, Dmytro. Good news that you’re planning to bring select fields with clear button. As this is planned on your side, I will refrain from your solution with “abusing” the multiselect field and just wait for the new feature to arrive.

Kind regards, Roger

Dear Veronica,

Thank you so much for your quick reply. Highly appreciated. I wasn’t aware of the ‘um-after-email-confirmation’ hook. I’ve implemented the code snippet, and it works just fine. I have added to following line in order for the admin to get an email when the email is confirmed and his review of the new account is needed:
um_send_registration_notification( $user_id );

Thanks again for the great plug-in and support!
Kind regards, Roger

P.S. The ‘um-after-email-confirmation’ hook is not listed in your provided list of hooks (https://ultimatemember.github.io/ultimatemember/hooks/).

Hello all,

I had the same issue, solved it and would like to let you know about the solution.

What I experienced: Two radio fields in the form, each with 5 options and associated calculation values (1 – 5). Calculation field at the end that sums up the values of the selected options (e.g. 4 + 2 = 6). The calculation field showed the correct result (6) in the form, while it was a totally different number (14 instead of 6) in the email.

For analysis, I added calculation fields for each radio field that stored the value of the selected option. Result in the database:
– calc field of radio with option 1 or 2 selected was correct (e.g. 2)
– calc field of radio with option 3, 4 or 5 selected was wrong (e.g. 12 instead of 4)
– total calc field was correct because the sum of the correct radio 1 value (2) and the wrong radio 2 value (12) was 14

The solution: After some more research I realized that in the radio fields’ settings, the options 3, 4 and 5 had a red border and a warning about some options having the same value (which was not the case). I deleted the “red” options and recreated them one by one, making sure they had no more red borders. And voilà, the calculation works now and is correct in form, email and database.

Hi,
Thanks for looking into this matter. The website is not launched yet, so I’m sending you the bypass link:
https://www.eautotest.ch/testdrive/booking/?cmp_bypass=ldifisd7898034jalfvasefua09845j345fjsdf

There’s a Forminator form that gets translated despite the notranslate class. I thought it might just be an issue with Select2 (Forminator uses Select2 for the select fields), but Forminator support told me that they tried the notranslate class for the entire form, and it still gets translated.

Hope you can find a solution. Thanks!

Kind regards,
Roger

My current solution is a JS change event that triggers a callback function via AJAX, and then JS again that fills the returned option values into the select field.

It works, but having the parent option in multi-select fields would be neater… ??

Kind regards,
Roger

Thanks for your reply, Patrick. So, let’s hope conditional visibility will work in v1.20…

Big thanks to you and the Forminator team for your outstanding work!

Kind regards,
Roger

Thank you very much for your quick response, Patrick.

Your solution for replacing the placeholder works.

Changing the option of the select field on the fly worked until the previous version, but not with the current 1.19.0 anymore. I switched the backend validation of the options of select fields off (in the select.php). As there’s a “payment wall” in my form, there’s no risk of having bots abusing my select fields.

Maybe you could add a possibility to have select field options dynamically filled from the backend. E.g. Ultimate Member allows this with 2 optional entries in the select field configuration: a callback function and a parent field.

Kind regards,
Roger

Thanks for the roll-back idea, @felix997. You’re right: I’ve just discovered that the problem not only exists when using hidden fields as a visibility trigger, but any field. The entire show/hide mecano seems broken in the current version.