Previously on the CogitActive Saga:
When installing an SSL certificate, you need some additional configuration. I thought that by turning ON the Enforce HTTPS tool, I just accomplished that. However, I didn’t.
I teased it before; here comes the unbelievable misadventure
, or at least, its opening act. Let me remind you the story first.
Given WordPress “requirement” for HTTPS support (see A web host), I decided to install an SSL certificate. Thanks to Let’s Encrypt and SiteGround, the installation process was a breeze (and free). The tool developed by SiteGround did all the heavy lifting for me: it requested the free certificate (provided by Let’s Encrypt) on my behalf and installed it (see Let’s Encrypt).
The tool was also offering the possibility to force my site to work entirely over an encrypted HTTPS connection. Without investigating further (mea culpa), I turned on this HTTPS Enforce option. My Let’s Encrypt certificate was correctly installed and my site was accessible via https://. At that point, I thought I was done. However, I made a tiny mistake that would be the source of so much trouble. Now, how to fix it? How to make my WordPress website work through HTTPS? The correct way!
What should I have done, but didn’t!
Okay, to understand what this is about, you need a little bit more information. After installing an SSL certificate, you need to make sure your domain is not accessible over both http:// and https://. Specifically, to avoid duplicate content, you need to configure your application to work via https://
1. Naively, I though the HTTPS Enforce option did exactly that:
Forces your site to work entirely over an encrypted HTTPS connection.
However, as explained by Hristo Pandjarov from SiteGround, this is a server level enforce, that does not perform any change to your application configuration and database
2. According to him, the best way to make your site [works] through HTTPS is to re-configure your application [manually]
2; HTTPS Enforce being only an alternative for people that have not and cannot use the previous two options
2. Disappointingly, SiteGround does not explain the procedure (for this recommended approach). It is just described as a task that requires some technical knowledge to be completed properly
2.
Unless you have a brand new website – as it was my case (back then). In that situation, the correct procedure (to configure my application to work via https://) could not be more straightforward: update both WordPress Address (URL) and Site Address (URL) fields (in Settings > General of the WordPress dashboard) by replacing “http” with “https”. That simple! For a brand new website AND a regular WordPress installation!
Unfortunately, I read Hristo’s post a little too late…
WordPress Multisite
Meanwhile, the situation had changed. I turned my (regular) WordPress installation into WordPress Multisite – a feature, which allows multiple virtual sites to share a single WordPress installation (see Multiple installations vs WordPress Multisite?). Once you have created a Multisite network, you become the Network Admin (aka Super Admin). In addition, you have now access to the Network Admin dashboard, which differs from the regular Administration dashboard (see Network Settings). In fact, even the latter will differ slightly from the one of a regular installation (see Configuring WordPress (Multisite) Settings).
Even if you’re familiar with WordPress, the location and behavior of Multisite Network Administration can be confusing.The WordPress codex
As a matter of fact, the WordPress Address (URL) and Site Address (URL) fields are no more in Settings > General. Instead, these items are managed at the network level that is via the Network Admin dashboard. Specifically, you have to navigate to the Sites screen (My Sites > Network Admin > Sites), which lists all the sites within the network. From there, you have to hover your pointer over the name of your site of interest, and click the Edit link, which will bring you to the Site Options. While the Info tab displays the Site Address (URL) field3, you have to go to the Settings tab to access the correct fields, namely Siteurl and Home.
All site settings are stored in this table. Do not edit anything here unless you know what you’re doing.The WordPress codex
Here is another intimidating statement: Just as with the site URL, changing the home URL . . . can also break a portion or your entire site if all instances of your site’s URL aren’t changed in your database
. To make things worse, these two fields – as well as the Site Address (URL) for that matter – were grayed out for the main site. Only the sub-sites, namely this blog in my situation (see Adding a site to my Multisite network), could be edited – with the above risk in mind, though.
What to do?
Clearly, the simple procedure described for a regular WordPress installation does not apply for a Multisite network. Still, I wanted to configure WordPress to work via HTTPS the proper way. Keeping things as they were (i.e. using the HTTPS Enforce tool) was not an option! Regrettably, SiteGround does not provide any “road map”4 for how to proceed – neither in their Tutorials nor in their Knowledge Base.
Nonetheless, I found in their WordPress Toolkit Tutorial a functionality with which, apparently, I could easily configure [my] application to work with [an SSL certificate]
. To do so, I would just have to select Enable SSL within the toolkit and apply my change. Of note, the current SSL state of my WordPress application (as displayed in the toolkit) was indeed Disable SSL. However, there was no indication on how the configuration would be done (behind the scene) and I was a little reluctant to use another tool that I didn’t comprehend.
After scouring Internet for a solution, I eventually found one in this Support Forum: Need to change MAIN multisite “http” to “httpS” – How? In a nutshell, I had to modify the database. Specifically, I had to replace “http” with “https” for siteurl in two tables (wp_options and wp_sitemeta) and for home in one table (wp_options). I found another source confirming this information and still…
SiteGround chat
… I was not confident with manipulating the database and I wanted to double-check with SiteGround if this was the correct way, and what is more a safe way, to proceed. In addition, I was curious about the WordPress Toolkit – a potential alternative. I tried to open a ticket, but was redirected to the chat instead.
On the pop-up window, we will recommend the best channel for your particular inquiry, taking into consideration the current load on our support channels, your account type, and the complexity of your question. We recommend you use the suggested channel for faster resolution.
Anyway, I explained the situation and my configuration. Specifically, I told that I was currently using the Enforce HTTPS tool
, but wanted to configure WordPress manually instead. I also described the different solutions that I thought of (see above and below); clarifying that I didn’t want to use (at least for now) the SG Optimizer plugin
. I also asked – several times – to correct me if I [was] wrong
, whether this was the correct procedure
and whether I forgot anything
. Undeniably, I had many questions, probably too many (for a chat5); anyway, here they are with the responses (if any) provided by the SiteGround’s support agent:
Can I do this 1) directly within the dashboard for the subdomain [site] and 2) using Enable SSL (WordPress Toolkit) for the main site?
Indeed you will need to manually set the https:// connection in the Site and Home URL sections. Then the actual enforcement can be made either through the Lets Encrypt tool or the SG Optimizer as well.
Would this do the trick? Is the mechanism different from the Enforce HTTPS switch, i.e. not a rule at the server level?
UNANSWERED
Should I switch OFF Enforce HTTPS (Let’s Encrypt) before, after or not at all?
You can leave it activated.
If the Enable SSL procedure is not the best way (= server level), what about changing my wp_options and wp_sitemeta tables (siteurl + home) using phpMyAdmin?
UNANSWERED (but see below)
In case I have to modify the database (via phpMyAdmin), should I just change http:// to https:// in my wp_options table (siteurl and home) and in the wp_sitemeta table (siteurl), or should I change it everywhere (replacing all instances of http:// with https://)?
UNANSWERED (but see below)
Is there anything else I should do? Also, what about .htaccess? Should I modify it as well?
UNANSWERED
Do I miss something and are there some bugs or changes to expect?
UNANSWERED
Globally, he was not answering anything; yet, I was able to have him assert – correct
– that I had to do the changes (for the main site) within the database. Thus, at the end of the conversation, I asked again:
To recap, I can do the change via the WP dashboard for the sub and that is it. I have to change 2 entries in the first table and 1 in the second for the main site (using phpMyAdmin) and that is it.
Yes basically this is a straight forward process and by following those steps, you will be able to enforce the SSL connection.
Any advice on starting with the sub first or second?
Please do start with the Main domain name.
That was the end of our chat; if I don’t take into account the you can contact us at absolutely any time
. Ironically, I concluded the chat with this:
I hope that I will not need a ticket after this.
Time for action
It goes without saying that the chat was probably not the best channel to get my questions answered. In particular, I received no information whatsoever concerning the WordPress Toolkit, which might have been a great option. Nevertheless, I was feeling a little bit more confident (with modifying the database) and decided to proceed with this option.
After doing a full backup, I opened phpMyAdmin (located in the Databases section of cPanel) and clicked on the database of my WordPress installation (on the left). This brought me to a list of tables, from which I easily located the ones in question. Starting with wp-options, I chose the Browse action to access all the records inside this table. To modify the option_value record for both siteurl and home, I clicked on the Edit button, replaced “http” with “https”, and submitted my changes by clicking the Go button. Then I moved to the wp-site-meta table and did the same (i.e. added an “s” to “http”) for the siteurl option.
Once the first step completed, I double-checked if I could still access my website. Relieved, I also checked whether the new URL had been updated within the WordPress dashboard (My Sites > Network Admin > Sites). Thankfully, it was! I navigated to the Sites screen of the sub-site, clicked the Edit link, went to the Settings tab, updated the two fields of interest, namely Siteurl and Home, and clicked the Save button. Done!
Almost done, actually
Despite the suggestion to leave the HTTPS Enforce tool activated (see chat), I turned it OFF for both the website and the blog. Now, when I installed my SSL certificate for the website, and turned ON the HTTPS Enforce switch, I also activated the External Links Rewrite functionality.
Ensures your website will not show any “Mixed content” warning due to insecurely loaded external resources.
However, I did not activated this functionality for the blog (see Adding a site to my Multisite network). It is noteworthy that until Gutenberg I was writing my posts in HTML. As dreaded, all the links to my images were still using the insecure HTTP protocol in the URLs. Thus, I had to change all my links (within the <img> tag), one by one! Luckily, there were not so many.
I did this within WordPress (i.e. HTML code), but could have accomplish the same task within phpMyAdmin (i.e. database > wp_post table > post_content). Anyway, after updating my posts, I run a search for %HTTP://% (the exact phrase; selecting all the tables) in the database and noticed that I did forget few occurrences (so ended up correcting them directly within post_content). I also noticed that the wp_post tables had a “guid” column with still many HTTP URLs. The codex is rather clear about this Globally Unique Identified (GUID) field: it is critical that you do NOT change the contents of this field
– Never, ever, change the contents of the GUID column, under any circumstances
. Oops6!
Conclusion
So, where is the unbelievable misadventure
, you may wonder. As I said, this is the opening act – even though I didn’t know that back then. At that point, I was enjoying the fact that 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.
To be continued…
1 In the Let’s Encrypt Tutorial from SiteGround. ^
2 Hristo Pandjarov (2017) Let’s Encrypt Interface New Options. SiteGround. ^
3 Besides, here is the message displayed in the help link about this field: The site URL is rarely edited as this can cause the site to not work properly
. Not very reassuring!. ^
4 A suggestion made on June 9, 2017 at 13:50 by someone called Tim in the comments of the aforementioned post2. Yet, despite Hristo response – that’s a really good idea and I will discuss it with the rest of the team for sure
– this road map tutorial was never issued. ^
5 Indeed, I was ready for the ticketing channel that is with a comprehensive description of the issue (i.e. a 563-word long one). Actually, here was the comment of the agent to this matter: This is quite a long inquiry 🙂
. I apologized and offered him to take his time. ^
6 In reality, my feed was not affected. Given that I changed only the protocol (i.e. https://) and not the Fully Qualified Domain Name (FQDN) part of the URL (see A domain name), I don’t think this will be a problem. ^