• Resolved llannik

    (@llannik)


    Hello,

    I would like to report a potential issue with webhook conditions related to a consent (checkbox) field.

    I have configured a form where the webhook should be sent only if the marketing consent field is checked. The condition is set as follows:

    • Field: Marketing | consent-2
    • Condition: is
    • Status: checked

    However, even when the checkbox is selected in the form, the webhook is not being triggered.

    Additional observations:

    • The configuration appears to be correct,
    • The same setup works properly in another form,
    • In this particular form, even when the consent is checked, the webhook is not sent,
    • It seems that the condition may not correctly recognize the state of the consent/checkbox field.

    Additionally, I am experiencing a similar issue in another form on a different page, where the webhook condition also does not work as expected.

    Could you please verify if there is an issue with how conditions are evaluated for consent fields?

    The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter llannik

    (@llannik)

    I have identified the root cause of the issue and wanted to share additional findings.

    The problem is related to how the condition value is saved when using a non-English (Polish) admin interface.

    When configuring the webhook condition in Polish, the value is saved as:

    "value": "sprawdzony"

    However, in the Forminator backend, the consent field actually returns the value:

    checked

    As a result, the condition comparison fails, because:

    • expected (saved): sprawdzony
    • actual runtime value: checked

    After switching the WordPress admin language to English and re-saving the condition, the configuration is stored correctly as:

    "value": "checked"

    and the webhook works as expected.Conclusion

    This appears to be a localization issue:

    • The UI translates the condition state (e.g. “checked” → “sprawdzony”),
    • but the translated value is incorrectly saved to integration_conditions,
    • instead of using the internal value (checked) required by the backend logic.

    Suggested fix

    The condition value should always be stored using internal (non-translated) values such as:

    • checked
    • true
    • etc.

    and translations should be applied only at the UI level, not in saved configuration.Impact

    This issue likely affects all non-English admin environments where condition values are localized before saving.

    Please let me know if you need additional logs or test cases.

    Plugin Support Nithin – WPMU DEV Support

    (@wpmudevsupport11)

    Hi @llannik,

    Thanks for bringing this to our attention, I’m passing this further to our Forminator teams attention to check and review it.

    However, possible to also share the form export so that we could understand the exact configuration you have?

    Please check the following doc on how to export a form:
    https://wpmudev.com/docs/wpmu-dev-plugins/forminator/#import-export

    If you are concerned about any sensitive information in the form, then you can duplicate your form, remove any sensitive information, and then export it.

    You can share the export file via Google Drive, Pastebin, Dropbox, or any cloud service in the next reply.
    Looking forward to your response.

    Best Regards,
    Nithin

    Plugin Support Nithin – WPMU DEV Support

    (@wpmudevsupport11)

    Hi @llannik,

    I would like to update that our Forminator team has confirmed this bug, so we don’t need the form export as mentioned above.

    At the moment there isn’t any exact ETA we could provide bug can confirm the issue is being looked into.

    Thanks for bringing this into our attention.

    Regards,

    Nithin

    Plugin Support Dmytro – WPMU DEV Support

    (@wpmudevsupport16)

    Hello @llannik,

    I hope you’re doing great today!

    Our developers are working on implementing the fix after version 1.54, so I’m marking this thread as resolved for now.

    Please feel free to reopen it, in case you have any further questions.

    Best Regards,
    Dmytro

    Thread Starter llannik

    (@llannik)

    Thank you for the update.

    Could you please provide an estimated timeline for when the fix is expected to be released after version 1.54? Even an approximate timeframe would be very helpful.

    Plugin Support Jair – WPMU DEV Support

    (@wpmudevsupport15)

    Hello @llannik

    I’m sorry but I’m afraid we don’t have any ETA of when the version will be released. These updates includes fixes and improvements that needs to be properly implemented and tested, and that can take its time. I can just confirm that our development team is aware of the bug and they are working to fix it.

    Kind regards,
    Jair.

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.