Monthly Archives: July 2014

I had half an hour of personal downtime last night, so I thought I’d have another bite at the ‘migrate the TLD website and trailing sub-domain blog from Arizona to my state of the art data centre (haaaahahaha) in my lounge.

I’d researched the WSoD problem that WordPress had presented on the previous attempt to migrate the blog (the common fault seemed to be either theme-related or plugin-related), and decided on a cunning course of action:

• Leave the MariaDB database and associated user that I’d created for the previous migration intact on the NAS
• Move *all* of the WordPress files/directories that I’d brought over from Arizona to a new temporary directory 
• Download a vanilla WordPress package
• Install the vanilla WordPress package in to the blog trailing sub-dir, and see what I got

What I got was the usual WordPress install screen; it prompted me to enter enter the config details for the database and user.

I entered the details as I had configured during the previous attempt, and what I got was a WordPress error message: theme style sheet missing.

I went in to the admin screen, selected and loaded a native WordPress theme, and a native version of WordPress loaded in the blog’s location.

I then downloaded and installed the latest version of the Mantra theme (my preferred theme), and checked that the site loaded.

It did.

I copied back in to the wp-content directory all of the old blog content (but not the themes or plugin sub-dirs) from where I’d moved them in the temporary directory.

And everything worked – the blog loaded in its customised theme/design, and with almost the entire range of content.

Bizarrely, a couple of photos have gone AWOL somehow, but they are in the minority; just about everything else was in place.

The logical explanation is that something went wrong in the migration of content from Arizona to my NAS.

Except it can’t be that simple, because when I hit the problem the other day, I took, and deployed, a second data migration – and hit the same problem.

It was at that point that I backed out of the previous attempt to migrate (a backout plan is always a good thing to have!).

So I’m puzzled as to what may or may not have occurred during the first migration, but I’m not going to lose any sleep over it.

It was a bizarre fix to an unknown problem, but the fix worked.

I wanted to move my TLD and blog (resides in a trailing sub-dir) from Arizona to my state-of-the-art datacentre in my house in Rugby, so:

1. I backed up (and exported to my local hard-disc), the MySQL databases for the TLD and for the blog.
2. I FTPd the content plus WordPress files from Arizona to my local hard-disc.
3. In phpMyAdmin I created two users and an associated database for each user
4. I imported the exported MySQL databases in to each new instance (both completed with non errors)
5. I created the webspace on my NAS, and copied the WordPress files plus content in to it – changing the wpconfig.php in both the TLD and the blog sub-dir for the user details I had created in step 3.
6. I logged on to the domain admin panel and changed the root IP address from the Arizona datacentre to the Rugby one
7. Waited

After about 10 minutes the TLD had completed the propagation; I had full navigation being served up by the Rugby environment.

However the blog sub-dir failed: when I tried to access it I just got a blank screen of whiteness.

I dropped all of the tables in the database and did another import (which completed successfully).

And got the same white space.

So I deleted the MySQL database and the user, and tried to access the blog – and got a Database Connection error message, which is what I’d expect.

Then I created a new database to match the same credentials I’d created in the wpconfig.php file, and imported the old MySQL database again.

It failed once more; same white screen.

Hmm.

This needs thinking about.

I have temporarily closed down Server 1 and Server 2, and transferred all data and functionality to the NAS.

Reason for this is twofold:

1. I’m going to install VMWare on Server 1, and clone my laptop in to a virtual desktop on Server 1
2. I’m going to install VMWare on Server 2, and configure it as a virtual hosting platform

The reason for 1. is because I have some audio production software on my primary laptop which is no longer available. If the laptop should suffer a critical failure (and I’ve had three of those in the last 12 years), I would lose that software and lose the unique goodness that it gives me. But if I virtualise the laptop on to a Raided VMWare server, then the laptop and its applications should be protected, yes?

The reason for 2. is just because I’d like to set up virtual servers, to see how easy the initial stand-up and config is, and look at the management overhead of running virtual hosts.

Although I’ve kicked off these tasks by migrating the content from Server 1 and Server 2 to the NAS, the actual installation/stand-up and config of both virtual environments is going to take a while to complete.

Not because they are long, complex tasks (they aren’t particularly complex), but because I have a hectic, complex calendar, with scant spare capacity for such leisure-time geekery.

I’ve just bought a 3Tb Seagate USB3.0 storage disk for £87.

Three terabytes?

For £87?

I know, that’s just bonkers.