Proxy-set-header: Forwarding HTTP headers from Nginx to a WordPress container

I detailed in a recent post how I got a working WordPress container setup, complete with database and PHP engine. I saved the bit about how to redirect traffic to the container (and apply encryption to the outbound connections) because I knew it was going to be just as much work as getting the setup running. Also I needed to first get up to speed on HTTP headers in general and how to inspect them specifically.

This post is not a how-to any more than it’s a how-not-to. I wanted to detail as much the attempts that did not work as the final one that did because the former were just as illuminating as the latter.


Moving site: Using MySQL to search-and-replace WordPress domain name

It seems that the recommended way to change the references to the domain name in MySQL on a WordPress install is to take the whole thing offline and do it by using text tools on a database dump. Either that or change the settings in WordPress while the site is still live on the old domain.

It was too late for the latter and I could not be bothered to do the former – partly because I had just gone through the whole mysql dump routine, partly because the site I wanted to move was only one among a number of sites contained in the dump. While the web server was all set up to use the new domain name, WordPress persisted in redirecting me to the old.

So I looked at the recent database dump, figured out what tables and fields to target so that I could replace the domain name on a live install.


WordPress on Docker: The 1-2-3 approach

There’s an official WordPress docker image on the hub. Which means I have no good excuse to go make my own. Here’s my bad excuse: The official approach contains Apache and WordPress files all mashed up in one image. This feels icky to me partly because I don’t know Apache, having decided early on to hitch my wagon to Nginx, partly because it feels un-containerly to have everything in one big pot.

I cannot argue the merits and demerits of the official image with regards to performance, scalability, or security. What I saw was an opportunity to solve the problem in a way that felt more correct to me – 1 network, 2 volumes, 3 containers,  – that would also work as a learning experience. Here’s how I did it.


Playing fast(cgi) and loose

Problem: On all my non-https enabled WordPress sites, the links to CSS and images were always https which meant they failed, rendering as pure html. Assumption: It’s either a WordPress or an nginx issue. Solution: Turns it it was neither but a bad fastcgi parameter. Lesson: Kids, don’t copy-paste fastcgi parameters.

Is Bolt CMS more than just WordPress Lite?

I’ve got blogs and I’ve got blogs.

That is to say, I’ve got three public facing blogs (this one, one on gaming and one general themed) and then I’ve got various things for my eyes only. Matt Mullenweg is quoted somewhere saying that he can with great certainty instantly recognise a WordPress site and I don’t think mine would be any exceptions. I have used WordPress for all my CMS needs so far but for various reasons – the most pressing of which was the need to run various services under the same shared https protected subdomain – I started looking elsewhere for some projects.