Jake Charman

Resident Geek of Nitrous Junkie Racing



How I run a fast, HTTPS enabled WordPress site for free (nearly)

Sat 12 Aug 2017


First off, before people disappear because of that ‘nearly’ in the title, I pay £7 a year for a custom .co.uk domain. If you wanted to go truly free however, there are plenty of people around who will give you free use of a subdomain. Just be aware that some have been called out for having some fairly questionable business practices, one particular case that springs to mind is a certain provider parking domains as soon as they gain significant traffic.

Now back to the subject. I’ve seen a lot of people talking about the cost of HTTPS, this post by Troy Hunt shows a couple of those people who seem to think they HTTPS is expensive to implement and slows down pages. I am here to prove the opposite.

I don’t get paid for writing this blog, the most I’ll ever do is add Google AdSense to it but I need to properly finish building the theme first. For that reason, I have to keep the running cost to an absolute minimum and I feel I’ve succeeded since everything except the domain name is free. I achieve this using a mix of services which all provide a particular piece of the puzzle, the first is the CMS. WordPress.org is the self hosted version of WordPress and gives you more control as well as giving your users an ad-free experience at no cost to you. WordPress requires PHP and MySQL to run, this brings me nicely onto OpenShift.

OpenShift is cloud hosting from RedHat, they give you 3 applications for free with a few limitations. First of all, you’re limited to their least powerful offering and only one server location, not a huge problem for a small site, especially since we’ll solve any speed issues later. Another limitation is that the app must receive traffic regularly or it will suspend causing the next viewer to have to wait for the VM to spin up again. In my experience this is not acceptable from a user point of view as it sometimes takes so long it causes the browser to time out. The main issue for our use case here is the lack of HTTPS for custom domains, however, what makes this possible is support for HTTPS using the standard subdomain provided by RedHat. It’s worth noting that I’m using OpenShift 2, these offers may change with OpenShift 3. While there is a click to deploy type thing for WordPress, it will be useful to have some knowledge of Linux before trying to set up OpenShift. Namely some knowledge of SSH (using key based authentication), Git and basic file operations. A little knowledge of symlinks will help too when things break.

CloudFlare is the final piece of the puzzle that ties everything together. I replaced my nameservers in my GoDaddy control panel to allow CloudFlare to fully manage my DNS records. Firstly, the caching in CloudFlare solves any issues with speed and seems to request a new copy from the origin often enough to keep the application running. Because OpenShift supports SSL for the standard subdomain, a HTTPS connection to the origin is possible but returns an invalid certificate so shows a HTTPS error in the browser. However, we can use the full SSL option in CloudFlare to provide a valid certificate. There are better people to explain how this works (I’m by no means a security expert) but the simple explanation is that the browser connects using SSL to the CloudFlare edge node for the site using the valid certificate from CloudFlare. CloudFlare then forward this traffic on (still using SSL) to the origin where CloudFlare receives an invalid certificate instead of the user. Obviously this process changes depending on caching.

From this point some setup is required in WordPress otherwise you’ll get redirect loops in the admin panel and lock yourself out (like I did… Multiple times). I’m using two plugins, the official CloudFlare plugin and a third party one called CloudFlare Flexible SSL. These two plugins fix the redirect loops and in theory fix any mixed content warnings. However, in my case I had to manually fix some issues with my theme to stop the mixed content warnings. The Chrome developer (f12) tools are a great diagnostics tool to find out which resources are still loading over HTTP.

Assuming this all went to plan, you should have a nice, green padlock in the URL bar and a fast WordPress install below it.

This method should work on static content served using the PHP server in OpenShift too, although for this purpose I’d reccomend GitHub Pages as you can use the full (strict) option in CloudFlare or ditch CloudFlare all together (not that I’d reccomend it, the caching is excellent alone).

 

EDIT: The OpenShift related parts of this post are no longer true as of September 30th. OpenShift V2 is being shut down and the free offering of V3 does not give enough disk space to run a WordPress site. For this reason, I’m now using a paid hosting provider.