Ryan

Hi guys, yep, the plugin was acquired by WPExperts. It’s happened quite quickly, and leading into a holiday weekend here in Canada, so I haven’t had a chance to post much of a notice. I’m sure they will have more to say on their plans with the plugin, but as a response to you all and @pidengmor’s nice comment — my hope is also that they’ll continue to build and support the plugin in ways that I just haven’t been able to lately.

When I started the Honeypot plugin 13 years ago I was a web developer full-time, but I have since left the industry (though not the WordPress community) and my sluggish responses to support requests, and releases hasn’t been up to snuff. I’m excited that there is someone interested in taking on development and assuring that the plugin continues to get the support it deserves.

I truly appreciate all the help many of you have provided here in the forums and at points in the code as well. I’m also a user of the plugin, and look forward to seeing where it goes next.

Hey @letsfindaway – apologies about the confusion. The plugin works with the latest versions of WordPress. The readme (and plugin page) have been updated to reflect that.

Hi, it looks like CF7 5.1.9 came out in 2020. I’ve not tried the latest version of Honeypot on that version of CF7, but it is possible something was changed between 2.0.5 and 2.1 of this plugin (which happened around that time). A lot of new features were added in 2.1. If you have no way to get off of the old CF7 version (and it is highly recommended you find a way, because plugins should always be kept up to date for better security), then you can try using Honeypot 2.0.5 (available here)

Frigin Eric Jones! He has been my nemesis for years!

Sorry for the late reply. There is no way to specifically block a single email using Honeypot. I would play with the field names to try and trick Mr. Jones into filling out the honeypot field. But also, make sure you have Enable Timecheck enabled. Set it as high as you can without blocking non-bot people (i.e. how long does it take you to fill out the form as a human, minus a couple seconds in case others are a bit faster)

I’m going to say… “maybe”. This is not officially supported, but I just did a quick (in Inspector) test and it does actually work. You should be able to use the filters (recipe Gist here) to rewrite the HTML so instead of an <input type=”text” value=””> it uses an <input type=”checkbox” value=”spam”> (or whatever value you want).

You’ll need to rewrite the CSS too, so it’s not hidden.

Hi @trkoehler – apologies for the long overdue reply. Been hectic here.

Honeypot doesn’t have anyway to block a specific email. It’s meant to “trap” spam submissions by tricking the bots submitting them into filling out a “honeypot” field.

I’m very late getting back to this. Did disabling the time-check help?

Just to clarify something from above – if the Store Honeypot Value is enabled, then Flamingo will retain the spam submissions in the SPAM tab, and there they can be reviewed to see what caught them (i.e. what is put in the honeypot field or if it was time check, how long it took to submit).

If the spam submissions are being stored in the regular Flamingo submissions area, there’s something wrong, especially if Flamingo is showing a value in the honeypot field. That would indicate the honeypot field isn’t working for some reason.

Hi @roderickgadellaabsl – I finally had a chance to dig into this a bit and unfortunately I don’t think I can fix this at the moment. But there may be a solution for you.

Basically, the random wrapper ID isn’t very essential, and I could probably get rid of that. However, the issue is the honeypot field has a label associated with it – this is largely for accessibility purposes – so in scenarios where the field is “displayed” in some way, there is descriptive text to let a person know not to fill in the field. Standards dictate that this requires the honeypot field must have an ID to associate it with the label element.

Both the wrapper ID and the field ID can be set, as shown here:

[honeypot website id:some-field-id wrapper-id:some-wrapper-id]

When they are not set, a random ID is created to assure the field has an ID to associate with its label. So, I could get rid of the wrapper part, but the field part would still trip up the Autoptimize cache.

Two (admittedly not perfect) solutions:

1. When creating/inserting the honeypot field, add the ID and Wrapper ID values, which will then override the random value and allow the new static values to be cached.
2. Use the output override functionality here to rewrite the field’s HTML. Recipe here. It’s the last of the 3 example functions.

Hi @beamzen – very sorry about the slow reply, I’ve been swamped in other projects.

The global setting for this can be overwritten by a unique value set on the honeypot form tag (in the CF7 form editor). Something like this:

[honeypot website timecheck_value:3 timecheck_enabled:true]

So, if you’ve set it to 3 in the actual form editor’s honeypot tag it overrides the global value. I would check there, and report back if still an issue.

Hi @pixelprod – very sorry to take so long to get back to you about this. I got hit by a million other things and Honeypot had to get back-burnered for a while.

Are you still experiencing this issue? I reviewed things on my test servers and the plugin appears to be working as expected. And you’re certain the form that is sending the spam has a honeypot field setup?

Hey @rodricus – very sorry that I was so slow to reply to this. Yes, Honeypot is integrated with Flamingo and uses the Spam folder there to display info about the spam submission.

Thanks @zodiac1978 for addressing this, and yep, that’s exactly right – all fields in a CF7 form are run through the autop filter and get wrapped in P tags if they are on a new line in the form editor. @guido07111975 the easiest way to solve this is to just do as you did, remove the whitespace between the honeypot field and another field (like the submit)

At the moment, this is not a feature of the plugin. It might be possible to do by creating a “global” honeypot value that is auto-inserted. I’ll have to think about this a bit. I’ll add it as a feature to add to future updates.

Hi @nitrokev – I’ve tested honeypot and it is working as expected on my test sites. Perhaps there is something else going on that is interrupting things. I would double-check you don’t have any errors in your PHP/WP error logs and also in the browser’s Console (JS errors). If you continue to have problems, please start a new thread with the issue so it can be tackled directly.

Hey @mganeshaxioned – just tested it and all appears to be working fine in 6.2. I’ve updated the plugin’s readme to reflect. Should be all good, but let me know if you notice any problems.