SiteGround New Client Area and Site Tools – part 11

… starting from the point where the story stopped.

First, I double-checked my wp-config.php file. Sure enough, the line of code added by SiteGround was still here. However, there was something else!

Two weeks ago, I posted a “non-post” – Want to bet? – explaining that I would need more time to explore Site Tools and to prove Hristo wrong or right. The way things are going, I may have plenty of time (without having to resort to delaying tactics indeed). Verdict¹ next week… Maybe!

Anyway, kidding aside, here is the “something else”:

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

Although I have noticed this extra line of code following a problem related to the migration (see part 10), this issue is not related to SiteGround New Client Area and Site Tools. A quick inspection of my monthly backups (kept locally) revealed indeed that SiteGround added this code around May 2019. Anyway, what the heck did SiteGround add to my wp-config.php?

My own investigation

My immediate reaction was indeed to try to figure out when SiteGround added such a code. When I found the info (see above), I felt a bit ashamed not to have noticed this change earlier. On the other hand, the wp-config.php file is not a file that I modify often.

One of the most important files in your WordPress installation is the wp-config.php file.WordPress

I could not find anything of relevance on SiteGround blog (at least nothing published around this period). What could this date – May 2019 – correspond to? The only thing I could think of was the release of WordPress 5.2 (on May 7, 2019), but again nothing on SiteGround blog about this release either.

Without going into details, the include_once() PHP statement is used to include a PHP file in another one. As for the “once” – i.e. as opposed to include() only – it prevents including the same file twice. In addition, if the file is not found, a warning is shown and the program continues to run. I assume that SiteGround added the @ symbol to prevent such warning.

The at sign (@) is used as error control operator in PHP. When an expression is prepended with the @ sign, error messages that might be generated by that expression will be ignored.Vineet Joshi

The next obvious question was about the content of the included file. Unfortunately, I could not find the file in question. Of course, I could not but blame² Site Tools for such a limited access – no longer access the home folder of File Manager.

Siteground adding code to suppress Site Heath feature

Unable to figure out by myself what this was about, I was glad to find on WordPress.org this thread – Siteground adding code to suppress Site Heath feature – initiated by jeffersonpowers:

The WordPress community had some opinions – 16 replies to be precise – on that matter indeed. From Most hosts don’t change things without good reason to They are managing WordPress for you…let them do that, the first opinions were neither useful nor satisfactory as demonstrated by Jeffersonpowers own reply:

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.jeffersonpowers

And him to insist – rightly so:

I don’t think it’s Siteground’s [sic] call to censor the Site Health feature like they’re doing.jeffersonpowers

Here is what Hristo Pandjarov (from SiteGround) answered:

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 [sic] 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 [sic] reason for that and enabling it is pretty straight forward (https://www.siteground.com/kb/enable-imagick-imagemagick/).

The idea for Health Check is great but it has to take into consideration speciffics [sic] 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.

Unfortunately, I currently don’t have the time (see Back to normal?) to look into this matter further; yet, the above explanation looks convincing enough. Nonetheless, I could not but agree (again) with jeffersonpowers:

What I object to is Siteground [sic] 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.jeffersonpowers

Of course, Hristo had the last word:

We allways [sic] notify our customers for changes that might affect their websites including PHP version changes and auto update events. The configuration we’re including is simply to handle better the new feature provided by WordPress and does not affect your site in any way.

“Really, when, where?”

---

As for now, given my lack of expertise on the subject matter, I will not remove (or simply comment out) this code from my wp-config.php. Besides, SiteGround seems to have a good reason to add it (see above). However, to repeat what jeffersonpowers said, I don’t think they should be modifying our website files without asking first and/or telling us why they’re doing it. Yep, these are clearly bad practices!

---

¹ Spoiler: there is a high probability that my first impression turns out to be accurate. ^
² That being said, I should equally put the blame on my lack of acquaintance with the aforementioned directory. ^