Everyday, the threat of online hackers continues to grow and it’s essential that websites remain secure.  This article describes how to convert an existing HTTP WordPress site to HTTPS-Only.

Note:  this article assumes that you have already obtained an SSL certificate for your website and have installed it on your web server.

How to Convert an existing HTTP WordPress Site to HTTPS-Only in 5 Simple Steps

  1. Force all traffic coming to the admin and login areas of the site to SSL-Only.
  2. Secure all public areas of Your WordPress website
  3. Secure CSS and JavaScript requests in the .htaccess file.
  4. Clear any cached resources from WordPress.
  5. Identify any remaining issues you may need to address from previously operating over HTTP.

Secure the Admin Areas FIRST

The first area we need to address is the user login and admin areas of your WordPress site.  If you’re new to WordPress, the admin area is the place where all the magic (and your hard work) happens.  It’s imperative to secure this area immediately.

Connecting via HTTP

To access the admin area of your website, enter your URL in the address bar using HTTP, as in http://yoursite.com/wp-admin.  Or, you can simply enter yoursite.com/wp-admin in the address bar and the result will be the same.  In the example below, I’m using my website.  On an unsecured connection, you will see something similar to the following, depending on the browser you are using.

Unsecure connection to WP Admin Area
HTTP Access – no SSL Encryption

The first thing you’ll notice is that to the left of the ‘www’ in the address bar is a site information icon (the little ‘i’ in the circle.)  This webiste may not be secure  I’m going to refer to this as the ‘dreaded eye’ from here on out.

Unsecured connections such as this transmit data between computers in what is called plain text.  That means that anybody between those two computers, with the right software, can intercept the data being transmitted and read it just like opening a page of a book!

We want to encrypt this information using a secure connection.  This makes things much harder on anybody trying to steal it.

Connecting via HTTPS

Now, in the same browser, re-enter your URL into the address bar, but this time use a secure connection by typing ‘https://’ in front of your URL, as in https://yoursite.com/wp-admin.  The picture below shows that we are connecting to the site over HTTPS, but the dreaded eye is telling us the site is not totally secure, which is bad.  Especially on pages where we enter our login credentials.

 

 

Site may not be secure
HTTPS Access and the Dreaded Eye

The Dreaded Eye

The “https:” in front of the address in our browser tells us that the connection is secure; that the information flowing between our computer and the server is encrypted.  This is great!  But, the dreaded eye tells us that there are still problems with the site security.  We will address the issues causing this once we lock the front door to the site.

What we’ve shown so far is that we can access this site using both unsecured (HTTP) and secured (HTTPS) access.  That’s a bit like putting a really great lock on the door to a secure area of your store, but always leaving it unlocked.  What we want to do now is engage that lock, and force anybody coming in to use the secure access.  So, let’s lock it down.

Locking it Down

Forcing WordPress to use only secure connections for logins and admin sessions is straightforward and simple.  Simply add the following entry to your WordPress main configuration file.

 

Force SSL-Only in the WordPress Admin Dashboard
Force SSL-Only in the WordPress Admin Dashboard

 

The wp-config.php file is located in the root directory (folder) where all our WordPress files are stored on the web server.  Open this file in your favorite text editor and add the two lines shown above.  The comment above the ‘define’ command is purely optional, but I like to add comments with changes I make to the code found inside WordPress files.  It’s a good practice and it makes maintaining the site easier down the road.

Once you’ve added this line to your config file, save the changes.  If your website runs on a remote server and you either already had a copy of this file locally, or downloaded it via FTP to work on it, you will need to upload it back to the server for the change to take effect on your website.

Now try access the admin area of your site using either http://yoursite.com/wp-admin or simply yoursite.com/wp-admin.

You will see that your browser forcefully redirects you to the secure address at https://yoursite.com.

 

Secure all Public Areas of your Website Using the WordPress Admin Dashboard

Although we have now secured all our WordPress site login screens and admin areas, the public area of the site that all of your visitors see is still unsecured.

 

HTTP Access to WordPress Home Page
Visitor’s view of your website with the Dreaded Eye

 

Notice the dreaded eye to the left of the URL in the address bar.  Unfortunately, the changes we made in the previous section don’t address the public areas of the website.  To properly convert an existing HTTP WordPress site to HTTPS-only, we have to cover all our bases on both sides of the site – Public and Private.

Now, whether the public sections of your website are secure may or may not be a big deal to you, I’ll say this – if your site uses any forms whatsoever to capture user information, even if it’s only a simple ‘Contact Us’ form, you should be concerned.

Furthermore, SSL security is a huge deal to Google!  In fact, failing to properly secure your website using HTTPS and SSL certificates can negatively impact your site’s search engine rankings.

A Quick Note on Contact Forms

Even if it’s only a simple contact form with no credit card or other sensitive information, I personally wouldn’t want to provide any information over an unsecured connection.  At the minimum, we’re talking about your name and your email address, and possibly your telephone number and physical address.  We don’t want to send this data across the wires on a silver platter for any hacker using a man-in-the-middle attack to exploit.

Not to worry though, there’s an easy fix!

Log in to your WordPress Dashboard using your nifty new secure SSL-only connection (https://).  Open the general settings by clicking on the ‘Settings’ option and selecting ‘General’ in the left navigation menu.  This will open the main settings panel that controls site-wide settings for your WordPress website.  In the middle of this screen you will see two fields for your website’s address like this:

 

WordPress Address Settings
WordPress Address Settings in the WP Admin General Settings Panel

 

Again, I used my website as an example.  Your address structure may be a bit different depending on whether your WordPress site runs at the root level of your website or in a sub-folder.  The important part, though, is the ‘http’ part.  Change the beginning of both addresses to ‘https’ as in:

 

WordPress Address Settings in the WP Admin General Settings Panel

 

Now, scroll down to the bottom of the page and click the ‘Save Changes’ button.

In your browser, go back to the tab showing your home page and refresh the page by hitting F5 on your keyboard.  Now, we can see that the web server is forcing all traffic over to the secure connection (note the “https” in front of the address.)

But the dreaded eye is still there!  Balefully staring at you, like you took the jelly out of its doughnut.

Addressing Internal Asset Requests

Everything we’ve addressed so far has to do with page-level access on our website.  What we have to realize is that when we request a page in our browser, the page itself makes many, many internal requests in order to create itself so it can show off to you in all its splendor.  What’s happening here is that the page itself is not making these requests to the server on a secure connection.

These requests could be for other pages, page styling information, images, and scripts such as JavaScript files.  We commonly call these internally-requested resource files “assets”.  In the next section of this article, we discuss how to request these assets in a secure way.

 

Securing CSS and JavaScript Requests

Locking down the site admin and login pages and changing the site URLs to start with “HTTPS” instead of “HTTP” is a good start, but we’re not there yet.  To convert an existing HTTP WordPress site to HTTPS-only, we also have to look at how the site pages themselves request site resources.

By modifying our site’s .htaccess file we can control website asset requests.   The .htaccess file is in the root directory of our WordPress site’s folder structure.  Let’s open this file in a text editor.  You should see something similar to picture below which shows a typical .htaccess file.

Typical WordPress .htaccess file
Typical WordPress .htaccess file

This is the standard .htaccess file that is installed with any new WordPress installation.  First, the file checks whether the mod_rewrite.c module is enabled on the web server.  If it is, .htaccess filters all requests coming to the server through this set of rules before the server processes and responds to them.  Basically, this tells WordPress to send any permalink request to index.php for processing, and if the request is already for index.php, ignore any further processing.  What we need is a way to determine whether requests are coming in over HTTP (unsecured) or HTTPS (secured) and to force any HTTP requests to come back using HTTPS.

 

Secured and Unsecured Traffic

Practically everybody has heard the term, “Information Highway.”  Let’s take that a little bit further.  Think about all the request traffic coming into your website on this information highway and picture toll booths in front of the web server much like toll booths on a tollway.

I realize this probably oversimplifies the reality, but it’s a good analogy for any nontechnical readers out there.  In a real tollway, you will see different lanes for different traffic.  Vehicles with more than 2 axles take the center lane, vehicles with only 2 take the right, and Toll-Pass customers breeze on through the left lane – You get the picture.

Web traffic comes into the web server on different lanes also.  We refer to these lanes as ‘ports’.  Specifically, unsecured web traffic (HTTP) generally comes in on port 80 and secured web traffic (HTTPS) usually comes in on port 443.  (These are default settings that providers may, depending on the situation, change to meet security requirements.)

What we need to do then, is to identify any traffic NOT coming in on port 443 and redirect it to the secure lane.  To do this, we rewrite unsecured requests as they come into the web server.  We rewrite these requests with directives in the .htaccess file.

Rewriting the Request to Use the Secure Channel

Using 301-Redirects in .htaccess
Using 301-Redirects in .htaccess

Since we want ALL requests, whether they originate externally or internally, to use HTTPS (port 443), this will be the first thing we check for in our .htaccess file.  In the image shown to the left, consider the two highlighted lines immediately beneath the line that reads “RewriteEngine On.”

The first line, “RewriteCond %{SERVER_PORT} !^443$” tests to see if the incoming request to the web server did NOT come in on port 443.  If that is true, then the rewrite rule immediately following the test redirects the request to the secure HTTPS port.   The ‘L’ flag at the end of the rewrite rule tells the processor to stop executing any further rewrite rules found in the file.

When the request comes back in on port 443, the .htaccess file sees that the request doesn’t meet the initial condition, so it continues with normal processing of server requests.

Once you have added these two lines to your .htaccess file, save the changes and then upload the changed file back to your web server using FTP.  Now it’s time to test our changes in the next step.

Confirming the Changes

Go back to your home page in your browser and once again hit F5 on your keyboard to refresh the page.  If all is well, the browser no longer displays the dreaded eye in front of your URL.  Instead, it happily replaces it with the safe, green padlock that gives the world warm assurances that it can safely interact with your website.

If you still see the dreaded eye, the chances are that WordPress is caching certain resources to improve performance.  Not to worry though, the next section discusses how to clear this cache and set things right.

 

Clearing Cached WordPress Resources

Now that we’ve secured the public and private areas of the site and secured internal resource requests, we’re firmly standing on solid ground in our quest to convert an existing HTTP WordPress site to HTTPS-only.  However, sometimes we can complete all of the steps in the previous sections and still see the dreaded eye:

 

The dreaded eye
The Dreaded Eye on Your HTTPS Site

 

Many WordPress websites use plugins to speed up and improve the performance of the website.  Rather than retrieving common site elements from the hard drive, we improve performance by storing these elements in memory. Unfortunately, at this point, some of these elements in the server memory are living on unsecured connections.  To completely convert an existing HTTP WordPress site to HTTPS-only, we need to ask these elements to pack up and move to a safer neighborhood.  In the section below, I’ll give an example of clearing the cache for one of the most popular plugins, W3-Total-Cache.

Clearing Plugin Caches

Two popular plugins used for improving WordPress website performance are W3 Total Cache and WP Super Cache.  If either are in use, we need to log in to the dashboard and the clear the cache.  Clearing the cache removes any lingering resources in memory that still live on unsecured connections.

For W3 Total Cache, mouse over the ‘Performance’ link at the bottom of the admin navigation menu and select ‘Dashboard’.  Open this dashboard and click on the ‘Empty All Caches’ button.  This will be located at the top of the dashboard on the left side.

W3 Total Cache
Clearing the W3 Total Cache

If you are using a different caching plugin to optimize your website, check with the developer’s page if you need assistance clearing the cache.

For the most part, the first four steps above should complete the steps needed to convert your existing HTTP WordPress site to HTTPS-only.  However, certain cases require a little more work.  The last section of this article addresses these situations.

 

Identifying Remaining Issues

In some cases, especially if you have performed numerous appearance customizations on your WordPress theme before converting your website to HTTPS-only, even completing all of the steps above will not remove the dreaded eye.  In these cases, we have to dig a little bit deeper.

So, the first thing we can do to get to the bottom of it all is ask the browser itself!

I use Google Chrome and Firefox for virtually all of my browsing.  As this is what I am most familiar with, I’ll be “speaking Chrome” as I go through the following steps.

With the dreaded eye on the address bar staring right at us, we can open the Chrome Developer Tools (Dev Tools) in the browser to look for a quick fix.  Do this by pressing CTRL+SHIFT+I (or F12) on the keyboard.  This opens the Dev Tools panel in the browser.  Fortunately, Dev Tools allows us do many wonderful things and can be a great help in our quest to convert an existing HTTP WordPress site to HTTPS-only.

Using Developer Tools to Identify Issues

However, since we’re presently concerned with website security, we’ll click on the Security tab at the top of the window.  This will give us some initial information regarding the security situation on the website.

 

Chrome Developer Tools Security Tab
Chrome Developer Tools Security Tab

 

The first thing that should catch our eye is the ominous message at the top of the Security Overview telling us the page is not secure. But this page also tells us 3 other things:

  1. The site has a valid SSL certificate, which is great.
  2. The connection to the server is secure, which is also great.
  3. BUT, the page is serving ‘mixed content’, meaning it is serving HTTP (unsecured) resources over the HTTPS connection.

We also see a suggestion to reload the page to record requests for HTTP resources.  If we follow this suggestion, we can narrow things down a bit more:

 

Chrome Dev Tools Mixed Content Warning
Chrome Dev Tools Mixed Content Warning

Viewing Mixed Content Errors in the Network Panel

If we want to successfully convert an existing HTTP WordPress site to HTTPS-only, we have to make sure the site is not serving up mixed content.  This means all resources have to be requested via HTTPS.

We can view the unsecured resource requests by looking in the Network Panel. When we click on the link, we find the culprit is the website’s header background image.

 

Chrome Dev Tools Network Panel
Chrome Dev Tools Network Panel

 

If we click on the ‘index’ link shown in the above image, Dev Tools will open the downloaded copy of the file that is currently residing in the browser.  Performing a search for ‘http:’ shows where the index page requests this file.  Sure enough, the page requests the file over HTTP and not HTTPS.  The clipping below shows this:

 

Chrome Dev Tools Code Inspect
Chrome Dev Tools Code Inspect

 

Now, knowing WordPress like I do, I know the system stores this value in a mystical place in its database.  Things like this can make the task to convert an existing HTTP WordPress site to HTTPS-only a real challenge.

The accepted way for customizing headers and such on WordPress themes is to use the appearance customization screens in the WordPress Dashboard.  When you apply these customizations, WordPress stores the information in the database. In this case, the header was customized before the site addresses in the General Settings were changed to use HTTPS.  Therefore, the full path to the image file was stored with ‘http://’ on the front of it instead of ‘https://’.

A detail this tiny can be all that is still causing the dreaded eye that makes us flinch every time we look at our website home page.  Fortunately, for this particular case, the fix is an easy one.

Luckily, It’s an Easy Fix!

WordPress websites store the path to the header background image file in the WordPress database.  Specifically, in the wp_options table.  The issue is not with the header background image itself, but with the way the access to it is recorded.

There a a couple of different ways we can address this, but the easiest way to correct it is to use the appearance settings in the WordPress Dashboard.

Now that we are running on HTTPS, we will simply change the header background image to a different image, and then change it back to the desired image.  We do this from the dashboard navigation menu.  Go to Appearance -> Customize -> General Settings -> Header Settings.  Once there, click on the ‘Change Image’ button.

Changing the header image in WordPress
Changing the Header Image

Now, select any image from your Media Gallery (or upload a new one) and click on the ‘Choose Image’ button in the bottom right.  Click on the ‘Publish’ button at the top of the customization panel to save your changes.

 

Publish the new header image
Publish the New Header Image

 

 

Finally, return to your home page, and hit the F5 key to refresh the page in the browser one more time.  Once you’ve verified that the dreaded eye is finally gone and has been replaced by the lovely green padlock, and all is well in the world, you can change your header image back to the original.

Your final result should be along the lines below and everybody is happy now because this quest to convert an existing HTTP WordPress Site to HTTPS-only is over.

Secure Site Home Page
Serving up a nice and secure site over HTTPS

One Final Note

Depending on how long your site has been running on an unsecured HTTP connection, and how many customizations have been made to it, you may not be so lucky as to only have to run down one measly header image request to wrap things up.

If the Dev Tools Network panel shows multiple items being requested via HTTP, each one of these have to be chased down individually.  Their causes determined, and fixes implemented.  This can turn into a daunting task.

I have even read books on SEO suggesting that it is easier to scrub a site and start from scratch using HTTPS.  However, I find that notion quite radical.

If you have any trouble, feel free to give me a shout!  Either leave a comment below or drop me a line using my Contact Form.  I will be happy to help.

If You’ve Gotten This Far

If you’ve reached this point of the article, I’d like to first thank you for taking the time to read all the way through it.  I realize it’s quite lengthy, but there’s so much that can be covered here.

By now, you’ve seen that the job to convert an existing HTTP WordPress site to HTTPS-only touches on some different but related areas.  In conclusion, we can boil all of this down to 5 steps:

The 5 Steps to Convert an Existing HTTP WordPress Site to HTTPS-Only

  1. Making sure the log in and admin pages of your site use the HTTPS protocol.
  2. Making sure all public areas of your site use the HTTPS protocol.
  3. Securing website asset requests with the .htaccess file.
  4. Clearing site performance improvement caches.
  5. Finally, resolving possible theme customization issues.

Thanks again for reading, and Have a Great Coding Day!

 

Please follow and like us:

Leave a Reply

Your email address will not be published. Required fields are marked *