Ryan

Hi @fernandosilveira, apologies on not seeing this sooner. The Honeypot plugin integrates with the CF7 plugin, using its internal validation system. If you’re using Mailchimp integrated with CF7, then it should work inline with that. It won’t work with Mailchimp-generated forms though, as they don’t go through the CF7 validation system.

Hi @mreed3689, just a quick FYI to let you know I’ve just released a new version of the plugin that handles the ID generation differently. It now appends a more generic ‘wpcf7-‘ to the random ID, rather than “hp”. It can also be completely changed/overridden when creating the form and generating the Honeypot tag.

Hi @rockysaini, apologies for only now just seeing this. Not sure how I missed it.

I believe the problem is that your jQuery is casting too wide a net, setting all fields to “required”.

Specifically, this:
jQuery(“.wpcf7-form-control”).prop(‘required’,true);

That will set all fields to “required”. You could simply be more specific in their selection there. However, if you have a lot of fields and that’s a hassle, then yes, overriding that with your Honeypot field and setting it back to false would work. You could also utilize jQuery’s .not() function in the initial jQuery, rather than add an additional line. But either way will work.

Hi @delawaregrad, just wondering if you ever resolved this. I just released a new version of the plugin that explicitly sets CF7’s “do-not-store” flag, which if plugins respect it means that the Honeypot field should not be stored in the database.

Yes, as you can see from the source, the term “honeypot” isn’t displayed. It’s just the name of the tag.

The “hp-” as message class prefix is used for uniqueness so that the HP message CSS can be overridden if desired. Changing this would require either checking the “Disable accessibility label” option when generating the form tag, or altering the HTML output (more info here).

The ID with “hp” in it was a way to use a unique ID and I had originally felt it was sufficiently masked (IDs in CSS can’t start with a number). I’ve just released the latest version of the plugin that changes this to the more plugin-specific, but Honeypot generic “wpcf7-” prefix instead. Simply update the plugin and you should notice the change. I’ve also included a way to override that value with a user-defined value.

Hi @chesio, sorry it took so long, but I’m happy to report that v1.14 of the plugin (just released moments ago) now contains the do-not-store flag. Thanks a lot for the suggestion. Please let me know if you notice any problems.

Unfortunately the plugin hooks directly into CF7’s functions for building and injecting its inputs. So no way to integrate it directly.

That said, looking at the link to the Recaptcha integration, it looks like WPJM could definitely use a honeypot. I don’t have time at the moment to work it out exactly, but essentially you’d need to modify the recaptcha_field() function (and probably rename it for clarity in your code). You would use that function to insert a blank <input type="text"> field (you could view the CF7 honeypot HTML for general structure — just view the source of your CF7 form). Then you’d modify the logic of the validate_recaptcha_field() function (again, maybe change “recaptcha” to “honeypot” for clarity) to check if the field is empty (success) or not (fail).

Hey @mayuxi, thanks! I was an expat in China for 10 years and know well the Google issues. Glad it’s useful!

It’s an accessibility feature — not all (or even most?) screen readers render CSS, so it’s important to have the message there for those use cases. You can disable the accessibility message in the field’s settings when adding it to your form though.

Yep, you nailed it.

WordPress filters are used to modify intended output. So in the case of the Honeypot plugin, they allow you to change the accessibility message, the container CSS or the whole shebang. Those initial (default) values are supplied to the filter function via a variable, and that variable can then be modified and returned (see the PHP examples). It’s all handled in the PHP functions, nothing is placed in the honeypot tag.

Hi. First, I should note that these are advanced customizations and so some familiarity with theme files/WordPress’ nuts and bolts is recommended.

The PHP code goes in your theme’s (or child theme’s) functions.php file.

I’m not sure what you mean in your #2 question. What filter text do you mean?

Hi @benrich1302, apologies about the late reply. Is the spam you’re getting in German? If not, try renaming the honeypot field to something in English.

i.e. change:
[honeypot erdbeere-489 validautocomplete:true move-inline-css:true]

to:
[honeypot email-489 validautocomplete:true move-inline-css:true]

That way when a bot is looking for fields to fill out, if it is using English terms for field names to look for, it will have a better chance of finding this one and be trapped.

That looks right. There’s no way to avoid using “honeypot” in the first part of that shortcode, as that’s what tells the CF7 system to generate the honeypot field — it isn’t output in the HTML though. The second term, “website”, is used as the field’s name.

Perhaps also try moving the CSS to the footer. You can do that by replacing your shortcode with this one: [honeypot website move-inline-css:true]

Hi @tomheil — good suggestions. Will look at implementing some additional obfuscation to the IDs/labels in the next version.