How to fix SSL & caching issues with your WordPress site

Web browser icons

I noticed something odd this morning after sharing a recent article from this blog. For some reason, theme assets like stylesheets and certain images were loading using http:// instead of https://, which I found strange because I’m pretty careful about keeping such things in mind when theme developing.

It turns out that, yes, I was getting a security warning and some assets weren’t loading, but it turned out the bigger problem was caching. Well, kind of both, but for the purposes of this article, let’s focus on the latter and how I managed to (eventually) resolve the problem.

Find the problem causing the security warning

After inspecting the offending page, it turned out that my sidebar.php template file had one asset that was using http://, so I corrected that and replaced the file on the server. Then, I reloaded my browsers. The fix only seemed to apply on Chrome after doing a hard-refresh.

This at least verified that I was now dealing with a caching issue and resolving that would take care of the associated security warnings, but just to be sure, I decided to go a little further…

Forcing https in theme files

You really shouldn’t have to go this route, but you can also add a filter to force any URLs in your template files where you’re using the function to use https. Add the following to your functions.php file this will ensure that links to your assets are using a secure path.


add_filter( 'template_directory_uri', function( $original ) {
    $output = preg_replace( "/^http:/i", "https:", $original );
    return $output;
});		

Again, not necessary, but a little extra covering of one’s hiney isn’t always a bad thing.

Now back to this caching problem…

Manually empty the cache

I’m using the W3 Total Cache plugin, so the first step of course is to manually flush my site cache, which typically solves such problems.

W3 Total Cache empty cache screenshot

Before doing this, I made a minor change to my sidebar template file to see if it loaded after emptying the cache. It did for some pages, but not others. In this case, the result was bupkis. Something else was going on.

Double-check WordPress site settings

It doesn’t hurt to rule everything out, no matter how smart and/or thorough you think you are. In the WordPress dashboard, go to Settings > General and make sure that the two fields containing your site URL begins with https://.

WordPress General Settings screenshot

Everything checked out here as well.

The universe seems to hate me.

Eureka! Behold the mysterious, server-side culprit!

Before biting the bullet and contacting my web host, I decided to FTP in to my site and check out the lay of the land for anything peculiar. Wouldn’t ya know it, within my site’s wp-content directory was this folder called endurance-page-cache. As it turned out, this was a folder containing cached versions of my pages and files that was part of a caching system provided by my hosting provider.

Bluehost endurance page cache folder

I hadn’t noticed this before, so I decided that with nothing to lose, I renamed the directory to endurance-page-cache-old to see if it made a difference.

That was it! My ego hath been restored!

A little further research led me to believe that this is not uncommon with some web hosts and if you’re already covering your bases with caching on the WordPress side, you can either log in to your Control Panel, locate the caching service and deactivate it, or contact your host to have them do it for you.

Share this:
My big, fat head

About

I'm a front end developer and designer specializing in WordPress, User Experience, SEO, and have been working with businesses of all sizes since 1999 in helping build web properties that gets the job done.

Subscribe! You know you wanna!

Get new articles from my blog sent directly to you via email. You know the drill, send me your details and you're in.

Discussion