A new website — porting with WP Migrate DB Pro

This is a continuation of a series of posts about reworking my website into one that is entirely WordPress based. The series starts here:

A new web site – general requirements

After about 30 hours of back and forth emailing with the VaultPress support staff, I gave up on using them for migration. At first, they didn’t understand what I was trying to do, and sent me messages verifying that I was trying to do migrations that were different from what I intended, including one that involved a WordPress installation that is protected — I’m going to keep on using that word in spite of my recent experiences, because I think that restorations to the original site would probably go more smoothly — by VaultPress, but is neither the source or the destination of this migration. There we also emails telling me to consult documents that I’d already consulted, and to do things I’d already tolsd them that I’d done. The fact that there were three techs involved, and that they didn’t appear to be communicating with one another didn’t help. Also, there was some resistance to clicking on the link I provided in my original query that explained in detail what I was trying to do and what I’d done. I’m not sure why that is; in the blog post I was able to provide screen shots and context that I couldn’t by filling out thier web form.

So I decided to try another way. It is easy to use ftp to move the appropriate directories and files from kasson.name to a subdirectory in kasson.com, so I set up yet another WordPress instance in kasson.com/wp1 and copied all the relevant files over. That just left the database. After poking around for a while, I found a tool called WP Migrate DB Pro that let’s me do the database migration, and also handles the changes to the directory structure from the source to the destination site. I picked this software — it’s a WordPress plugin — because it does the transfer of the information directly from the source to the destination site, which provides a  remarably seamless user experience.

I installed the plugin on both the source and destination sites, and told the source site that it was going to be pulled from. I copied the secret identification string from the source site, went to the destination site, and told the plugin that it was going to be pushed to, and where the source site would be. Entering the source site’s secret code gave an element of security at this point. Then I told the destination site to pull the database from the source. Lesss than a minute, and about 10 MB of tables, later, the job was done. However, I got a warning:

Both WordPress installations were setup for possible multisite operation, which is why there were table prefixes. In the original message, the table prefixes weren’t grayed out. I did that for security. Actually, I’m not sure how they would be of any use to a hacker, but I’m green enough at this WordPress stuff that I’m erring on the side of safety.

I navigated to the kasson.com/wp1 site before I changed the database prefixes just to see what would happen. Lo and behold, I got the initial WordPress install configuration, complete with the “Hello, World!” post. I changed the database prefixes, held my breath, and reloaded the site. There was my home page in all its beauty, complete with rotating teaser slide show. Wow! Flushed with success, I clicked on the menu entry to one of the galleries. Oops, a 404 error.  All the pages were that way. I went into the admin console, created a brand new page called “Delete Me”, and tried to navigate to the permalink. No dice.

After an embarrassingly long time — we’re talking hours here — of looking at files and making tweaks, I discovered this link. Can’t hurt; might help, I thought. I dutifully went to Settings » Permalinks, and clicked on “Save Changes”, and everything worked. At least all the things I tested worked; I haven’t gone through the whole site. A friend of mine at the IBM Almaden Research Center once said; “Half of computer science is caching.” Things like this make me think he could have been right.

Now I have to make sure my paid plugins are happy, change some of the links on my other blog sties, including this one, and test some more. When I’m happy, I’ll change the index.php file in the  kasson.com web root directory to start the WordPress instance in kasson.com/wp1.

Wish me luck.

PS. I went back and looked at a page that was full of links to the source site, figuring that those links would still point there and I’d have to change them all. Surprise! They now pointed to the new site. Thinking about it, that makes sense: the links weren’t in html code, but in the WordPress database, so they got changed by WP Migrate DB Pro during the migrations. Still, this WordPress amateur is impressed.