Web Development

It Is Hard to Believe How Poor SiteGround’s Support Documentation Is

From our experience people trust their web host to provide good advice on dealing with problems with their websites, but also from our experience, unfortunately, the advice is often useless and sometimes even harmful. Since most of that is coming from one-off exchanges with support personnel, it is hard to attribute that to a general issue with the web host. But with a recent instance involving SiteGround, the public advice they provide in their support documentation is so bad it is hard to understand how it exists in that form.

With a website we have been brought in to do some work, a problem needing to be dealt with was at least part caused by an ill-conceived action taken by the SiteGround, but in trying to resolve that our customer had tried to resolve another issue, a mixed content error. Mixed content refers to having content on a page being served over HTTP when the page itself is served over HTTPS. SiteGround provides instructions on dealing with that, on a page titled What Is Mixed Website Content Error and How to Fix It?. Under the heading “How to fix the mixed content error” they write this:

The fastest way to solve this issue is by using the functionality ‘Force HTTPS’ in the SG Optimizer plugin. It will redirect all the traffic for your website to HTTPS which should help avoid mixed content, except in some cases of remote resources still being pulled over HTTP.

Then the first step to do that is:

Install the plugin by logging into the WordPress Admin > Plugins > Add New.

You can only log in to the WordPress Admin if your website is using the WordPress software, so these instructions are only relevant for WordPress websites, but that isn’t clearly noted. The first mention of WordPress is in step 1. After getting through all the instructions, they write this:

If you are not using WordPress or even after using SG Optimizer there is still mixed content on the website pages, then you can use this online tool to find which content is being served via HTTP. You would have to attempt to correct all of them to load over HTTPS manually, based on the specific elements.

Wouldn’t you want to note that the instructions are not relevant to websites not using WordPress before providing them, and not after?

It isn’t like that is something that you can only come across from their website with notice that it applies to WordPress. At the bottom of that page a related article, How to enable padlock on my site?, is listed. The totality of the information provided on that is, with a link to this page at the end:

Your SSL certificate is installed and valid.

The website is working over HTTPS.

There are no elements loaded over an HTTP connection (mixed content).

SiteGround Doesn’t Even Warn Their SuperCacher Caching System Can Break Website Functionality

Less than a month ago we wrote a post that mentioned a recent situation where a Zen Cart based ecommerce website was not allowing products to be added to the shopping cart in some instances, which is a big problem. The source of the problem was caching done by a web host we didn’t mention in the post. The same exact issue has come up with another website and this time we had access to the web host’s control panel, so we could better see what is going on with the web host, SiteGround, and things don’t look good.

When you go the settings page for their SuperCacher caching system, you are provided with this information about it:

SuperCacher services are developed by our server optimization experts to increase the number of hits a site can handle seamlessly and dramatically boost your website’s loading speed. There are 3 different caching options for maximum optimization of your websites. Our tests show that a website using simultaneously NGINX Direct Delivery & Dynamic caching along with Memcached can handle 100 times more hits than a regular website without any caching.

There is no warning that the feature can cause problems, like the one we have now run across twice in less than a month. Perhaps they don’t understand the implications of what they are doing, which is quite problematic considering the caching causing the problem with those websites is enabled by default.

Disabling Dynamic Caching

If that were not bad enough, while two of three types of caching provided, NGINX Direct Delivery and Memcached, can easily be disabled on the feature’s settings page, the one that is at issue here, Dynamic Caching, can’t. The tutorial for the feature, which is linked from that page, also doesn’t currently provide any information on disabling that. If you use the search function accessible on that tutorial, you also won’t find the information. There is a page on a separate part of their website, for some reason they have two different support sections, explains how to disable that using code added to the website’s .htaccess file.

Update – 4/16/2021 – SiteGround doesn’t provide a way to contact them through their website unless you are a customer (which is odd), but we tried notifying them through Twitter about the problem they are causing here. They responded, but the response wasn’t good, starting with them stating that performance is apparently more important to them than not breaking websites:

One of our primary goals is to ensure the best possible performance of all sites hosted on our servers and our caching setup plays a major role in the process.

The rest of it involved them ignoring the reality of the situation, so it doesn’t seem like they are a great option for a web host.

Hiring a Freelancer Isn’t Necessarily Going to Save You Money on Web Development Tasks

We often deal with people managing their own websites who would probably be better served to hire someone to handle things for them on a continuing basis instead of handling things through a combination of doing things themselves and hiring someone like us or freelancers on a one-off basis. It’s worth noting that they are not necessarily even saving money by hiring freelancers to do work. Take something we ran across on a freelancer website recently while looking for some unrelated information. The person hiring a freelancer wanted a very simple .htaccess redirect written:

I need a website to redirect to www version and https in one hop. In other words, if user enters non-secured domain, it always needs to redirect to www. version.

For example, if they enter “[login to view URL]” it needs to go to “www.domain.com.”

If they enter non-secured domain, it needs to go to secured domain, www version. For example, If they enter “[login to view URL]”, it needs to go to “[login to view URL]”

So the end result should always be the secured domain, www version, in one hop.

I will not allow access to the server due to security reasons. The current code for the HT access is below. Please let me know if questions.

They ended up paying $60 for what should amount to a couple to a few lines of code being written. Which would take, conservatively, ten minutes to write and test. That is the sort of thing we do for no additional charge when doing other work, since it is so insubstantial.