Support » Everything else WordPress » Siteground adding code to suppress Site Heath feature

  • I’ve recently discovered that Siteground is adding something to the wp-config file of WordPress sites they host that suppresses some of the new Site Health features. According to their support staff:

    The corrupted health checks in WordPress that the line disable are the following:

    – No warning about auto updates being disabled

    – No warning about PHP version older than 7.3

    – No warning about missing imagic pecl

    This strikes me as being very bad practice on Siteground’s part, but I wanted to get some opinions from the WordPress community before I pursue the matter further.

    Has anyone encountered this with any other hosting companies? Does this strike you as something they should be doing?

Viewing 15 replies - 1 through 15 (of 16 total)
  • What they have done is try to keep the issues down to a minimum by removing a few ‘sore spots’. I kind of expect SiteGround to have a good handle on things and they seem honest and forthright.

    No warning about auto updates being disabled

    I’m not a big fan of auto update myself

    No warning about PHP version older than 7.3

    I’d prefer to see that warning but I run whatever and don’t get real excited about PHP version… unless it doesn’t work. I really don’t think my clients need to see that but then again… maybe they need to prod me sometimes. I forget things, lose notes, and I’m lazy.

    No warning about missing imagic pecl

    I’d rather see that one too but again… It triggers clients to call me. I don’t need more phone calls.

    If it was me I’d take control of my own site and tweak my WP-config to suit me and my needs… and I’d be complaining if they then redid my files without my knowledge unless they added rem statements and also emailed me to explain why.

    Most hosts don’t change things without good reason.



    If you have a Siteground Managed WordPress hosting plan, then their disabling automatic updates makes sense. They are managing WordPress for you…let them do that.

    I am quite frankly glad to see some hosting companies disabling the PHP check. PHP simultaneously maintains two stable branches, a stable development (aka “bleeding edge”) branch, and a stable production branch. I consider it fearmongering and quite frankly a bit dangerous to suggest/coerce people to update to the bleeding edge branch; it should instead suggest/coerce people to update to the stable production branch. In this specific case, PHP 7.3 uses a completely new regex system (PCRE2) than all previous versions of PHP. PCRE2 is not 100% compatible with the old system (PCRE), and in those incompatible cases, PCRE2 typically spits out a different result as opposed to throwing an error. While not technically a WordPress problem, this can be disastrous in cases such as username/email sanitizing. Were these regexes tested to verify they produced the same results with PCRE2 as they did with PCRE? I will not install PHP 7.3 on client sites unless the PHP applications they are using have been tested to verify their regexes are compatible with PCRE2.

    The PHP imagick extension is a CPU pig (more so than GD), and it has numerous compatibility issues due to being dependent on a core application (ImageMagick) that changes features pretty dramatically between versions. If a hosting company provides GD and doesn’t want to provide Imagick, that’s fine. I have no issues with them blocking a notice which doesn’t impact the customer…and that includes all other Health Check notices that the customer can do nothing about.

    @diondesigns I’m seeing this happen across several Siteground accounts, none of which should be on any managed WordPress plan. You make good points about PHP and imagick, but wouldn’t those be issues for the WordPress Site Health development team to address?

    I don’t think it’s the hosting company’s place to decide what should be blocked from the Site Health scan, and I don’t think they should be modifying our website files without asking first and/or telling us why they’re doing it.

    Anita C


    I just checked 5 of my client sites on SiteGround. All of the Site Health links are there, active and I can manage them, troubleshoot just fine.

    ** What exactly is missing or blocked? **

    • This reply was modified 1 year, 5 months ago by Anita C.

    @mymothersdaughter they are blocking several Site Health notifications from appearing – one about your PHP version, one about auto updates being disabled, and one about a missing PHP extension.

    If you want to see if your site is affected, check your wp-config file, there will be a line of code added to the end with a note that reads “added by SiteGround WordPress management system.”

    None of them are critical notifications, but I don’t think it’s Siteground’s call to censor the Site Health feature like they’re doing.

    Anita C


    I only see one line associated with them at the bottom related to “wp-settings.php”. Auto updates are False because I set them that way. I want to update all my sites on my own. I downgraded my site to 5.5 and when I went back to it – I got a notification on a white screen that I needed to 5.6 or higher to run WordPress. Are you saying that notification is blocked for you? Not sure about that missing PHP extension or where to look, but maybe I don’t have any missing PHP extensions.



    If you don’t have managed WordPress hosting, did you install WordPress using some sort of “one-click install” application, or did you install it yourself? I would find it hard to believe that Siteground modified files in a self-installed version of WordPress. On the other hand, it is very common for hosting companies to customize applications for one-click installers such as Softaculous.

    Hristo Pandjarov


    SiteGround Representative

    We at SiteGround provide Managed WordPress service. This means that bigger part of the environment is controlled for you than in a regular hosting provider.

    @jeffersonpowers is correct, we do hide those three notices and there’s a good reason for that.

    The warning about WordPress updates being disabled is shown because we have our own autoupdate system running. We believe it’s better than the core one because we make backups before updates and allow customers to update plugins alongside WordPress. However, in order to avoid problems, the default system must be disabled thus causing the false-positive warning.

    PHP versions is another thing we manage. We support new PHP versions on day zero but the default PHP version on our servers intentionaly stays behind a couple of versions from the bleeding edge. The only way, you can have an old PHP version on our servers is if you have manually switched to it and even then, we regularly run compatibility checks on sites using old versions and upgrade them to the latest possible.

    Last but not least is the Imagick module for PHP which is available but disabled by default on our servers. It’s a very resource-consuming module and I wouldn’t use it unless there’s a speciffic reason for that and enabling it is pretty straight forward (

    The idea for Health Check is great but it has to take into consideration speciffics of the hosting environment. That’s exactly why filters for disabling warnings were added to the check and I think that all Managed WordPress hosting companies will hide a number of warnings because they are irrelevant to the environment they provide.

    [ Signature deleted ]

    @hristo-sg Thank you for responding. I was not aware that Siteground hosting was Managed WordPress by default — I maintain backups and updates for my clients, so I don’t normally recommend that they sign up for managed accounts.

    What I object to is Siteground making these changes without informing us of what you’re doing, and giving us a choice to opt out if we want to handle updates ourselves, or if we want to see the full Site Health report without part of it being blocked.

    An additional issue with the SG line in wp-config.php, is that it interferes with site loading if you clone a site, especially locally.

    Many backup solutions use what’s in the original wp-config.php file to write the new one for the clone site. Since the folder and file called don’t exist, the site errors and won’t load until you know about the SG line and remove it.

    Hristo Pandjarov


    SiteGround Representative

    If you move a site locally or to a different hosting company you will have to edit the wp-config.php file anyway because of the difference in server settings, database hostname, database name and username. If you’re using a software to automate that, I would recommend reaching out to the devs developing it so they can handle this better.

    Hristo Pandjarov


    SiteGround Representative

    Just to add. We will update the way we include our config so it does not break functionality when you clone your config 1:1 to a local environment or other hosting company.

    The second reply is much better than asking ALL the plugin/migration plugins out there to modify their code just for SG.
    You have great hosting, but cloning a site locally should be easy.

    Thank you!

    Hristo Pandjarov


    SiteGround Representative

    Well, migrator plugins should monitor for such changes too because there’s always a change for something to happen. We try to work with all of them and fix issues on the side where it’s most appropriate.

    I was unaware that SG is considered managed hosting. That’s such a broad term that many hosts are using it and what it includes on SG is not listed anywhere, especially the fine details of directives added without permission or knowledge of the client.

    I’m also dismayed that many of the management features are inserted without explicitly letting clients know or giving a way to opt out.

    Publishing a KB article or burying that info in this type of thread is NOT the same as actually alerting folks.

    Instead, we waste time with 4 support tickets to get the info about something that just showed up, or trying to figure out why a local clone of a site broke when using a backup plugin or such.

    I’m also very concerned about the legalities of this pseudo managed position SG has put itself into of updating WP, PHP, and tweaking WP features that could break sites. Most of those features are not for the site owner’s benefit. They mainly function to keep the servers safe, which I get why you would want to do that, but not keeping folks informed is not a good way to do it.

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘Siteground adding code to suppress Site Heath feature’ is closed to new replies.