I’ve taken a site from regular HTTP to HTTPS before, and at the end of the process my conclusion was that “this was much harder than it should have been.” This time, I chose a simple one page website to migrate and it went relatively smoothly. Here are my steps and experiences in moving a website to SSL.
The site I was moving did not change a lot and there were not comments open on posts that I had to worry about. SiteGround does a daily backup of sites, that you can restore from cPanel, so I knew I had a backup in the worse case scenario. I also use BackupBuddy, which saves a nightly backup to my Dropbox account.
WordPress stores the full URL of your site in the database for each post and media item. One of the tasks in moving to HTTPS is to update those links in the database. To simplify, I thought it would be make sense to delete all of the old revisions and unused items for the database. I started off making a snapshot of my production site onto my local machine. I use BackupBuddy’s “Push / Pull” functionality to pull the current production site down to development.
With the current version copied to my local machine, I downloaded and installed the WP-Sweep plugin. WP-Sweep provides a single page with the option to clean your database tables. After the sweep, I used phpMyAdmin to manually take a look at the database tables and found that I still had some demo data installed.
For the website in question, I was using Themify’s Ultra theme. Themify makes it very easy to install the demo data for its themes by providing a button in the settings page. They do this so that it is easy to setup the theme to look like the demo. Fortunately they also make it easy to remove the demo data, via another button on the same page. With that done, I took another look at the database using phpMyAdmin and saw that the posts table was down to a single screen of entries. I deleted any unused themes and plugins and used BackupBuddy to Push the cleaned site back to production.
I logged into cPanel at SiteGround and clicked the icon for Let’s Encrypt SSL. I expected the setup of the SSL certificate to be more complicated. What I saw, when I got to the GUI for the SSL Let’s Encrypt, was a drop-down list of my sites. I chose the single page site I was working with and clicked the “Install” button. About 40 seconds later it was done.
The usual suggestion is that you add a directive to your wp-config.php file to force the WordPress admin to SSL:
Since this was such a simple site, I decided to skip this step and try logging into the admin without it. I was able to log in without problems, which I took as a good sign. I then tried to reach the front page of the site via HTTPS and it came up also, though without the green lock icon, which indicated that some of the data was still coming over HTTP. Since I was expecting to need to change the URLs in the database, this was expected.
I used the Search & Replace plugin from the WordPress repository to change the URLs from HTTP to HTTPS. This involved running the search using the plugin, downloading the SQL file it generated, and then importing that same file back into the plugin to actually do the updates. I guess the author of the plugin did not want to make it too easy to make changes, because this is a power tool, and power tools can be dangerous. With the database updated, I then hit the front page of the site using the very nice web tool, Why No Padlock. This site provides a nice actionable report showing any files or links that are not SSL. I was surprised to see that there were still some links with the old HTTP URL. What gives?
Looking closely at the problem links, I saw that those were links to images on the home page. I jumped into phpMyAdmin on the production site and verified that all of the links I could see in the database were correctly pointing to HTTPS. I had used the Themify page builder to create the page. I popped it open and saw that the image links for the home page still pointed to the old URL. Those image cells in the page builder were the culprit. I suspect that the page builder stores its content in shortcodes, and the database search and replace probably does not change the data in a shortcode. I manually updated the links, checked back with Why No Padlock and … crap, still no change. Ah, I remembered that SiteGround has a nice caching feature, so I went back to cPanel and cleared the cache for the site and … Green padlock!
In testing the site, I noticed that even though SSL was working correctly, I could still access the site the old way by typing in the old HTTP address. I downloaded and installed the WP Force SSL plugin, which took care of that issue. I believe I could have instead added a redirect in the Apache .htaccess file, which I may go back and do later.
All in, it took about an hour and half, which was much quicker than my previous experience. Yeah! I moved a site to PHP 7 and SSL!