Defender error when scanning website

Greetings wpmudev,

I recently reactivated Defender and I get an error when attempting to scan the website. Sometimes the loading/progress bar will show up but will remain in initializing stages or not move at all.

Support Access should be granted if you'd like to take a look!

Best Regards,
C Bey

  • Adam Czajczyk

    Hello CiroBey,

    I hope you're well today and thank you for your question!

    I checked the site and the PHP/WP resources seem to be set to levels high enough to be able to handle Defender scan. There's however a chance that there are "hard limits" on a server per CPU/Memory/DB usage. That's something that often applies to shared hosting accounts but is not often stated clearly by hosting providers, unfortunately.

    I have used a "Try Again" button on your site and Defender started scan again. I then cancelled it but I'd like you to give it another try. First please enable WP debugging by making sure that following lines are in the "wp-config.php" file of your site:

    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', true);

    These lines should be located above the "/* That's all, stop editing... */" line.

    Once they are there, please try to run scan again and see if it ends up with the same error. If it doesn't, wait about half an hour and give it another go. If the message shows up again, please:

    - download the "/wp-content/debug.log" file from your server
    - rename it to "debug.txt"
    - attach to your replay here
    - if there's an "error.log" file in a root folder of your WP install, please download it too and also rename to "error.txt" and attach here.

    I hope that this will shed some light on the case :slight_smile:

    Best regards,
    Adam

  • Ciro Bey

    Hey there Adam Czajczyk I get the error sometimes and sometimes the scan stays at the initializing phases. If I cancel and rerun the scan, sometimes it'll say "continuing" but won't move anywhere. If I hit try again I get the stuck progress bar as well.

    EDIT: I changed the debug log to debug.txt but the file still adds the .log extension so the file stays as "debug.txt.log" and thus I'm not able to upload. Here is a screenshot of the log as well.

  • Adam Czajczyk

    Hello CiroBey!

    Thank you for your response.

    I checke error and debug logs and the first one doesn't carry any relevant information. The debug.log though suggests that there may be some PHP level issue so I checked your site again and I noticed that your site is powered by PHP 5.4.45 which is pretty "old" actually. That shouldn't be an issue I think however since it's not as "performance efficient" it may be related.

    Do you think it would be possible to switch the site to a newer version of PHP? At least 5.6.2x but I think 7.0 would be the best choice (though I wouldn't suggest 7.1 yet!) as it should also improve overall stability and performance of the site.

    Kind regards,
    Adam

  • Ciro Bey

    Greetings there Adam Czajczyk

    I changed the php version via the 'PHP Selector' extension within cPanel. I'm not sure if that is the correct way or not.

    I am able to select up to 5.6, but if I select 7.0, the website no longer loads and comes to a 500 error. This seems odd to me. Do you have any idea what's causing this? I noticed the 7.0 version had less options (checkboxes) within the PHP Selector.

    I hadn't realized there were different PHP versions to select from in the first place. Do they not update when Wordpress updates and are the updates useful? You mentioned that the 7.0 update may increase performance overall. Is there any information to learn more about PHP updates and possibly have them be auto updated?

    As for the Defender scan, going to php version 5.6 doesn't seem to have changed anything.

    Much Love,
    Ciro Bey

  • Adam Czajczyk

    Hello Ciro Bey!

    The PHP is a server side tool that doesn't get updated with WordPress. It's usually not updated automatically as well. It's a bit more complex than WP update, the bottom line is that too many things depend on the PHP to let it be automatically updated.

    Usually the process is that host updates PHP on the server and/or host makes different versions available for a user to choose from.

    You can read more about PHP and its updates here: http://php.net/

    The way you switched it is correct. I'm a bit surprised that 7.0 broke the site but I understand that switching to 5.6.x brought it back. That version should be good enough though.

    Having said that, I checked the site again and also reviewed plugin files. The message that you are getting is triggered by two places in entire code only and is related to the CPU usage. There's a CPU usage counter that prevents scan from reaching over the 55% limit in order not to cause the site to go down. That limit is "hard-coded" in a plugin so it seems there's no way to overcome it.

    However, when I tried to run scan again I found that during that partial scan (I cancelled it in just a few minutes) it used only up to around 12% of available CPU. There's however a lot of concurrent ajax-based calls made pretty much all the time from your site to the wordpress.com API which, I believe, must be coming from Jetpack or some code related to it.

    I'm not sure if that is strictly related but it's possible that this is affecting that CPU usage and as a result causing it to hang up sometimes. I'm not also quite able to test it on my end due to a different server configuration - that wouldn't be relevant. That brings me back to the point that we have most likely exercised many times before but not in that case. That is a classic theme/plugin conflict test. I hoped to avoid that but it seems that it's again necessary.

    I would however start with disabling Jetpack temporarily and checking if that helps. Then, if it doesn't change anything, a full conflict test would be required as it may reveal why the CPU gets used over that allowed level. Could you please give it a try? Start with Jetpack only please and then, if that doesn't let scan complete, proceed according to the steps on a flowchart in this article:

    https://premium.wpmudev.org/manuals/using-wpmu-dev/getting-support/

    Hopefully this will reveal the main culprit that we could then further investigate.

    Best regards,
    Adam

  • Dimitris

    Hey there Ciro Bey,

    hope you're doing good and don't mind chiming in!

    I added a mu-plugins file but the code had no effect on the scan and the code was displayed on the top of every page within the admin dashboard.

    That should be happening because the code wasn't inside PHP tags.
    Could you please replace previous snippet with this one instead and test again?

    <?php
    add_filter( 'wd_limit_cpu', function () {
    	return 20;
    } );

    Warm regards,
    Dimitris

  • Ciro Bey

    Hey there Dimitris thanks for the tip.

    The code seems to have worked and I ran a scan successfully! Will I need to keep the new php file within mu-plugins? Will this slow things down in anyway? Is this a problem with my install? I'm not quite clear on the cause of the issue.

    Also, after running the scan there was a 'suspicious file' found that is titled "fix.php"
    I'm not sure where this is ("Wordpress Core") or if it's needed any longer or where it came from.

    <?php
    function ___wejns_wp_whitespace_fix($input) {
        /* valid content-type? */
        $allowed = false;
    
        /* found content-type header? */
        $found = false;
    
        /* we mangle the output if (and only if) output type is text/* */
        foreach (headers_list() as $header) {
            if (preg_match("/^content-type:\\s+(text\\/|application\\/((xhtml|atom|rss)\\+xml|xml))/i", $header)) {
                $allowed = true;
            }
    
            if (preg_match("/^content-type:\\s+/i", $header)) {
                $found = true;
            }
        }
    
        /* do the actual work */
        if ($allowed || !$found) {
            return preg_replace("/\\A\\s*/m", "", $input);
        } else {
            return $input;
        }
    }
    
    /* start output buffering using custom callback */
    ob_start("___wejns_wp_whitespace_fix");
    ?>
    
    <?php
    /**
     * Front to the WordPress application. This file doesn't do anything, but loads
     * wp-blog-header.php which does and tells WordPress to load the theme.
     *
     * @package WordPress
     */
    
    /**
     * Tells WordPress to load the WordPress theme and output it.
     *
     * @var bool
     */
    define('WP_USE_THEMES', true);
    
    /** Loads the WordPress Environment and Template */
    require('./wp-blog-header.php');
    ?>

    Do you by chance have any idea about this file?

    Thanks for the support here. Happy to have Defender working now!

    Much Love,
    Ciro Bey

  • Dimitris

    Hey there Ciro Bey,

    hope you're doing good and I'm really glad that we finally sorted that out! :slight_smile:

    The code seems to have worked and I ran a scan successfully! Will I need to keep the new php file within mu-plugins? Will this slow things down in anyway? Is this a problem with my install? I'm not quite clear on the cause of the issue.

    There's no worries about this little MU plugin. Just keep in place as is and you shouldn't experience any latencies or anything similar with that. It only contains a filter that only Defender plugin can understand. The CPU reach threshold that Defender uses was raised from 5 to 20. :wink:

    Also, after running the scan there was a 'suspicious file' found that is titled "fix.php"
    I'm not sure where this is ("Wordpress Core") or if it's needed any longer or where it came from.

    This isn't a WP core file indeed but on the other hand doesn't seem harmful. Here's more details from its author
    http://wejn.org/stuff/wejnswpwhitespacefix.php.html
    I believe that this should be coming from a plugin and "ignore" it shouldn't cause any issues.

    Warm regards,
    Dimitris

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.