Securing your self-hosted website with Let’s Encrypt, part 6: WordPress considerations

In part 5, we looked at the great things you can do when your website is running over HTTPS, but we didn’t get into specifics of which type of website and the particular considerations you should have in mind.

There are so many types of websites that I am not going to start looking at all of them because that would probably end up being the work I do until the end of my days (exaggerating, me??). But I will look at a very popular type of website with which I have hands-on experience–WordPress!

Before migrating my blog to HTTPS, I created a brand new installation of WordPress in a subdomain–just to make sure it would all be working correctly. It all seemed fine, so I then tried migrating my 10 years old WordPress blog, and see what happened and… it was mostly fine too.

The short story is: there are not many differences between running WordPress or any other site under HTTPS.

It has a really predictable behaviour… and that’s good!

There are just a few minor details worth considering

WP’s Admin uses iframes for things such as showing plug-in details, which might interfere with strict X-Frame-Options settings

Mind you–the iframe is actually coming from your own WP website, so it’s not that it’s trying to embed a page from wordpress.org into your admin. But if you set up the strictest of X-Frame-Options, with DENY, you will be denying even your own site to be iframed on itself, and you won’t be able to install plugins via the admin area at all.

If that’s what you intend, keep using

X-Frame-Options DENY;

but if you just want to make sure your site is not embedded somewhere else, this should be enough:

X-Frame-Options SAMEORIGIN;

When moving from http to https, update the WordPress Address and Site Address URLs, or plugins using WP_PLUGIN_URL might break

WordPress does quite a good job nowadays of detecting which URL it is being served from, but some plugins might use the WP_PLUGIN_URL constant to build the path to their assets (e.g. CSS or JS files), and since that setting comes untouched from the database, they will use an http:// path – triggering Mixed content warnings in your browser.

So, remember to update those two settings to use https:// urls!

If using Super Cache, empty the cache, or already cached files using http:// will be served

This should be explanatory: empty the cache to avoid files that contain http:// references being served. If you’re using Strict Transport Security, the impact will be lessened, as the browser will turn http:// links into https://, but it’s possible it will also display a warning or two as well 😉

And now it’s time for some goodies!

My colleagues at Mozilla have been busy building a few WordPress plugins that enable your blog to take advantage of HTTPS-only advanced JavaScript features such as Push notifications without having to implement them yourself.

It’s install and go!

Next part: a workflow for migrating from HTTP to HTTPS.