SiteGround AutoUpdate failed, again!

Immediate¹

Occurring or done at once; instant.

On September 8, WordPress released a maintenance and security update with three security issues. These vulnerabilities were so concerning that the WordPress announcement recommended immediately updating WordPress installations. “Immediately”; the exact setting I have on the SiteGround AutoUpdate tool for minor releases (see Updates & Upgrade Network). Actually, it is set to “Immediate”, but you get my point.

This security and maintenance release features 60 bug fixes in addition to 3 security fixes. Because this is a security release, it is recommended that you update your sites immediately.WordPress

Of course, the SiteGround tool seems to have a different definition of “immediate”. Now, this is not the first time I had to complain about what used to be an amazing tool. Indeed, it all started with the migration to Site Tools (see SiteGround New Client Area and Site Tools – part 10). Despite my insistence on not giving up on the AutoUpdate tool (see AutoUpdate tool cured?), I have however to face facts: AutoUpdate is out of order!

WordPress 5.8.1

As alluded to, this new version of WordPress was released on September 8. In keeping with the definition of “immediate”, the AutoUpdate tool should have taken care of this critical update instantly. That is on September 8.

On September 9, I received a notification from my security plugin:

High Severity Problems:
* Your WordPress version is out of date

As you may know, if you are following this blog (see Change of plan), I don’t have enough time to be on top of everything website-related anymore. For this reason, I didn’t know about this short-cycle security and maintenance release; I thought erroneously that it was already the next major release. Owing to my “24 hours” setting for major releases (in AutoUpdate), I didn’t think too much about this warning at the time. Unfortunately, I didn’t have much time the following days either – buried beneath a huge mass of work.

On September 11, in doing some reading (in bed; on my new smartphone²) I happened across an article that was covering the Multiple Vulnerabilities fixed by the latest WordPress release. Given the late hour – and despite the sense of urgency of this article – I postponed the task to the following morning.

These security vulnerabilities add a sense of urgency to this update. All publishers are recommended by WordPress to update.Roger Montti

Same old same

Sure enough, my WordPress installation was not up-to-date. As for the AutoUpdate tool, it was showing the same signs of “it looks like it’s working, but actually, it is not” as for the last update (see An update on AutoUpdate):

WordPress 5.8.1 now available
Status: UPDATE SCHEDULED

Last time, i.e. for WordPress 5.8 release, the tool updated my installation a week on the due date. Waiting that long for a security update, which was already tardy, was out of the question! Therefore, I clicked on UPDATE NOW and …

… everything went smoothly. The tool even updated a plugin, which was also out of date. So, what’s the matter, you may wonder.

wp-config.php

As explained in SiteGround AutoUpdate tool ruined, given the risk of letting a broken AutoUpdate tool handling my WordPress update, I did comment out the SiteGround code that disables all core updates (see SiteGround New Client Area and Site Tools – part 10). However, SiteGround decided some other way (see An update on AutoUpdate). They removed, or I assumed moved, their code to another location. I guess that I should look at the wp-settings.php file from the ‘/var/lib/sec’ directory. However, I cannot find it or access it; thanks to Site Tools restrictions.

Anyway, I have searched a little further on the subject matter and found this StackExchange question, in which the current content of the file in question was given by RSG. Sure enough, the code to disable WordPress core updates was there:

if (!defined('WP_AUTO_UPDATE_CORE')) {
    define( 'WP_AUTO_UPDATE_CORE', false );
}
if (function_exists("add_filter")) {
    function siteground_remove_php_modules_imagick( $modules ) {
        unset( $modules['imagick'] );
        return $modules;
    }
    function siteground_remove_update_check( $tests ) {
        unset( $tests['async']['background_updates'] );
        unset( $tests['direct']['php_version'] );
        return $tests;
    }
    add_filter( 'site_status_test_php_modules', 'siteground_remove_php_modules_imagick' );
    add_filter( 'site_status_tests', 'siteground_remove_update_check' );
    add_filter( 'auto_core_update_send_email', '__return_false' );
    function siteground_xmlrpc_bruteforce_detector( $user_login = 'unknown', $error = false ) {
        if ( !isset( $_SERVER["SCRIPT_FILENAME"] ) )
            return;
        if ( !strpos( $_SERVER["SCRIPT_FILENAME"], "/xmlrpc.php" ) )
            return;
        if ( function_exists( 'c74ce9b9ffdebe0331d8e43e97206424_notify' ) )
            c74ce9b9ffdebe0331d8e43e97206424_notify( 'wpxmlrpc', getcwd(), $user_login );
    }
    add_action('wp_login_failed', 'siteground_xmlrpc_bruteforce_detector', 10, 2);
}

As RSG said, I just wish they would be more transparent about what they are doing.

To sum up, the tool developed by SiteGround to keep your WordPress sites always safe and up-to-date is doing exactly the opposite. By disabling the automatic background update, which was introduced in WordPress 3.7 to update automatically the minor releases for WordPress core, i.e. the maintenance and security updates (see SiteGround New Client Area and Site Tools – part 10), SiteGround puts my WordPress installation at risk and I cannot even solve this issue!

Talking about nonsense!

---

¹ Immediate (2010) Oxford Dictionary of English – Third Edition. Oxford University Press. ^
² An implied reference to the last post of the micro-entrepreneur mini-series. ^