WordPress HTTPS Redirect Problem? Destroy it Like a Boss

The last time I had to update a WordPress website for SSL delivery, I thought it would be quick and easy. But a couple of things tripped me up along the way. I’ve documented my particular WordPress https redirect problem here, in the hope that you don’t run into the same issues I did.

Let’s get the obvious out of the way first

You’ll have to check your theme code for any references to http and update them. Pay attention to things like script and style calls. Make sure there’s no weird stuff going on with functions that use regex on urls, things like that.

Also remember to update your admin > options > general ‘site address’ fields. When it comes to updating your database, I’ve found the easiest way is to use the free better search replace plugin. This plugin also has a dry run mode, which is non-destructive to your database, if you want to test it out first. Personally I prefer to clone the site locally, and apply the changes to a copy of the database. Then you just swap out the databases on the server. Alternatively you could try Search Replace DB if you’d prefer a more hands on approach, which doesn’t require a WordPress installation. This’ll work on any local dev setup running PHP and MySQL.

Make sure .htaccess is right

This is usually the first stop for fixing a WordPress https redirect problem. Check that no other htaccess rules are goofing it up. This also might sound odd, but clear your web cache in your browser. I’ve found Firefox weirdly caches any htaccess config settings, (although I think it’s more to do with it caching the redirects). Seriously.

In my case, I needed to make sure I was always pointing to www with https turned on. I found this to be my best set up:

RewriteCond %{HTTP_HOST} !^www\.(.*)$ [OR,NC]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.mydomain.com/\ [R=301,L]

My chops with htaccess has never been amazing to be honest, so props to Daniel Morell for making htaccess writing super easy.

Check other plugins aren’t interfering

My main issue related to a caching plugin I was using, called WP Fastest Cache. I couldn’t seem to get htaccess working quite right, and it was down to how I was using the plugin. I had do the following – in this order – to get it working:

1. Deactivate the plugin.
2. On the admin page where I set the ‘site address’ fields, save it. I didn’t need to change anything, saving just gave the whole thing a ‘kick’.
3. Reactivate the plugin.

Turned out that the plugin was adding it’s own set of rules to the htaccess file, but also it was making use of the WordPress admin site address fields somehow.

With this in mind, you should make sure you have no other caching plugins which could affect your urls or htaccess rules.

I made sure this block of code was at the very top of my htaccess file (above the previous rules):

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^www.mydomain.com

I’d also check that there are no other plugins interfering with links, ones that use url re-writing, change the permalinks and so on. Of course, all this is based on the assumption that the site uses www as a subdomain. But who’s using that anymore? That’s such a 90’s thing. Now I’d use this at the top of my htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

wp-config

One last thing I normally add to an SSL enabled wordpress site is this:

define('FORCE_SSL_ADMIN', true);

// Or, for any login user, not just admin
define('FORCE_SSL_LOGIN', true);

Which will help with security by preventing login without https enabled. On a related post, I discuss how to reduce the likelihood of a hacked wordpress website. Because, frankly, WordPress sometimes gets a bad rep.