Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter mingyeungs

    (@mingyeungs)

    Hi @wfgerald,

    I’ve just SEND REPORT BY EMAIL with my username mingyeungs.

    Regarding ‘switch to a WordPress default theme and visit those links’, I’m sorry but our client won’t let us make any changes to the site, as their management team is reviewing the site now.

    If I visit “https://mydomain.com/?wordfence_syncAttackData=xxxxxxx.xxxx” with a browser using existing theme, it’s 50/50 chance seeing a blank page or seeing the website homepage (both with 200 as response code)

    Btw, we’ve temporarily commented out Line 8427 echo "<script type=\"text/javascript\" src=\"$URL\" async></script>"; in wordfenceClass.php, so that the management team won’t be put off by the script issue; and notice a side effect that the ‘complex’ attack block by the firewall is massively reduced (but still very high IMHO). As our site hasn’t been put to live yet, I don’t think we should be seeing any attack, or at least not that high?
    Screenshot-2020-05-25-at-12-42-48

    Thanks,
    Ming

    Thread Starter mingyeungs

    (@mingyeungs)

    Dear @wfgerald ,

    I tried adding the IP that our domain’s A record specified in the IP whitelist, but it doesn’t seem to make a difference. As our site is running across multiple instances (scale-out), I ain’t sure whether the IP entered is the “server IP” you’re referring to.

    Some questions:
    1. How often should this script run?
    2. What are the drawbacks if we remove the script from the website frontend (assuming we hack the plugin/disable it with hook)?
    3. can we do it using a cronjob instead?

    The loading time of this script is too unstable – while it has the “async” attribute which solve the blocking issue, it is still make the webpage appears as ‘loading’ in the browser tab, which our client doesn’t accept.

    Thank you very much for your help!

    Thread Starter mingyeungs

    (@mingyeungs)

    Just noticed that removing the line “check_admin_referer” would cause another issue, that is, custom meta will be erased after you click on ‘Update’ in ‘Quick Edit’ mode.

    A workaround (no sure if it’d cause other problem though…), is to add

    || ( $_POST['action'] == 'inline-save' )

    after line 426 of

    inc/classes/meta-box.php

    In this case, the ‘save_post’ filter will not be applied when user quick edit a post.

    Still, waiting for official update from the plugin author to solve this problem.

Viewing 3 replies - 1 through 3 (of 3 total)