Hi.
This sounds really bad. It is most probably not the spam check itself, but the fact that the stamp is not created at all.
Can you give a screen shot of some messages in your spam inbox which you think they are “false-positives”?
Cheers
Thanks for responding so fast. It’s really hard to tell since there’s so many entries, but here are a few that caught my eye (some info redacted):
from_site:post_on_site:www.MYSITE.com/?wordfence_syncAttackData=1698071201.5858is_ajax:false
from_site:www.MYSITE.com/warranty-return/post_on_site:www.MYSITE.com/warranty-return/is_ajax:false
A lot of cron ones like below:
from_site:post_on_site:www.MYSITE.com/wp-cron.php?doing_wp_cron=1698072520.5641379356384277343750is_ajax:false
from_site:www.MYSITE.com/recipes/calzone-panzerotti/post_on_site:www.MYSITE.com/recipes/calzone-panzerotti/is_ajax:false
Here’s my settings: https://imgur.com/a/gv4JOnJ
Thank you
I just realized you asked for “messages”, but what I gave you is from the “spam” folder. There’s only ever been 2 messages, but thousands of spam, so that’s why I pasted some spam entries. Hope that helps.
Which version do you use? Is it 3.0.4?
Do you have time for a short teams-call? If yes, just send me an email.
Hi.
- the wp-cron.php-bug is fixed
- the “wordfence_syncAttackData”-Post will not be blocked anymore
- the most WooCommerce-calls won’t be blocked anymore, but still those which are relevant for the user-front-end. So you don’t need to switch to explicit mode I think.
I hope, this works fine for you know.
Cheers, Matthias
So far so good, will let you know if we encounter any issues. Thank you so much! Great plugin
Matthias, wordfence_syncAttackData is being blocked again. No more cron though. Should I whitelist wordfence_syncAttackData?
Could you try the new Release please? I hope, that I have fixed it now. Unfortunately I cannot reproduce it. Therefore it is hard to be tested test.
Ok I’ll let you know. BTW I think another rule to add to the universal white list is: autoptimize_delete_cache. I noticed when I cleared my Autoptimize cache it took a little longer than normal. It still worked though, from what I can tell, so no biggie.
Hi, another related error, with MC4WP (Mailchimp For WordPress plugin)
EMAIL:MY_EMAIL
_mc4wp_honeypot:
_mc4wp_timestamp:1698175654
_mc4wp_form_id:614
_mc4wp_form_element_id:mc4wp-form-1
from_site:www.MYSITE.com/
post_on_site:www.MYSITE.com/
is_ajax:false
Hi.
I have just changed the way non-ajax-calls are recognized to be less restrictive, i.e. it only recognizes WordPress-standard-submissions for the spam-check. This is the way it worked before the release from the weekend.
I noticed when I cleared my Autoptimize cache it took a little longer than normal.
Did you receive any spam messages from that? If not, it may be helpful, if you switch on “Save clean messages” before clearing the cache one time, in order to get the respective messages. If they are ajax-calls you can simply whitelist them. If not, the problem may be fixed already due to the less restrictive submission-recognition. If you still get non-ajax-messages I would be interested into the structure of these messages.
I think that your problems with mailchimp should be avoided by that too.
For ajax-calls I’ve just added an option to whitelist them directly from the spam-inbox. I wonder whether it may be useful to add this button for the clean messages inbox too.
But WooCommerce is using a proprietary own AJAX-system that doesn’t follow the WordPress standards. These calls are still recognized as non-ajax-submissions. As they don’t use any WordPress standard many of them are not recognized from the plugin.
One of them is the “checkout”. Therefore I have implemented a specific routine that identifies WooCommerce-checkouts.
“add-cart” is process via WordPress standard-submission.
I think these two are the most important ones. If you receive some spam, at other points in WooCommerce please give me a note and I’ll implement something that is similar to the checkout-solution.
I hope this helps.
Cheers, Matthias