thueske

You only need to load the code above and set the correct css classes.

My provided code should be used within an functions.php of a child theme or a simple custom developed plugin.

Then give the forms one Input (e.g. text-1 in my code) and add the css class honeypot (or however do you name the class) there.

Hey @wpmudev-support8,

the today released 1.19 does not fix the issue :/ It is also not mentioned in the changelog.

Any news?

Tobias

Hey,

thanks for your answer.

I understand that not all bots can be filtered. However, the above method works much better than Forminator’s built-in honeypot. Maybe it makes sense to use both variants.

WP Armour (https://plugins.trac.www.ads-software.com/browser/honeypot/trunk/includes/js/wpa.js#L9) does it similar to me. It works great.

The captchas integrated in Forminator are out of question for me, because the scripts are loaded from servers in the USA. This is a bit problematic regarding the GDPR.

Glad to hear from you and hope for an even better honeypot feature.

Tobias

Any news here fixing the initial problem introduced with 1.18.1? ??

Same issue here with current version. Rollback works.

Pretty stupid, since our whole form is made of conditions. Is there already a timeframe when the bug will be fixed? Would be very important for us.

Do you need more examples? For example, on one of our pages the visibility condition works (without hidden field), but on other pages with hidden fields it doesn’t (despite the same plugin version).

• This reply was modified 2 years, 5 months ago by thueske.
• This reply was modified 2 years, 5 months ago by thueske.

Hello @wpmudevsupport12,

thank you very much for your efforts. Unfortunately I can not test it.

With version 1.14.11 the PayPal Submit button is no longer displayed.

If I change the plugin version back to 1.14.10.1, then the button is displayed.

There must be an error here.

Tobias

Hey @wpmudevsupport12,
thank you ??

The problem is that these values should be adjusted “centrally” via a field, instead of in each calculation when something changes. I have now adjusted it to normal number inputs and hidden them with CSS, but it would be nicer if this would also work with the hidden fields. Maybe you can include this for future development.

Thanks for continuing to look at getting the “1” bug fixed.

Tobias

Hey @wpmudevsupport12 ??

Thanks for your effort!

I’m looking forward to seeing the results.

Have a nice day.

Tobias

Hey @wpmudevsupport12 and @wpmudev-support2,
sorry for my late answer. The problem still exists.

Glad you were able to understand the second mistake. Is there any fix on your roadmap?

The first error requires you to select something other than “Wertgutschein”, for example “Frühstück” or “Fu?ball-Golf”.

Thank you,
Tobias

The problem are…

a) incorrect calculations
b) incorrect inputs (1 instead of 0 / empty)

Both are displayed incorrect in the confirmation mail.

• This reply was modified 3 years, 12 months ago by thueske.

My problem is that the workaround (using number inputs which are hidden with css) only work for the calculation problem but not for the incorrect values. That makes it unusable for customer order mails.

Both is not nice.

@wpmudevsupport12 @wpmudev-support2 @wpmudev-support9 @wpmudevsupport16 is this possible? ??

Hey Patrick,

tested the new version.

Issue not solved ??

See here: https://imgur.com/teCBmGi

Marked the wrong fields… Empty fields with no values still become “1” and others (“Zwischensumme”) are not correctly calculated, too.

Can you check this again, please? My JSON is still up2date: https://pastebin.com/x2KsUGRE

Thanks…

• This reply was modified 4 years ago by thueske.
• This reply was modified 4 years ago by thueske.

Thank you very much.I will test and report when the version is available.