Are the wordpress settings (abspath, disable core updates) added by SiteGround of any use after I've migrated to a different host?

I had started my wordpress site with the host SiteGround. Later I moved to another host.

I now see that in my wp-config.php file the following settings are present near the end of the file:

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

# Disables all core updates. Added by SiteGround Autoupdate:
define( 'WP_AUTO_UPDATE_CORE', false );

@include_once('/var/lib/sec/wp-settings.php'); // Added by SiteGround WordPress management system

Does anyone know whether or not I should let these settings remain as they are? I'm particularly suspicious about the third one - disabling auto-core updates.

Is it better to keep core updates disabled or enabled?

Topic wp-config hosting automatic-updates Wordpress

Category Web


This is the current content of the file if someone is interested. I just wish they would be more transparent about what they are doing.

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);
}

Both of these settings are used in all WordPress installs - they're not specific to any host.

The ABSPATH ensures that WordPress knows which folder to look in to find all of its files.

Whether Core auto-updates are good or bad really comes down to your own processes and preferences. For security reasons, enabling the updates is recommended. However, if you are running a site with a lot of plugins and/or themes where small changes to Core may have major affects across your site, you may want to instead build a staging/dev site which is a copy of your live site, but where you update everything and test the effects before updating your live site. WordPress Core developers try not to break things in changes, but particularly with the Block Editor some things like block classes and styling may vary from version to version, so if you're doing for example a lot of custom blocks and modifying Core blocks, you might be better off not enabling updates on your production site.

About

Geeks Mental is a community that publishes articles and tutorials about Web, Android, Data Science, new techniques and Linux security.