• Resolved Surbma

    (@surbma)


    Hi,

    I already updated the plugin to 1.1.1 and just realized with my client, that entries are still going to spam since April 22.

    Not all entries go to spam. Our conclusion is, that only big traffic pages have this problem. So those form entries go to spam, which have high traffic.

    I also deactivated the plugin and then re-activated. Server side cache has been purged several times.

    The plugin is deactivated now, as it is not working properly. Can you please check, what could be the reason to send entries to spam from high traffic forms? The forms, that have this problem processed 200-300 entries since then.

    Thank you!

Viewing 14 replies - 1 through 14 (of 14 total)
  • I had the same issues with all forms on our sites. Deactivating Gravity Forms Zero Spam plugin and activating again fixed the issue.

    • This reply was modified 3 years, 6 months ago by sjmacnz.
    • This reply was modified 3 years, 6 months ago by sjmacnz.
    Plugin Author GravityKit

    (@gravityview)

    The plugin is deactivated now, as it is not working properly. Can you please check, what could be the reason to send entries to spam from high traffic forms? The forms, that have this problem processed 200-300 entries since then.

    The plugin adds JavaScript to the form that adds a field when the form is submitted. If that JavaScript is modified by a caching plugin, that could explain it.

    @sjmacnz Does your caching plugin compress JS or HTML?

    Can you please share a link to the page in question?

    Plugin Author GravityKit

    (@gravityview)

    Whoops, I meant to ping @surbma on this ??

    Please let me know!

    Thread Starter Surbma

    (@surbma)

    There is no minification, but caching is on and it is very “aggressive”. But caching can not be disabled on these pages.

    Here is an example page:
    https://jelzalog.com/csok/

    Please note, that your plugin is deactivated now and I can not enable it, as the site has high traffic.

    I found this thread as I’m having the same problem. EVERY single entry on our form since April 24 has gone to spam, including myself testing just this morning. I’m investigating caching, etc. but I found it interesting that mine started within a few days of @surbma

    Plugin Author GravityKit

    (@gravityview)

    @surbma @blakemiller What version of Gravity Forms are you running?

    The 2.5 Gravity Forms release has caused some JavaScript-related functionality to fail. This plugin uses JavaScript to function.

    From what I understand, those issues with Gravity Forms have been fixed in 2.5.4.

    Thank you for responding.

    I’m at GF 2.4.24. I have purposely not upgraded to GF 2.5 since I’m waiting for all the dust to settle for a variety of other reported issues.

    I’ve disabled the plugin and shifted to Akismet integration since I’ve had luck with it on other sites. (This site I’m working on was originally designed by another designer who put your plugin in a few years ago) If I get a chance to circle back and test yours, I’ll let you know.

    Hi,

    I had a similar issue and found that the POST value was html encoded, preventing comparison with the key stored in options table.
    Applying html_entity_decode() to the POST variable fixed it.

    
    if ( html_entity_decode($_POST['gf_zero_spam_key']) !== $this->get_key() ) {
      return true;
    }
    Thread Starter Surbma

    (@surbma)

    @thomascharbit My only concern is, that if it depends on a database query, it won’t work well on a cached page. So yes, it is very important to compare with the right format, but still can’t depend on a query every time a form gets submitted.

    @gravityview What is your opinion regarding caching?

    Plugin Author GravityKit

    (@gravityview)

    @thomascharbit Thanks for finding a possible fix! We’ll include this fix in an update and see how it goes.

    @surbma This wouldn’t be affected by caching at all, thankfully; it’s all after the entry has been submitted. Caching is often the problem, but this plugin won’t be hurt by caching unless the plugin is de-activated and re-activated and the cache isn’t cleared.

    Plugin Author GravityKit

    (@gravityview)

    @thomascharbit Do you have a plugin that overrides default password generation in WordPress? Something that might generate more secure passwords?

    Something modifying the wp_generate_password() function output is the only reason I can think of for why html_entity_decode() would be needed.

    Thread Starter Surbma

    (@surbma)

    @gravityview Thank you for confirming that! So how can we be sure, that the plugin won’t send entries to spam?

    Is it possible to have a notification option? So when spam gets 10 or more entries in a day, then the plugin will send an email to let admin know about the situation. So we can check if those spam entries are false positives or not?

    Plugin Author GravityKit

    (@gravityview)

    I’ve released the 1.1.2 update with @thomascharbit’s code fix. Thank you, Thomas!

    @surbma Thanks for the suggestion regarding email summaries of spam entries. That’s a great idea. I’m not sure when that will be developed, so until it is, I recommend using the Entry Automation plugin by ForGravity for email reports.

    Please update and confirm that the fix works for you! ??

    Thanks!
    Zack

    Thread Starter Surbma

    (@surbma)

    @gravityview Thank you for the fix! I don’t want to test it on my client’s live sites, as I can not be sure, if there will be false positives.

    The email summaries notification would be a good feature, so I could test it on live sites.

    I’m not sure, that the mentioned add-on can manage spam entries. I guess it is good for only normal entries.

    • This reply was modified 3 years, 4 months ago by Surbma.
Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Entries are still going to spam (1.1.1)’ is closed to new replies.