Yesterday afternoon, whilst configuring my Kubernetes cluster to use SSL certificates (see Installing & Configuring Traefik with SSL certs), I managed to screw up this blog hosted on that same cluster. Just about every part of the site was broken. I could not believe that the URLs within the content management part of WordPress are stored with the full site URL. I mean, what happens if you go from HTTP to HTTPS or if you change the URL in some way. This seems like a poor design in this day and age and caused me quite a problem.
I couldn’t get into the site to update the URL, and I couldn’t even view the site properly as just about every URL, CSS reference, redirect, etc., goes to the old setting despite the site being hosted and accessed using the new URL. Have they not heard of relative URLs or storing URLs with tokens for the base address?
Anyway, the only way I could fix the problem was to connect to the MySQL container and update the database directly.
My blog is deployed as two containers – one for the WordPress application and another for the MySQL database. The manifests define the user and password for database access as a Kubernetes secret – albeit base64 encoded and, therefore, not exactly a real secret.
So the first thing was to exec into the container. For this, I simply used Lens – this connected and provided a simple command line: –
I then had to connect to the mysql instance. For that, I needed the username and password from the Secret within Kubernetes.
The secret looks like this: –
apiVersion: v1
kind: Secret
metadata:
name: mysql-pass
type: Opaque
data:
username: c2Zxxxxxxx==
password: c2ZibG9nc3BhcxxxxxxxI took the username and the password from above and pushed them through a base64 decoder at https://www.base64decode.org/ to decode them.
Armed with these, I then logged onto the MySQL instance using this command: –
mysql -u root -p wordpressAfter entering the above command and pressing Enter, I was prompted for the password from the secret.
There were then a few MySQL commands to enter to update the old URL with the new ones, as shown below: –
UPDATE wp_options SET option_value = replace(option_value, 'http://www.oldurl', 'http://www.newurl') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'http://www.oldurl','http://www.newurl');
UPDATE wp_posts SET post_content = replace(post_content, 'http://www.oldurl', 'http://www.newurl');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.oldurl','http://www.newurl');Note that the semi-colon on the end of each line is required on MySQL.
Once these commands were run, the site still didn’t work correctly. This is because WordPress caches much of the data from the database for performance reasons. So, I simply deleted the WordPress container and had Kubernetes re-create it. Once the container restarted, much of the site seemed to work. Still, there were various problems until I deleted the cookies from the site in my browser(s) – I tried a few different browsers to get things to work before updating the database.
