A (SiteGround) ticket to hell

Previously on the CogitActive Saga:
I managed to configure my Multisite installation to work through HTTPS – a task more demanding than for a brand new regular installation, but not impossible. Despite the suggestion to leave the HTTPS Enforce tool activated . . . , I turned it OFF for both the website and the blog.

To recap, I realized (a little too late) that I should have done some additional configurations after activating Let’s Encrypt rather than using SiteGround HTTPS Enforce tool. While the procedure is very simple for a brand new WordPress installation, making a Multisite network to work through HTTPS is a different story (see Making my website work over HTTPS – the proper way). Nonetheless, after some research (and a useless chat with SiteGround), I managed to configure my main site and the subdomain site (i.e. this blog) the proper way. I then switched OFF the HTTPS Enforce tool for both sites and looked at my achievement with satisfaction.

This feeling didn’t last long, though. Few days later, I discovered that my blog was accessible over both HTTP and HTTPS. Not a good thing because of duplicate content issues¹. Besides, what is the point of having an SSL certificate in place if an unsecured version remains accessible? Surprisingly, the main site was not affected by this problem!

I started to wonder if I made a mistake during the aforementioned configuration and the unanswered questions from the chat with SiteGround suddenly came back to me:

• Is this the correct procedure?
• Is there anything else I should do?
• What about .htaccess? Should I modify it as well?
• Do I miss something and are there some bugs or changes to expect?

Here comes “the unbelievable misadventure” previously teased.

My own investigation

I switched the HTTPS Enforce tool back to ON – for the blog only (since the main site was fine) – and searched again (Google) about how to setup SSL manually; a permanent and more performance optimized solution².

Going through the procedure one more time

As explained earlier, in order to make a new WordPress website to work over HTTPS, you just have to replace “http” with “https” for both WordPress Address (URL) and Site Address (URL) fields in the dashboard (General > Settings). That simple! Except that this applies to brand new WordPress websites only (see below) on the one hand, and this task ended up being a little more challenging given my Multisite installation on the other hand. Nonetheless, my WordPress installation was now correctly set. Checked!

Moving an installation from HTTP to HTTPS involves another step that is to add some lines to your .htaccess file to force the SSL usage³. Doing so will redirect all traffic to the HTTPS URL. Again, this is important for existing WordPress sites, but not necessary for brand new WordPress websites! Furthermore, all new WordPress installations completed on [SiteGround] servers via Softaculous or via [their] setup Wizard now use the automatically installed Let’s Encrypt SSL and run through HTTPS by default³.

New WordPress installs already run via HTTPS out of the box.Hristo Pandjarov

The aforementioned post³ was published about a year before I installed WordPress via the setup Wizard. Curiously however, I still had to install my Let’s Encrypt SSL certificate and my WordPress was not running through HTTPS by default! Actually, one of the comments from this post (by Roy; February 8, 2017) was as follow: do we still need to change the WordPress and Site URL in WordPress settings?. SiteGround’s reply was clear No, it will do it for you. No, it didn’t!

So, is this “redirect” step checked? No, but I don’t think it is required.

Continuing with the procedure to make your WordPress site run over HTTPS, the last step consists in identifying and fixing mixed content issues (again, for sites that were using HTTP before). As explained in the previous post, I went through my posts to update the links to my images (replacing “http” with “https”). To double-check that I didn’t left any “unsecured” resources, I then used this tool to search for non-secure images, scripts and css-files. I was glad that no issues were found. Checked!

While not mandatory, some articles were also mentioning the possibility to force SSL and HTTPS on your WordPress admin area or login pages². To do so, there was a line of code to add in the wp-config.php file. However, I didn’t implement this rule because it is related to administration over SSL – when entering wp-admin or wp-login – that was not my current concern.

Stuck!

I could not fathom why my blog was accessible over both HTTP and HTTPS. In particular, the fact that the main site was working just fine was quite puzzling. What was the difference? Why the problem was limited to the protocol (i.e. HTTP/HTTPS) and not affecting the host (i.e. www vs non-www)? Was there something, at the server level, not properly configured? The “something” probably done by SiteGround (“somehow, somewhere”), for instance!

After several infructuous searches over the net, I thought I finally found the outline of a solution in Canonical URLs⁴. In theory, this feature, introduced in WordPress 2.3, automatically redirects all incoming links to the proper URL defined by siteurl, namely Site Address (URL). Why this built-in redirect was working perfectly well for my main domain, but only partially for my subdomain (i.e. for the host, but not the protocol)?

My first (and wrong⁵) guess was that this feature was only applied to the host, not to the protocol. The implementation of this functionality was quite old (September 25, 2007) that is before Google and others pushing the entire web toward HTTPS adoption. Thus, neither the related post⁴ nor the codex page (for that function) was referring to HTTPS, just providing examples for www vs. non-www. Then, why the main site was correctly redirected for both? Again, I was thinking of this “something, somehow, somewhere” from SiteGround, when I stumbled on this article: WordPress Redirect – Best Practices For Faster Performance.

Encouragingly, it was starting with this sentence: There is a WordPress redirect functionality built into core which is designed to catch wrong URLs⁶. According to the author, however, the situation gets more complex if you set up your website to resolve using HTTPS. Okay, keep going… Disappointingly, the rest of the article was about performance issues; hence its title. Nonetheless, it was quite informative, this statement in particular: resolve your top-level domain with no more than one redirect⁶.

Your goal is to make sure that your URL is reached with no more than one redirection no matter what combination of protocol prefix and subdomain a visitor throws in front of the top-level domain.Jon Penland

What he meant is that all of the following URLs should resolve to the [canonical URL] with no more than one redirection, and one of these should resolve with no redirects⁶:

• http://example.com
• http://www.example.com
• https://example.com
• https://www.example.com

He was not offering a solution to my problem, but a Redirect mapper tool to check how many redirections are required to resolve [a] site’s URL using those different combinations⁶. When I run the tool for the main site, the outcome was as recommended – only one redirect happening for each of the three non-canonical URLs and no redirect for the good (canonical) one. Great!

However, for the blog the situation was different. As expected, without HTTPS Enforce, both www versions (i.e. http://www and https://www) were redirected to their respective non-www versions, but there was no redirect from http:// to https:// (neither directly for one of the non-canonical URL nor after the previous redirect from http://www for the other). When HTTPS Enforce was active, the redirect from http:// to https:// was indeed enforced, but this was resulting in a double redirect in one of the configuration (from http://www to https://www and then to https://). An example of redirect that is not setup correctly according to Jon Penland’s article⁷!

His advice concerning the double redirect was to create rules that target any URL formulations that require more than one redirection to force those URLs to resolve directly to the properly formulated URL⁶. This was not a fix to my problem, nor an answer to my questions, but a lead worse considering. If I could not fix the canonical URL functionality for the blog, at least, I could try to achieve the same result with a 301 redirect⁸.

The ticket

Not able to fix (or even comprehend) the problem on my own, I had to resign myself to post a ticket in [SiteGround] Help Desk. Given my previous experience with the chat (see Making my website work over HTTPS – the proper way), I was resolute not to accept a redirection to this channel (suggested or not).

After describing my WordPress configuration, as well as my recent changes (i.e. HTTPS in WordPress), I explained the problem (see above) – trying not to be too verbose. Yet, I emphasized that I had a multisite installation that was not using Wildcard subdomains (see Setting up WordPress Multisite) and that I wanted to keep it that way! At the end, I recapitulated the main issue:

To avoid duplicate (http and https) for the subdomain, I have to switch back ON the Enforce HTTPS tool (for the subdomain only). However, this is using a double redirect for the http://www to https://. The main site is perfectly configured, without using the Enforce HTTPS tool, with nice and clean redirects.

And asked the following questions:

Why? What is the difference compared to the main site? What did I miss? What should I do (other than using SG optimizer plugin)? Would the Let’s Encrypt Wildcard help fixing my problem?

I will not provide the transcript, which is excessively long, but try to summarize the whole story in a chronological order – one Guru at a time!

Support Guru K (day 1)

Seven minutes later, I received a response, but not the one I was expecting:

I have tested your websites by accessing them and as I can see both force HTTPS and function with it well. Note that as I can see there is no need for any further modifications and despite the different methods you have used the end result is the same and both websites are functioning properly.
I can confirm that there are no issues generated by the configuration of your websites and would advise you to not make any further modifications on their HTTPS settings. Additionally, as I can see both your domain and subdomain have valid SSL certificates issued for them thus a WildCard SSL is not necessary in this case.

I immediately responded that indeed the main site was working well, but the blog was NOT. I clarified the problem and asked again:

What should I do for the subdomain site (and other in the future) to work as the main site (i.e. working with https without the Enforce HTTPS tool and with clean single redirect)?

And him to reply:

I would like to say that both of your websites are using a single redirect to enforce HTTPS . . . you do not need to make any further modifications.

Really! Is he kidding me? I tried to sleep on it…

Support Guru A (day 2)

Even though I could not sleep because of anxiety-related nausea, I had plenty of time to think about my response. Thus, I reiterated my concern – with a long, detailed explanation – and concluded with I hope that this explanation help clarifying the issue and that you will be able to provide me with answers. I addressed it to Guru K, but received an answer from a new Guru:

I checked both websites and . . . I am being redirected automatically to HTTPS. I used several manual redirects through the .htaccess file, however, since the site URL is already changed, any additional redirect causes a redirect loop and it is not necessary. In case of multiple redirects that the domain name goes through before the final destination, they will be visible in the curl request. However, such redirects are not present currently and the websites work properly.

She also provided me with an online tool (redirectdetective.com) that should confirm her, as well as Guru K, results. Of course, the tool was giving the same outcome as the one I was using. One more time, I repeated my message trying my best to explicate the issue: in particular, the SINGLE 301 redirect for the main site versus the TWO 301 redirects: the first to the secure https://www and the second to its non-www form for the blog. I also reiterated my questions:

Why the main site is fine and the subdomain one is not? Why for the main site, but not the subdomain one, I don’t have to use the Enforce HTTPS tool and all the redirects are “direct”?

Apparently, this time the message was clear given her response:

Apologize for the misunderstanding. I believe the issue is resolved now and the HTTPS option through the Let’s Encrypt tool is disabled. I used manual redirects through the .htaccess file and everything seems to be working as expected now. Please proceed to verify the results on your end.

For a brief moment, I felt relief! However, the fix was NOT . . . working as expected. After telling her that the main site was now having the double redirect issue, I added the following:

Believe me, if the solution was easy, I would have found it on my own. I am not an expert, but strong-willed, and I search for a solution for days. I assume the key is to understand what differs in between the configuration of the two sites. However, as I didn’t do anything particular on my side (except for configuring the multisite on my own, as well as the subdomain), I could not find anything to explain why they behave differently. For this reason, I turned to you for help.

And concluded with this:

So, could you please UNDO your ‘fix’ and hopefully try and identify a solution.

I also insisted on her taking all the time required to identify the correct solution (if any), explaining that there was no emergency. Apparently, she didn’t got that part and replied almost instantaneously:

The applied redirects are removed. It is quite normal when a redirect in .htaccess file is added, the same to affect all websites because the primary one the sub-site is using the same document root folder. I adjusted one of the rules so it can apply only for the subdomain and not the main domain name. However, it disabled the HTTPS redirect on the subdomain due to the opposite configuration.
The task that you are trying to achieve will require different configuration of your network, like using Subdirectories and not subdomains, which will create different subfolders and the rules will be applied per subfolder or you can contact a professional developer to create a custom redirect rules and adjust the configuration of the website.

Resignedly, I concluded the ticket with this:

I am afraid that this leave my issue unresolved. Thank you for trying, though.

Support Guru M (day 2)

Actually, before the above conclusion, I stated that:

I don’t want to change the configuration of my multisite installation. As I said, I am a strong willed, stubborn person; I will keep searching for a solution. At least, I know it is not a low-hanging fruit.

I really thought the ticket was over. My (supposedly last) reaction was just a thank-you-but-no-thank-you kind of response. I didn’t await any reply, and yet, unexpectedly, I received one from a new Guru (from the “Technical Support Team” for that matter):

I apologize for the delayed reply. As for [the main site] it is properly pointed toward HTTPS and the SSL is fully operational.

What? Do they read tickets before to reply? I should have ignored it, but probably in hope for a solution, I took an unwise step:

I thought from the previous answer from [A] that she will stop searching for a solution, hence my previous response. To be honest, I didn’t expect you or anybody to reply to it. If you end up resolving my issue, I would be grateful. On the other hand, if you can’t, I would understand. PS: No need to apologize for the delay. As stated earlier, I prefer to wait longer for my problem to be fixed rather than receiving a quick response without solution.

Apparently, he read my post scriptum:

Thank you for the understanding. Please allow us some time to look into this, once we have any updates you will be notified here. Thank you for your patience in advance!

Support Guru S (day 2)

Given the previous answer, I was feeling reassure that from now on, they would take my ticket seriously. No more hasty response, no more rash fix… I had no idea just how reckless the next Guru would be:

For your convenience I have replaced the blog sub-domain with actual Wild Card sub-domain.

When I saw, the following day, what this Guru (supposedly) from the “Senior Technical Support” did, I thought I was entering The Twilight Zone.

You unlock this door with the key of imagination. Beyond it is another dimension: a dimension of sound, a dimension of sight, a dimension of mind. You’re moving into a land of both shadow and substance, of things and ideas. You’ve just crossed over into… the Twilight Zone.Rod Serling

To be continued…

---

¹ If the same content appears at more than one place – a place being a unique URL – search engines don’t understand that all these alternative URLs represent the same source. Consequently, you end up competing against yourself in search engine rankings. Importantly, this applies to the www vs. non-www and/or HTTP vs HTTPS versions of the URL. ^
² Syed Balkhi (2018) How to Properly Move WordPress from HTTP to HTTPS (Beginner’s Guide). wpbeginner. ^
³ Hristo Pandjarov (2017) HTTPS for WordPress with a click. SiteGround. ^
⁴ Mark Jaquith (2007) WordPress 2.3: Canonical URLs. ^
⁵ Indeed the function redirect_canonical(), which is located in wp-includes/canonical.php, includes an is_ssl() function in the section to “build the URL in the address bar”. The latter check if SSL is being used. If so, the URL will start with https:// otherwise it will use http://. ^
⁶ Jon Penland (2019) WordPress Redirect – Best Practices For Faster Performance. Kinsta . ^
⁷ One of the submission requirements for the HSTS preload list is to redirect from HTTP to HTTPS on the same host, if you are listening on port 80. This involves a double redirect: first to https:// (without new DNS query, so the server can send the HSTS header) and then to the correct host (either www or non-www). Apparently, performance (i.e. single redirect) and security (HSTS) do not mix! ^
⁸ As suggested by the name, a redirect is a way to send to a different URL (than the one requested). The number associated with the redirect is an HTTP response code status, the two most common being 301 for permanent and 302 for temporary redirects. The former is typically used to ensure users (and search engines) access the latest version of a website (or web page) after a move (e.g. from one domain to another). A 301 redirect is also appropriate, among other uses, when converting an HTTP into an HTTPS site for that matter. As for the 302 redirect, it makes more sense to implement it when a website is undergoing maintenance, for example, or if the destination URL depends on state (e.g. seasonal pages). ^