TIB Has Moved – The Migration Experience to WordPress 3.0

For good or for ill, I’ve moved TIB over to WordPress 3.0 multi-site. What does this mean? For you guys, it pretty much just means that instead of typing “http://cjcs.com/tib” you’ll be typing “https://tib.cjcs.com”. Hopefully that will be the only significant inconvenience you’ll have.

tib.cjcs.com

As I’ve mentioned in other posts, the move to having all of my WordPress sites running off of one code installation was more for my sanity than anything else. Now I only have one code base to administer instead of several. Day-to-day, this isn’t much of a difference. When update time comes around — either with WordPress or its plugins — it can be a major headache.

So as to make things as easy as possible, I’m redirecting all of the requests from the old site to the new one. That means your links should still work–though I do recommend updating them at some point.

The one thing I have no control over is whether your passwords made the trip unscathed. I did the best that I could with them. My tests worked fine, but who knows? I’m hoping that, at worst, you’ll have to create new passwords (but what I’m really hoping is that they still work).

I did rewrite the theme. I used the new WordPress theme, twentyten, as the new theme’s foundation. I tried to make it look and function as close to the previous one as I could, but there will be some differences here and there. Plus, it’s going to change during these first days as I tweak and correct some things that either slipped through the cracks or that I simply haven’t gotten to, yet.

There were a couple of comments and forum posts made to the other site after I’d moved the database over. I’ll try to transfer those manually.

Nuts and Bolts

I used the procedure I outlined in a previous post to transfer the old data into the new database. As I’d practiced several times on my development machine just prior to the move, this core move was uneventful. But that’s not all the database stuff I needed to do.

On the old site, the thumbnail images were created using a custom field and then hooking into that from the theme. Since WordPress has had thumbnails (now “featured images”) for a point-update or two, I decided that now was the best time to migrate over to core functionality.

I wrote some SQL to transfer the information my custom field had stored in wp-postmeta and convert it to the featured image format. That actually went surprisingly well… until. Yeah, I discovered that not everything migrated. At first, I wasn’t sure why. When I was going through and manually doing the conversion (fortunately there were only a few dozen posts affected), I realized that the error occurred when a thumbnail was used for more than one post. Wish I’d have noticed that sooner; I could have taken care of that with an SQL tweak.

That wasn’t the end of my fun with the database. I still had to migrate my forum. Turns out that Simple:Press Forum stores user information in four tables in their database tables. I needed to go in and convert the old user numbers to the ones that are stored in the common user table in the new WordPress. I knew that situations like this would occur which is why I retained the user translation table from the initial data move. There was a small problem in that my administrative account wasn’t where SPF thought it was, but it was a quick fix.

Once the database was squared away, most of my attention turned to the theme. I mentioned my transition from custom-field-oriented thumbnails to using featured images. In an interesting twist, I stumbled across some code pertaining to custom fields that allowed my life to get easier.

With The Connor Wars, in order to preserve the screenplay format, I posted the scripts as pdf files. Thing is, the WordPress editor doesn’t play nice with pdf files. If you are working in the HTML code section, it’s fine. The code needed to wrap around the pdf file stayed just as I’d written it. Unfortunately, if I happened to flip over to the visual part of the editor, it would filter the wrapper code and break the pdf presentation. I worked around it by creating a special account where the visual editor was disabled–that way I wouldn’t accidentally corrupt my wrapper code.

Needless to say, this was a little annoying, having to logout and log in again just to post a script. Well…enter the code. I found a post where a workaround for WordPress’s infamous iframe problem. With it, you store the problematic code in a custom field and then use a shortcode to reference that field in your post. I figured if it would work for iframes, why not for my little problem? So I made a plugin from the code and tried it out. Huzzah! It worked! I then edited all the script posts to take advantage of this. It made me happy. PLUS, if/when I stumble across an iframe I want to embed, I’m all set.

The last step in the exercise was posting a new .htaccess file in the old directory so that all attempts to access those posts/pages/etc get redirected to the new site.

There were/are a few more things to do, mostly concerned with changing URIs at outside sites, but that’s just normal admin stuff.

So…I hope the move is relatively uneventful for y’all. If you come across something snarky–especially something that used to work before–let me know.